传统模式是把软件开发分为软件需求、软件开发（设计&编码）、软件测试、软件发布等阶段，一般利用里程碑的方式对各阶段进行明确定义。软件测试是研发过程中的一个阶段，而且一般都属于项目的最后阶段；测试团队都是立场比较明确，与团队之间的沟通以正式为主；测试以需求为依据，要求有需求规格，自动化测试不作为要求；测试计划做得比较详细，对测试活动都会做好周密的安排；需求方确定需求后，中间环节参与较少。
在敏捷模式里，相对传统模式，软件测试不再是一个独立的阶段，测试是融入在软件开发过程中的一个组成部分，发生在每一次迭代中，也包含所有类型的测试，如单元测试、集成测试、系统测试、验收测试等。测试人员与开发人员工作更紧密，非正式的直接沟通成为了一种常态；测试以最终用户为准，辅以用户场景或用户故事作为测试的依据；测试追求快速高效，自动化测试在测试中扮演了及其重要的角色，敏捷测试人员辅以探索性测试跟踪核心业务场景；敏捷测试拥抱变化，测试计划比较灵活，按业务价值交付顺序执行；需求方需求定义后，参与每一次产品演示，确认每一次迭代产物，全程参与项目。
典型的敏捷软件开发过程
开发团队通过提供最小化可用产品获取用户反馈，并在这个最小化可行产品上持续快速迭代，直到一个相对稳定的阶段产品。在此过程中，敏捷测试人员快速验证团队的目标，快速试错。
降低软件质量风险
敏捷测试人员以专业的能力，引导项目全体成员开展测试，编写自动化测试用例，关注自动化测试执行结果，以稳定的每次编译及测试均未发现缺陷为目标。
节省项目研发成本
在一个敏捷迭代周期里，一般团队规模7~8人，敏捷测试人员至少2~3人，测试工作不在是一个萝卜一个坑，每个人承担的事情种类较多，要求的知识面更广泛，个人技术栈会越来越丰满，独挡一面的能力更强。
3.敏捷软件测试的经验分享
经过普元多年敏捷测试的项目实施，要支持产品的快速迭代，达到敏捷测试的预期效果，我们重点在以下几个方面开展了工作。
组织文化的改变
从项目特点来看，敏捷是属于“强项目型”管理的方式，但敏捷人员可以在自于静态的职能组织或将测试人员整合到敏捷项目中。
无论人员来自哪里，在敏捷团队中，测试和开发同属一个项目，大家的目标是一致的，敏捷测试人员在质量思想方面影响团队的其他成员。如测试人员可能会帮开发人员评审代码，开发人员也会帮测试人员进行测试，人员角色的职能可以模糊化。
敏捷测试团队还需要把客户纳入到组织中，学会一起工作并建立起彼此间的信任，一起做好软件的质量保证。
获得领导支持
测试人员需要了解敏捷，掌握敏捷的基本知识和原则，从而才能在整个敏捷体系中更快的融入到敏捷环境中，从而更好的开展整个测试工作。
测试工作不再是软件功能实现后再进行，而是测试工作前移，功能实现前就已经对测试做好规划，做好测试用例的设计及准备，等待测试的执行。
建立有效沟通方式
敏捷测试要取得好的效果，CI、CD及CT3是必不可少，缺少任何一项，整个流程就会不顺畅，效果也就大打折扣。
但要做好这CI、CD和CT，除了需要合适的工具提供支撑，还需要项目整体团队紧密协作。测试团队还需要具备一定的技术能力，在过程中提供驱动力，推动整个过程有序进行。
持续集成
自动化部署
自动化测试
回到测试的本质，作为敏捷测试人员需要做好敏捷测试的知识储备，无论是测试基础知识还是测试的技术技能，个人都需要考虑提升，组织上需要为个人提升打开空间，组织相关的培训，与行业先进测试理念接轨。
团队内部要经常进行团队分享，需要传道。对于敏捷测试的新思维，如果没有进行相关培训和了解，会让具体执行人觉得没有底气。同样，敏捷项目中测试人员在进行测试前也需要接受敏捷知识的培训。如果可能的话，最好是由具有丰富经验的敏捷测试教练帮忙进行指导，避免走错方向。
4.总结
敏捷软件测试不是独立存在的，它依赖敏捷的软件开发过程，强调的是敏捷项目团队的整体对质量的负责，测试团队不再是质量职责的全部。但敏捷测试团队需要以专业的知识驱动团队的质量意识，通过团队之间的紧密合作，实现敏捷研发的过程，快速推进业务价值的交付。
参考材料
1、维基百科的敏捷测试定义：
http://wikipedia.moesalih.com/Agile_Testing
2、Bill Wake INVEST规则：
https://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
3、CI：Continuous Integration（持续集成） CD：Continuous Deployment（持续部署）CT：Continuous Testing（持续测试）
相关资源：基于C程序的周易占卜软件_c语言算命系统-C#代码类资源-CSDN文库
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！