敏捷测试 - 象限
与传统测试一样，敏捷测试也需要覆盖所有测试级别。
- 单元测试
- 集成测试
- 系统测试
- 用户验收测试
单元测试
- 由开发人员与编码一起完成
- 由编写测试用例的测试人员提供支持，确保 100% 的设计覆盖率
- 单元测试用例和单元测试结果需要审查
- 未解决的主要缺陷（根据优先级和严重性）不会留下
- 所有单元测试都是自动化的
集成测试
- 随着冲刺的进展与持续集成一起完成
- 在所有 Sprint 完成后最后完成
- 所有功能需求均经过测试
- 单元之间的所有接口均经过测试
- 所有缺陷均已报告
- 测试尽可能自动化
系统测试
- 随着开发的进展而完成
- 用户故事、特性和功能经过测试
- 测试在生产环境中完成
- 执行质量测试（性能、可靠性等）
- 已报告缺陷
- 测试尽可能自动化
用户验收测试
在每个 Sprint 结束时和项目结束时完成
由客户完成。反馈由团队收集
反馈将作为后续 Sprint 的输入
Sprint 中的用户故事经过预先验证，可测试，并且具有定义的验收标准
测试类型
- 组件测试（单元测试）
- 功能测试（用户故事测试）
- 非功能测试（性能、负载、压力等）
- 验收测试
测试可以是完全手动、全自动、手动和自动组合或由工具支持的手动。
支持编程和批评产品测试
测试可以用于 -
支持开发（支持编程） - 支持编程测试由程序员使用。
决定他们需要编写哪些代码来完成系统的特定Behave
编码后需要运行哪些测试以确保新代码不会妨碍系统的其余Behave
仅验证（批判产品） - 批判产品测试用于发现成品中的不足之处
面向业务和面向技术的测试
要决定何时执行哪些测试，您需要确定测试是否是 -
- 面向业务，或
- 技术面向
面向业务的测试
如果测试回答了用业务领域的单词提出的问题，那么它就是面向业务的测试。这些是业务专家所理解的并且他们会感兴趣，以便可以在实时场景中解释系统的Behave。
技术面临考验
如果测试回答了用技术领域的词语提出的问题，那么它就是面向技术的测试。程序员根据技术的说明了解需要实现什么。
测试类型的这两个方面可以使用 Brian Marick 定义的敏捷测试象限来查看。
敏捷测试象限
结合测试类型的两个方面，以下敏捷测试象限由 Brian Marick 得出 -
敏捷测试象限提供了有用的分类法，帮助团队识别、计划和执行所需的测试。
Q1 象限- 单元级别，面向技术并支持开发人员。单元测试属于这个象限。这些测试可以是自动化测试。
Q2 象限- 系统级、面向业务并符合产品Behave。功能测试属于这个象限。这些测试可以是手动的，也可以是自动的。
Q3 象限- 系统或用户接受程度、面向业务并关注实时场景。用户验收测试属于这个象限。这些测试是手动的。
象限 Q4 - 系统或操作验收水平、技术面向并关注性能、负载、压力、可维护性、可扩展性测试。可以使用特殊工具以及自动化测试来进行这些测试。
结合这些，反映测试内容、测试时间的敏捷测试象限可以可视化如下：
