自动化测试的误区

陷阱1：自动化测试工具是万能的！

　　到目前为止，还没有一款商业测试工具能支持从测试计划，到测试设计，再到测试执行的自动化。

　　你经常会在某些测试工具的产品推介会、演示会上看到演讲者展示测试工具的种种好处、优点，让你为自动化测试激动不已；但是他们往往不会告诉你自动化测试的难点所在，实施自动化测试的复杂度，以及所需的投入有多大。

　　你的项目经理也许就在这时候开始一步步迈向自动化测试的陷阱。

　　陷阱2：一个工具能适合所有项目

　　到目前为止，还么有一款工具可以支持所有操作系统环境。

　　你也许会被项目经理要求寻找一款可以支持所有实时嵌入式系统测试的测试工具，而你们的应用需要跑在各种操作系统环境上，包括VxWorks、Integrity、mainframe、Linux 和 Windows XP，编程语言包括Java和C++。

　　陷阱3：引入自动化测试工具后，测试人员的负担立即减轻

　　引入自动化测试工具后，并不会马上就减轻测试负担，事实上一开始往往会增加负担。

　　项目经理往往希望通过引入自动化测试工具来减轻测试负担。但是经验表明，在一个新项目中尝试实施并且有效地应用自动化测试，往往需要经过一条学习的曲线。测试的负担并不会马上减轻，但是项目经理却希望马上看到自动化测试发挥其威力，希望马上看到效果。

　　事实上，在一开始的时候，很大可能会增加测试的负担，因为测试工程师需要一段时间熟悉和掌握测试工具，而与此同时，手工测试一刻也不能停止，因此测试的负担没有减轻，反而加重了。

　　另外，自动化测试需要仔细的分析被测试应用程序，哪些部分需要和能够被自动化实现；并且需要仔细地设计和开发测试脚本。这些无疑都将加重测试的负担，尤其是在初始阶段。

　　陷阱4：引入自动化测试工具后，进度可以马上被压缩

　　上了自动化测试工具之后，整体测试进度不会马上缩短，相反，在初始阶段，往往会对进度造成一定的延误。

　　另外一个误区是，自动化测试工具能马上缩短测试时间表。但是由于测试的负担在初始阶段加重了，因此很自然地，我们不能期待进度缩短，相反，在引入自动化测试后，我们应该给初始阶段的进度表预留一些时间。一旦整个自动化测试的流程建立起来之后，我们就可以期待自动化测试给我们的进度带来积极的影响。

　　陷阱5：自动化工具是很容易使用的

　　自动化测试工具要求测试人员掌握新的技巧，通常需要额外的培训。应该制定培训计划，投入时间和成本，度过学习的曲线。

　　通常很多工具厂商都会夸大自己产品的易用性，他们会否认所谓的"学习曲线"。工具销售人员通常鼓吹所谓的"录制/回放"可以简单地记录下测试工程师的键盘和鼠标动作，然后再简单地回放出来。

　　但是，有效的自动化测试远远不仅仅是"录制/回放"那么简单。录制下来的脚本需要手工修改，以便让其可重用性和可维护性更强一点、更灵活一点，而这些都需要语言和脚本知识。因此他们需要针对工具和内建的脚本语言接受培训。
并非所有的测试都可以被自动化。

　　自动化测试是手工测试的增强。乞求项目中的测试百分百实现自动化是不合理的。在首次引入自动化测试时，最好先验证一下，工具是否能识别出所有对象和第三方的控件。这对于基于GUI的测试工具来说非常重要，因为这类工具往往在识别一些个性化控件方面有困难，例如一些calendar、spin、grid控件，而这些控件被广泛应用在程序界面中，并且这些控件往往由第三方编写，大部分测试工具厂商未能跟上他们的发展速度。

　　测试工程师在碰到这种情况时要么放弃这部分应用了难以识别的控件的测试自动化，要么找出一些解决的办法。

　　另外，还有一些测试是基本上不可能被自动化实现的，例如，测试工程师可以实现自动化地把文档发送到打印机的过程，但是检查打印的效果（是否被正确地打印出来，有没有越过纸张打印线）这部分则必须人工进行。

　　至于哪些测试用例应该被自动化实现，可以参考下表决定：

		YES	NO
测试执行的次数	测试会被执行多次吗？
	测试会有规律地运行吗？例如经常被重用，作为回归测试的一部分或每日构建测试？
测试的关键程度	测试覆盖了软件功能的最关键部分的路径吗？
	测试覆盖了最复杂的部分吗？（通常是最容易出错的部分）
测试的代价	如果手工进行测试的话，是否不可能、非常难以执行，例如并发测试、持久性测试、性能测试、内存泄漏测试等。
	测试非常耗时吗？例如需要检查成百上千个测试结果输出。
测试的类型	测试需要组合很多输入，但是共用一个测试步骤吗？例如同一个功能，用很多不同的输入来验证。
	测试需要在多种软硬件配置环境下执行吗？
被测试应用或系统	测试是在一个稳定的应用程序上执行的吗？例如功能特性已经基本完成。
	使用兼容的技术和开放的架构

　　陷阱7：自动化能提供百分百的测试覆盖率

　　并非所有内容都可以被自动化地测试到。不可能覆盖所有可能的输入，所有可能的组合和路径。

　　自动化测试可以增加测试的广度和深度，但是仍然无法达到100%的测试覆盖率，因为没有足够的时间或资源。

　　例如一个简单的登录界面的测试，假设我们需要测试它的密码验证函数的正确性，密码长度在6到8个字符之间，每个字符可以大写或小写，至少包含一个数字，那么输入的可能组合将达到2,684,483,063,360个。

　　即使我们可以每分钟创建一个测试，也需要155年来完成全面的测试。因此，不可能穷尽所有可能的输入的测试。

　　陷阱8：测试自动化就是录制和回放

　　仅仅录制得到的不是有效的自动化脚本。

　　很多项目经理仍然把测试自动化等同于使用录制回放工具。而事实上，录制得到的脚本通常是不可重用的脚本，脚本中充满了硬编码的值，这些值应该被参数化，否则脚本仅仅适用于一个测试情况，脚本还应该加入条件判断、循环等结构，以便增强测试脚本的灵活性。

　　陷阱9：自动化的软件测试与手工的软件测试过程一样

　　自动化测试所需要的技巧与手工测试所需要的技巧是不一样的。

　　通常，你的项目经理会被那些测试工具销售们迷惑，认为自动化的软件测试就是简单地按一个录制的按钮，产生测试脚本。而事实上并没有那么简单。

　　区分自动化测试所需要的技巧与手工测试所需要的技巧是非常重要的。最重要的是，自动化测试工程师需要掌握软件开发技巧，没有接受任何培训的手工测试人员，或者没有编程背景的手工测试人员，在实施自动化测试时会碰到很多困难。

　　陷阱10：忘记了测试的最终目标：找到BUG

　　在自动化测试中，同样要注意把边界值分析、等价类分析、基于风险的测试方法、挑选最合适的测试用例等技术应用起来。

　　通常在自动化测试过程中，我们都忙着搭建自动化框架和编写测试脚本，但是我们往往忘记了测试的本来目的：找bug。

　　项目经理可能雇佣了最好的自动化开发人员来搭建框架，使用了最新最好的自动化开发技术，创建了成千上万的自动化测试脚本。但是如果BUG仍然被遗漏了，那些本该被自动化测试脚本捕捉到的BUG，结果没有被捕捉到，那么你的自动化测试仍然会被认为是失败的。