以下几个方面严重影响着自动化测试的效率，如果处理不当，将会造成事倍功半甚至前功尽弃的后果，自动化测试也成了一副空架子。
一是测试的范围：想要百分百的实现自动化测试是不现实的，而且从时间投入上也是不可行的；有选择性的挑选应用程序的一些功能或区域模块，采用自动化测试。
二是测试时间的准备工作：自动化测试脚本的开发时间必须考虑在内，一般来说，开发测试脚本的时间要比手工测试多出三分之二，因为现实里工具会在初始阶段增加测试的范围；因此，对自动化测试保持适度的期望值很重要：工具不能取代手工测试，更不能代替测试工程师。测试初始阶段，投入会比较大，当自动化完成后，将会大大缩短后续的版本的测试时间。
三是投资的回报：自动化测试的准备工作如此漫长，据说自动化测试的效益只会出现在测试被执行三次以后的时间里。
四是何时获得自动化测试的收益：定位合适的测试目标，并认真分析自动化测试的收益出现在何时、何处。如果测试程序频繁进行大幅度变更或修改，还是放弃自动化测试吧！－你将会耗费相当的时间去修改测试脚本，但收益是微乎其微的。（但是，如果应用程序频繁变更的模块彼此独立，或者修改较小，或者只是特定区域的变更，那么仍然可以成功采用自动化测试。）另外，谨记只有当应用程序将近发布时，才可以进行完整的自动化测试；如果应用程序缺陷太多，功能点运行失败，想要运行全面的测试套件程序是不太可能的。
五是变更的程度：自动化测试最适合用于回归测试，将那些已经存在并相对完善的功能进行自动化测试；例如应用程序1.0版本的功能模块已经稳定，没有引入1.1版本的新功能，这种情况下，我们对其制订自动化测试计划并设计测试脚本，不至于因为简单的GUI变更（例如某个控件改名或移动）而使脚本无效。我们也需要将修改脚本的时间考虑在内，例如，如果应用程序的版本升级造成很大的功能改变，那么也许要全部重新书写测试脚本，这种情况是我们不愿意看到的。但是，如果只是某个相对独立的功能模块发生变更，或者变更较小，我们可以成功的实现在回归测试里的自动化。
六是测试的完整性：我们如何度量一个测试是否通过或失败呢？单单凭借工具返回的“pass”不足以证明测试本身通过无误，例如，没有错误的提示信息出现并不意味着脚本的下一步动作能够成功进行。因此这一要点需要在规划测试脚本的通过与否标准上考虑在内。
七是测试的独立性：测试的独立性应该被考虑在内，从而不至于某一个测试用例的运行失败引起全局影响，甚至阻止整个测试套件程序里其他脚本的运行；但是，在实践中对该问题的把握并不容易，需要一定的努力达到此目标。
八是对测试脚本本身的调试和测试：必须花费一定的时间进行该工作，以检验测试本身的完整性。
九是录制/回放：不要完全把工具的录制/回放功能作为创建测试脚本的唯一方法，这个观念是很重要的。测试者在后台运行测试工具，再手工执行测试，工具将测试者的动作记录下来，自动生成一个脚本，以便测试者可以重新运行测试动作，这虽然是个好想法，但对测试工作本身并无太大意义。
十是对测试脚本的维护：最后一点，对自动化测试脚本的维护是一个高投入的工作，脚本必须持续的更新，否则一旦应用程序有太多的变更而要修改测试脚本时，你会因为一下子需要上百个小时而考虑是否值得这样做，从而最终放弃自动化测试。因此，测试脚本每次更新时，对其进行文档化管理是必要的。
