51Testing软件测试论坛

标题: 聊聊测试开发中测试策略模型有哪些? [打印本页]

作者: lsekfe    时间: 2021-1-27 09:52
标题: 聊聊测试开发中测试策略模型有哪些?
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 总结
  最后,我用一张图表,来总结 冰淇淋,金字塔、冠军杯 三个模型的特点。








欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2