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

不少人在回答为何要开展自动化测试时，当即回想到的答案是提升测试效率。

　　这种回答自己并无错，但我想这只是问题的次要方面。在通过数次的自动化测试时间投入与效益比来看，

　　能够基本得出，基于某个场景的测试脚本，在没有变动与维护状况下，脚本执行频率大于5-7次才基本可以收回

　　投入成本，产生自动化效益。基于互联网的产品条件下，一个项目或系统若是包含 > =100个测试场景，事实远超这个数据的N倍，其实很难可以保证在收回自动化效益后，场景业务或数据才变动，一般变动是没法预期的或难以控制。

　　从技术的手段来保证：

　　曾经咱们大胆试图在技术上创新，尝试以下技术攻关点：

　　一、可否经过手工用例，自动化生成脚本？

　　二、业务对象变动自动识别，与脚本自动化维护？

　　技术点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

　　那么最后固然得出结论自动化测试更适合缺陷预防，而不是提升测试效率，但愿看完这篇文章的同窗，可以和我悟出一样结论与观点，也帮助影响你的主管或身边的同事。