见缝插针: 积极寻找适合的自动化测试对象

当软件开发的工作人员不具备测试自动化的意识时，（自动化能力总可以培训提高，所以不是自动化的最大障碍）个人偏爱渐进式的改革：

选择自动化工作量小，测试重复性高，投入产出回报率高的项目，甚至只是某个项目的一小部分任务，应用自动化。building from small pieces, 积累多了，好处就显现了，测试员自然就能培养自动化的意识，推广自动化的阻力就会自然降低。

最近，接触到了公司一个测试项目，开发员根据客户要求，要对现有数据库重新整理。实现方法比较简单，基本上，就是通过调整一个配置文件(ini file)来实现的。
这是一个重复性较高的项目，开发只需要几个小时，然而，现有的测试需要3-6天的时间。
进一步研究，发现测试员是通过连接数据库的客户端软件来进行测试的。这是一个手工的，繁琐的，容易出错的过程。

经过与开发人员讨论，了解到客户端程序会读入并解析更新的配置文件的，从而达到对现有数据库的自动调整。理论上，如果假设客户端对配置文件的解析正确，我们只需要验证配置文件正确就可以了。

这个客户端是个使用了很久的稳定的版本，对配置文件的解析从未更动过，所以，我们的假设是成立的。为了进一步确认这个假设，对这个项目的历届版本的Bug Tracing 进行统计，发现在所有测试员提交的bug 列表中，所有接受的bug, 除却客户需求变动的因素，都是开发人员没能正确配置这个文件。由此可见，我们的假设是正确的。

现在问题明朗了，我们只需要针对配置文件进行测试就可以了。对于基于ini格式的文件进行测试，对于自动化工具（e.g autoIT3)再简单不过了。

接下来的，就是要详细了解配置文件的规范，运用自动化工具开发。这个问题就解决了。