当 CI/CD 环境或 DevOps 测试基础设施准备好之后，我们就准备开始自动化测试了。自动化测试一直是测试开发者感兴趣的内容，也是本专栏的重点内容之一。说起自动化测试，先要说清楚从哪里开始比较好、哪些方面更容易见成效，这也是我们经常说的自动化测试策略，明确自动化测试的特点，争取以较低的代价产出更高的收益。

敏捷测试四象限来源和问题

看到这讲的标题，你就知道我会谈“敏捷测试四象限”，我是把它当作自动化的测试策略，而不是作为敏捷的测试四象限，虽然 Lisa & Janet 在 2009 年出版的 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 也就是产品相关利益者一起来评审产品，真正从业务角度来评估产品的质量，这些实践也符合敏捷测试原则和思维方式。

从上面看，也反映了整个敏捷中的自动化测试策略，基于技术层的测试，可以进行更彻底的自动化测试，而基于业务层的测试，更需要发挥人的创造性、思维能力。如果更理想的话，可以实现整个闭环的自动化测试，包括让需求可执行（BDD / 实例化需求）、基于人工智能的众测和探索式测试等，这是后话，留到第 24、25 讲及其之后讨论。

测试金字塔模型

测试四象限可以看做是整个敏捷测试的自动化策略，而金字塔模型更倾向于功能的自动化测试策略，一般也可以看做是自动化测试的分层模型，即将一个被测系统分为不同的层次，根据不同的层次，在自动化测试和手工测试上有不同的投入，以达到最优的效果（即最高的 RoI）。金字塔模型，如图 4 模型 a 所示，估计不少人都很熟悉，它蕴含着以下几点自动化测试策略：

尽可能实现单元测试的自动化，自动化测试在单元（代码）层次没有障碍，而且代码天天要添加、修改或重构，要随时做回归测试，更需要就绪的自动化脚本的支撑；

API 测试的自动化也容易实现，记得当年，我们就是从接口开始自动化测试的，效果显著，自动化测试率也能达到 95% 以上；

尽量不要做基于 UI（用户界面）的自动化测试，这类脚本开发和维护的成本都很高，执行还不稳定。

模型 a 是理想模型，许多公司做不到，主要是因为单元测试投入的成本高，同时在质量上没有那么高的要求，所以不少公司（包括互联网电商、移动 App 开发等公司或团队）没有采用金字塔模型，而采用的是橄榄球模型（和敏捷中的 Scrum 倒是吻合），如图 4 模型 c 所示。

特别是在微服务中，每个微服务用契约驱动测试方法，只要验证被调用的接口组合（已实现的业务逻辑），没有被调用的接口（用不到的逻辑）无需测试，这样测试的效率会更高，避免不必要的测试浪费。但如果按照金字塔模型，针对底层的单元进行充分的测试，其实存在浪费，只是这样系统更健壮，因为有时接口会被错误调用。

少数公司还在采用中间的模型 b——彻底倒过来的金字塔模型，这是我们反对的，所以把它称为“反模式”。除了 a、b、c 三个模型之外，还有冰淇淋模型等。

图4 自动化测试金字塔模型及其衍生模型

总结一下，这一讲我侧重分析了 Lisa 和 Janet 所提出的“敏捷测试四象限”的来源和问题，并给出了我自己设计的、新的敏捷测试四象限；然后介绍了自动化测试的分层策略，即著名的金字塔模型及其衍生出的橄榄球模型、反模式等。

最后，给你出一个思考题：自动化测试的冰淇淋模型是怎样的？冰淇淋模型是值得采用的吗？如果在金字塔模型三层基础上再增加一层，会分出哪一层？ 欢迎留言回答。

-– ### 精选评论 ##### **林： > 多加一层性能自动化吗？ ######     讲师回复： >     是指金字塔模型吗？应该不能加，性能自动化也可以分单元、接口、UI等多个层次进行。除了性能，还有安全性、可靠性、兼容性测试… ##### **者： > 朱老师修改后的敏捷测试四象限更清楚地说明了业务和技术如何结合来实现产品的质量。