分层自动化测试模型的发展

系统管理员 2023-09-24 16:33 146阅读 0赞

![9e55a7ac9d1f45458ce5e55805266330.png][]

分层自动化测试模型最早是由Mike Cohn在2009年出版的《Succeeding with Agile》书中的第十六章进行阐述的，他说“测试金字塔是分层测试的一种最佳实践“。金字塔自动化测试模型如上图A所示，从下往上分为单元测试、接口测试、界面测试（其实我更习惯于叫UI自动化）。那么他为什么是金字塔的样子呢？这其实是和每一类自动化测试的投入产出比相关联的。

“越早开始测试，发现问题修复问题的成本越低”，这句话决定了在单元测试阶段发现的问题修复成本最低，因此应该加大单元测试的投入，因此在金字塔模型中单元测试就应该占据的面积最大，以此类推，接口测试次之，界面测试占面积最少。也就是说，在金字塔模型中各类测试所占的面积代表了对应测试的投入成本。 随着互联网的快速发展，以及微服务、容器的快速推广，金字塔模型已经不是非常满足业务交付的需求，测试重心逐渐的偏移到了接口测试，接口测试的投入越来越大，相比单元测试的投入越来越少。接口测试逐渐的内部分成单接口测试和业务接口测试，单接口测试向下做了一个本该由单元测试的工作，因此单接口测试会充分测试接口的稳定性，这部分主要通过边界值以及其他一些测试用例设计方法完成测试用例设计。业务接口测试用例主要是通过一些接口的调研摸你部分业务来验证业务实现的真确性，这部分常用场景法等测试用例设计方法。如上图B所示，称之为橄榄球模型。

### 分层测试模型为什么分层 ###

![3e5e5b2fa3544e79a194019085adba48.png][]

前面我说过，金字塔分层自动化模型单元测试投入最大是因为单元测试的投入产出比最大，那么为什么不能将这种最大收益的测试类型最大化，那岂不是应该为最优秀的自动化测试实践吗？

![5ad40d7b224b4c73a05195ef44e078a3.png][]

其实，这不能达到最大收益，反而会降低整体自动化测试效果。如上图所示蓝色部分（蓝色部分表示单元测试）所示，单元测试的被测件是每一个逻辑单元，在做单元测试的时候会讲外部依赖、数据依赖等通过TestDouble进行解耦，这就可以看出，单元测试没有覆盖到真实数据的依赖、外部服务依赖等，而且它只测试了每一个逻辑单元（很大程度上可以理解为是一个函数），那么函数和函数间的调用却没有被测试到称之为测试间隙，如上图绿色部分（绿色部分表示接口测试）所示，通过单接口测试和业务接口测试就可以弥补单元测试的测试间隙，那么黄色部分（黄色部分代表界面自动化测试）通过模拟主要业务，弥补了接口测试的测试间隙。

### 分层中的测试实践要点 ###

#### 单元测试实践要点 ####

单元测试是分层自动化中最快速的测试活动，它聚焦在一个函数是否按照预期运行，从而可以判定完成的feature是否能够完成预期结果。

![c8d83d4f905040d5b9367e6af6289c13.png][]

单元测试中需要使用一些解耦框架完成外部依赖的解耦，在单元测试中常用的解耦技术包含了Mock、Stub等。在单元测试中比较推崇将函数对其他函数的调用、外部API的调用以及数据层的依赖全部解耦。假设有一个函数调用了一个外部的API，在获得这个API的response后，函数会更具这个response的内容做一些后续处理。在做单元测试的时候，这个外部的API就需要等价的解耦。常规做法会使用一些mock框架返回一个预先定宇好的response，这个预先定义好的response能够让被测函数执行想要覆盖的代码逻辑。 由此可见，单元测试的好处就在于它运行速度快，执行成本低（因为外部的依赖都解耦了所以运行不需要其他很多外部服务支持），能够覆盖全面的代码路径。由于大范围的使用Mock等解耦技术，因此也导致很多外部交互没有被验证到。

#### API自动化测试要点 ####

API自动化测试就验证服务端的逻辑是否满足预期设计，这里既包含了单个API的测试也包含了多个API模拟业务逻辑的测试。在对单个API测试用例设计过程中，比较常用的测试用例设计方法是边界法、等价类划分法等；在对多个API模拟业务逻辑的测试用例设计中，常用的因果图法、场景法等。在单个API测试中更加推荐使用一些解耦服务对外部服务依赖进行解耦，这里推荐的解耦技术是服务虚拟化。 对于一些运行速度慢、故障时间长、部署成本高等的外部依赖的服务，我们都推荐通过解耦技术进行解耦，以达到低成本、高效能的完成测试。

#### UI自动化测试要点 ####

UI自动化测试更加关注的是最终用户的交互角度，因此更加推荐在验收测试的实践中利用UI自动化测试完成。这个时候无论系统外部依赖有多么的复杂、成本有多高，都要真实的集成到一次进行测试。这也是最容易出现Flaky Test的地方。 UI自动化测试投入成本高，运行效率相对低下，但是这部分发现的问题确实站在E2E测试的角度发现的问题，更加的容易被客户触发。

### 发展中的分层自动化测试模型的不变实践 ###

无论分层自动化测试模型怎么发展，UI自动化测试部分却永远没有发生变化。这是为什么呢？

首先，UI测试需要SUT的各个组件都处于就绪状态。那么为了支持UI自动化测试就需要在准备测试环境、测试数据这等，需要投入很多人力物力。 其次，UI是给人与系统进行交互，用户手工操作速度就比计算机运行速度慢了很多个数量级。

所以无论怎么发展，分层自动化测试模型都没有增加在UI自动化上的投入。虽然UI自动化测试在分层模型中并没有绝对的变化，但是UI自动化测试也并没有完全被取代，这说明UI自动化测试还是有其的优越性的：

*  1、UI自动化测试可以大大缩短反馈周期，发现BUG、修复BUG相较于手工测试更快更容易。
 *  2、UI自动化测试的一个合格的测试场景需要开发工程师、测试工程师、产品经理紧密的合作，相互理解，这也使得团队更加关注于质量内建，团队全部的角色都会关注业务价值交付。

合适的技术还是需要用到正确的地方，UI自动化测试最适合验收测试阶段。验收测试是测试部分的最后阶段，因此在这个阶段中被测试系统的外部依赖会真实访问外部依赖服务。利用UI自动化测试实现自动化验收测试，能够加快验收测试反馈周期，提升验收测试阶段的效率。自动化验收测试会模拟系统使用的主要流程，那么这里的主要流程在最开始的设计UI自动化测试的时候有可能覆盖并不全面，因此会在后续迭代中不断的发现遗漏主要业务场景，并马上变写一个UI自动化测试覆盖这个场景，逐渐就会的得到一个完善的自动化验收测试的测试用例集。那么自动化验收测试也并不是随意执行的，如果执行频次很高，那么无论是从测试耗时还是外部依赖系统的压力上都会有所影响，所以自动化验收测试推荐每天运行一次的频次。

### 总结 ###

未来伴随则自动化测试技术的发展，分层自动化测试模型也会不断演进和发展，但是无论如何演进分层模型的依据还是测试投入，因此未来如果智能化测试能够替代人工投入那么分层模型也会有根本性的改变的。

## 资源分享 ##

**下方这份完整的软件测试视频学习教程已经上传CSDN官方认证的二维码，朋友们如果需要可以自行免费领取 `【保证100%免费】`**

![在这里插入图片描述][4b0f9bb1a4dd4ab3a24710143c5cd349.png_pic_center]

![在这里插入图片描述][d96b58a511f84668b59f3f620964da07.png_pic_center]

[9e55a7ac9d1f45458ce5e55805266330.png]: https://img-blog.csdnimg.cn/9e55a7ac9d1f45458ce5e55805266330.png
[3e5e5b2fa3544e79a194019085adba48.png]: https://img-blog.csdnimg.cn/3e5e5b2fa3544e79a194019085adba48.png
[5ad40d7b224b4c73a05195ef44e078a3.png]: https://img-blog.csdnimg.cn/5ad40d7b224b4c73a05195ef44e078a3.png
[c8d83d4f905040d5b9367e6af6289c13.png]: https://img-blog.csdnimg.cn/c8d83d4f905040d5b9367e6af6289c13.png
[4b0f9bb1a4dd4ab3a24710143c5cd349.png_pic_center]: https://img-blog.csdnimg.cn/4b0f9bb1a4dd4ab3a24710143c5cd349.png#pic_center
[d96b58a511f84668b59f3f620964da07.png_pic_center]: https://img-blog.csdnimg.cn/d96b58a511f84668b59f3f620964da07.png#pic_center