lsekfe 发表于 2020-7-30 10:29:32

测试金字塔不是银弹

金字塔模型是一种十分重要的软件测试策略模型,在很多场合被奉为“金科玉律” 。测试金字塔告诉我们,在单元测试,集成测试和端到端测试三个阶段的测试资源投入,应该满足接近7:2:1的关系。
  在金字塔模型中,软件测试的重心是在开发阶段的单元测试。通过测试左移和质量内建,从源头上保障软件质量,实现预防bug(而非发现bug)的目标。
  单元测试还具有实现成本低和执行速度快的特点,因而可以很容易地与持续集成和敏捷开发相结合,共同实现软件的快速迭代。
  通过将大部分问题消灭在单元测试阶段,高成本,速度慢的端到端测试就可以更加聚焦。通过将有限的资源投入到主干流程和核心业务的端到端测试上,我们可以保障在快速迭代的过程中,核心业务不受影响。

不得不说,金字塔模型是一种进步的模型,尤其是与它的前任模型相比。在金字塔模型诞生之前,主流的测试策略模型是倒金字塔模型,也叫冰淇淋模型。
  冰淇淋模型与金字塔模型完全相反,它更强调端到端测试。也就是说,我们主要依靠端到端测试来保障软件质量。由于端到端测试投入大,速度慢,周期长,经常需要数周甚至数月完成测试,无法做到快速迭代,因而在敏捷时代被金字塔模型取代。
  但是,冰淇淋模型也并非一无是处。这是因为,相比单元测试,端到端测试无疑可以给我们更高的信心。端到端测试模拟的是用户的实际行为,测试的是系统整体,更有能力发现全局的,对用户直接产生影响的问题,因而测试有效性更高。
  对于一些对质量要求极其苛刻,发布周期较长的系统级软件,例如电信软件,操作系统等,仍然十分依赖端到端测试。因此,冰淇淋模型在这些场景中仍然是实用的。

图2: 测试冰淇淋模型
  尽管具有时代的先进性,测试金字塔模型也是有短板的。由于金字塔模型过分依赖单元测试,而单元测试的测试对象是代码,离最终的用户场景可能存在距离。因此,单元测试即使很充分,即使实现了100%的代码覆盖率,其有效性仍然存在不足,从而降低我们对软件质量的信心。
  那么,有没有一种更加均衡,同时具备金字塔模型与冰淇淋模型优点的新模型呢?近年来,一种新的测试策略模型,即测试冠军杯模型,引起了业界的关注。
  与金字塔模型和冰淇淋模型不同的是,冠军杯模型强调集成测试的重要性。这种模型的出发点在于:相比端到端测试,集成测试的执行速度更快;相比单元测试,集成测试的有效性更高。因此,在单元测试,集成测试和端到端测试中,最能够兼顾执行速度,实现成本和测试有效性的,就数集成测试了。

当然,在我看来,冠军杯模型是一种比较理想化的模型。冠军杯模型能不能成功,取决于集成测试是否真的成本低且有效性高。实际上,冠军杯模型只在特定的场合使用,它的典型应用场景是Web应用测试。
  对于Web应用,集成测试对应服务端测试或接口测试。在基于Restful的接口测试中,用例执行速度非常快,通常在毫秒级。并且,大量的业务逻辑位于服务端,大多数软件问题也源自服务端,因此接口测试只要用例设计合理,其有效性可以期待。
  事实上,评价测试还有另外一个维度。那就是在重构代码和修复bug(它们是比新特性开发更高频的代码活动)时,测试用例是否经常需要适配。
  单元测试与代码的耦合性一般较高,因此我们在重构代码或修复bug时,经常不得不对单元测试用例进行修改。而接口测试测试的是软件对外的接口,不易发生变化,因而用例不需频繁更新,维护成本也就更低。
  鉴于在Web应用中,接口测试具有执行速度快,测试有效性高,维护成本低的优势,值得大力投入。冠军杯因而是一种更适合的模型。
  相对来说,金字塔模型其实非常适合规模较小,功能单一的库(library)软件。细心的朋友会发现,通常优秀的第三方开源库,其单元测试覆盖率都是很高的。由于业务简单,功能单一,我们可以比较容易地在代码级别实现充分的功能测试。
  最后,一张表总结冰淇淋模型,金字塔模型和冠军杯模型的特点。






Miss_love 发表于 2020-7-30 14:15:01

:handshake

楠族开心果 发表于 2020-7-31 09:50:38

谢谢管大的分享

赵佳乐SMILE 发表于 2020-7-31 18:43:29

学习

高祎梦吖 发表于 2020-9-9 13:49:48

有用有用
页: [1]
查看完整版本: 测试金字塔不是银弹