敏捷测试 - 概述

---

敏捷是一种迭代开发方法，其中开发和测试活动是并发的。测试不是一个单独的阶段；编码和测试以交互方式和增量方式完成，从而产生满足客户要求的优质最终产品。此外，持续集成可以尽早消除缺陷，从而节省时间、精力和成本。

敏捷宣言

敏捷宣言由软件开发团队于 2001 年发布，强调了开发团队、适应不断变化的需求和客户参与的重要性。

敏捷宣言是 -

我们通过实践并帮助他人开发软件，从而发现更好的软件开发方法。通过这项工作，我们认识到了价值 -

• 个人以及流程和工具上的交互。
• 工作软件胜过全面的文档。
• 客户协作胜过合同谈判。
• 响应变化而不是遵循计划。

也就是说，虽然右侧的项目有价值，但我们更看重左侧的项目。

什么是敏捷测试？

敏捷测试是一种遵循敏捷软件开发原则的软件测试实践。

敏捷测试涉及项目团队的所有成员，并由测试人员贡献特殊的专业知识。测试不是一个单独的阶段，而是与所有开发阶段（例如需求、设计和编码以及测试用例生成）交织在一起。测试在整个开发生命周期中同时进行。

此外，随着测试人员与跨职能团队成员一起参与整个开发生命周期，测试人员将有可能根据客户要求构建软件，并提供更好的设计和代码。

敏捷测试涵盖了所有级别的测试和所有类型的测试。

敏捷测试与敏捷测试 瀑布测试

在瀑布开发方法中，开发生命周期活动按顺序发生。因此，测试是一个单独的阶段，只有在开发阶段完成后才开始。

以下是敏捷测试和瀑布测试之间差异的要点 -

敏捷测试原则

敏捷测试的原则是 -

• 测试推动项目前进- 持续测试是确保持续进展的唯一方法。敏捷测试持续提供反馈，最终产品满足业务需求。

• 测试不是一个阶段- 敏捷团队与开发团队一起进行测试，以确保在给定迭代期间实现的功能实际完成。测试不会保留到稍后阶段。

• 每个人都进行测试- 在敏捷测试中，包括分析师、开发人员和测试人员在内的整个团队都会测试应用程序。每次迭代之后，甚至客户也会执行用户验收测试。

• 缩短反馈循环- 在敏捷测试中，业务团队了解每次迭代的产品开发。他们参与每一次迭代。持续的反馈缩短了反馈响应时间，因此修复它所涉及的成本更少。

• 保持代码整洁- 缺陷在同一迭代中出现时得到修复。这可以确保在任何开发里程碑时都保持干净的代码。

• 轻量级文档- 敏捷测试人员不是全面的测试文档 -

  • 使用可重复使用的清单来建议测试。

  • 关注测试的本质而不是附带的细节。

  • 使用轻量级文档样式/工具。

  • 在探索性测试的章程中捕获测试想法。

  • 利用文档实现多种目的。

• 利用一个测试工件进行手动和自动化测试- 相同的测试脚本工件可用于手动测试并作为自动化测试的输入。这消除了手动测试文档和等效的自动化测试脚本的需求。

• “完成”，不仅仅是完成- 在敏捷中，据说某个功能不是在开发之后完成的，而是在开发和测试之后完成的。

• 最后测试与测试驱动- 测试用例与需求一起编写。因此，开发可以通过测试来驱动。这种方法称为测试驱动开发（TDD）和验收测试驱动开发（ATDD）。这与瀑布测试的最后阶段的测试形成对比。

敏捷测试活动

项目级别的敏捷测试活动是 -

• 发布计划（测试计划）

  • 对于每一次迭代，

  • 迭代期间的敏捷测试活动

• 回归测试

• 发布活动（测试相关）

迭代期间的敏捷测试活动包括 -

• 参与迭代计划
• 从测试的角度评估任务
• 使用功能描述编写测试用例
• 单元测试
• 集成测试
• 功能测试
• 缺陷修复
• 集成测试
• 验收测试
• 测试进度状态报告
• 缺陷追踪