很多人在回答为什么要开展自动化测试时，立即回想到的答案是提高测试效率。
这种回答本身并没有错，但我想这只是问题的次要方面。在经过数次的自动化测试时间投入与效益比来看，
可以基本得出，基于某个场景的测试脚本，在没有变更与维护情况下，脚本执行频率大于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
那么最后当然得出结论自动化测试更适合缺陷预防，而不是提高测试效率，希望看完这篇文章的同学，能够和我悟出同样结论与观点，也帮助影响你的主管或身边的同事。
