Appearance
第16讲：测试四象限与金字塔模型
当 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 所提出的"敏捷测试四象限"的来源和问题，并给出了我自己设计的、新的敏捷测试四象限；然后介绍了自动化测试的分层策略，即著名的金字塔模型及其衍生出的橄榄球模型、反模式等。
最后，给你出一个思考题：自动化测试的冰淇淋模型是怎样的？冰淇淋模型是值得采用的吗？如果在金字塔模型三层基础上再增加一层，会分出哪一层？ 欢迎留言回答。