敏捷实践 | 浅谈测试金字塔

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 外部接口测试无法快速发现上下游由于接口改动造成的一些问题，因此采用更多的集成测试可以更好地覆盖微服务的模型，更多细节可以参考文末的参考文献。

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

现在我邀请你进入我们的软件测试学习交流群：【**

746506216

】，备注“入群”， 大家可以一起探讨交流软件测试，共同学习软件测试技术、面试等软件测试方方面面，还会有免费直播课，收获更多测试技巧，

我们一起进阶Python自动化测试/测试开发，走向高薪之路。

**

喜欢软件测试的小伙伴们，如果我的博客对你有帮助、如果你喜欢我的博客内容，请 “点赞” “评论” “收藏” 一 键三连哦！