测试模型的分类

• 1 引言
• 2 金字塔
• • 2.1 金字塔模型 引入
  • 2.2 金字塔弊端
  • 2.3 金字塔图形
• 3 冰淇淋
• • 3.1 冰淇淋模型 引入
  • 3.2 冰淇淋模型 优缺点
  • 3.2.1 缺点
  • 3.2.2 优点
  • 3.2 冰淇淋图形
• 4 冠军杯
• • 4.1 冠军杯模型 引入
  • 4.2 冠军杯模型厉害之处
  • 4.3 应用场景
  • 4.4 冠军杯图形
• 5 总结

1 引言

记得小鱼在上一篇聊到三种高性价比的测试，有的测开的同学就反馈，写的还过得去，希望再多讲一些测开领域资深的内容。
好的， 安排~ ~
我们今天就来聊一聊，测试模型。
我们都知道，项目有项目的模型，
那么，测试策略，是否也有模型呢/p>

2 金字塔

2.1 金字塔模型 引入

金字塔模型，是一种非常重要也很常见的软件测试策略模型，在很多场合被奉为“金科玉律” 。
测试金字塔告诉我们，在单元测试，集成测试和端到端测试三个阶段的测试资源投入，应该满足接近7:2:1的关系。

在金字塔模型中，软件测试的重心是在开发阶段的单元测试。
通过测试左移和质量内建，从源头上保障软件质量，实现预防bug(而非发现bug)的目标。

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

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

通过将大部分问题消灭在单元测试阶段，高成本，速度慢的端到端测试就可以更加聚焦。
通过将有限的资源投入到主干流程和核心业务的端到端测试上，我们可以保障在快速迭代的过程中，核心业务不受影响。

2.2 金字塔弊端

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

2.3 金字塔图形

4 冠军杯

4.1 冠军杯模型 引入

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

4.2 冠军杯模型厉害之处

与金字塔模型和冰淇淋模型不同的是，冠军杯模型强调集成测试的重要性。
这种模型的出发点在于：

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

4.3 应用场景

当然，于金字塔模型和冰淇淋模型相比，冠军杯模型是一种比较理想化的模型。
冠军杯模型能不能成功，取决于集成测试是否真的成本低且有效性高。
实际上，冠军杯模型只在特定的场合使用，它的典型应用场景是Web应用测试。

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

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

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

鉴于在Web应用中，接口测试具有执行速度快，测试有效性高，维护成本低的优势，值得大力投入。
冠军杯因而是一种更适合的模型。

4.4 冠军杯图形