1 引言

记得小鱼在上一篇聊到三种高性价比的测试，有的测开的同学就反馈，写的还过得去，希望再多讲一些测开领域资深的内容。

好的， 安排~ ~

我们今天就来聊一聊，测试模型。

我们都知道，项目有项目的模型，

那么，测试策略，是否也有模型呢？

2 金字塔

2.1 金字塔模型 引入

金字塔模型，是一种非常重要也很常见的软件测试策略模型，在很多场合被奉为“金科玉律” 。

测试金字塔告诉我们，在单元测试，集成测试和端到端测试三个阶段的测试资源投入，应该满足接近7:2:1的关系。

在金字塔模型中，软件测试的重心是在开发阶段的单元测试。

通过测试左移和质量内建，从源头上保障软件质量，实现预防bug(而非发现bug)的目标。

单元测试还具有实现成本低和执行速度快的特点，因而可以很容易地与持续集成和敏捷开发相结合，共同实现软件的快速迭代。

这在《深聊测开领域之：三种高性价比测试方法》博文中，有介绍。

通过将大部分问题消灭在单元测试阶段，高成本，速度慢的端到端测试就可以更加聚焦。

通过将有限的资源投入到主干流程和核心业务的端到端测试上，我们可以保障在快速迭代的过程中，核心业务不受影响。

2.2 金字塔弊端

尽管其具有时代的先进性，但测试金字塔模型也是有短板的。

由于金字塔模型过分依赖单元测试，而单元测试的测试对象是代码，离最终的用户场景可能存在距离。因此，单元测试即使很充分，即使实现了100%的代码覆盖率，其有效性仍然存在不足，从而降低我们对软件质量的信心。

2.3 金字塔图形

不得不说，金字塔模型是一种进步的模型，尤其是与它的前任模型相比。

3 冰淇淋

3.1 冰淇淋模型 引入

金字塔模型的前任，是倒金字塔，俗称 “冰淇淋模型”，也是在很久之前，非常主流的一种测试策略模型。

冰淇淋模型与金字塔模型完全相反，它更强调端到端测试。

也就是说，我们主要依靠端到端测试来保障软件质量。

3.2 冰淇淋模型 优缺点

3.2.1 缺点

由于端到端测试投入大，速度慢，周期长，经常需要数周甚至数月完成测试，无法做到快速迭代，因而在敏捷时代被金字塔模型取代。

3.2.2 优点

相比单元测试，端到端测试无疑可以给我们更高的信心。

端到端测试模拟的是用户的实际行为，测试的是系统整体，更有能力发现全局的，对用户直接产生影响的问题，因而测试有效性更高。

对于一些对质量要求极其苛刻，发布周期较长的系统级软件，例如电信软件，操作系统等，仍然十分依赖端到端测试。因此，冰淇淋模型在这些场景中仍然是实用的。

3.2 冰淇淋图形

4 冠军杯

4.1 冠军杯模型 引入

由于金字塔模型的缺点，导致，我们需要一个更加均衡的模型，需要同时具备金字塔模型与冰淇淋模型优点，随着不断的发展，这种新的模型就诞生了，即"冠军杯模型"。

4.2 冠军杯模型厉害之处

与金字塔模型和冰淇淋模型不同的是，冠军杯模型强调集成测试的重要性。

这种模型的出发点在于：

相比端到端测试，集成测试的执行速度更快；

相比单元测试，集成测试的有效性更高；

在单元测试，集成测试和端到端测试中，最能够兼顾执行速度，实现成本和测试有效性的，就数集成测试了。

4.3 应用场景

当然，于金字塔模型和冰淇淋模型相比，冠军杯模型是一种比较理想化的模型。

冠军杯模型能不能成功，取决于集成测试是否真的成本低且有效性高。

实际上，冠军杯模型只在特定的场合使用，它的典型应用场景是Web应用测试。

对于Web应用，集成测试对应服务端测试或接口测试。在基于Restful的接口测试中，用例执行速度非常快，通常在毫秒级。并且，大量的业务逻辑位于服务端，大多数软件问题也源自服务端，因此接口测试只要用例设计合理，其有效性可以期待。

事实上，评价测试还有另外一个维度。那就是在重构代码和修复bug(它们是比新特性开发更高频的代码活动)时，测试用例是否经常需要适配。

单元测试与代码的耦合性一般较高，因此我们在重构代码或修复bug时，经常不得不对单元测试用例进行修改。而接口测试测试的是软件对外的接口，不易发生变化，因而用例不需频繁更新，维护成本也就更低。

鉴于在Web应用中，接口测试具有执行速度快，测试有效性高，维护成本低的优势，值得大力投入。

冠军杯因而是一种更适合的模型。

4.4 冠军杯图形

5 总结

最后，我用一张图表，来总结 冰淇淋，金字塔、冠军杯 三个模型的特点。