敏捷测试 – 象限

与传统测试一样，敏捷测试也需要涵盖所有测试级别。

• 单元测试
• 集成测试
• 系统测试
• 用户验收测试

单元测试

• 由开发人员与编码一起完成
• 由编写测试用例的测试人员提供支持，确保 100% 的设计覆盖率
• 需要审查单元测试用例和单元测试结果
• 不会留下未解决的主要缺陷（根据优先级和严重性）
• 所有单元测试都是自动化的

集成测试

• 随着 Sprint 的进展与持续集成一起完成
• 在所有 Sprint 完成后最后完成
• 所有功能需求都经过测试
• 单元之间的所有接口都经过测试
• 报告所有缺陷
• 在可能的情况下测试是自动化的

系统测试

• 随着开发的进行而完成
• 测试用户故事、特性和功能
• 在生产环境中完成的测试
• 执行质量测试（性能、可靠性等）
• 缺陷报告
• 在可能的情况下测试是自动化的

用户验收测试

• 在每个 Sprint 结束时和项目结束时完成

• 由客户完成。反馈由团队接受

• 反馈将成为后续 Sprint 的输入

• Sprint 中的用户故事已预先验证为可测试且具有定义的验收标准

测试类型

• 组件测试（单元测试）
• 功能测试（用户故事测试）
• 非功能性测试（性能、负载、应力等）
• 验收测试

测试可以是完全手动的、完全自动化的、手动和自动的组合或工具支持的手动。

支持编程和评论产品测试

测试可以用于 –

• 支持开发（支持编程） – 程序员使用支持编程测试。

  • 决定他们需要编写什么代码来完成系统的特定行为

  • 编码后需要运行哪些测试以确保新代码不会妨碍系统的其余行为

• 仅验证（评论产品） – 评论产品测试用于发现成品中的不足之处

业务面和技术面测试

要决定何时执行哪些测试，您需要确定测试是否是 –

• 业务面，或
• 技术面

业务面测试

测试是面向业务的测试，如果它回答用业务领域的词构成的问题。这些是业务专家所理解的，并且会引起他们的兴趣，以便可以在实时场景中解释系统的行为。

技术面临测试

测试是面向技术的测试，如果它回答用技术领域的词语构成的问题。程序员根据对技术的澄清了解需要实现什么。

可以使用 Brian Marick 定义的敏捷测试象限来查看测试类型的这两个方面。

敏捷测试象限

结合测试类型的两个方面，以下敏捷测试象限由 Brian Marick 推导出 –

敏捷测试象限提供了一个有用的分类法来帮助团队识别、计划和执行所需的测试。

• 象限 Q1 – 单元级别，面向技术，并支持开发人员。单元测试属于这个象限。这些测试可以是自动化测试。

• 象限 Q2 – 系统级、面向业务和符合产品行为。功能测试属于这个象限。这些测试要么是手动的，要么是自动的。

• 象限 Q3 – 系统或用户接受水平，面向业务并专注于实时场景。用户验收测试属于这个象限。这些测试是手动的。

• 象限 Q4 – 系统或操作接受水平、技术面临和关注性能、负载、压力、可维护性、可扩展性测试。特殊工具可用于这些测试以及自动化测试。

结合这些，反映什么-测试-何时的敏捷测试象限可以可视化如下 –