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

发布时间:2023年12月17日

自动化测试的分层模型

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

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

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

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

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

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

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

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

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

单元自动化

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

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

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

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

接口自动化

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

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

  • ??有比较好的流程规范

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

UI自动化

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

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

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

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

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

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

文章来源:https://blog.csdn.net/m0_47485438/article/details/134973270
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。