最近重新设计了一个对大家实施敏捷测试更有价值的敏捷测试四象限。
之前写过一篇文章，讨论了 Lisa & Janet 在她们的书 Agile Testing: A Practical Guide for Testers and Agile Teams 中所定义的 “敏捷测试四象限（Agile Testing Quadrants）”，如图 1 所示，但这是一个伪 “敏捷测试四象限”。
图1 所谓的“敏捷测试四象限”
说起这四象限，要回到 2003 年。这年 8 月，Brian Marick 连续写了几篇文章试图为敏捷测试指明发展方向，因为之前有人总是对他说，敏捷测试只是一项技能，而不能成为一门学科。在此期间，他花了很多时间在思考这样的一个问题——敏捷测试将往哪个方向发展， 于是产生了这个四象限，但那时还不叫四象限，而是叫测试矩阵（Marick Test Matrix），也没有图 1 那么详细，只是一个非常简单的矩阵，如图 2 所示，告诉测试人员可以朝这四个方向努力。
图2 Marick Test Matrix
1）面向业务的测试，即用业务领域的术语来表达测试设计或测试用例，比如说，你去 ATM 机上取钱，输入的金额多于你账户上现有的资金，系统会告诉你，余额不足。面向业务的测试最好由了解业务的人员（如 Product Owner、业务分析师 BA 等）编写，一般不适合自动化测试，而是手工测试。2）面对技术的测试，是用技术的方式来完成测试，例如，不同的浏览器和服务器交互的逻辑处理没什么不同，但前端界面展示会有不同，因为不同的浏览器对 JavaScript 处理方式是不同的，所以不同的浏览器测试重点是在前端的兼容性测试。这部分测试，最好由开发人员、测试人员来做，也适合自动化测试。3）支持编程的测试，是定义软件应该执行具体功能操作而进行的测试，而且认为这些测试可以在软件版本构建之前就能编写，通常是自动化的，而且主要用于回归测试。4）产品批判性的测试是一种尝试识别完整软件中问题的测试，更多的场景是负面测试、异常测试，即测试人员尝试破坏软件以发现软件的缺陷。如果仅仅从图 2 这样简单的矩阵来看，和自动化测试不是特别相关，虽然面对技术的测试、支持编程的测试都是适合自动化测试的，而且这两个方向有些重叠，区分起来很难。产品批判性的测试差不多也可以归为面向技术的测试，和支持编程的测试并非对立，其相反性不明显。产品批判性的测试可以是手工测试，也可以是自动化的，包括自动生成边界值、异常值来进行测试，或采用模糊测试、变异测试等方法来进行测试。这四个方向，和敏捷关系不大，没有体现敏捷的价值观、敏捷测试的原则，甚至都没体现敏捷测试的思维方式。在传统软件测试中，也需要考虑面向业务、面向技术的测试。之前，我们就常说，测试人员是技术人员中业务最好的，与业务人员相比，技术又强很多，即测试人员既要懂业务又要懂技术，才能做好测试，而且，测试人员既要做正向的验证也要做反向的异常测试。所有这些，基本体现了这四个方向。在 Lisa & Janet 在图 1 的基础上，加了不少内容，包括特别注明自动化（Automated）、手工（Manual）、工具（Tools）等之后，它更不像敏捷测试四象限，而是自动化测试策略，否则会有不少疑问：- 不为业务的测试都是耍流氓，测试面向业务，不能面向技术；
- 为什么单元测试是支持团队，而性能测试就不是支持团队呢？
- 为什么功能测试和用户故事测试是支持团队，而探索式测试就不是呢？
- 性能测试／安全性测试是评价产品，功能测试为什么不是评价产品呢？
- 实例化、原型和仿真有验证的作用，但更多时候不是为了测试，而是为了沟通，澄清用户的真实需求。
看到上述问题，我只好重新设计一个真正的敏捷测试四象限，如图 3 所示，是不是好多了？虽然可以理解为是对图 1 进行修改的结果，其中蓝色文字的内容是我修改的，也就是说绝大部分都已改了，完全可以说是一个崭新的敏捷测试四象限。不能说“面向业务或技术”，所以垂直方向改为“业务层次”和“技术层次”，即从不同的层次来进行测试，但都是为了业务。把原来左边的“支持团队”改为“驱动构建质量”，正如前面谈到的敏捷质量管理思维是认为““预防缺陷”比“发现缺陷”更有价值，即在敏捷测试中，我们如何驱动团队构建出高质量的产品更有价值。 图3 作者设计的敏捷测试四象限这样修改的结果，形成新的敏捷测试四象限：基于业务层构建产品质量、基于技术层构建产品质量、基于技术层评价产品质量和基于业务层评价产品质量。顺序和图 1 也不一样了，之前是顺时针，现在是逆时针：业务驱动测试，业务必须在前，最后收集用户反馈、进行分析，再输入到需求中，形成闭环，这样更科学合理。Q1：基于业务层构建产品质量。业务驱动测试，即包括验收测试驱动开发（ATDD）和行为驱动开发（BDD）、实例化需求、测试驱动设计等，不仅澄清和验证需求与设计，更重要的是构建高质量的需求与设计，这更有价值。Q2：基于技术层构建产品质量，侧重 CI/CD 技术和环境的支持，实现单元测试驱动开发，以及良好的自动化单元测试、代码的静态分析和基于 CI 的代码评审流程、全自动且流水线式的持续集成测试（BVT）等，以构建高质量的代码。Q3：基于技术层评价产品质量，基于工具的 “功能、性能、安全性、可靠性”等建模、评估、监控与分析，这也依赖于技术和 DevOps 的测试基础设施，不仅能开展全生命周期的、持续的系统测试，而且可以开展在线监控与分析，包括性能、安全性的监控与分析，还有 A/B 测试，即前面说的测试右移，这部分也充分体现了技术性。Q4：基于业务层评价产品质量，包括探索式测试、众测、Sprint Review 等。Sprint Review 也就是产品相关利益者一起来评审产品，真正从业务角度来评估产品的质量，这些实践也符合敏捷测试原则和思维方式。