分层自动化测试模型变与不变
最近在思考自动化分层模型，多少有些相关，所以就赶紧总结出来。
分层自动化测试模型的发展
分层自动化测试模型最早是由Mike Cohn在2009年出版的《Succeeding with Agile》书中的第十六章进行阐述的，他说“测试金字塔是分层测试的一种最佳实践“。金字塔自动化测试模型如上图A所示，从下往上分为单元测试、接口测试、界面测试（其实我更习惯于叫UI自动化）。那么他为什么是金字塔的样子呢？这其实是和每一类自动化测试的投入产出比相关联的。
“越早开始测试，发现问题修复问题的成本越低”，这句话决定了在单元测试阶段发现的问题修复成本最低，因此应该加大单元测试的投入，因此在金字塔模型中单元测试就应该占据的面积最大，以此类推，接口测试次之，界面测试占面积最少。也就是说，在金字塔模型中各类测试所占的面积代表了对应测试的投入成本。
随着互联网的快速发展，以及微服务、容器的快速推广，金字塔模型已经不是非常满足业务交付的需求，测试重心逐渐的偏移到了接口测试，接口测试的投入越来越大，相比单元测试的投入越来越少。接口测试逐渐的内部分成单接口测试和业务接口测试，单接口测试向下做了一个本该由单元测试的工作，因此单接口测试会充分测试接口的稳定性，这部分主要通过边界值以及其他一些测试用例设计方法完成测试用例设计。业务接口测试用例主要是通过一些接口的调研模拟部分业务来验证业务实现的真确性，这部分常用场景法等测试用例设计方法。如上图B所示，称之为橄榄球模型。
分层测试模型为什么分层
前面我说过，金字塔分层自动化模型单元测试投入最大是因为单元测试的投入产出比最大，那么为什么不能将这种最大收益的测试类型最大化，那岂不是应该为最优秀的自动化测试实践吗？
其实，这不能达到最大收益，反而会降低整体自动化测试效果。如上图所示蓝色部分（蓝色部分表示单元测试）所示，单元测试的被测件是每一个逻辑单元，在做单元测试的时候会将外部依赖、数据依赖等通过TestDouble进行解耦，这就可以看出，单元测试没有覆盖到真实数据的依赖、外部服务依赖等，而且它只测试了每一个逻辑单元（很大程度上可以理解为是一个函数），那么函数和函数间的调用却没有被测试到称之为测试间隙，如上图绿色部分（绿色部分表示接口测试）所示，通过单接口测试和业务接口测试就可以弥补单元测试的测试间隙，那么黄色部分（黄色部分代表界面自动化测试）通过模拟主要业务，弥补了接口测试的测试间隙。
发展中的分层自动化测试模型的不变实践
无论分层自动化测试模型怎么发展，UI自动化测试部分却永远没有发生变化。这是为什么呢？
首先，UI测试需要SUT的各个组件都处于就绪状态。那么为了支持UI自动化测试就需要在准备测试环境、测试数据这等，需要投入很多人力物力。
其次，UI是给人与系统进行交互，用户手工操作速度就比计算机运行速度慢了很多个数量级。
所以无论怎么发展，分层自动化测试模型都没有增加在UI自动化上的投入。虽然UI自动化测试在分层模型中并没有绝对的变化，但是UI自动化测试也并没有完全被取代，这说明UI自动化测试还是有其的优越性的：
- 1、UI自动化测试可以大大缩短反馈周期，发现BUG、修复BUG相较于手工测试更快更容易。
- 2、UI自动化测试的一个合格的测试场景需要开发工程师、测试工程师、产品经理紧密的合作，相互理解，这也使得团队更加关注于质量内建，团队全部的角色都会关注业务价值交付。
合适的技术还是需要用到正确的地方，UI自动化测试最适合验收测试阶段。验收测试是测试部分的最后阶段，因此在这个阶段中被测试系统的外部依赖会真实访问外部依赖服务。利用UI自动化测试实现自动化验收测试，能够加快验收测试反馈周期，提升验收测试阶段的效率。自动化验收测试会模拟系统使用的主要流程，那么这里的主要流程在最开始的设计UI自动化测试的时候有可能覆盖并不全面，因此会在后续迭代中不断的发现遗漏主要业务场景，并马上变写一个UI自动化测试覆盖这个场景，逐渐就会的得到一个完善的自动化验收测试的测试用例集。那么自动化验收测试也并不是随意执行的，如果执行频次很高，那么无论是从测试耗时还是外部依赖系统的压力上都会有所影响，所以自动化验收测试推荐每天运行一次的频次。
总结
未来伴随则自动化测试技术的发展，分层自动化测试模型也会不断演进和发展，但是无论如何演进分层模型的依据还是测试投入，因此未来如果智能化测试能够替代人工投入那么分层模型也会有根本性的改变的。
