笔者在企业里就有类似的经历，一个项目已经上线，以后每次发布一个补丁之前，测试人员都需要通过执行一些SIT(System Integration TestCase)测试用例来覆盖整个系统的大部分模块。而执行一遍这样的用例，至少需要花费六个测试人员一天的时间。后来在这个项目内进行了自动化测试的实验，根据SIT的测试用例转换成自动化脚本。运行一个用例脚本只需要十五分钟，而每次也只需要一个测试人员把所有脚本运行一遍就可以了，其他人就可以从中解放出来做其他工作了。像这样比较成功的例子，一定要在后期工作开展时加以宣传，要认大家认识到自动化好处，这样大家才会有积极性去学。
4）有了上面的经验，接下来该在整个部门进行自动化测试的推广了。当然适当给从业人员进行工具的使用技能以及一些相关知识培训还是有必要的。因为在工作中常常发现由于测试工程师掌握知识的差距，每个人对工具上手操作有快有慢。为了尽量给大家造成好的影响，能够更好的开展这项工作，使其能更快的应用到日常工作中去，减轻部分繁琐的重复性劳动，对测试工程师进行培训还是必不可少的。
5）正如软件生命周期有需求分析阶段一样，在录制自动化脚本之前也需要收集需求,这些需求主要是用于后期录制脚本的选取。这些需求可以根据需求人员做的需求文档，也可以选择测试人员的测试用例来转化成脚本，还可以让需求分析人员推荐几个常用的，相对简单的流程转化成脚本。总之一句话，需求就好比源头，从源头抓起才能开发出高质量的脚本。
6）做了前面一系列准备工作，已经有了一个好的开始。接下来就要求大家进行一次头脑风暴，对刚收集来的需求进行分析，设计出一个好的实现方案。这里我想强调两点：
第一、工具只能帮助测试人员去更好的进行测试，至于怎样使用才能提高工作效率，还是需要测试人员在实施前期进行更多的思考，比如思考如何把一个好的设计转化成我们后期的自动化脚本等。因为脚本是不会创造性的发现本身没有涉及到的缺陷，就好比许多测试人员编写测试用例，如果你没有把你要测试的功能点写入测试用例中，根据测试用例执行人员是不会考虑到这一点的。因此设计一个全面，详细的设计方案显得尤其重要。
第二、出于程序可复用的角度考虑，按照怎样的划分粒度，如何把脚本进行好的规划也很重要。例如：将一些使用率高的模块录制成共享脚本，使用者只需要通过一些参数进行使用，无须考虑到内部的具体实现机制。这样还可以大大减少大家的重复劳动量。
7）对工具有了一定认识以后，就到了上手操练阶段。俗话说：“拳不离手，曲不离口”。由于前期投入大量精力、人力、物力，现在正是出成果的时候。但在开发脚本之前，笔者还有几点想着重申明一下：
第一、开发脚本必须遵循一些规范化，就类似于程序员编程规范一样。我们的测试脚本就好比是我们测试人员的程序，同样要形成一个编写规范。因为养成这样的好习惯，是为了能方便维护脚本，避免增加后期的维护量和方便使用者使用；
第二、保证开发的脚本回放没有问题的基础上，适当增加出错处理来增强脚本；
第三、后期还可以在脚本中加入检查点，这样做的好处可以把原来需要人工去校验的地方让脚本去做；
第四、在脚本中增加数据驱动方法，使脚本能覆盖更多的分支路径，进一步提高脚本的集成度。因为前面已经说过了，脚本是不会执行那些没有被编写进去的功能点的，所以说后期测试人员一旦发现这个地方有必要让脚本来代替手工进行执行，就可以不断的增强我们的自动化脚本。
8）最后，切记任何工作的开展并非一朝一夕，新技术的开展将需要投入大量人力物力，而自动化测试就是我们测试工程师必须要坚持的一个长期的发展方向。为了不至于做事只做表面，建议每个测试团队中都必须要有专人去负责推动自动化工作的开展。还必须有专人负责维护脚本，规范脚本，甚至可以引入配置管理工具来统一管理脚本和把经验文档化。只有这样我们的测试财富才会从中不断积累，只有这样自动化测试才能走得更远。
以上总结了几点，都是笔者在企业中推行自动化测试的一些心得体会。最后希望能够有更多人从自动化测试中获得快乐，从繁琐的手工测试中解脱出来。
文章来源于领测软件测试网 https://www.ltesting.net/
