（1）必须信任自动化测试
自动化虽然已经经历了10来年的发展历史，但是很多同事潜意识里还是更愿意相信手工测试的真实可靠性。他们其中一部分认为自动化测试是不错的方法和思想，但是相比来说机器永远代替不了人的大脑，不够灵活、不懂得变通；另外一部分从根本上就不信任自动化测试所做的测试执行，认为执行结果不可靠，根本无法节约成本，而且反而会降低测试质量。 对自动化测试到底怎么看还是受站在什么角度想问题、考虑问题是否全面等因素的影响。这些不看好自动化的想法很可能是来自没有自动化实践经历的凭空想象或者是有过失败的自动化经历；他们这种失败的经历中自动化测试没有选取合适的应用范围、方法不得当所占比重非常大，并且他们在失败之后没有进一步思考，没有总结出这些导致失败的诱因。比如，认为不够灵活的往往是因为要求太高而技术实现又达不到预期；为什么想要变通呢？想必是因为需求没有达到足够细致的程度，测试设计太模糊从而导致执行实际结果很容易产生一定的偏差：如果测试分析、设计上下了足够的功夫，那么所谓的变通是完全不必要的。自动化测试脚本或者工具为什么要替代人的头脑呢？换个角度思考一下，被测系统是否达到了替代人脑的功能呢？当然没有！自动化测试只是在对被测系统进行操作，每一处验证点的检查都是针对系统的设计和实现进行的，从根本上说，如果被测系统无法替代人脑的存在，自动化测试也没有这个必要去考虑这个问题。无法节约成本的看法是因为不懂得自动化的成本效益如何分析，一味的单从自动化开发投入时间和运行时长作比较；认为自动化会降低测试质量的看法则是由于不懂自动化测试理论、不懂测试理论导致的。
对自动化测试作用的彻底信任是自动化测试开始的必要条件，抱着半信半疑的态度去尝试只会带来很多的困扰。犹犹豫豫地总是怀疑自动化测试是否值得很可能就会导致人力投入、其他设备资源支持上的问题，认识上的误差——尤其是管理者的误解会给自动化的策略和发展带来很大的障碍。不要把自动化作为一种资本或者实力的体现，从项目管理的角度来说，它只是在测试过程中实现测试周期调控和测试质量把控的手段而已，而在整个测试过程中是起到辅助手工测试的作用还是主导着测试主要是看自动化使用的水平和程度。
（2）了解测试开发的模式
前面也谈到开发模式略有不同，测试自动化开发也随着不一样，一般说来自动化开发有下面几种模式，我们来看下他们各自的特点。
1、超前式，在项目设计编码的同时就开始了自动化脚本开发，依赖系统开发过程中的高度复用；是一种比较先进的自动化设计开发模式，能够在系统移交初期就完成自动化开发，并且得到很好的应用，但是极少有公司能达到这种水平。
2、尾随式，在系统开发环境紧随编码进度去做自动化的开发，需要投入人力较多，开发进度稍滞后与系统编码进度，但是总体来说测试开发、调试完成之后还是能够得到较好的应用。
3、基线式，在SIT或者FAT完成之后的某个较为稳定的版本上进行自动化脚本、程序的开发。开发的时候需要有一套独立的自动化开发环境（也可以是Staging环境），界面比较稳定；但是在后期需要同步更新的地方较多，测试运行基本只能够应用在ST的冒烟测试和回归测试。
这几种只是几种相比其它方式较为正常、普遍的模式，也有一些不为笔者所了解的方法，如果大家能够补充一下就更好了。
在第一、第二种模式里，比较容易出现的问题是没有满足相应的条件又去使用对应的自动化开发方法；比如在第二种方式里人力投入较少，那么自动化开发进度可能严重滞后，并不能达到预期的效果，这在第一章已有阐述。基线式最常见的问题是在测试过程中不断的更新项目版本，在不断更新的项目版本上进行不断地进行自动化更新。乍一看这种操作没有什么问题，可实际上系统开发过程中有缺陷修复带来的反反复复，UI变动也存在A-B-C-A的过程。由于测试脚本开发较晚，这种测试运行基本只能够应用在ST的冒烟测试和回归测试，中途的更新并不能带来什么实际的好处，不断地随项目版本的变更去进行自动化的更新反而会消耗更多的时间和人力。我们经常听到的是：“这个系统不适合做自动化测试”这种说法，究
其原因，却是因为变更（需求）太多导致的。同时这种不适合做自动化的抱怨也是一种误解，只要调整对应的自动化开发策略，问题还是能够得到一定程度上的缓解的。 　　那有些同事可能说“刚经过SIT或者FAT的版本和经过ST的版本有着天壤之别，后期的更新可能跟重新开发消耗一样的时间和人力，那最初的自动化开发不是一种浪费吗？！”很简单，拿出需求规格来看看，为什么有这么多的变更呢？这些变更如果没有对应的流程记录，那毫无疑问项目经理或者你的直接主管要为这么多的人力浪费买单；如果有已经明确知会的变更，那么请记得在自动化开发过程中要跟踪每次变更，同步更新测试需求和自动化开发需求。软件开发成熟度评估标准中有一项是对需求管理的指标，上文之所以强调软件开发成熟度对自动化的影响，其中一部分原因就在这个地方了。
（3）莫为自动化而自动化
无论是项目测试还是运营测试中，自动化测试的目的是测试而不是自动化，自动化测试应该是先进的测试手段，是提高测试质量、测试速度的手段，而并不是单纯为了技术研究而做的事情。在这一点上犯形式主义错误的人和事屡见不鲜，笔者总结有以下三种情况：
1、主观上崇拜技术，只是为了要证明自己有做自动化测试的实力，进行自动化的出发点错误。把自动化测试技术作为第一要义，不注重测试的需求内容，盲目追求测试自动化实现的华丽程度，但事实上没有给系统测试做太多的贡献。费时费力并不可怕，可怕的是费时费力之后却没有得到应该得的东西；你可以鼓吹自己的自动化平台、技术多先进，但是却没有资格对别人说自己的自动化能来带什么样的收益。例如有很多人在有QC和QTP的情况下，喜欢舍近求远，放弃QC的预留接口和它与QTP之间非常好的兼容性，另起炉灶去开发难度较大的测试框架。这样技术投入上消耗了更多的资源，但是效果却并不一定有已有的东西好。
2、偏离测试主旨，长期运作但是没有实际产出物。试想一下，每天上万的测试脚本反复运行，但是从未见有发现任何缺陷或者从来就没有对“每日回归”发现的缺陷进行统计分析，这是一种什么概念。按理说能进行每日回归并且我们这种几近无甄选的“每日回归”是非常强大的，即便是大家津津乐道的持续集成中的高频度构建也是能支持的；但是我们这里缺失了一个重要的环节：对当前版本上运行结果的分析。其实高频度的运行涵盖两个方面，一是冒烟测试，这是版本每次发布Staging之后的运行，另一个是回归测试，也就是版本定版之前的运行。那么有可能哪个版本移交过来之后就没有缺陷么？当然几乎没有！既然有缺陷，那么自动化运行失败而置缺陷不理，一味追求测试脚本的修复、更新又是所谓何来呢？那只能理解为你只求把自动化的运行用在回归测试上，但事实上回归测试的时候版本基本已经稳定，一般自动化运行是很难发现什么问题的。最终自动化测试成了回归测试时增加测试人员信心的手段，目的只是为了证明没有缺陷，而不是争取发现缺陷，这也就从根本上偏离了测试的主旨。如果能形成每次运行之后的报告分析机制，那么种情况或许能够得到改善，缺陷提交是自动化运行失败必须要做的，缺陷关闭是版本移交生产必须做的，这样卡住过程的首尾，自动化测试方能起到它该起的作用。