1. 不正确的观念或不现实的期望

　　没有建立一个正确的软件测试自动化的观念，或操之过急，或认为测试自动化可以代替手工测试，或认为测试自动化可以发现大量新缺陷，或不够重视而不愿在初期投入比较大的开支等。多数情况下，对软件测试自动化存在过于乐观的态度、过高的期望，人们都期望通过这种测试自动化的方案能解决目前遇到的所有问题。而同时测试工具的软件厂商自然会强调其工具的优势、有利的或成功的一面，可能对要取得这种成功所要做出持久不懈的努力和困难却只字不提。结果，最初的期望，便得不到实现。

　　2.缺乏具有良好素质、经验的测试

　　有些软件公司舍得花几十万元去买测试工具软件，但缺乏具有良好素质、经验的测试。软件测试自动化并不是简简单单地使用测试工具，还需要有良好的测试流程、全面的测试用例(Test case)等来配合脚本的编写，这就要求测试人员不仅熟悉产品的特性和应用领域、熟悉测试流程，而且很好地掌握测试技术和编程技术。

　　3.测试工具本身的问题影响测试的质量

　　一般不会对自动测试脚本再做大规模的测试，所以自动测试脚本的质量往往依赖于TA工程师的经验和工作态度，如果自动测试工具不能提供一种机制来保证脚本的的质量，那将直接影响到测试结果的正确性。通过自动测试工具测试的Test Case是不需要再进行手工测试的，将自动测试与手工测试有效的结合，并在最终的测试报告中也体现自动测试的结果，是比较正确的做法。

　　4.没有进行有效的、充分的培训

　　人员和培训是相辅相成的，如果没有良好的、有效的、充分的培训，测试人员对测试工具了解缺乏深度和广度，从而导致其使用效率低下，应用结果不理想。这种培训是一个长期的过程，不是通过一两次讲课的形式就能达到效果。而且，在实际的使用测试工具的过程中，测试工具的使用者可能还存在着这样那样的问题，这也需要有专人负责解决，否则的话，会严重影响测试工具的使用积极性。

　　5. 没有考虑到公司的实际情况，盲目引入测试工具

　　有一点很明确，不同的测试工具面向不同的测试目的、具有各自的特点和适用范围，所以不是任何一个优秀的测试工具都能适应不同公司的需求。某个公司怀着美好的愿望花了不小的代价引入测试工具，半年一年以后，测试工具却成了摆设。究其原因，就是没有能够考虑公司的现实情况，不切实际地期望测试工具能够改变公司的现状，从而导致了失败。

　　例如，国内多数软件公司是针对最终用户进行项目开发--工程性质的软件，而不是产品开发。项目开发周期短，不同的用户需求不一样，而且在整个开发过程中需求和用户界面变动较大，这种情况下就不适合引入黑盒测试软件，因为黑盒测试软件的基本原理是录制/回放(虽然通过修改，形成结构化测试脚本)，对于不停变化的需求和界面，可能修改和录制脚本的工作量大大超过测试实施的工作量，运用测试工具不但不能减轻工作量，反而加重了测试人员的负担。这种情况下可以考虑引入白盒测试工具，以提升代码质量。

　　6. 没有形成一个良好的使用测试工具的环境

　　建立良好的测试工具应用环境，需要测试流程和管理机制做相适应的变化，也只有这样，测试工具才能真正发挥其作用。例如，对于基于 GUI录制/回放的自动测试来说，产品界面的改变对脚本的正常运行影响较大。再者，白盒测试工具的一般在单元测试阶段使用，而单元测试在多数公司是由开发人员自己完成，如果没有流程来规范开发人员的行为，在项目进度压力比较大的情况下，开发人员很可能就会有意识地不使用测试工具，来逃避问题。所以，有必要将测试工具的使用在开发和测试的流程中明确起来，如在项目各个里程碑所提交的文档中，必须包含某些测试工具生成的报告，如集成测试时DevPartner工具生成的测试覆盖率报告、Logiscope生成的代码质量报告等。

　　7.其它技术问题和组织问题

　　软件测试自动化所需要的测试脚本其维护量很大，而且软件产品本身代码的改变也需要遵守一定的规则，从而保证良好的测试脚本使用重复性，也就是说测试自动化和软件产品本身不能分离。其次，提供软件测试工具的第三方厂家，对客户的应用缺乏足够理解，很难提供强有力的技术支持和具体问题的解决能力。也就是说，软件测试工具和被测试对象—软件产品或系统的互操作性会存在或多或少问题，加之技术环境的不断变化，所有这些对测试自动化的应用推广和深入，都带来很大的影响。还有性的错觉，如果软件测试工具没有发现被测软件的缺陷，并不能说明软件中不存在问题，可能测试工具本身不够全面的问题或测试的预期结果设置不对。