本文介绍自动化金字塔以及两种自动化测试的反模式（蛋筒冰激凌、纸杯蛋糕）中存在的问题与产生的原因，并借助经济学分析，简要介绍了一种适合独立测试团队自动化实施的改良模式-橄榄模式。

一、自动化金字塔

自动化金字塔最早是在2009年由Mike Cohn提出的。最早提出来的时候是一个三层的金字塔，从上到下分别是UI/Service/Unit测试。后来Lisa Cripin 在她著名的《agile testing》 [1]这本书中，又给这个金字塔加了一个手工测试的帽子。随着敏捷测试的不断推进，帽子部分又转变成了探索式测试，如图1所示。当然service层可以也理解为 API测试，或者集成测试等等。这种下宽上窄的三角形结构，代表着各层自动化的投入分配应该是底层的单元测试最多，接口测试居中，UI层最少。

图1自动化金字塔（敏捷测试）

自动化金字塔提出之后，几乎为奉为圭旨，甚至还一度出现了配合敏捷转型，大规模裁撤独立测试部门，将人员打散并入各个Scrum团队的风潮。但在现实中，真正能长期通过TDD等实践大力发展单元测试，构建稳定的自动化金字塔的团队是少之又少。

另外，有些重要的决策信息并没有在金字塔模式中体现。如从每个用例的价值来说，手工或者UI层的用例价值最高，越往下越低。这里的价值，可以是用例带来的质量信心，也可以是每个用例所覆盖的代码行数等等。并且自上而下，用例也是逐步从面向业务过渡到面向技术。

二、蛋筒冰激凌模式（反模式）

Alister Scott 在2012年提出了蛋筒冰激凌(ice cream cone)这一反模式[2]。从图形上看，这其实是一个倒置的自动化测试金字塔。这个模式的特点就是，整个组织的自动化测试主要还是针对于用户界面，对于单元测试和集成测试用例的数量或者投资要少许多。更为可怕的是，这个冰激凌桶上面有一大坨手工用例。这个冰淇淋吃起来，估计远不如哈根达斯或者暴风雪那么好的口味了。

图2 自动化冰激凌

这一模式中庞大的手工用例数量，反映了工程团队对于自动化测试投资的不足。许多开始投资自动化测试的团队，为了能尽快产出效果，获得收益，就采取了一些短平快的措施，从最容易上手的用户界面开始。在传统的商用软件供应商或者某些新兴的SAAS服务提供商的系统中，往往用户界面中包含有非常多的业务逻辑，他们的测试团队过往主要依赖于通过手工测试来完成其业务的测试，评测产品的质量，因此其自动化测试的投资重点和目标，也往往是逐步提高现有手工测试用例的自动化替代率。这是一种非常典型的路径依赖，由此产生的结果就是，团队对于底层的自动化测试方面的关注相当不足。

三、纸杯蛋糕模式（反模式）

如果说蛋筒冰激凌模式还只是反应了自动化测试在测试类型和投资分配上的问题，那么来自ThoughtWorks的Fabio Pereira于2014年提出的纸杯蛋糕模式(Software Testing Cupcake)[3]这一反模式就反映出了许多更深层次的问题。

图3 自动化纸杯蛋糕

从图形上看，这个团队的自动化测试投资在各个类型间的分布更加的合理。集成测试或者接口的数量相比蛋筒冰激凌模式来说大了许多，单元测试的规模也有较大增长。在引入敏捷和全员质量的意识之后，工程团队也愈加重视测试和产品质量，于是测试用例可能来自于以下三个团队:

1.开发团队编写单元测试、集成测试和组件测试用例

2.自动化测试团队编写UI自动化测试用例

3.手工测试团队编写手工运行的测试用例，以系统集成测试/业务场景测试为主

根据提出者的介绍，纸杯蛋糕模式的形成原因，主要是因为开发和测试团队分属不同部门，两者中间有着厚厚的部门墙。从团队协作的角度上来讲，因为墙的存在，这些团队都各自为政，彼此间并不能很有效地协作。在测试的级别/类型/场景划分上，这三个团队是彼此没有协同的。这样就必然导致某些重复工作，有些用例被反复地进行自动化；而另一方面，质量拼图不完整也是不完整的，存在缝隙和漏洞，结果必然是1+1+1<3。

从流程上来讲，测试工作也依然是依次线性发生的，而不是同步的。首先，开发编写代码以及对应的测试用例；然后手工测试者设计并运行自己编写的用例；最后，自动化测试团队编写UI自动化测试用例并执行。这个场景可能某些读者非常熟悉，这就是许多声称已经敏捷化的团队的工作模式，在Scrum的流程中依旧使用传统的瀑布式开发模式。他们的Scrum模式，有同行给取了个名字，叫做Scrummerfall[4] 。

类似的模式还有ThoughtWorks公司的Anand Bagmar 在《Is Selenium Finely Aged Wine?》中提到的“双金字塔反模式”(Dual Test Pyramid Anti-Pattern)以及Graham Russell 提出的以伫立在英国纽卡斯尔南部的地标性雕塑“北方天使”（Angel of North）命名的“北方天使反模式”(Angel of North Anti-Pattern)等，这里就不一一赘述了。它们都不约而同地关注于协作与沟通、利益与壁垒等有关人员与组织层面的问题，而不仅仅集中在如何进行自动化测试自身。

当然，很多时候拘泥于部门间职责的切分，有些很好的建议，在现实中比较难以展开。如使用垂直分布的自动化测试度量目标，实现针对某个story或者某个发布在所有级别(UI, Unit)上与所有团队(开发、测试)进行共享。因为度量目标是分享的，更容易达到双赢和互相补位的结果。而现实中，有些Scrum团队的工作DOD(Definition of Done，完成的定义)并不包含测试团队或者测试人员的交付物。当在看板里把一个story置为“Done”的时候，那么很可能只是"Dev Done"(开发完成)，然后交付给测试去实现“Test Done”(测试完成)。另外，出于专注于本职工作，做精做细功能和非功能测试的考虑，一般独立的测试团队也很少去参与开发团队的测试，更不要说共同探讨如何分享测试资源、度量目标了。

四、橄榄模式（不倒翁模式）

众所周知，软件测试的边际成本会随着缺陷探测率的提高而提高，这就是软件测试的基本公理之一"测试的不可穷尽性"的经济学体现。这一规律也适用于自动化测试，也就是说随着自动化覆盖率的提升，自动化的成本也呈现指数式上升。按照这个思路进行拓展，可以分析下单元测试，集成测试和UI测试的自动化成本曲线如图4所示。与通常理解的一致，为了达到相同的自动化率(x0)，UI的成本最高、其次是API，Unit则最低。

经济学中有另外一个著名的理论叫做边际效益递减。当做一项投资，随着投资量的增加，单位投资增量所带来的单位收益是越来越少的，甚至在某个临界点之后，这个收益有可能是负数。而这个零界点，就是投资收益最大的点。在这个点之前的所有投资，都可以扩大总收益，而在超过之后继续进行投资，就不那么明智了。

图4 自动化成本/收益曲线

按照这个思路，在图4上，针对三种不同类型的自动化测试，可以获得三个零界点。而总收益最大的点在集成测试上，随后是单元测试，UI测试则最低。

如果从测试效果上看，接口测试和UI/单元测试相比，有很多优势。 对于单元测试来说，通常单元测试是针对代码进行的测试，而接口测试是在测试一个活的，经过部署的系统。 另外，单个接口测试与单个单元测试用例相比，也可以覆盖更多的代码。更重要的是，接口测试也可以是面向业务的测试，通过接口进行业务层面的测试。

而相比UI自动化用例，接口测试更加的简单直接，执行效率更高。 除了部分如企业级应用软件，可能很多业务在前端进行之外，很多情况下，绝大部分通过UI完成的业务操作完全可以通过API端完成。某些情况下，API的测试条件覆盖率甚至可以多过UI。

综合上述的分析，笔者认为在在自动化测试的初级阶段，适合奔小康的测试团队的自动化模式应该是中间层的接口最大，两端的UI和Unit测试适度实施。从图形上看，就是一个橄榄型。如果再加上一部分的手工测试，那就是一个不倒翁了。

按照这个模式，将大部分自动化投资用于接口测试，可以获得最高的投资回报。再结合持续测试与持续集成等最佳实践，在团队之间彼此共享测试用例、测试框架或者平台，通过接口测试这一承上启下的测试类型，可以自下而上地逐步翻越过纸杯蛋糕模式中的那堵墙。