敏捷测试象限基于Brain Marick在2003年创立的矩阵，测试专家Lisa Chrispin & Janet Gregory在《敏捷软件测试：测试人员与敏捷团队的实践指南》一书中进行了更新，最新的矩阵中将测试技术划分到Q1~Q4四个象限中。

Q1：面向技术的、支持项目团队的自动化测试，例如单元测试、组件测试等。
Q2：面向商业的、支持项目团队的自动化和手工测试，包括功能测试、样例、用户故事测试、原型、模拟等。
Q3：面向商业的、考验产品的手工测试，包括探索式测试，情景测试、可用性测试、用户验收测试、Alpha测试及Beta测试等。
Q4：面向技术的、考验产品的、使用工具的测试，例如性能测试、负载测试、安全性测试、质量特性测试等。

敏捷测试象限.jpg

象限矩阵的左侧一栏是关于在编码前和编码中预防缺陷的，而右侧一栏是关于找缺陷和发展特性缺失的，但我们都希望尽快找到它们。

象限一

左下方的象限代表测试驱动开发，是一个核心的敏捷开发实践。

单元测试验证系统的一小部分的功能，例如一个对象或方法。组件测试验证系统的一大部分的行为，例如提供某些服务的一组类[Meszaros，2007]。所有这两类测试一般都使用自动化工具的xUint家族的一个成员进行自动化。这些测试被认为是程序员测试、面向开发人员的测试或者面向技术的测试。程序员使用它们确保Kent Beck所谓的代码的内部质量[Beck，1999]。

象限一的测试的主要目的是测试驱动开发（TDD）或者测试驱动设计。首先编写测试的过程帮助程序员更好的设计代码。通过这些测试，程序员可以自行的编写代码来实现用户故事的功能，而不用担心对系统引入意外的改变。这些测试可以验证他们的设计和架构决定是否恰当的。单元测试和组件测试是自动化的，使用与应用相同的编程语言编码。业务专家不能通过直接阅读而理解他们，但是这些测试不是打算让客户使用的。实际上，内部质量不是通过客户判断的，而是由程序员定义。程序员测试通畅是自动化过程的一部分，在每次代码导入的时候运行，即时的持续的向团队反馈内部质量。

象限二

象限二的测试也是支持开发团队的工作，但是是在一个更高的层次上。这些面向业务的测试也叫做面向客户的测试或者客户测试，他们确定外部质量和客户需要的功能。

像象限一中的测试那样，他们也是驱动开发，但是是在一个更高的层次上。在敏捷开发中，这些测试来源于客户团队提供的实例。他们描述每个用户故事的细节。面向业务的测试在功能层运行，每个测试验证一个业务满足条件。他们使用业务领域语言以一种业务专家可以容易理解的方式编写。实际上，业务专家使用这些测试来确定产品的外部质量并帮助他们。这个象限可能与单元级别完成的某些测试重复。但象限二的测试是面向实例说明的，并在一个更高的层次确认期望的系统行为。

2. 评价产品的测试

如果你曾经是客户，需要描述软件功能的需求，那么应该知道知道看到软件才能确切的知道需要什么是多么的痛苦。即使你对功能应该如何工作很有信心，描述它使程序员完全理解也是很困难的。

单词“评价”不是否定的意思。评价可以包括赞扬和改进建议。评价软件产品需要艺术性和科学性。我们以建设性的方式评论软件，目的是研究我们如何如何改进它。通过研究，我们可以提出新的需求和测试或者实例来支持团队和指导开发。

象限三

面向业务的实例帮助团队设计期望的产品，但是至少我们的某些实例可能是错误的。业务专家可能遗漏了某些功能，或者如果该功能不是他们的技术领域的，而没有正确的了解这个功能。团队可能至少误解了某些实例。即使程序员变形的代码可以使面向业务的测试通过，他们也可能没有产生客户真正想要的东西。

这就是使用第三象限和第四象限中的评价产品的测试的地方。象限三属于面向业务的测试，这些测试使用运行的软件来查看它是否没有达到期望或能否对抗竞争。当通过面向业务的测试来评价产品时，要尽力模仿真正用户使用应用的方式。这是只有人类可以从事的手动测试。可能使用某些自动化脚本来帮助配置需要的数据，但是需要凭我们的感觉、我们的大脑和直觉来检查开发团队是否交付了客户需要的业务价值。

可用性测试是本身具有完整的理论的一类测试的示例。可以引入焦点小组，在他们使用应用的时候研究它，并与他们交谈以获取他们的反应。可用性测试也可以包括页面间的切换或者甚至是像Tab键顺心这样的简单功能。了解人们如何使用系统是测试可用性时的优势。

探索测试是这个象限的重点。在探索测试阶段，测试人员同时设计和执行测试，使用评论的思想来分析结果。这比脚本测试提供了研究应用的更好的机会。这不是即兴、简易的随机测试。探索测试是比随机测试更深思熟虑的方式。它通过策略和确定现在的动作来指导。在每个项目和用户故事的开始，测试人员开始思考需要尝试的场景。在有了一小部分可以测试的代码后，测试人员分析测试结果，并随着他们的了解，发现新的探索的领域。探索测试使用最终用户操作系统的方式。测试人员使用他们的创造性和直觉。结果，许多严重的缺陷通过这种类型的测试被发现。

象限四

第四象限中的测试类型对敏捷开发和对许多其他类型的软件开发一样重要。这些测试的目的是面向技术的，我们使用技术而不是业务来讨论它们。象限四的面向技术的测试的目的是评价产品的性能、健壮性和安全性等特性。

2014年开始，IT技术上已经产生非常巨大的变化，持续交付，DevOPs，大数据分析，精益创业交付和探索式测试已经广为流行，最近甚至听到AI测试被频繁谈论，是时候对这个象限进行一些修整了。

Gojko Adzic，一名作家和软件交付战略顾问，更新了此象限。使其看起来现在类似以下的模样：

敏捷测试象限Gojko Adzic版.jpg

更多的革新往往发生在这个模型的第二坐标轴：差异在于寻找预期结果还是分析未知结果，不定义是/否的问题，这些结果需要分析解析的能力。

安全性关注点会集中于针对加密，数据保护，认证等合规性的功能测试（预知结果），和渗透或调查（未预先定义的）。这样，交付团队和业务赞助商可以更好的围绕功能性的安全部分展开讨论。

性能关注点可划分为通过运行业务场景来证明双方协定的服务水平和能力，持续交付方式（预知结果）和负载测试（未知拐点）。

敏捷测试象限实际是从项目的各个方面和各个层级上对测试需要触碰到的点进行了一个分类，按照Michael Huttermann的话来说，他在所有象限的中心增加了“由外而内，无障碍，协作”的标签。

比如BDD作为无障碍测试的示例，可以用自然语言“Given_when_Then”的方式来编写测试或者进行测试用例的设计。这样不仅便于和开发人员之间的沟通交流，也方便和客户进行交流，同时更方便于邀请业务团队与交付团队之间进行交流。

总体来说，以上的敏捷测试象限图都仅仅是一个分类或者模型，在实际运用中，你可以按照自己项目的背景或者当时的情况参照此象限图来打造你的测试堡垒和无敌舰队。

四象限.jpg