一、敏捷测试象限起源

        敏捷测试象限的起源是出自 Brian Marick 最开始提出的敏捷测试矩阵。后来在他的许可下，敏捷测试专家 Lisa Crispin 和 Janet Gregory 对敏捷测试矩阵进行补充和扩展，并在她们的著作《敏捷软件测试：测试人员与敏捷团队的实践指南》提出了敏捷测试象限的概念，如图1所示。

图1 敏捷测试象限

        敏捷测试象限作为敏捷测试的基础框架，是每个敏捷测试人员必须要了解的知识。敏捷测试象限表示了不同类型的测试有不同的目的，主要的维度包括面向技术还是面向业务、面向支持团队还是面向评价产品。然后根据这几个维度按组合分为四个象限，而敏捷测试中涉及到的所有测试类型都归集到这四个象限中：

• 第 1 象限（Q1）：面向技术、支持团队的测试
• 第 2 象限（Q2）：面向业务、支持团队的测试
• 第 3 象限（Q3）：面向业务、评价产品的测试
• 第 4 象限（Q4）：面向技术、评价产品的测试            

二、敏捷测试象限介绍

        敏捷测试象限具体每个象限的介绍如下：

        (Q1) 面向技术和支持团队的测试

•     主要是开发人员执行的测试
•     测试类型：单元测试/模块测试、集成测试
•     测试目标：验证单元模块被正确的实施
•     主要采用自动化测试的方式，例如在代码检入之前的频繁的自动化测试和重运行

        (Q2) 面向业务和支持团队的测试

•     主要是测试人员执行的测试
•     测试类型：功能测试、样例、用户故事测试、原型、模拟等。
•     测试目标：验证一个功能或者用户故事根据验收标准被正确的实施
•     主要采用自动化为主，手工测试为辅的方式

        (Q3) 面向业务和评价产品的测试

•     主要是业务验收人员和测试人员执行的测试
•     测试类型：探索式测试，情景测试、可用性测试、用户验收测试、Alpha 测试及 Beta 测试等
•     测试目标：验证功能满足业务和终端用户需要
•     主要以手工测试为主，自动化测试为辅的方式

        (Q4) 面向技术和评价产品的测试

•     主要是测试人员执行，项目团队配合的测试
•     测试类型：性能/负载测试、安全性测试、其它非功能性“-ility”测试
•     测试目标：确定产品符合非功能性要求
•     很多测试需要借助测试工具来完成，主要是自动化加手工结合的方式

        敏捷测试象限虽然把不同的测试类型根据目的进行了归类，让我们能得到相对全面的敏捷测试总览图，但是在真正进行敏捷测试的过程中其落地性的指导意义还是不够明确，对此更进一步的敏捷测试框架是 Mike Cohn 的测试金字塔。

三、传统测试 V 模型的问题

        我们知道在传统的瀑布型开发模式中，对于测试领域有一个著名的模型叫 V 模型。V 模型主要按项目周期的时间轴把测试分成不同的测试阶段，比如单元测试、集成测试、系统测试、用户验收测试等，如图2所示。V 模型的好处在于定义了不同阶段的测试应该关注于被测系统的哪些测试范围，各司其职而不重复。例如单元测试更关注于模块内部的质量；集成测试更关注于模块之间的集成；系统测试更关注于整个系统的功能正确性以及是否满足需求文档；用户验收测试是从最终用户的角度关注是否满足最终用户的需要。

图2 测试 V 模型

        但是 V 模型在敏捷环境下还是存在一些不适性。一方面在敏捷中测试活动是融入到整个开发过程中而不作为单独的阶段，所以 V 模型这种按不同阶段划分的方式明显不适合敏捷测试；另一方面在时间有限的情况 V 模型对各测试阶段需要投入多少精力并没有明确规定，所以导致有不少项目对于单元测试不重视，开发人员由于受到开发进度的压力，很多时候简单测试一下甚至是没有经过自测就提交给测试人员，从而让测试人员不得不花大量的时间来拦截缺陷，一不小心就成为“背锅侠”。在集成测试阶段有些时候因为有测试人员的介入，所以相对来说会做得充分点。但是由于在这个阶段对测试人员的技能要求需要有白盒测试的基础，所以不是每个测试人员都有能力执行集成测试，因此更多的测试工作被推后到了 UI 层的测试，包括 UI 界面的自动化测试和大量的手工测试。这种情况如下图3所示的左边部分。由于左图看起来很像一个冰激凌，所以我们称为“冰激凌”模式。

图3 测试“冰激凌”模式与金字塔模式

        冰激凌模式有几个弊端：

•     测试脆弱性：由于我们的自动化测试脚本集中在 UI 界面，而 UI 界面往往是最不稳定的部分。界面控件经常会发生变化，这对于 UI 端自动化测试脚本来说简直就是灾难。我们知道 UI 自动化测试是非常依赖 UI 界面的控件稳定，只要控件有变化，整个脚本就得重新调整和维护，否则脚本就会运行失败。所以自动化测试非常脆弱。
•     延迟可能性：由于我们在单元测试、集成测试做得不够充分，导致把风险留到了后面阶段，我们需要在后面的 UI 测试花大量的时间进行测试，这时发现缺陷修复缺陷的周期变得非常长而且不可控，从而大大提高了延迟的可能性。
•     复杂性：假如我们在单元测试、集成测试阶段没有测试充分的话，在 UI 界面测试时如果发现缺陷，那么对于缺陷的定位、诊断和分析都变得更加复杂。
•     成本：我们知道测试的一个定律，也就是越早发现缺陷，修复的代价越低。如果我们把一个缺陷留在后面阶段才发现的话，将会大大提升整个项目的成本。

四、测试金字塔介绍

        由于冰激凌模式有这么多弊端，所以敏捷专家 Mike Cohn 在 2003 年提出新的测试思路——测试金字塔。不过测试金字塔的真正流行是2009年Mike Cohn在他的著作《Succeeding with Agile》一书中正式提出后才开始的。而后在敏捷测试专家Lisa Crispin的著作《敏捷软件测试：测试人员与敏捷团队的实践指南》一书中再次提到测试金字塔，让它成为了敏捷测试中最重要的测试模型之一。

        测试金字塔最初的原型分三层，底层是单元测试，中间层是 API 测试，上层 是UI 自动化测试。而且底层的单元测试需要做最多的测试工作，越往上测试工作应该越少。根据《谷歌软件测试之道》的经验，三者对于精力投入的比例是：把 70%的精力放在单元测试，20%放在 API 测试，而剩下 10%的精力放在 UI 测试。

        测试金字塔的这个理念和时下流行的“测试左移”的理念是一致的。测试左移（Shift Left Testing）是指要把质量保障的活动尽量前移到更早的开发生命周期中。这个理念和测试金字塔的思想是不谋而合的，也就是我们要把测试工作往前移（对应于测试金字塔是往下沉），要把单元测试、集成测试做得更加充分和完善。而上面的 UI 测试只需要针对关键业务进行自动化回归测试即可。

        当然，我们知道如果只靠自动化测试是没办法完全保证系统的质量，有些地方还是需要人工的介入、需要人的思维判断才行，比如用户体验测试等。所以后来 Lisa 在金字塔的塔尖再补上了一片“云”，这片“云”就是人工探索式测试（Exploratory Test，简称 ET）。最终就形成了我们在图3右侧看到的样子。由于此模型形状像埃及的金字塔，所以被称之为测试“金字塔”模型。

五、分层自动化测试

        除了测试金字塔外，我们经常还听到一个词叫“分层自动化测试”。在国外基本上很少提这个词，但是在国内却总是在不同的场合会听到。如果我们把测试金字塔顶尖上由 Lisa Crispin 补充的那块“云”（探索式测试）先去掉的话，那么分层自动化的内容和测试金字塔基本上是一回事，没有太大的区别。

        分层自动化测试从“自动化”这个角度出发，说明了自动化需要按不同的层级来实施，不仅仅只是关注在 UI 层，也需要关注 API 接口层和单元层。UI 层的自动化测试这个理念在过去的二三十年一直处于主导地位，大多数的测试同行在实施自动化测试的时候一开始映入脑海的就是 UI 自动化测试，而且业界也提供了很多成熟的 UI 自动化测试工具，比如商业工具 QTP/UFT、开源工具 Selenium 等等。

        但是正如上一节所述，随着 UI 自动化测试本身的痛点日益明显，其脆弱性和复杂性也让人怀疑 UI 自动化测试的投入产出是否合理，因此当 Mike Cohn 提出测试金字塔模型后，让人们改变了以前一直认为 UI 自动化测试为主导的意识，从最初我们所熟悉的 UI 自动化测试扩展到 API 层的自动化测试以及底层的自动化单元测试，使得自动化能够在不同层级的测试中都发挥其作用，降低了测试的脆弱性和复杂性，提升整个测试的效率，这就是我们说的分层自动化测试，如图4 所示：

图4 分层自动化测试

六、测试自动化与自动化测试的区别

        近年来，随着敏捷开发模式的流行，测试领域也在不断地发生变化。由于敏捷开发所谓“小步快跑”的方式迫使测试人员需要在更短的时间完成整个测试过程，而以前的纯手工测试应付这种“短平快”的开发节奏渐渐变得吃力起来，于是提升测试的速度和效率则变成了能否很好支撑敏捷开发的关键。而提升测试速度和效率，自动化就变得比以前任何时候更显得重要了。

        当我们谈自动化的时候，经常会听到两个词：自动化测试和测试自动化。相信很多人都认为这两个概念说的是同一个意思。但是在我看来，这俩个概念却是有本质上的区别。那么到底什么是自动化测试？什么是测试自动化？所谓“自动化测试”，一般是指在测试执行过程中，通过自动化的工具或手段来代替人工执行的过程。它强调的是解决“测试执行过程”的效率；而“测试自动化”，是指在测试领域中的任何方面都可以通过各种自动化的方式和手段来加快测试的效率，保证测试的质量，缩短软件交付的周期。所以它强调的范围是整个测试的过程而不仅仅是测试执行过程。比如说测试数据准备的自动化、测试环境搭建的自动化都可以包含在测试自动化这个概念里面。从这个角度来说，测试自动化所包括的范围更广，而我们在项目中，更应该从自动化测试思维转变到测试自动化思维中，从整个测试生命周期 STLC（Software Testing LifeCycle）中去寻找可以自动化的点，全方位的提升测试的效率，这也是外国同行经常使用的一句话：Automate Everything！

七、测试自动化的目的

        我们再来谈谈自动化的目的。测试自动化的目的，很多人第一反应就是加快测试的速度。诚然，加快测试速度是其中的一个目的。但是我认为，测试自动化最核心最重要的目的是保证软件的质量。大家知道我们在做测试时，无论是版本升级还是缺陷修复都需要大量的回归测试。而如果仅仅只是靠“人肉”战术，一方面测试人员要应付新功能的测试，另一方面又要进行缺陷的回归测试，往往这时候测试人员会把重点放在新功能上面，而回归测试就会因为时间紧被简化了。简化的后果就是原来应该被回归的范围缩小，从而导致有些缺陷被遗漏掉；另外因为人毕竟不是机器，在经过重复枯燥的点鼠标测试工作后，往往会有“审丑”疲劳，而软件的“丑”有时就被熟视无睹了。所以如果通过自动化来进行回归测试，则可以弥补这方面的问题。一方面机器可以覆盖更广泛的回归测试范围，确保该测的地方都测到；另一方面因为机器不会疲惫、不会像人一样出现疏忽或者出错，从而提升整个软件质量。

        当然，第二个目的就是大家所熟知的加快测试速度了。但是这里需要阐明一点的就是加快测试速度不是指加快脚本执行步骤的速度。其实从某种意义上来说，熟练的测试工程师对某一个业务流程的人工操作有可能比机器操作还要快。机器为了脚本健壮性，往往在脚本中会人为设置一些等待时间，避免因为操作比系统反应更快从而导致脚本运行失败。所以这里提到的加快测试速度有两个层面的意思：一是指我们如果通过机器来执行，机器不像人类一样，每天工作 8 小时。如果需要，机器可以 24 小时不间断的运行，当然也就可以利用晚上甚至是凌晨的时间来执行，而这个是人类所没办法做到的；另一方面，随着虚拟化和容器的发展，我们可以很容易的部署多套自动化工具来进行脚本的执行。如果脚本量很大的情况下，我们可以通过容器部署更多的执行机来实现分布式执行测试，从而大大加快整个测试的速度、提升整个测试的效率。

        最后，自动化还有一个目的是大家容易忽视的，也就是自动化可以解决人工不能做到的一些测试操作。比如说性能测试，如果需要测 10000 个并发，我们是不可能找 10000 个测试工程师坐在电脑前同一时间去点击系统的。即使能找到 10000 个工程师，但是怎么保证他们真的是“同一时间”呢？通过自动化，却是可以通过模拟这种并发的请求来实现。

八、增强的分层自动化

        我们在上一节中已经了解了分层自动化。但是如果我们按照“测试自动化”这个理念重新再思考图4的话，我们会发现其实图4是有所缺失的，因为它只是考虑了测试执行过程，而没有关注包括测试数据准备、测试环境准备等方面。

        所以从整个测试的过程来看，图4的描述还不是最完整的分层自动化测试。分层自动化测试不仅仅是 UI 的自动化，而是需要在测试的不同阶段都考虑自动化；同样，分层自动化测试不仅仅只是关注测试执行过程的自动化，还应该需要关注包括数据、环境准备等各个方面的自动化，特别是测试环境的自动化。我们知道测试环境准备特别耗时，有统计数据表明，测试环境的准备时间占整个测试过程的 40%。所以通过自动化来解决测试环境将会大大提升整个测试的效率。因此我们需要对图4 进行优化，补充测试数据及测试环境自动化在最下层，作为自动化测试执行的基础设施，如图5 所示：

图 5 增强的分层自动化