前言
一直以来,测试团队都面临一个迫在眉睫的问题:自动化测试收效甚微,甚至被认为是”为了实现自动化而自动化“。之前写过一篇博客自动化测试的评价维度,其实自动化的评价不乏有其他的评价指标。但这里想说的一点是,自动化方案产出低的一个重要原因是自动化整体方案的不合理。
下面根据自己的经验,做下总结,个人之见,不免有不足之处,欢迎补充交流!!!
自动化整体方案不合理的证据
1、自动化发现bug率太低/甚至很长一段时间没有发现过bug
可能你会说自动化本来就不如手工测试容易暴露问题,况且有些业务本来bug就不多。但注意了,这里强调的是自动化发现bug的占比,如果这个比例趋向于0,那自动化实现的价值还有多少呢
2、没有减少手工成本/或时间成本
自动化虽然也不断暴露问题,但自动化测试一次,与手工测试一次相比,并没有节省多少 人工成本和时间成本(例如,执行过程中还需要人工参与等),甚至反而增加了自动化的维护成本。那么这样算起来,自动化可能成为了一种”摆设“。
这种情况流行的一种说法是:”为了自动化而自动化“。将不适合做自动化的地方,强行自动化实现后,是得不偿失的。
3、自动化运行失败, 极大概率并不能说明真的bug存在
这在实际业务中,是大多数实现自动化的测试同学比较痛心疾首的情况了。日常的工作就是不断调试自动化,确保运行时不再那么频繁失败了。很早之前,自己也曾经历过这样的痛苦。
这种情况除了白白浪费很多时间精力外,还会让参与自动化建设的同学丧失继续实现自动化的信心。 说白了,自动化实现的目标是帮测试同学干活的,如果失去这个作用,还不如果断放弃自动化。
4、自动化执行后仍然需要重复投入手工测试
这种自动化运行类似于”空跑“一样,并没有起到什么作用,其实这种情况也是”为了自动化而自动化“的一种证明了。目前很多团队评价自动化好坏的重要指标就是自动化case数量、运行稳定性/成功率,其实这两个指标对评价自动化并没有那么的有说服力。
自动化整体方案不合理的几个原因
根本原因是自动化整体方案与实施不合理,具体说来,有几点值得注意:
1、自动化方案与手工测试流程千差万别
不会做手工测试的同学,真心很难做好自动化测试(当然了,这里的自动化排除掉压测)。不敢想象,如果自动化方案与手工测试流程完全不在一个维度上,自动化怎么能像手工测试一样大量暴露问题呢!!!
2、实现的自动化只能”一条腿走路“
这里说的”一条腿走路“是说,只实现了半自动化,并没有实现100%的自动化,运行前/中/后需要人为参与。 半自动化的例子,在实际的业务中,还是挺多见的。比如,自动化执行前输入人为输入一些参数、或自动运行前需要人为准备一些数据、或自动化运行后需要人为check一些东西。
3、试图将一切自动化
所谓过犹不及,试图将一切自动化的后果是自动化变得臃肿不堪,要么常常失败,要么成了摆设。
4、没有根据业务实现特点进行自动化
各个公司/团队的业务、实现千差万别,哪怕是不同产品线都会因为团队合作、迭代、架构设计的不同,导致自动化方案的千差万别,进而自动化使用的工具、平台都会有很大不同。因而,在别的业务上运行完美的自动化,拿过来直接用,很可能会产生”水土不服“。
如果自动化目前用的不顺手,或者没有达到效果预期,那么不妨评估一下,你的自动化方案是不是也正在”水土不服“呢
写在最后
自动化实现的方法论:
1、承认不是所有的东西都适合自动化;
2、自动化测试的前提是强大地进行手工测试;手工测试是自动化测试的必要条件。自动化测试应该尽可能模拟手工测试的流程
ps: 这里的手工测试,当然是完美、大神级别的了, 并不是仅仅是说点点点的功能级别测试
3、自动化实现之前,不妨先列一些自动化实现最为核心的目标。
在频繁的迭代上线过程中,如果遗漏到线上的问题太明显,太多,这是测试技能问题;但如果线上无遗留,测试技能没有问题,只能说明自动化整体方案可能有很大的提升空间。文章来源:https://www.toymoban.com/news/detail-688530.html
【整整200集】超超超详细的Python接口自动化测试进阶教程合集,真实模拟企业项目实战文章来源地址https://www.toymoban.com/news/detail-688530.html
到了这里,关于自动化方案不合理的原因浅析的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!