现在业界，自动化软件测试就像一个人见人爱的香馍馍。自动化测试好像已经和“高科技”，“高测试效率”，“成熟的QA team”这些褒义词联系了起来。在这种一边倒的氛围下，自动化程序的缺点不足和必须要付出的代价很容易被忽略。

　　为什么要做自动化测试，看过有些同行在博客里分析到，有的说是QA的自尊心，不写点程序就觉得对不起计算机科班出身这个称号，也有说是为了出成绩，跟管理层展示，我们的自动化达到覆盖率多少多少，可以节约多少多少时间。

　　别的公司是否这样我不知道，但在我们公司，我还没觉得有这两点原因。起码leader给我们的automation目标是完成核心test case的覆盖以及每个release时dev deploy的health check的任务。当初自动化测试的任务分配下来，我是带着一脸好奇和学习欲望去做，压根没想到上面那么多，作为新人，在项目组我是属于没有决定权的小兵，做不做自动化测试也不是我说了算，不在其位不谋其政。但有一点可以肯定，在几个月的自动化测试中，的确让我找到coding的乐趣，黑盒测试做久了，换换新鲜的感觉也是很美妙的一件事。

　　我对自动化测试的认知也是一个变化的过程。

　　刚开始听说要做自动化测试时，对自动化测试抱着无限美好的期待，好像自动化测试，只动一下手指点下鼠标让自动化程序就跑起来，所有的test case就跑起来了。

　　但随着实际参加了这个自动化测试项目后，对自动化的期望在下降。

　　loadrunner没用过，所以性能测试自动化这块我没有发言权。对于功能测试的自动化，用了这么久的QTP以及FWK，现在再来看待自动化：

　　第一：“自动化测试并不是用来发现bug的”。原因很简单，自动化测试基于test case，但所有的bug中只有大约1/4是仅仅按照test case来测试就能发现的，其它的bug，来自于测试人员的经验，分析，发散思维和说不清道不明的“灵光一闪”。而这些特性对于自动化程序来说完全是无能为力。所以，幻想“动一下手指”，所以的bug都被自动化程序发现出来是完全不可能实现的。

　　测试的规律是bug少的地方bug越少，bug多地方buy越找越多。做测试自动化，往往在开发自动化程序的时候，该发现的bug就发现了。自动化开发完成，再想发现更多bug就很难了。这是无论你怎样跑你的自动化，也不会发现新的bug。

　　第二：自动化另外一个特点是自动化本身也是程序，也需要投入大量的人力来实现。我们项目组的期望值是，自动化程序可以为产品下一次版本release时节约dev INT阶段health check时间，如果连health check都通不过的话，dev也不用deploy给QA测试。它运行的次数越多，它的价值越大。同事曾经开玩笑算到，我们花了几个月做的这个，要dev release多少次，节约多少次时间，才能把我们投入的时间和精力赚回来呀。

　　第三：不要指望自动化对Regression Test的测试的贡献。回归测试时，每一次程序改动的地方都不一样，跟改动关联的模块每次都是不一样的，回归测试的重点也就不同。况且回归测试我个人觉得靠测试人员经验比较重要。你能在自动化程序里预知哪些地方以后会改并且影响到哪些地方么。

　　第四，自动化最大的风险：测试产品功能或界面变化不能太频繁。因为QTP或者其他自动化功能测试软件大多基于GUI的，如果测试系统功能变化界面变化了，每一次系统release新版本后，自动化可能完全不能用了。