与传统测试一样，敏捷测试也需要涵盖所有测试级别.
单元测试
集成测试
系统测试
用户验收测试
单元测试
与Coding一起完成，由开发人员
支持编写测试用例确保100％设计覆盖率的Tester
需要审核单元测试用例和单元测试结果
未解决的主要缺陷(按照优先级和严重性未被保留
所有单元测试都是自动的
集成测试
随着Sprint进度一起完成持续整合
在所有Sprint完成后完成
>
测试所有功能要求
测试单元之间的所有接口
所有缺陷均为Re移植
测试尽可能自动化
系统测试
完成开发进度
测试用户故事，功能和功能
在生产中完成测试环境
执行质量测试(性能，可靠性等)
报告缺陷
测试尽可能自动化
用户验收测试
在每个Sprint结束时和项目结束时完成
由客户完成.团队反馈
反馈将成为后续Sprint的输入
Sprint中的用户故事已预先验证为可测试且具有已定义的接受标准
测试类型
组件测试(单元测试)
功能测试(用户故事测试)
非功能性测试(性能，负载，压力等)
验收测试
测试可以是完全手动，完全自动化，手动和自动或手动相结合的工具.
支持编程和批判产品测试
测试可以是:
支持开发(支持编程) : 程序员使用支持编程测试.
决定他们需要编写什么代码才能完成某种行为系统
在编码后需要运行哪些测试以确保新代码不会妨碍系统的其他行为
仅验证(批判产品) : 批判产品测试用于发现成品中的不足之处
面向业务和面向技术的测试
决定在进行什么测试时，你需要确定测试是否为 :
面向业务，或
技术面临
面向业务的测试
测试是面向业务的测试，如果它回答了用业务领域的文字构成的问题.这些都是业务专家所理解的，他们会对它们感兴趣，以便在实时场景中解释系统的行为.
面临测试的技术
如果测试用技术领域的单词来回答问题，那么测试就是面向技术的测试.程序员根据对技术的澄清了解需要实施的内容.
可以使用Brian Marick定义的敏捷测试象限来查看测试类型的这两个方面.
敏捷测试象限
结合测试类型的两个方面，以下敏捷测试象限由Brian Marick派生并减去;
敏捷测试象限提供了一个有用的分类法，可帮助团队识别，计划和执行所需的测试./p>
Quadrant Q1 : 单元级，技术面向并支持开发人员.单元测试属于此象限.这些测试可以是自动化测试.
Quadrant Q2 : 系统级，业务面临和符合产品行为.功能测试属于此象限.这些测试是手动或自动的.
象限Q3 : 系统或用户接受程度，面向业务并专注于实时场景.用户验收测试属于此象限.这些测试是手动的.
象限Q4 : 系统或操作验收级别，技术面向并关注性能，负载，压力，可维护性，可扩展性测试.特殊工具可用于这些测试以及自动化测试.
结合这些，反映什么的敏捷测试象限 - 测试 - 当可以显示如下 :
