自动化测试更适合缺陷预防,而不是提高测试效率

2018-02-09 14:11:00
大管家
原创 295 投稿得红包

很多人在回答为什么要开展自动化测试时,立即回想到的答案是提高测试效率。这种回答本身并没有错,但我想这只是问题的次要方面。在经过数次的自动化测试时间投入与效益比来看,可以基本得出,基于某个场景的测试脚本,在没有变更与维护情况下,脚本执行频率大于5-7次才基本能够收回投入成本,产生自动化效益。基于互联网的产品条件下,一个项目或系统如果包含 > =100个测试场景,事实远超这个数据的N倍,其实很难能够保证在收回自动化效益后,场景业务或数据才变更,通常变更是无法预期的或难以控制。


从技术的手段来保证:

曾经我们大胆试图在技术上创新,尝试如下技术攻关点:

1、能否通过手工用例,自动化生成脚本?

2、业务对象变更自动识别,与脚本自动化维护?


技术点1与2看起来很有挑战,很值得做,曾经为这样的Idea 也热血,与冷静思考过,并开始一步步逼近实现。但现在可以告诉大家四个字:“得不偿失”,其实上面技术点的本质,是在客观上用技术来代替现实世界中人的主观。

对于技术1,事实上很难能够找到通用的建模方式,来描述用例生成脚本;

对于技术2,   自动化技术是永远落后开发实现技术的发展,任何新的操作对象产生,必须跟进自动化识别技术,但搞自动化一帮人不可能在office意淫明天会有什么新的对象面世。即,真正意义上的做到完全无人职守,脚本自动生成或通过对象嗅探自动维护脚本,几乎是“布尔什维克”主义, 或者可以说实现上述两种技术方法,要先诞生实验室研究或论文阶段,类似于企业或像阿里巴巴,华为这样的大的公司来说,也不会有人站出来说这样做肯定有收益。


从流程的手段来保证:通过自动化测试体系中流程来约束变更的发现机制?如果,任何变更的源头来自于需求或者业务,他们可以在变更时告诉软件生命周期后期测试环节的QA工程师来维护脚本么?答案也是几乎很难,所以从上述技术与流程两个方面来看,就会涉及到测试效率提高的被动性,当然和重复生成测试数据与较稳定功能的回归,测试效率还是有提高的,但和刚才提到的测试效率提高的被动性来比,通过自动化测试来提高效率,其局限性就不言而喻了。


举例来看:

上个月发布了功能点A,有2000个case,这个月发布了功能点B又新增1000个case。

对于QA手工测试来讲,如果没有自动化测试介入的情况下,我们只是测试与后面1000个case相关的功能,如果时间允许的情况下,我们把顶多把A功能其中主要的500case测试一遍,就可以认为尽力测试到放心上线了,但问题恰恰出现在A功能2000减去500后的1500个case中,但如果我们用了自动化测试角度来看,但我们用了2000个case脚本,我们只要开发功能点B又新增1000个case的脚本,那么我们是可以保证在发布之前,用自动化来check 2000+ 1000=3000case的,手工测试的发布时间,肯定要早于用了自动化测试的发布时间,但测试的覆盖与范围从1500case增加到3000case


那么最后当然得出结论自动化测试更适合缺陷预防,而不是提高测试效率,希望看完这篇文章的同学,能够和我悟出同样结论与观点,也帮助影响你的主管或身边的同事。 

    技术交流QQ群 522720170 小强加悦软件测试群

    电影下载QQ群 533341883 XQ电影下载圈



    技术交流QQ群 522720170 小强加悦软件测试群

    电影下载QQ群 533341883 XQ电影下载圈

    博客分类