51Testing软件测试论坛

标题: 最初的目标 [打印本页]

作者: VincentYang    时间: 2011-9-16 12:12
标题: 最初的目标
 有一位程序员,喜欢新东西,经常引入新方法新思路试图改变现状。

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

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

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

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

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

  第一、所有的测试人员都认为自动测试组写出来的脚本没有用。为什么呢?因为自动测试组的员工都是新招的,对产品不熟;因此他们只好对照着手工测试用例一条条的做,就像做翻译一样把手工测试用例变成自动脚本。但测试人员说,手工测试用例本身就不够完善

,很多测试的验证点是凭经验的,这样翻译出来的用例当然不过关。

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

  第三、短期内投入产出比很低。手工测试一天能走100个测试用例,1000个用例10天走完。但4个自动测试工程师3个月才完成1000个用例的开发,也就是花了4×3×20=240个人天,就算测试用例100%可用,也需要240÷10=24轮才能在成本上持平,如果每个版本测3轮

的话,相当于8个版本。而8个版本,产品还在不在都难说了。

  程序员做了反省,发现自己犯的最大错误是:自己提出问题的初衷是减少测试工作量,但执行的时候却把“翻译”完所有的测试作为了目的,而忘记了最初的目标。因为只顾着往前赶数量,从来没有请手工测试的工程师来看看,是不是可以100%替代手工测试;也没有

在小模块上试试,看看开发人员有什么意见。

  这样,程序员改变了做法。和开发、手工测试和手下沟通后,他决定把自动测试工程师分散到模块去,和相应模块的开发,测试成为一个工作小组。开发人员设计编码的时候,他们就设计自动测试用例,充分听取手工测试工程师的经验,并且每天都运行一遍。这样

,自动测试的脚本就完全和产品同步。他们把自动测试用例和产品代码签入到同一个代码库,同样的版本具有同样的标签,这样,每个版本的产品都有了自动测试的脚本。

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

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




我们的Bug描述中同样也要包括以下三要素:位置、操作、现象。具体来说:
1.位置:首先应说明操作进行的位置,通常是系统中的某一模块。另外是具体的出错位置,可能是某一字段、某一页面...
2.操作:详细的、有次序的、每一步的操作步骤,包括输入的数据
3.现象:具体的错误描述,包括界面显示、错误信息
        
Bug的记录是测试人员工作的基本内容,也是测试和开发交流的基础,确保了Bug描述的有效性,即可提高Bug的修改速度,也可提高Bug的修改质量。而作为测试人员在Bug描述中出现错别字就如同开发人员在程序中出现界面上的Bug一样,完全是不细心造成的,对于测试

人员来说是不应该出现的。
作者: 愚人    时间: 2011-9-19 16:56
写的不错,推荐阅读
作者: 苦瓜001    时间: 2011-9-21 16:39
写的很好!!
作者: 千里    时间: 2011-9-21 20:27
我也推荐阅读
作者: lyq999999    时间: 2011-9-22 01:16
看得我现在充满动力了




欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2