测试金字塔不是银弹

上一篇 / 下一篇  2020-09-02 17:08:04 / 个人分类:其他

  测试金字塔曾经神一样的存在,很多人认为制定测试策略知道测试金字塔就够了。
  真的是这样吗?今天,利用这篇短文跟大家聊聊测试金字塔。
  如果你恰好知道测试金字塔,也把它奉为测试策略的指导方针,那么这篇文章正好适合你。
  如果你还不了解测试金字塔,但是很关注质量和测试,那么不管你是什么角色,这篇文章也适合你。
  测试金字塔最早由MikeCohn提出,MartinFowler在文章TestPyramid中有详细介绍。如果你对测试金字塔不了解,可以先看Martin的文章。
  总结说来,测试金字塔是自动化测试分层覆盖情况的一个参考模型,其特点是:
  金字塔底层的测试是最接近代码的测试——单元测试,编写成本低、执行速度快、定位问题也更准确,但是离业务层较远,不能很好的体现业务价值;
  金字塔顶层的测试是UI层的自动化测试,这一层离业务近,能够体现业务流程覆盖情况,但是编写成本较高、执行速度较慢、不够稳定、定位问题也更难;
  而中间层的集成测试,则是成本和价值都是处于居中位置。
  因此,金字塔建议底层单元测试占比应该最多,而顶层UI层测试占比较少,中间层的集成测试居中,整体呈现金字塔结构。
  这适合比较理想的项目,而实际项目中可能有很多不适合测试金字塔的情形存在:
  1.微服务架构的系统
  微服务系统服务间的依赖关系和连通性,是微服务测试的关键,相对而言,服务内部出错可能性小。因此,对于微服务架构下的自动化测试应该是蜂巢结构或纺锤形,也就是中间层服务间的集成测试最多,底层的单元测试和上层的UI测试都相对较少。
  2.遗留系统改造
  为了支撑新型业务形态,越来越多的传统行业在向数字化转型,面临的一个问题是需要对大型业务复杂的遗留系统进行改造。这种情况,一般不适宜写大量的单元测试,技术和人员能力可能都不允许,而应该从顶层业务开始梳理,先增加业务层的功能测试作为基本保障,同时编写API集成测试和适量的单元测试。整个自动化测试覆盖情况,有可能是呈现为甜筒冰淇淋结构形式。
  3.人员技能不匹配的团队
  有的团队可能开发人员忙着开发不参与写测试,只有测试人员来负责写测试,而测试人员的要写单元测试还得熟悉底层代码实现,可能比较困难,通常也只能是写更多的UI测试。
  当然,这不是一个健康的状态,虽然客观存在,但是不提倡。
  4.测试策略不能仅依靠测试金字塔
  把测试金字塔当做测试策略制定的唯一参考规范,是不合适的。别说是只关注测试金字塔,就是只关注测试金字塔背后的分层策略,也是远远不够的。
  测试分层理论更多的是对自动化测试分层的指导,而测试策略需要考虑和关注的因素则比这个要多得多,比如:业务风险、质量目标、交付周期……很多很多,需要根据具体项目来确定。
  如果只是关注自动化测试要测哪些,没有关注业务风险,有可能把精力都放在了对错误功能的测试上,事倍功半,得不偿失。
  最后,测试金字塔不是万能的,不要只强调测试金字塔。

TAG: 职业发展 测试开发

旋枫的个人空间 引用 删除 旋枫   /   2020-09-05 09:25:43
根本没有什么金字塔模型,自欺欺人,误导各位测试工作者了
 

评分:0

我来说两句

Open Toolbar