聊聊测试开发中测试策略模型有哪些？

lsekfe

1 引言
　　我们今天就来聊一聊，测试模型。
　　我们都知道，项目有项目的模型，
　　那么，测试策略，是否也有模型呢？
　　2 金字塔
　　2.1 金字塔模型 引入
　　金字塔模型，是一种非常重要也很常见的[url=]软件测试[/url]策略模型，在很多场合被奉为“金科玉律” 。
　　测试金字塔告诉我们，在单元测试，集成测试和端到端测试三个阶段的测试资源投入，应该满足接近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 总结
　　最后，我用一张图表，来总结 冰淇淋，金字塔、冠军杯 三个模型的特点。