自动化框架及其设计搭建浅谈（二）--分层自动化测试
目录
测试金字塔模型
分层自动化测试的模型
分层自动化测试的最佳实践
自动化分层测试的误区
自动化框架的设计与自动化分层
自动化测试的设计建议
分层自动化测试，顾名思义，就是分层的自动化测试，那么自动化测试为什么要分层呢？
举个栗子：
某天开发改了一个功能，让你最好全量回归一下。哇哦~ 作为测试一听这话，内心复杂，其实全量回归使用自动化测试代替手工做全量回归是比较好的方法，但是团队的自动化的覆盖范围到什么程度呢？要知道自动化的覆盖范围，这就首先要求自动化测试要进行分层。
测试金字塔模型
国内互联网界习惯将测试金字塔模型层称为分层测试，测试金子塔模型将自动化测试从下到上分为3个层次（1）单元测试（2）服务测试（3）UI测试，以下表格为三者区别
| 单元测试 | 服务测试 | UI测试 | |
|---|---|---|---|
| 面向对象 | 系统的最小组成单元，可以是函数，方法，类，对象 | 集成在一起的服务进行测试 | 集成好的软件整体 |
| 黑盒/白盒测试 | 白盒 | 可以是白盒也可以是黑盒，甚至是灰盒测试 | 黑盒 |
| 是否有外部依赖 | 否 | 依赖其他集成在一起的模块 | 依赖其他集成在一起的模块 |
| 执行时间 | 毫秒到秒级 | 分钟级 | 小时级 |
| 编写语言 | 一般和开发语言一致 | 不要求语言 | 不要求语言 |
| 编写人员 | 通常是开发，测试介入较少 | 通常是测试 | 通常是测试 |
测试金字塔模型图如下：
根据测试金字塔模型可知：
（1）要多做单元测试，少做UI测试
（2）自动化测试要分层，分颗粒度进行
分层自动化测试的模型
随着互联网行业的发展，测试金字塔模型也有了更多的演进方案，当前主流的自动化测试分层模型有，有测试金字塔演化模型，奖杯模型，蜂巢模型等。我们主要介绍蜂巢模型，模型如下图
蜂巢模型主要适用于微服务架构开发的系统，原理是：在微服务开发模型下，集成测试，契约测试应该在自动化测试总占据最大比重。然后针对每一个具体的微服务，有适量的单元测试，最后针对微服务整体进行测试（端到端测试 如UI测试）
分层自动化测试的最佳实践
- 测试尽量下沉
无论是哪种模型都是强调单元测试在整体中的占比，一个bug在单元测试过程中就能发现能够在分钟级别的时间解决问题，一旦这个bug拖到了端到端测试的过程才发现，那么就可能花费1天的时间解决。一个bug从单元测试拖到端到端测试，定位范围也会变大，对应的bug定位时间也会变长，所以单元测试是减少测试成本的最直接办法。
- 不要重复测试
造成重复测试的原因一般是测试用例重复，基础代码重复。自动化测试用例执行前总会有些前置执行业务操作，多次执行相同的业务流程，不仅会延长测试用例执行时间，也会造成测试用例之间耦合性过高，一旦有系统性的改动，那将会影响很多测试用例。
基础代码重复就是指框架的某些基础功能不够模块化，公用功能重复建设。
- 合理选择分层模型
微服务开发模型是当前最受欢迎的开发模型之一，那么适合的分层自动化的模型就是我们前面提到的蜂巢模型，所以一切分层模型要根据实际开发情况或者业务情况而定。
- 考虑用户场景
通常一个功能的实现是需要前端和后端一起合作完成，那么后端的单元测试覆盖率达到100%，或者前端接口的覆盖率达到100%就能证明完全没有bug了吗？肯定不是，后端需要通过接口自动化测试验证，而前端需要通过UI自动化测试才醒。
自动化分层测试的误区
- 测试一定是按顺序执行的
金字塔测试模型不是一定要按照从下到上的顺序执行，即一定先有单元测试，再有服务测试，再有UI测试，如果是一个新的项目顺序测试是没有问题的，如果这个项目已经上线很久了，该项目的单元测试并没有被利用起来，那么集中补录单元测试是没有意义的
- 分层自动化测试跨层执行是反模式
自动化测试分层之后，也是会有可能进行跨层测试的。
- 分层后单元测试越多越好
根据金字塔模型，理论上单元测试是越充分越好，不过也要考虑成本，效率的平衡
自动化框架的设计与自动化分层
自动化框架的设计也要遵循自动化分层
- 按照测试类型分层
根据测试目的不同分为接口自动化框架，UI自动化框架，性能自动化框架，混合自动化框架
- 按照测试业务分层
根据业务分层，最常见的就是三层架构自动化测试框架
测试层：测试套件，测试用例，测试数据
业务层：与业务交互的功能，UI自动化里面的PageObject，控制业务流程的制定
核心层：就是所有能让框架运行起来的功能，数据库，日志，报告等
自动化测试的设计建议
- 尽量模块化，插件化
- 很多模块化的功能
- 测试用例，测试数据应该跟业务逻辑隔离，独立维护。
- 框架应有一定的容错能力，遇到错误能识别，能够尽量恢复
- 版本控制和详尽完备的文档。