【IT168 评论】谁在推动软件自动化测试?

　　做过一个单元测试自动化，我们开发了近百行的测试代码去测试一个代码行为10行的函数;在UI测试自动化，则调用了IE的COM接口去驱动IE application，以模拟在界面上的两个动作，输入“测所”和点击“搜索”按钮，总共9行代码(如果考虑自动化健壮性的话，还要增加错误处理代码)。

　　观察到这些，我们暂且不考虑自动化测试开发之后的维护，至少可以有一个直观的认识：从手工测试向自动化测试的转变是要付出的成本的，而且这个投入要远比做一次手工测试的代价要高，比如，一个有经验的自动化测试开发人员完成一段健壮的100行左右的测试脚本大概需要一天左右的时间，而手工完成这个功能点的测试则只需要10分钟。一天 VS十分钟，按理说，这是一个赔本的买卖，但为什么还有这么多的软件企业对测试自动化情有独钟呢?排除一些盲目跟风，试图提高测试技术含金量的情感因素，至少有以下几个理性的现实驱动力。

　　1. 测试自动化主要是做长线投资，而非一时之计

　　显而易见地，开发一个程序，只为了运行一次自动化测试是非常不划算的。那么要想能收回开发自动化测试的投资，就要尽可能多地运行测试程序，每多运行一次，就会多节省一份手工测试工作量。这个简单的道理可以说明为什么如今测试自动化应用最多的就是回归测试阶段。由于回归测试往往是验证软件bug的fix或者软件补丁的有效性，理论上，每一次bug的修复，都需要进行一次全面回归测试。如下图所示。

　　这样在软件测试流程里，回归测试包括在测试分支(Test Branch)上进行的bug验证测试，还有在发布分支(Release Branch)上进行的补丁更新测试(在实际的企业实践中，发布分支的更新远远比图中频繁)，这样回归测试的重复性就非常高，而且持续时间长，直到软件在市场上的退出才结束。这对于手工测试人员来说，可以说是一个对耐心和毅力的巨大考验，再美好有趣的事情如果天天重复去做，而不做任何变化，最终也会成为枯燥乏味的代名词。所以手工测试人员是有愿望通过自动化测试来改变现状的。这就为回归测试自动化的实施同时提供了主观的动机和客观需求。