📅 最后修改于: 2020-12-07 05:20:14 🧑 作者: Mango
敏捷是一种迭代开发方法，开发和测试活动同时进行。测试不是一个单独的阶段。编码和测试以交互方式和增量方式完成，从而产生了满足客户要求的优质最终产品。此外，连续集成可尽早消除缺陷，从而节省时间，精力和成本。
敏捷宣言是由一组软件开发人员于2001年发布的，着重强调了开发团队的重要性，可以适应不断变化的需求和客户的参与。
敏捷宣言是-
我们正在探索通过开发和帮助他人来开发软件的更好方法。通过这项工作，我们实现了价值-
也就是说，尽管右侧的项目有价值，但我们更重视左侧的项目。
敏捷测试是一种遵循敏捷软件开发原理的软件测试实践。
敏捷测试涉及项目团队的所有成员，由测试人员提供特殊专业知识。测试不是一个单独的阶段，而是与所有开发阶段(例如需求，设计和编码以及测试用例生成)交织在一起的。测试在开发生命周期中同时进行。
此外，随着测试人员与跨职能团队成员一起参与整个开发生命周期，测试人员对根据客户要求构建软件，提供更好的设计和代码的贡献将成为可能。
敏捷测试涵盖了所有级别的测试和所有类型的测试。
在瀑布式开发方法中，开发生命周期活动按顺序进行。因此，测试是一个单独的阶段，只有在开发阶段完成后才开始进行测试。
以下是敏捷测试和瀑布测试之间的区别的重点-
| Agile Testing | Waterfall Testing |
|---|---|
| Testing is not a separate phase and occurs concurrently with development. | Testing is a separate phase. All levels and types of testing can begin only after the completion of development. |
| Testers and developers work together. | Testers work separately from developers. |
| Testers are involved in coming up with requirements. This helps in requirements mapping to the behaviors in the real world scenario and also framing the acceptance criteria. Also, logical Acceptance Test Cases would be ready along with the requirements. | Testers may not be involved in the requirements phase. |
| Acceptance Testing is done after every iteration and customer feedback is sought. | Acceptance Testing is done only at the end of the project. |
| Every iteration completes its own testing thus allowing regression testing to be implemented every time new functions or logic are released. | Regression Testing can be implemented only after the completion of development. |
| No time delays between coding and testing. | Usual time delays between coding and testing. |
| Continuous testing with overlapping test levels. | Testing is a timed activity and test levels cannot overlap. |
| Testing is a best practice. | Testing is often overlooked. |
敏捷测试的原则是-
测试使项目向前发展-持续测试是确保持续进展的唯一方法。敏捷测试不断提供反馈，最终产品可以满足业务需求。
测试不是阶段性的-敏捷团队与开发团队一起进行测试，以确保在给定迭代过程中实现的功能实际上已经完成。测试不会保留到以后的阶段。
所有人进行测试-在敏捷测试中，包括分析师，开发人员和测试人员在内的整个团队都对应用程序进行测试。每次迭代后，甚至客户都执行用户验收测试。
缩短反馈循环-在敏捷测试中，业务团队将了解每次迭代的产品开发。它们参与每个迭代。连续反馈缩短了反馈响应时间，因此修复它所涉及的成本更少。
保持代码干净-在同一迭代中提出缺陷时，这些缺陷将被修复。这样可确保在开发的任何里程碑都提供清晰的代码。
轻量级文档-敏捷测试人员代替了全面的测试文档-
使用可重复使用的清单来建议测试。
关注测试的实质，而不是偶然的细节。
使用轻量级的文档样式/工具。
在章程中记录测试思路以进行探索性测试。
利用文档有多种用途。
利用一个测试工件进行手动和自动测试-同一测试脚本工件可以用于手动测试，也可以用作自动化测试的输入。这样就消除了手动测试文档和等效的自动化测试脚本的需求。
“完成”，而不仅仅是完成-在敏捷中，据说某个功能不是在开发之后进行，而是在开发和测试之后进行。
最后测试与测试驱动-测试用例与要求一起编写。因此，开发可以通过测试来驱动。这种方法称为测试驱动开发(TDD)和验收测试驱动开发(ATDD)。这与瀑布测试的最后阶段测试相反。
在项目级别的敏捷测试活动是-
发布计划(测试计划)
对于每次迭代，
迭代期间的敏捷测试活动
回归测试
发布活动(与测试相关)
迭代期间的敏捷测试活动包括-