程序员的灯下黑:不要忘记你的目标

   
有一位程序员,喜欢新东西,经常引入新方法新思路试图改变现状。
有一次,他觉得部门在测试手段太依赖手工测试了,于是就想引入自动测试。他调研试用了几种工具以后,选择了某大公司的产品作为主要工具。
他计算了一下,一共有1000条测试用例需要自动化,于是他定下计划:一个人一天可以写5个测试用例,所以需要200个人天;计划要在一个季度完成,按一个人一季度共60个人天的话,需要4个人还有余。这样,全部用例做好以后,他估计,至少减少一半测试工作量。
于是,这老兄报告给总经理,总经理同意了。于是就给他招了4个人,成立了自动测试组,风风火火就干起来了。
他的做法是,手工测试有多少条用例,他就用自动测试工具实现多少条。
一个季度下来了,全部测试用例完成了。当然大家敲锣打鼓的庆祝。但接下来,却遇到了意想不到的问题。
第一、所有的测试人员都认为自动测试组写出来的脚本没有用。为什么呢?因为自动测试组的员工都是新招的,对产品不熟;因此他们只好对照着手工测试用例一条条的做,就像做翻译一样把手工测试用例变成自动脚本。但测试人员说,手工测试用例本身就不够完善,很多测试的验证点是凭经验的,这样翻译出来的用例当然不过关。
第二、新产品特性已经改变了,写出得脚本过期了。因为是比照着手工用例,自动测试组使用的用例是产品的上一个版本的,这样写出来的用例当然不适合现状。
第三、短期内投入产出比很低。手工测试一天能走100个测试用例,1000个用例10天走完。但4个自动测试工程师3个月才完成1000个用例的开发,也就是花了4×3×20=240个人天,就算测试用例100%可用,也需要240÷10=24轮才能在成本上持平,如果每个版本测3轮的话,相当于8个版本。而8个版本,产品还在不在都难说了。
 
程序员做了反省,发现自己犯的最大错误是:自己提出问题的初衷是减少测试工作量,但执行的时候却把“翻译”完所有的测试作为了目的,而忘记了最初的目标。因为只顾着往前赶数量,从来没有请手工测试的工程师来看看,是不是可以100%替代手工测试;也没有在小模块上试试,看看开发人员有什么意见。
 
这样,程序员改变了做法。和开发、手工测试和手下沟通后,他决定把自动测试工程师分散到模块去,和相应模块的开发,测试成为一个工作小组。开发人员设计编码的时候,他们就设计自动测试用例,充分听取手工测试工程师的经验,并且每天都运行一遍。这样,自动测试的脚本就完全和产品同步。他们把自动测试用例和产品代码签入到同一个代码库,同样的版本具有同样的标签,这样,每个版本的产品都有了自动测试的脚本。
 
这样,又过了一个季度,团队开始接受自动测试了。而且有了一个意外的收获,开发人员现在乐于用自动脚本做单元测试,居然开发效率和质量都提高了。
 
程序员得出一个经验,目标在最初的设定,一般都会比较清楚的,但在漫长的实现过程中很容易忘了原来的目标是什么,而把一些表面的指标当成重要的东西。因此,经常看看今天所做的努力和原先的目标是否一致,和能否一致,是很重要的。
 
 
 

没有更多推荐了,返回首页