本文共 1444 字,大约阅读时间需要 4 分钟。
很多人在回答为什么要开展时,立即回想到的答案是提高测试效率。
这种回答本身并没有错,但我想这只是问题的次要方面。在经过数次的自动化测试时间投入与效益比来看,
可以基本得出,基于某个场景的测试脚本,在没有变更与维护情况下,脚本执行频率大于5-7次才基本能够收回
投入成本,产生自动化效益。基于的产品条件下,一个项目或系统如果包含 > =100个测试场景,事实远超这个数据的N倍,其实很难能够保证在收回自动化效益后,场景业务或数据才变更,通常变更是无法预期的或难以控制。
从技术的手段来保证:
曾经我们大胆试图在技术上创新,尝试如下技术攻关点:
1、能否通过手工用例,自动化生成脚本?
2、业务对象变更自动识别,与脚本自动化维护?
技术点1与2看起来很有挑战,很值得做,曾经为这样的Idea 也热血,与冷静思考过,并开始一步步逼近实现。
但现在可以告诉大家四个字:“得不偿失”,其实上面技术点的本质,是在客观上用技术来代替现实世界中人的主观。
对于技术1,事实上很难能够找到通用的建模方式,来描述用例生成脚本;
对于技术2, 自动化技术是永远落后开发实现技术的发展,任何新的操作对象产生,必须跟进自动化识别技术,但搞自动化一帮人不可能在office意淫明天会有什么新的对象面世。即,真正意义上的做到完全无人职守,脚本自动生成或通过对象嗅探自动维护脚本,几乎是“布尔什维克”主义, 或者可以说实现上述两种技术方法,要先诞生实验室研究或论文阶段,类似于企业或像,这样的大的公司来说,也不会有人站出来说这样做肯定有收益。不过,还是可以参照我的发明专利《http://www.ilib2.com/A-%E7%94%B3%E8%AF%B7%E5%8F%B7~CN200810007645.2.html》,来比较标准与历史对象来发现变更。
从流程的手段来保证:通过自动化测试体系中流程来约束变更的发现机制?如果,任何变更的源头来自于需求,
或者业务,他们可以在变更时告诉软件生命周期后期测试环节的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
那么最后当然得出结论自动化测试更适合缺陷预防,而不是提高测试效率,希望看完这篇的同学,能够和我悟出同样结论与观点,也帮助影响你的主管或身边的同事。
转载地址:http://ufadx.baihongyu.com/