有一位程序员，喜欢新东西，经常引入新方法新思路试图改变现状。

　　有一次，他觉得部门在测试手段太依赖手工测试了，于是想引入自动测试。他调研试用了几种工具以后，选择了某大公司的产品作为主要工具。

　　他计算了一下，一共有1000条测试用例需要自动化，于是他定下计划：一个人可以写5个测试用例，所以需要200个人天；计划要在一个季度完成，按一个人一季度共60个人天的话，需要4个人还有余。这样，全部用例做好以后，他估计，至少减少一半测试工作量。

　　于是，这老兄报告给总经理，总经理同意了。于是给他招了4个人，成立了自动测试组，风风火火干起来了。

　　他的做法是，手工测试有多少条用例，他用自动测试工具实现多少条。

　　一个季度下来了，全部测试用例完成了。当然大家敲锣打鼓的庆祝。但接下来，却遇到了意想不到的问题。

　　第一、所有的测试人员都认为自动测试组写出来的脚本没有用。为什么呢？因为自动测试组的员工都是新招的，对产品不熟；因此他们只好对照着手工测试用例一条条的做，像做翻译一样把手工测试用例变成自动脚本。但测试人员说，手工测试用例本身不够完善，很多测试的验证点是凭经验的，这样翻译出来的用例当然不过关。

　　第二、新产品特性已经改变了，写出得脚本过期了。因为是比照着手工用例，自动测试组使用的用例是产品的上一个版本的，这样写出来的用例当然不适合现状。

　　第三、短期内投入产出比很低。手工测试能走100个测试用例，1000个用例10天走完。但4个自动测试工程师3个月才完成1000个用例的开发，也是花了4×3×20=240个人天，算测试用例可用，也需要240÷10=24轮才能在成本上持平，如果每个版本测3轮的话，相当于8个版本。而8个版本，产品还在不在都难说了。

　　程序员做了反省，发现自己犯的大错误是：自己提出问题的初衷是减少测试工作量，但执行的时候却把“翻译”完所有的测试作为了目的，而忘记了初的目标。因为只顾着往前赶数量，从来没有请手工测试的工程师来看看，是不是可以替代手工测试；也没有在小模块上试试，看看开发人员有什么意见。

　　这样，程序员改变了做法。和开发、手工测试和手下沟通后，他决定把自动测试工程师分散到模块去，和相应模块的开发，测试成为一个工作小组。开发人员设计编码的时候，他们设计自动测试用例，充分听取手工测试工程师的经验，并且每天都运行一遍。这样，自动测试的脚本完全和产品同步。他们把自动测试用例和产品代码签入到同一个代码库，同样的版本具有同样的标签，这样，每个版本的产品都有了自动测试的脚本。

　　这样，又过了一个季度，团队开始接受自动测试了。而且有了一个意外的收获，开发人员现在乐于用自动脚本做单元测试，居然开发效率和质量都提高了。

　　程序员得出一个经验，目标在初的设定，一般都会比较清楚的，但在漫长的实现过程中很容易忘了原来的目标是什么，而把一些表面的指标当成重要的东西。因此，经常看看所做的努力和原先的目标是否一致，和能否一致，是很重要的。