我对软件自动化测试的见解

　　2、自动化测试是适用于任何情况的

　　2.1 自动化测试是适用于任何产品的

　　并不是所有的产品都适用于自动化测试的，如果这个产品只会做有限的几轮测试，接着不会再有持续的开发。那么没必要使用自动化测试，因为这样的投入产出比比较低。毕竟在开发自动化测试阶段需要耗费大量的人力物力。对于决定自动化一个测试用例的一般规则是这个测试用例必须被运行 4 次以上。这个数字是基于用户对测试工具有良好的技能并且有一个良好的测试框架的。如果情况不是这样的话，整个数字能够是 10-20次或者更高。

　　再者如果变化比较大的话也不适用自动化测试。国内多数软件公司是针对终用户进行项目开发—工程性质的软件，而不是产品开发。项目开发周期短，不同的用户需求不一样，而且在整个开发过程中需求和用户界面变动较大，这种情况下不适合自动化测试，对于不停变化的需求和界面，可能修改和录制脚本的工作量大大超过测试实施的工作量，运用测试工具不但不能减轻工作量，反而加重了测试人员的负担。

　　2.2 自动化测试是适用于任何测试阶段的

　　版本经理通常认为自动化测试能运用于任何阶段的钥匙，但事实上从本人的经验来看，自动化测试适用于回归测试，但不适用于新功能的测试。首先因为新功能刚递交之时稳定性是不可保证的。而自动化测试对于其不稳定性是相当敏感的，所以通常都无法正常的运行完测试，也无法达到我们尽快得到结果的预期。其次在新功能刚递交时其期望结果是不可预知的，这对于自动化测试脚本的编写带来了极大的不确定性。后在新功能递交阶段是需要我们发现大量问题的时候，而自动化测试无法担此重任。

　　2.3 自动化测试是适用于任何组织的

　　在初尝试自动化测试的时候，是需要投入相当的人力和物力去选择自动化工具，构建自动化测试的框架，做必要的技能培训，摸索编写自动化测试的脚本，如果一个组织无力承负这样的代价，那么是不适合自动化的，否则只能是半途而废的下场。

　　即使我们澄清了这些误区，我们对于自动化测试有了一个比较清晰的认识，也对其有了一个正确的期望，但实际在推行的过程中我们还是会遇到不少的困难，而困难主要来自于以下几个方面。

　　3、自动化测试推广中的困难

　　3.1 来自于测试人员的不接受

　　因为测试人员是自动化测试的主体，他们承担着转型的重要职责，所以他们的接受与否对于工作的展开是尤为重要的。但作为一个新生事物，通常是不太容易被接受的，尤其是在大家觉得原有的模式很舒服很习惯的情况下。所以在初的阶段完全是强推。而经过一年的努力，当作年终总结时，所有的测试人员都说那年艰难的是自动化测试，感触深的是自动化测试，从中学到多是是自动化测试，而且发现自动化测试的确帮了很大的忙。

　　3.2 来自于测试人员技术上的不足

　　测试人员很多都不具有编程的经验，但自动化测试脚本的编写还是需要一定的编程功底，如果组织中专门有一个具有编程功底的团队能开发自动化测试的工具，并且根据手动的测试案例编写自动化测试的脚本，那状况可能会好些。但目前更多的组织是需要人人能编写自动化脚本的。而在我们的转型中我们经历了三个阶段，基本完成了能力的建设。第一阶段以能用为目的，专门有人提供所需的函数，测试人员只需调用这些函数完成自动化测试的目的，不需要考虑程序的可移植性，可复用性。第二个阶段每个人会写一些自己所需要的函数，并且具有良好的移植性和灵活性。第三个阶段每个人会写能为他人复用的函数并且遵循制定的规范。这样的转型虽然慢但却是比较稳妥的方式。

　　3.3 来自于组织内其他人员的阻挠

　　在自动化测试的初期阶段，必然是会耗费相当多额外的精力去构建环境等等，而且我们也需要时间完成技术上的积累。所以这时候不得不像项目经理去索要更多的人力。这是一个长期受益的举措，但对于当前而言似乎是利大于弊的。所以会遭受各方各面的压力，尤其是来自于项目经理的压力。我们很幸运我们走过来了，而现在当所有的人尝到了甜头之后，对于自动化测试的支持程度也大大的提高了。

　　以上是笔者在经历自动化测试转型过程中的一点体会，希望能对其他正在转型或者准备转型的组织能有一些帮助。