1.1.1.3　自动化测试无法做到的事及其劣势分析

　　当然，自动化测试不是万能的，它的能力仍然是有限的。自动化测试同样有着各种各样的缺点和无法做到的事情。不过，人类是不断在进步的，测试自动化技术随着人类进步的步伐也一定会越来越强大。下面同样归纳了最重要的一些自动化测试的劣势以及它力不能及的事情。

　　● 永远不可能完全取代手工测试。自动化测试不能完全替代手工测试，这已经是业界中不需要再争辩的事实了。自动化测试无法做到手工测试的覆盖率。不是每个测试用例都适合转换成自动化测试用例的。另外，复杂性极强的操作也只能通过手工测试来完成，如果将这个复杂的操作写成代码那将会是件大麻烦事。还有一个例子也能证明，就是比如我们当前需要验证页面上的布局是否正确，那试问这该如何写成脚本代码呢？

　　● 无法完全保证测试的正确性。上面也说到了，自动化测试是由测试脚本组成，它的核心仍然是代码，说的简单点，自动化测试就是程序测试程序。我们知道，是程序就一定会有缺陷，所以，不能保证测试工程师开发的脚本就完全100%没有缺陷，如果代码中出现一个小小逻辑错误，哪怕一个条件判断的误写也会导致测试结果完全出错。当然，对于一个有经验和优秀的自动化测试开发工程师来说，大多数的错误还是会在脚本调试中避免的。

　　● 手工测试能发现的缺陷远比自动化测试多。可以这么说，有85%的缺陷是归功于手工测试，而只有15%的缺陷归功于自动化测试（注意：这个标准并不是随便说的，而是由自动化测试专家共同总结得出的一组数据结论）。而且在这15%中，大约只有0.1%不到的缺陷属于新缺陷。的确，自动化测试几乎是无法发现新缺陷的，自动化测试大多是用来发现曾经发现过的缺陷在每个版本下有没有重新出现。当然，我们情愿自动化测试永远不要找出缺陷！自动化测试更适合缺陷预防而不是发现更多缺陷。请记住，自动化测试最大的用途就是回归……再回归。

　　● 对测试质量的依赖性极大。自动化测试的运行首先要建立在版本测试质量（在这里基本指手工测试质量）稳定的大条件下，如果当前版本的测试质量不够稳定，运行自动化测试将会非常不顺利，几乎是一种无用功和白白浪费时间的行为。

　　● 测试自动化可能会制约软件开发。由于自动化测试比手工测试更脆弱，以及脚本维护会受到限制，从而制约软件的开发。

　　● 自动化测试工具是死的，它本身没有任何想象力。自动化测试是无法做到像人类一样随心所欲地创造的，自动化测试的好坏，完全取决于自动化测试负责人和测试开发工程师的思想与技术，和自动化测试工具没有任何关系，工具是没有思想的，所有的操作全部由人通过输入代码的方式告诉工具它该怎么做。

　　● 成本投入过高，风险大。自动化测试需要很大的成本投入，并且如果没有良好的成本分析与控制手段以及自动化测试计划与执行过程控制，那么失败的自动化测试案例数不胜数，导致企业白白浪费人力物力还得不到任何回报。

　　● 自动化测试对测试人员的技术要求较高，对测试工具同样有一定要求。自动化测试对测试工程师来说必须有一定的开发技术背景，开发技术越高则写出来的脚本质量也就越高、越有技术性和想象力。不是每个测试工程师都适合或有能力开发质量好的测试脚本的。同样，也不是每一个测试工具能真正地被使用在真实的项目中并驾驭项目的，也没有听说过有一个自动化测试工具能做到适合每一个项目。

1.1.1.4　何时适合引入自动化测试

　　在之前的章节中，通过总结和分析，相信读者已经对自动化测试的特性和优劣有了一定的了解，接下来，分析在实际项目中关于自动化测试成败的点点滴滴。

　　在我们的自动化测试中，必须让读者知道哪些情况下才适合把项目的系统测试交给自动化测试来完成。但是，如果不能善加利用，则给自己或者组织造成的后果还是比较严重的。下面让我们一起认知何时才比较适合做软件测试自动化！

　　● 项目周期长，系统版本不断。如果你目前所在测试的项目（或系统）是属于一个周期比较长的项目的时候，可以说，的确非常适合引入自动化测试，把大量的回归测试托付给测试自动化是一个比较明智的选择。还有一种根据是从系统的版本数得来的，曾经测试领域专家有过相关的研讨并最后得出结论，一般自动化测试耗费的时间是手工测试的6～10倍，所以，如果你所在的项目（或系统）版本数在10个以上，那么，引入测试自动化也同样非常的睿智，并且和之前的项目周期综合下，时间越长随之而来需要测试的版本就会越来越多，这样，自动化测试可以发挥它最大的作用，给企业带来各方面的利益。

　　● 需求变更不频繁。当项目的需求非常稳定，不会经常出现变更的时候，此时也很适合引入测试自动化。

　　● 系统中的测试对象基本可以正常识别。一般来说，自动化测试的基本要求或者说自动化测试工具对系统的基本要求就是对象的识别，一个自动化测试工具的好坏评判最基本的标准就是，是否能够识别更多的系统控件以及对无法识别的控件能否提供各种解决方案或自定义开发各种控件的识别代码。

　　● 系统中不存在大批量第三方控件。有实际项目经验的读者一定会发现，无论什么系统，B/S架构的也好、C/S架构的也行，多少存在一些第三方控件，但是，如果这些第三方的控件数量不多的话，经过详细的计划与评估后，完全可以引入测试自动化，当然，如果第三方控件数量庞大或者形式种类庞大的话，就会带来很多麻烦，在下文中也会提到。

　　● 需要反复测试，如可靠性测试需要进行上千次的系统测试。在我们的1.1.1.2项目的第一条例子中，提到过类似的情形。在项目中，如遇到这种情况，从理论上讲是相当适合使用自动化测试策略的，当然，前提条件是有能力把自动化测试做好，如果遇到这种情形，测试自动化实行最后成功的话，一定能给整个项目团队带来“丰功伟业”！