敏捷测试 – 概述

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

敏捷宣言

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

敏捷宣言是 –

我们正在通过做和帮助他人来发现更好的软件开发方法。通过这项工作，我们开始重视 –

• 个人和交互胜过流程和工具。
• 工作软件优于综合文档。
• 客户合作胜过合同谈判。
• 响应变化而不是遵循计划。

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

什么是敏捷测试？

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

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

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

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

敏捷测试对比 瀑布测试

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

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

敏捷测试原则

敏捷测试的原则是 –

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

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

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

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

• 保持代码清洁– 缺陷在同一迭代中出现时得到修复。这可确保在开发的任何里程碑处编写干净的代码。

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

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

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

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

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

  • 将文档用于多种用途。

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

• “Done Done”，不仅仅是完成– 在敏捷中，一个功能被认为不是在开发之后完成，而是在开发和测试之后完成。

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

敏捷测试活动

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

• 发布计划（测试计划）

  • 对于每一次迭代，

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

• 回归测试

• 发布活动（测试相关）

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

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