测试金字塔不是银弹
金字塔模型是一种十分重要的软件测试策略模型，在很多场合被奉为“金科玉律” 。测试金字塔告诉我们，在单元测试，集成测试和端到端测试三个阶段的测试资源投入，应该满足接近7:2:1的关系。在金字塔模型中，软件测试的重心是在开发阶段的单元测试。通过测试左移和质量内建，从源头上保障软件质量，实现预防bug(而非发现bug)的目标。
单元测试还具有实现成本低和执行速度快的特点，因而可以很容易地与持续集成和敏捷开发相结合，共同实现软件的快速迭代。
通过将大部分问题消灭在单元测试阶段，高成本，速度慢的端到端测试就可以更加聚焦。通过将有限的资源投入到主干流程和核心业务的端到端测试上，我们可以保障在快速迭代的过程中，核心业务不受影响。
不得不说，金字塔模型是一种进步的模型，尤其是与它的前任模型相比。在金字塔模型诞生之前，主流的测试策略模型是倒金字塔模型，也叫冰淇淋模型。
冰淇淋模型与金字塔模型完全相反，它更强调端到端测试。也就是说，我们主要依靠端到端测试来保障软件质量。由于端到端测试投入大，速度慢，周期长，经常需要数周甚至数月完成测试，无法做到快速迭代，因而在敏捷时代被金字塔模型取代。
但是，冰淇淋模型也并非一无是处。这是因为，相比单元测试，端到端测试无疑可以给我们更高的信心。端到端测试模拟的是用户的实际行为，测试的是系统整体，更有能力发现全局的，对用户直接产生影响的问题，因而测试有效性更高。
对于一些对质量要求极其苛刻，发布周期较长的系统级软件，例如电信软件，操作系统等，仍然十分依赖端到端测试。因此，冰淇淋模型在这些场景中仍然是实用的。
图2: 测试冰淇淋模型
尽管具有时代的先进性，测试金字塔模型也是有短板的。由于金字塔模型过分依赖单元测试，而单元测试的测试对象是代码，离最终的用户场景可能存在距离。因此，单元测试即使很充分，即使实现了100%的代码覆盖率，其有效性仍然存在不足，从而降低我们对软件质量的信心。
那么，有没有一种更加均衡，同时具备金字塔模型与冰淇淋模型优点的新模型呢？近年来，一种新的测试策略模型，即测试冠军杯模型，引起了业界的关注。
与金字塔模型和冰淇淋模型不同的是，冠军杯模型强调集成测试的重要性。这种模型的出发点在于：相比端到端测试，集成测试的执行速度更快；相比单元测试，集成测试的有效性更高。因此，在单元测试，集成测试和端到端测试中，最能够兼顾执行速度，实现成本和测试有效性的，就数集成测试了。
当然，在我看来，冠军杯模型是一种比较理想化的模型。冠军杯模型能不能成功，取决于集成测试是否真的成本低且有效性高。实际上，冠军杯模型只在特定的场合使用，它的典型应用场景是Web应用测试。
对于Web应用，集成测试对应服务端测试或接口测试。在基于Restful的接口测试中，用例执行速度非常快，通常在毫秒级。并且，大量的业务逻辑位于服务端，大多数软件问题也源自服务端，因此接口测试只要用例设计合理，其有效性可以期待。
事实上，评价测试还有另外一个维度。那就是在重构代码和修复bug(它们是比新特性开发更高频的代码活动)时，测试用例是否经常需要适配。
单元测试与代码的耦合性一般较高，因此我们在重构代码或修复bug时，经常不得不对单元测试用例进行修改。而接口测试测试的是软件对外的接口，不易发生变化，因而用例不需频繁更新，维护成本也就更低。
鉴于在Web应用中，接口测试具有执行速度快，测试有效性高，维护成本低的优势，值得大力投入。冠军杯因而是一种更适合的模型。
相对来说，金字塔模型其实非常适合规模较小，功能单一的库(library)软件。细心的朋友会发现，通常优秀的第三方开源库，其单元测试覆盖率都是很高的。由于业务简单，功能单一，我们可以比较容易地在代码级别实现充分的功能测试。
最后，一张表总结冰淇淋模型，金字塔模型和冠军杯模型的特点。
:handshake 谢谢管大的分享 学习 有用有用
页:
[1]
