Why? - 为什么要学习测试金字塔

之前做测试培训的时候经常会被问到几个问题——我们项目没有自动化测试,老板想让我做,我搞了几个星期 selenium 怎么不行呢?我应该先做 API 测试还是 UI 测试,他们之前关系如何?很多初学者甚至认为自动化测试=UI 自动化=selenium。在学习具体自动化测试技术之前,我们应该先了解一个概念——自动化测试金字塔。

自动化测试金字塔,或者简称为测试金字塔,他不是一个标准或者规范,但是这个概念为我们提供了从 0 开始构建自动化测试体系的一个最佳实践的参考。尤其是对初学者来说,这个金字塔模型可以说是开展自动化测试之前的一个最高指导纲领,因此我们有必要了解测试金字塔的相关概念和落地方法。

当然,并不是任何项目在任何阶段都适合开展自动化测试,什么时候应该开展自动化测试不再本文展开讨论,我们先假设一个项目需要做自动化测试,那么这个时候应该如何开始。

what?- 到底什么是测试金字塔

测试金字塔是 2009 年 Mike Cohn 在他的著作《Succeeding with Agile》一书正式提出的。他是一个类比的概念,形容每一层,或者说不同集成阶段测试覆盖率和执行效率之间的一个相对关系。话不多说,我们直接上图。

接下来我们来看图说话,这个图看似很简单,有些内容可以很容有些内容我们可以深挖一下。首先需要明白的是,这个三层分类是根据项目集成复杂度抽象出来的三个层级,实际有几层看项目复杂情况,主要是中间层的集成测试展开可能有几层。之前我做过一个电信核心网项目,代码至少百万级别那种,中间哪一层集成测试就会有多层。

覆盖率

覆盖率是金字塔的核心,底层是最宽的,象征着 UT 覆盖率应该是最高的,越往上越低,这一点大家都能达成共识。但是有一点需要注意的是,每网上一层应该是对下面一层覆盖率的一个补充。简单说集成测试应该聚焦于 UT 不好覆盖的场景或者 UT 采用 mock 方式测试的场景,而顶层的 UI 自动化应该聚焦于整个流程的集成测试,覆盖集成测试和 UT 难以覆盖到的场景。

执行速度

越接近代码层的测试,也就是单元测试,执行速度越快,离代码越远的测试,也就是 UI 测试,或者说端到端的测试,执行速度越慢。执行速度越快,意味着我们发现问题的时间越快,从而进一步减少了测试失败->定位问题->解决问题->再次触发自动化测试这个闭环的时间。

用例开发和维护成本

我们构建自动化测试通常是一个中间产品,是为了提高回归测试效率而产生的一个工具,并不是最终向客户交付的产品,因此我们更要考虑投入投入成本,也就是用例开发和维护的成本,成本对应图上标记的 dollar。从图上可以看出,UI 自动化显然是最不划算的,因为界面变化相对比较频繁,UI 自动化自然很容易受影响,UI 自动化用例的创建和维护也相对比较麻烦。

颗粒度

越往底层,颗粒度越细,问题越好隔离,发现问题越快,解决问题越快,越往上颗粒度越粗,问题越不好隔离,解决问题越慢。

How? - 如何落地

测试金字塔看起来很简单明了,真正落地没有想象那么容易,我们从一下几点展开讨论

对研发和测试团队的整体要求

因为测试处于开发流水线的下游,项目团队从一开始其实要有构建自动化测试的概念,不仅仅是软件架构师,研发和测试也要有相应的意识,除此之外还需要有 CICD(持续化集成部署)的概念,不然项目一旦开始,很多自动化测试根本无法开展和落地。比如一个项目没有任何自动化测试,全靠测试手动检查,过了一段时间,老板突然心血来潮找到测试小张说,你看 XX 公司都在搞自动化测试了,我们也搞起来吧。天天黑盒测试的 tester 们首先想到了 UI 测试,研究了几个星期之后发现不仅 UI 变来变去,好多元素没有唯一 ID 或者 name,于是花了大量经历去搞元素定位,最后 case 也没写几个。老板过来一看,搞啥呢?看来你们技术不行啊,别搞了,还是继续手动测试吧。
参考我们的测试金字塔概念,其实从一开始就错了,自动化一定是从 UT 开始的,如果开发不配合,只靠测试通过后面的 API 自动化或者 UI 自动化发现问题,只能是事倍功半的效果。

资源不够时候怎么办?

有时候测试资源非常有限,没法用自动化覆盖每一层级的自动化测试,这个时候建议从 API 自动化或者集成测试的自动化开始,构建除了 UT 测试的第一层防火墙,有了一定效果之后再考虑从下往上开始增加更多的自动化测试用例。

对 CICD 流水线依赖

在现代化的持续集成中,CICD 对于自动化测试就像基础设施一样。如果没有构建高效的 CICD 流水线,自动化测试的效果就会大打折扣,自动化测试其实只是整个 CICD 流水线的一个环节,只有构建了高效的 CICD,我们才能快速的触发自动化测试,发现问题,修复问题,然后再次触发让测试通过。

金字塔模型是万能钥匙么?

金字塔模型是自动化最佳实践的一个参考,并不是银弹,更不是万能钥匙。比如针对最近几年流行起来的微服务的概念,有人提出了针对传统测试金字塔的改进——蜂窝测试模型。

因为在微服务系统里面,每个微服务本身的功能相对单一,但是集成起来之后可能是一个蜘蛛网的模型,如果只是根据传统金字塔模型去做大量的 UT 覆盖,效果并不好,因为 UT 大量的 mock 外部接口测试无法快速发现上下游由于接口改动造成的一些问题,因此采用更多的集成测试可以更好地覆盖微服务的模型,更多细节可以参考文末的参考文献。

简言之,金字塔模型只是一个框架级别的参考,具体怎么实施一定要考虑项目的具体情况,不能生搬硬套。

我是成都的一名 tester,如果你也对测试感兴趣,欢迎加 wechat——Evolving_testers 一起交流。

参考文献


↙↙↙阅读原文可查看相关链接,并与作者交流