1、 自动化测试时间不足：根据项目计划的安排，测试人员往往被安排利用自己的个人时间或者项目后期介入自动化测试。这使得自动化测试无法得到充分的时间，无法得到真正的关注。

2、 缺乏清晰的目标：有很多好的理由去开展自动化测试工作，诸如自动化测试可以节省时间，使测试更加简单，提高测试覆盖率，可以使测试人员保持更好的测试主动性。但是，自动化测试不可能同时满足上述的目标，不同的人员对自动化测试有不同的希望，这些希望应该能被提出来，否则很可能面临失望。

3、 缺乏经验：尝试测试自己程序的初级的程序员经常采用自动化测试。由于缺乏经验，很难保证自动化测试的顺利开展。

4、 更新换代频繁：测试自动化往往需要花费很多时间学习的，当自动化测试更新频繁

的时候，你丧失了刚刚学习到的自动化测试经验。

5、 对于绝望的反应：在测试还远没有开始的时候，问题已经潜伏在软件中了。软件测试不过是发现了这些潜伏的问题而已。测试本身而言，测试是一件很困难的工作。当在修改过的软件上一遍接一遍的测试时，测试人员变得疲劳起来。测试什么时候后结束？当按照计划的安排，软件应该交付的时候，测试人员的绝望变得尤其强烈。如果不需要测试，那该有多好呀！在这种环境中，自动化测试可能是个可以选择的解决方法。但是，自动化测试却未必是好的选择，他不是一个现实的解决方法，更像是一个希望。

6、 不愿思考软件测试：很多人发现实现产品的自动化测试比测试本身更有趣。在很多软件项目发生这样的情况，自动化工程师不参与到软件测试的具体活动中。由于测试的自动化与测试的人为割裂，导致很多自动化对软件测试并没有太大的帮助。

7、 关注于技术：如何实现软件的自动化测试是一个很吸引人的技术问题。不过，过多的关注如何实现自动化测试，导致忽略了自动化测试方案是否符合测试需要。

我更愿意把 “ 测试自动化” 这个词解释成能够使测试过程简单并有效率，使测试过程更为快捷，没有延误。运行在计算机上的自动化测试脚本只是自动化测试的一个方面而已。

很多测试小组都是在回归测试环节开始采用测试自动化的方法。回归测试需要频繁的执行再执行，去检查曾经执行过的有效的测试用例没有因为软件的变动而失败。

回归测试需要反复执行，并且单调乏味。怎样才能做好回归测试文档化的工作呢？通常的做法是采用列有产品特性的列表，然后对照列表检查。这是个很好的开始，回归测试检查列表可以告诉你应该测试哪些方面。不过，回归测试检查列表只是合于那些了解产品，并且知道需要采用哪种测试方法的人。