之前做测试培训的时候经常会被问到几个问题——我们项目没有自动化测试，老板想让我做，我搞了几个星期 selenium 怎么不行呢？我应该先做 API 测试还是 UI 测试，他们之前关系如何？很多初学者甚至认为自动化测试=UI 自动化=selenium。在学习具体自动化测试技术之前，我们应该先了解一个概念——自动化测试金字塔。
自动化测试金字塔，或者简称为测试金字塔，他不是一个标准或者规范，但是这个概念为我们提供了从 0 开始构建自动化测试体系的一个最佳实践的参考。尤其是对初学者来说，这个金字塔模型可以说是开展自动化测试之前的一个最高指导纲领，因此我们有必要了解测试金字塔的相关概念和落地方法。
当然，并不是任何项目在任何阶段都适合开展自动化测试，什么时候应该开展自动化测试不再本文展开讨论，我们先假设一个项目需要做自动化测试，那么这个时候应该如何开始。
测试金字塔是 2009 年 Mike Cohn 在他的著作《Succeeding with Agile》一书正式提出的。他是一个类比的概念，形容每一层，或者说不同集成阶段测试覆盖率和执行效率之间的一个相对关系。话不多说，我们直接上图。
接下来我们来看图说话，这个图看似很简单，有些内容可以很容有些内容我们可以深挖一下。首先需要明白的是，这个三层分类是根据项目集成复杂度抽象出来的三个层级，实际有几层看项目复杂情况，主要是中间层的集成测试展开可能有几层。之前我做过一个电信核心网项目，代码至少百万级别那种，中间哪一层集成测试就会有多层。
覆盖率是金字塔的核心，底层是最宽的，象征着 UT 覆盖率应该是最高的，越往上越低，这一点大家都能达成共识。但是有一点需要注意的是，每网上一层应该是对下面一层覆盖率的一个补充。简单说集成测试应该聚焦于 UT 不好覆盖的场景或者 UT 采用 mock 方式测试的场景，而顶层的 UI 自动化应该聚焦于整个流程的集成测试，覆盖集成测试和 UT 难以覆盖到的场景。
越接近代码层的测试，也就是单元测试，执行速度越快，离代码越远的测试，也就是 UI 测试，或者说端到端的测试，执行速度越慢。执行速度越快，意味着我们发现问题的时间越快，从而进一步减少了测试失败->定位问题->解决问题->再次触发自动化测试这个闭环的时间。
我们构建自动化测试通常是一个中间产品，是为了提高回归测试效率而产生的一个工具，并不是最终向客户交付的产品，因此我们更要考虑投入投入成本，也就是用例开发和维护的成本，成本对应图上标记的 dollar。从图上可以看出，UI 自动化显然是最不划算的，因为界面变化相对比较频繁，UI 自动化自然很容易受影响，UI 自动化用例的创建和维护也相对比较麻烦。
越往底层，颗粒度越细，问题越好隔离，发现问题越快，解决问题越快，越往上颗粒度越粗，问题越不好隔离，解决问题越慢。
测试金字塔看起来很简单明了，真正落地没有想象那么容易，我们从一下几点展开讨论
因为测试处于开发流水线的下游，项目团队从一开始其实要有构建自动化测试的概念，不仅仅是软件架构师，研发和测试也要有相应的意识，除此之外还需要有 CICD（持续化集成部署）的概念，不然项目一旦开始，很多自动化测试根本无法开展和落地。比如一个项目没有任何自动化测试，全靠测试手动检查，过了一段时间，老板突然心血来潮找到测试小张说，你看 XX 公司都在搞自动化测试了，我们也搞起来吧。天天黑盒测试的 tester 们首先想到了 UI 测试，研究了几个星期之后发现不仅 UI 变来变去，好多元素没有唯一 ID 或者 name，于是花了大量经历去搞元素定位，最后 case 也没写几个。老板过来一看，搞啥呢？看来你们技术不行啊，别搞了，还是继续手动测试吧。
参考我们的测试金字塔概念，其实从一开始就错了，自动化一定是从 UT 开始的，如果开发不配合，只靠测试通过后面的 API 自动化或者 UI 自动化发现问题，只能是事倍功半的效果。
有时候测试资源非常有限，没法用自动化覆盖每一层级的自动化测试，这个时候建议从 API 自动化或者集成测试的自动化开始，构建除了 UT 测试的第一层防火墙，有了一定效果之后再考虑从下往上开始增加更多的自动化测试用例。
在现代化的持续集成中，CICD 对于自动化测试就像基础设施一样。如果没有构建高效的 CICD 流水线，自动化测试的效果就会大打折扣，自动化测试其实只是整个 CICD 流水线的一个环节，只有构建了高效的 CICD，我们才能快速的触发自动化测试，发现问题，修复问题，然后再次触发让测试通过。
金字塔模型是自动化最佳实践的一个参考，并不是银弹，更不是万能钥匙。比如针对最近几年流行起来的微服务的概念，有人提出了针对传统测试金字塔的改进——蜂窝测试模型。
因为在微服务系统里面，每个微服务本身的功能相对单一，但是集成起来之后可能是一个蜘蛛网的模型，如果只是根据传统金字塔模型去做大量的 UT 覆盖，效果并不好，因为 UT 大量的 mock 外部接口测试无法快速发现上下游由于接口改动造成的一些问题，因此采用更多的集成测试可以更好地覆盖微服务的模型，更多细节可以参考文末的参考文献。
简言之，金字塔模型只是一个框架级别的参考，具体怎么实施一定要考虑项目的具体情况，不能生搬硬套。
我是成都的一名 tester，如果你也对测试感兴趣，欢迎加 wechat——Evolving_testers 一起交流。
