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 总结
最后，我用一张图表，来总结 冰淇淋，金字塔、冠军杯 三个模型的特点。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
