摘要：稍具测试规模的项目团队皆想引进自动化测试，然而动手实现自动化测试的团队却不多，未能真正实施的原因多种多样，有扼杀在摇篮里的，有写了后弃之不用。那么是不是所有的业务都适合自动化测试呢？下面就介绍下自己在项目中怎样实施自动化测试。

我所在项目组将自动化测试应用于项目中已经有三年多，自动化脚本应用至今，按每月执行两次的频率，至今已经执行有七十二次有余。由于系统的GUI足够稳定，这期间发生了两次由于句柄（hwnd）引发的脚本维护，由于规律性极强，也只花费了十人日来维护所有的脚本，维护脚本的资源和时间成本较低。下面就简单记录下自动化测试实现和运用时的一些要点。

自动化测试引进实施的背景主要有两个方面客户投诉和系统改版。客户投诉的主要原因是系统的数据计算不稳定，发布的新版本对低版本的系统产生的数据计算错误。系统改版需要兼容已发布的系统的数据，保证改版后的数据计算与已发布的系统的数据一致。

自动化测试的实施，最重要的是自动化工具的选择。由于系统的GUI是图形界面，不能获取每个单元格的内容，TestComplete、QTP等考虑过，写了一两个基本功能的脚本，验证后实施起来有困难，TestComplete的通过图片的形式来进行结果的对比产生的误差比较大，运行的测试结果不稳定；放弃其它测试工具的原因就不一一描述了。最后使用的自动化测试工具是公司的开发人员基于系统框架开发的，提供了一些获取系统单元格和其他数据的函数，保证了自动化测试的顺利进行。

自动化测试工具确定之后，主要是测试脚本的培训和开发。由于自动化测试脚本语言和系统使用的二次开发语言相通，在二次开发人员的帮助下，测试人员很快掌握了测试脚本语言的使用方法。

接下来就是确定自动化测试的范围。如果系统能达到100%的自动化测试，当然这是最好的。项目的实际情况是有些功能的UI变化大和测试结果数据变化频繁，这些都不在自动化测试脚本开发的范围内。因此，我们最后确定的自动化测试的范围是版本迭代时验证系统的核心功能。

紧接着就开始自动化测试脚本的开发。开发第一个脚本是最费时间的，首先需要确定读取的配置文件格式及参数内容，参照数据的存放形式（Excel、Access、XMl或其他文件格式），实现的功能脚本，测试结果的存放形式（html、txt、Excel或其他文件格式）。开发脚本完成后，就是调试，在调试的过程中遇到问题时若三十分钟不能解决，则应向有经验丰富的同事请教，以免耽误脚本开发进度。第1个脚本开发完成后，接下来的开发工作可以在第1个脚本的基础上进行修改，并将常用的函数存在公共函数文件中，这样会大大提高开发效率。

自动化测试脚本的应用。每次版本迭代时，手工测试完成，需求变更等功能趋于稳定，这时运行自动化测试脚本的时机相对来说比较合理，这样保证了发布的系统的核心功能的准确性和稳定性。

最后要做的事就是自动化测试脚本的维护。系统GUI变化，自动化测试范围的增加，这些皆应在系统定版后安排进行，待下一次版本迭代时，用于验证系统功能的正确性。

经过这几年的自动化脚本用于项目的实战经验，我的个人看法是自动化测试并不能完全替代手工测试。每个系统都会发生需求变更，若系统的核心功能不变，则可以将不变的核心功能用自动化测试来替代，其他功能手工完成，这才是有效利用资源和时间的最佳方式，才能获得良好的ROI。