四、附加指南
1．自动化之前的考虑重要因素
    范围 －将所有的东西都自动化是不切实际的，通常也没有可利用的时间。要非常仔细的检查应用程序的功能和区域才能运用自动化。
    时间框架的准备 －准备自动化测试脚本的时间是必须要考虑到的。通常，自动化测试脚本的准备时间是手动测试的2/3倍。事实上，碰巧是最初的工具实际上会增加测试的范围。这就是因此管理期望的重要性。一个自动化工具不能代替手工测试，也不能代替测试工程师。开始的时候，测试工作将增加，但是当自动化使用正确得当的话，它是会大大的减少后面的发布时间的。

投资回报率 －因为自动化测试的准备时间过长，我听说测试自动化的受益仅只有在第三次测试开始运行的时候才产生。

什么时候开始受益？明智地选择你的对象，并且认真思考关于什么时候及在哪个阶段才开始受益。如果你的应用程序定期的有着较大的变化，放弃自动化测试－因为你将花费大把的时间来更新你的脚本而你将不会得到多的受益。【然而，如果只有应用程序的不通用部分改变了，或者这个改变较小－或者有一个具体的部分是不会改变的，那么你还是可以成功地利用自动化测试】记住，你可能只有在应用程序将要发布的时候才能做一个完整的自动化测试运行。－比如，接近完全的测试！！如果你的应用程序是非常错误的，然后这个可能性还是你还不能完全的运行一个完整的自动化测试套件－归咎于遇到了失败的功能。

变更的程度 －自动化测试非常好的的使用地方就是做回归测试，那样你使用自动化测试能确保之前存在的功能（例如：版本1.0里面的功能－即这个发布中没有新的功能）不受在版本1.1引入的某些改变的影响。并且，因为适当的自动化测试计划要求设计好的测试脚本要对于一个简单的GUI改变不会完全的无效。（比如重命名或者删除一个特定的控制），你需要考虑到更新脚本的时间和工作量。举个例子，如果你的应用程序有了意义上的改变，版本1.0的脚本在版本1.1中可能就要完全重新编写，并且这些涉及的工作可能就是成本过高的，至少没有被考虑进去！然而，如果只有无联系的应用程序部分改变了，或者改变很小，你才能成功的利用自动化测试来回归这些区域。

测试的完整性 －你怎么衡量一个测试是否测试成功或失败？仅是因为工具返回一个“Pass”是不能决定测试本身就是“Passed”。例如，仅是因为没有错误信息的出现是不能代表脚本下一步是能成功完成的。这需要考虑到具体测试脚本的fail/pass标准。

    测试独立性 －必须建立测试的独立性可以避免在第一个测试用例中的错误而导致该测试组件中余下的测试脚本产生多米诺骨牌效应或者被阻止，或引起失败。然而，事实上，这是很难达到的。

    实际测试脚本本身的调试或“测试”－时间必须允许这一点，并且要证明测试本身的完整性。
    录制和回放 －不要依赖录制和回放作为生成脚本的唯一方式。这种想法是伟大的。你手动的执行测试而测试工具是位于后台记住你所操作的，然后生成你能运行重复执行测试的脚本。不依赖录制和回放是一个伟大的想法－却很少能有效（并且证明也非常有限）。

    脚本的维护 －最终，对于自动化测试脚本的维护有着高昂的维护费用－它们不得不不断的更新，因为一个应用程序有了太多的变更需要对测试脚本进行修改，否则你将最终放弃数百小时的工作。结果，测试脚本的文档的更新也是很重要的。

2．推荐的测试工具