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 一起交流。
参考文献
感觉现在的自动化测试金字塔相对于以前的三角形，其实更加偏向于菱形，UI 与单元测试的比重减少，接口的比重增多，接口自动化相对于另两种成本低、效益高，是大部分公司的首选。
我学 “” 废了
感觉现在的自动化测试金字塔相对于以前的三角形，其实更加偏向于菱形，UI 与单元测试的比重减少，接口的比重增多，接口自动化相对于另两种成本低、效益高，是大部分公司的首选。
之前看的是各个阶段该做什么类型的测试，用金字塔展示顺序和测试的范围，现在看来还可以是：“他是一个类比的概念，形容每一层，或者说不同集成阶段测试覆盖率和知行效率之间的一个相对关系。”
从理论知识的角度，可以用来当作入门文章
图没了
没看到图呢
UT 采用 mock 方式测试的场景，而顶层的 UI 自动化应该聚焦于整个流程的集成测试，覆盖集成测试和 UT 难以覆盖到的场景。
--赞成这种思维，自动化需考虑 RIO,解决手工测试效率低或难于解决的问题
看了下原文，这两个图应该这样来对比：
PS：https://martinfowler.com/articles/practical-test-pyramid.html 这篇文章干货很多，值得细读。
个人感觉橄榄型要比金字塔型的可实施性以及实用性更高
