摘要：作者以自己多年在测试领域尤其是在自动化测试中的经验，从管理层面讲述了自动化测试相对于手动测试的优势；并且从不同的方面论述了目前大家对于自动化测试的错误认识，同时让大家充分意识到推行自动化过程中会面临的困难。
关健词：自动化测试；手动测试；
如今自动化测试以其执行速度快，结果反馈迅速的最大优点获得了业界的广泛认可，尤其在如今需求快速变化的今天，大家对于自动化测试的需求和渴望更是到了一个空前的地步。诚然，自动化测试受到大家的追捧是有充分的理由，因为相对于人工测试，它有着不少的优势。我们且来看看。
1、自动化测试的优势
1.1 对程序的回归测试更方便
回归测试可能是自动化测试最主要的任务，特别是在程序修改比较频繁时，效果是非常明显的。由于回归测试的动作和用例是完全设计好的，测试期望的结果也是完全可以预料的，将回归测试自动运行，可以极大提高测试效率，缩短回归测试时间。
1.2 可运行更多更繁琐的测试
自动化的一个明显的好处是可以在较少的时间内运行更多的测试。而且人工测试在面对多轮重复执行时，测试人员往往会趋于倦怠，而这将对产品的测试质量带来其他的损害
1.3 可以执行一些手工测试困难或不可能进行的测试
比如，对于大量用户的测试，不可能同时让足够多的测试人员同时进行测试，但是却可以通过自动化测试模拟同时有许多用户，从而达到测试的目的。
1.4 更好地利用资源
将繁琐的任务自动化，可以提高准确性和测试人员的积极性，将测试技术人员解脱出来投入更多精力设计更好的测试用例。有些测试不适合于自动测试，仅适合于手工测试，将可自动测试的测试自动化后，可以让测试人员专注于手工测试部分，提高手工测试的效率。
1.5 测试具有一致性和可重复性
由于测试是自动执行的，每次测试的结果和执行的内容的一致性是可以得到保障的，这样使测试结果具有可对比性，并且达到测试的可重复的效果。
1.6 测试的复用性
由于自动测试通常采用脚本技术，这样就有可能只需要做少量的甚至不做修改，实现在不同的测试过程中使用相同的用例。
1.7 增加软件信任度
由于测试是自动执行的，所以不存在执行过程中的疏忽和错误，完全取决于测试的设计质量。一旦软件通过了强有力的自动测试后，软件的信任度自然会增加。
因为自动化测试现在如旋风之势席卷而上，特别是全球风靡于敏捷开发之后，更是把自动化测试提高到了一个史无前例的高度。而且人工测试具有更敏锐的观察力，能从一个稍纵即逝的小异常中挖掘出大问题。
另外有些测试是必然需要人工干预的，如冷启动机器，如需要人的感官去体验的。那么如果真的需要追求100%的自动化测试覆盖率，我们唯一的选择就是牺牲这部分的测试案例来成全100%，这对于测试覆盖率也是很大的一个损失。
而从投入产出比的角度来看，以目前对各组织的统计而言，60%是一个比较合理的值，如果要高于这个值，那么付出的人力将是成倍增长的。在我们的组织中一度自动化测试覆盖率的要求是95%，曾经我们也勉强达到，但是投入的代价是不可维续的。所以我们过后调整了我们的合理期望值。比如说在比较简单的功能性测试中自动化测试是比较容易的，但如果是涉及模块和网元很多的系统测试或互通性测试中就显得相当的力不从心了。
2、自动化测试是适用于任何情况的
2.1 自动化测试是适用于任何产品的
并不是所有的产品都适用于自动化测试的，如果这个产品只会做有限的几轮测试，接着就不会再有持续的开发。那么就没必要使用自动化测试，因为这样的投入产出比比较低。毕竟在开发自动化测试阶段需要耗费大量的人力物力。对于决定自动化一个测试用例的一般规则是这个测试用例必须被运行 4 次以上。这个数字是基于用户对测试工具有良好的技能并且有一个良好的测试框架的。如果情况不是这样的话，整个数字能够是 10-20次或者更高。
再者如果变化比较大的话也不适用自动化测试。国内多数软件公司是针对最终用户进行项目开发—工程性质的软件，而不是产品开发。项目开发周期短，不同的用户需求不一样，而且在整个开发过程中需求和用户界面变动较大，这种情况下就不适合自动化测试，对于不停变化的需求和界面，可能修改和录制脚本的工作量大大超过测试实施的工作量，运用测试工具不但不能减轻工作量，反而加重了测试人员的负担。
2.2 自动化测试是适用于任何测试阶段的
版本经理通常认为自动化测试能运用于任何阶段的万能钥匙，但事实上从本人的经验来看，自动化测试适用于回归测试，但不适用于新功能的测试。首先因为新功能刚递交之时稳定性是不可保证的。而自动化测试对于其不稳定性是相当敏感的，所以通常都无法正常的运行完测试，也无法达到我们尽快得到结果的预期。其次在新功能刚递交时其期望结果是不可预知的，这对于自动化测试脚本的编写带来了极大的不确定性。最后在新功能递交阶段是需要我们发现大量问题的时候，而自动化测试无法担此重任。
2.3 自动化测试是适用于任何组织的
在最初尝试自动化测试的时候，是需要投入相当的人力和物力去选择自动化工具，构建自动化测试的框架，做必要的技能培训，摸索编写自动化测试的脚本，如果一个组织无力承负这样的代价，那么是不适合自动化的，否则只能是半途而废的下场。
即使我们澄清了这些误区，我们对于自动化测试有了一个比较清晰的认识，也对其有了一个正确的期望，但实际在推行的过程中我们还是会遇到不少的困难，而困难主要来自于以下几个方面。
3、自动化测试推广中的困难
3.1 来自于测试人员的不接受
因为测试人员是自动化测试的主体，他们承担着转型的重要职责，所以他们的接受与否对于工作的展开是尤为重要的。但作为一个新生事物，通常是不太容易被接受的，尤其是在大家觉得原有的模式很舒服很习惯的情况下。所以在最初的阶段完全是强推。而经过一年的努力，当作年终总结时，所有的测试人员都说那年最艰难的是自动化测试，感触最深的是自动化测试，从中学到最多是是自动化测试，而且发现自动化测试的确帮了很大的忙。
3.2 来自于测试人员技术上的不足
测试人员很多都不具有编程的经验，但自动化测试脚本的编写还是需要一定的编程功底，如果组织中专门有一个具有编程功底的团队能开发自动化测试的工具，并且根据手动的测试案例编写自动化测试的脚本，那状况可能会好些。但目前更多的组织是需要人人能编写自动化脚本的。而在我们的转型中我们经历了三个阶段，基本完成了能力的建设。第一阶段以能用为目的，专门有人提供所需的函数，测试人员只需调用这些函数完成自动化测试的目的，不需要考虑程序的可移植性，可复用性。第二个阶段每个人会写一些自己所需要的函数，并且具有良好的移植性和灵活性。第三个阶段每个人会写能为他人复用的函数并且遵循制定的规范。这样的转型虽然慢但却是比较稳妥的方式。
3.3 来自于组织内其他人员的阻挠
在自动化测试的初期阶段，必然是会耗费相当多额外的精力去构建环境等等，而且我们也需要时间完成技术上的积累。所以这时候不得不像项目经理去索要更多的人力。这是一个长期受益的举措，但对于当前而言似乎是利大于弊的。所以会遭受各方各面的压力，尤其是来自于项目经理的压力。我们很幸运我们走过来了，而现在当所有的人尝到了甜头之后，对于自动化测试的支持程度也大大的提高了。
以上是笔者在经历自动化测试转型过程中的一点体会，希望能对其他正在转型或者准备转型的组织能有一些帮助。