分层自动化测试的实战思考！

自动化测试的分层模型

自动化测试的分层模型，我们应该已经很熟悉了，按照分层测试理念，自动化测试的投入产出应该是一个金字塔模型。越是向下，投入/产出比就越高，但开展的难易程度/成本和技术要求就越高，但是根据目前各个公司实战落地方案来说，逐渐演变成橄榄球模型，单元测那一块各个公司落地都不是非常顺利，原因主要是依靠开发进行。如下图：

美国质量管理大师威廉·戴明博士提出产品质量是生产出来的，不是检验出来的，只有在生产过程中的每个环节，严格按照生产工艺和作业指导书要求进行，才能保证产品的质量。如果忽略过程控制，只靠检验，是不可能保证产品质量的，因为质量检验，只能剔除次品和废品，并不能提高产品质量。也就是说，质量控制的重点决不能放在事后把关，而必须放在制造阶段，即生产过程阶段。

从质量控制的角度来说，单元测试自动化是最应该值得投入资源去做的。因为代码的质量问题越早发现，修复的成本越低，对最终交付质量的影响也越小。

当前实际情况下，大多数公司均在API自动化上投入大量资源。这主要源于众多公司采用的前后端分离架构和复杂化的业务场景。接口作为交互和逻辑处理层的关键部分，其自动化覆盖率的提升能够确保数据处理逻辑的准确性，从而为后续测试节省大量时间，显著提升测试效率。

从用户体验的角度来说，UI层的自动化测试也是必不可少的，界面交互才是用户的最直观感受，如果用户感觉不好用，用户就会舍弃选择其他的产品。

我们都知道影响质量的因素有成本、范围和时间。在技术的落地实践过程中，尽管技术实践的重要性不言而喻，但我们仍需在成本和产出之间做出选择和平衡。因此，根据具体的业务场景选择最适合的自动化测试方式显得尤为重要。

现在我也找了很多测试的朋友，做了一个分享技术的交流群，共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源，没人解答问题，坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化，性能，安全，测试开发等等方面有一定建树的技术大牛
分享他们的经验，还会分享很多直播讲座和技术沙龙
可以免费学习！划重点！开源的！！！
qq群号：691998057【暗号：csdn999】

自动化测试分层的实战前置条件

先了解一下不同的自动化测试各自的特点，再来说它们的适用场景。

单元自动化

单元测试的目标通常是代码中的类、方法或者某个特定的函数，这些都是构成系统或服务的微小单元。因此，实施单元自动化测试变得非常重要，但有几个前置条件：

• • 对业务需求细节需要非常熟悉，如果不熟悉业务和需求细节，单元测试就聊胜如无

• • 由于公司很少或者没有专门的单元测试人员，从而进行单元测试主要是对应开发人员，开发人员在需求迭代期间需要一边写业务代码一边写单元测试代码，迭代需求需要足够的时间，但往往每个迭代时间不足，现在常见的都是敏捷开发模式

• • 需要团队领导支持， 如果没有团队领导的支持，往往大家都不会进行单元测试

接口自动化

与UI自动化相比，接口自动化的任务是验证数据交互和逻辑的准确性，这将检验系统设计和开发编码规范。因此，接口自动化的实施前提或适用场景包括：

• • 比较完善的技术架构和接口说明文档

• • 有比较好的流程规范

• • 比较稳定的环境和有相关的基础设施

UI自动化

UI自动化落地最大的挑战是需求和UI设计的频繁变化会导致大量的变更，如果需求和UI设计频繁变化，那测试框架、脚本甚至相关的测试数据都需要频繁的变更，环境和测试的维护成本大概率会高居不下，因此持续稳定的系统是UI自动化测试落地很需要的一个属性。UI自动化落地较为适用的场景有：

• • 比较稳定的系统版本迭代，回归测试

• • 接口巡检无法覆盖的线上业务主流程巡检工作

• • 不稳定系统里面高频稳定的小范围功能操作

自动化测试只是保证质量的众多技术手段之一。决定是否进行分层测试，以及投入多少资源于哪种测试手段，主要取决于我们面临的问题以及这些问题对质量的影响程度。接着，我们会根据具体情境选择最合适的测试手段来解决问题。成本、覆盖范围和时间仍然是影响我们进行技术选型和实施的最主要因素。

END今天的分享到此结束了！点赞关注不迷路！