敏捷测试 - 象限

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

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

单元测试

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

集成测试

• 与持续集成一起完成随着 Sprint 的进展
• 在所有 Sprint 完成后完成
• 测试所有功能需求
• 测试单元之间的所有接口
• 报告所有缺陷
• 尽可能自动进行测试

系统测试

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

用户验收测试

• 在每个 Sprint 结束时以及在项目

• 由客户完成。团队会收集反馈意见

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

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

测试类型

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

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

支持编程和批评产品测试

测试可以是 −

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

  • 决定需要编写什么代码来实现系统的某种行为

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

• 仅验证（批评产品） −批判性产品测试用于发现成品中的不足之处

面向业务和面向技术的测试

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

• 面向业务，或
• 面向技术

面向业务的测试

如果测试回答了用业务领域的词语提出的问题，则该测试为面向业务的测试。业务专家理解这些问题并会对此感兴趣，以便可以在实时场景中解释系统的行为。

面向技术的测试

如果测试回答了用技术领域的词语提出的问题，则该测试为面向技术的测试。程序员根据对技术的澄清，了解需要实施什么。

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

敏捷测试象限

结合测试类型的两个方面，Brian Marick 得出以下敏捷测试象限 −

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

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

• 象限 Q2 − 系统级别、面向业务和符合产品行为。功能测试属于此象限。这些测试是手动的或自动的。

• 象限 Q3 − 系统或用户验收级别、面向业务并关注实时场景。用户验收测试属于此象限。这些测试是手动的。

• 象限 Q4 − 系统或操作验收级别、面向技术并关注性能、负载、压力、可维护性、可扩展性测试。这些测试可以与自动化测试一起使用特殊工具。

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