每天进步一点点,点滴的积累终究会带来质的变化。在测试这条路上,我希望我可以走的更远~~

缺陷的描述是这样提高的

上一篇 / 下一篇  2010-01-28 16:52:14

    作为一名测试人员,提交缺陷是我们必须做的功课。不知各位是否考虑过,缺陷描述也是一门“艺术”,它影射了一个人的测试经验,测试深度。缺陷描述能否做好,直接影响了我们的测试效率,更确切的说是影响了开发人员修改缺陷的效率。一份高质量的缺陷描述让开发人员看的时候是一种享受,可以提高他们的工作效率;而一份让人费解的缺陷描述,不仅会让开发感到无从下手,还会降低对测试人员的信任度。因此说,一份好的缺陷描述,体现了一个测试人员的基本素质。

    傻哥博客中一篇文章让我对如何提高缺陷描述,有了点自己的一点想法,赶紧拿出来和大家分享一下。下面是傻哥文章中举的例子,一个关于资产财务月报折旧数据不对的缺陷,各个测试人员提交的内容。

人员

缺陷描述

测试员1

资产财务月报折旧数据不对。

测试员2

资产财务月报折旧数据跟资产台账明细的折旧数据之和不等,差287.53元。

测试员3

资产财务月报折旧数据不对,zc_zjjl(资产折旧记录)和zc_yjjl(资产月结记录)折旧额不等。

测试员4

只要出现资产重置,资产财务月报折旧数据跟资产台账明细的折旧数据之和就不等。

测试员5

资产财务月报折旧数据不对,经查发现资产重置以后,资产月结的时候和zc_yjjl(资产月结记录)的重置金额未更新,折旧金额还是按照重置前的金额计算,造成资产月报数据不对。月结处理算法不对,请修改。

      从上面的例子可以看出,一个缺陷竟然出现5种说法,如果你是开发人员你想看哪位测试人员的缺陷,肯定是第5位了。不仅清晰的描述出了系统存在的缺陷,还直接帮开发人员找到的缺陷的根源。可能你还会想,不管在怎样,我已经把系统中存在的问题描述出来了,开发总会找到原因的,下面,我们再来看一下,开发对于这5个缺陷的回复。

人员

开发人员回复

测试员1

我这里测了一下,折旧数据是对的,不是缺陷。

测试员2

我这里测了一下,折旧数据是对的,不是缺陷。

测试员3

我开发库里的这两张表数据是对,请再确认一下。

测试员4

晕,我查了两个小时,我的财务报表是对,是张三的月结处理的算法是错的,请提交给张三。

测试员5

张三回复:兄弟辛苦了,中午一起吃饭。

    可能有些调侃,不过我想这些情况在大家的工作中一定都遇到过。对于一些,描述不清或不准确的缺陷,往往都被开发拒绝掉。对于这些,我总结了几点自己的经验:

一、追根溯源。缺陷也存在表面现象和真正原因,我们不仅仅应该看到它在系统中表现出的表面现象,还应该通过一步步的分析,找出缺陷产生的真正原因。有时可能通过多个测试用例才能发现,有时可能还要在多个表中查找才能查出。作为一名测试员,我们应该本着认真负责的态度,去发现任何细小缺陷的真正根源。

二、面面俱到。详细的描述缺陷产生的真实情况。作为测试人员,我们对于业务要比开发人员熟悉太多。有时候,对于一个缺陷的产生过程,总以为简单描述就可以,殊不知开发人员对你”跳跃性“的步骤,往往是一头雾水。因此,我们在描述时,要尽可能的详细。

三、简明扼要。可能听起来和第二点有些矛盾,可这确实是我们应该注意的地方。开发的周期都是相当紧凑的。我们应该用最简单的语言描述缺陷,可多用短句,保证逻辑上的清晰。

先想到了这些。很高兴能和大家分享。


TAG:

honglq2009的个人空间 引用 删除 honglq2009   /   2012-10-08 10:19:06
5
竹摇清影的个人空间 引用 删除 竹摇清影   /   2012-09-27 16:49:01
5
竹摇清影的个人空间 引用 删除 竹摇清影   /   2012-09-27 16:48:45
ZMLsimple的个人空间 引用 删除 ZMLsimple   /   2012-09-27 11:46:06
5
web测试点滴 引用 删除 284815762@qq.co   /   2012-09-26 16:58:04
  我也犯过这种错误。
web测试点滴 引用 删除 284815762@qq.co   /   2012-09-26 16:57:36
5
引用 删除 feihxu   /   2012-09-26 16:53:03
5
ilove51的个人空间 引用 删除 ilove51   /   2012-09-26 15:28:04
5
5Q的个人空间 引用 删除 shine2001   /   2010-02-04 13:41:01
这个例子看到过,很不错的例子
我补充一点
对于测试人员而言,测试人员5是我们的榜样。
这个例子其实忽略了一点,就是开发人员
由于开发人员的素质也是和测试人员一样存在偏差的。因此,即使是一个定位非常好的缺陷,也有可能遭遇开发人员的不理不睬。这个时候,测试人员还需要做一件事情,就是“一而再,再而三”,按照正常方式汇报缺陷,若开发人员不解决,或者解决不力(拖拖拉拉)则扩大缺陷的受众面。例如发起一个会话群,再次告知一下。实在不行在汇报领导。

总而言之,不要让我们的良好的测试成果被非正常的放“烂”掉
点点的测试小窝 引用 删除 qicailingbing   /   2010-02-03 17:09:57
原帖由liaoxj于2010-02-03 15:11:27发表
引用的很好!分析的更好!
继续努力!


谢谢傻哥鼓励~~
大傻测试空间! 引用 删除 liaoxj   /   2010-02-03 15:11:27
引用的很好!分析的更好!
继续努力!
点点的测试小窝 引用 删除 qicailingbing   /   2010-02-03 11:40:21
原帖由liping4186于2010-02-03 10:37:22发表
我觉得bug描述还有最重要的一点就是:截图,图片的显示胜过语言的描述,而且有的bug在程序员看来是重现不.

对,缺陷截图也是一种十分重要的缺陷展示的方式,是我们提交缺陷过程中必不可少的好帮手!
引用 删除 liping4186   /   2010-02-03 10:37:22
我觉得bug描述还有最重要的一点就是:截图,图片的显示胜过语言的描述,而且有的bug在程序员看来是重现不了的,要是有截图了,他们也没什么话说,还可以帮程序快速定位问题
沙漠飞雪的个人空间 引用 删除 沙漠飞雪   /   2010-02-02 17:15:31
沙漠飞雪的个人空间 引用 删除 沙漠飞雪   /   2010-02-02 17:15:12
5
桃花心木 引用 删除 mrfismrf   /   2010-02-02 15:56:53
说的不错,学习了。
点点的测试小窝 引用 删除 qicailingbing   /   2010-02-01 10:04:06
谢谢各位支持啊~~我会继续努力,跟大家分享我的点滴收获~~
yyj0720的个人空间 引用 删除 yyj0720   /   2010-02-01 09:56:18
  不错,呵呵
ricky的个人空间 引用 删除 wwwricky   /   2010-01-31 23:36:12
calmqin_327的个人空间 引用 删除 calmqin_327   /   2010-01-29 15:53:35
经验总结的不错噢,看来很用心哦,分享啦。
 

评分:0

我来说两句

qicailingbing

qicailingbing

虽然是很糊涂的进入了测试一行,不过越来越发现对这一行的热爱。慢慢来,一步一步向着测试走去。

日历

« 2024-04-22  
 123456
78910111213
14151617181920
21222324252627
282930    

数据统计

  • 访问量: 18547
  • 日志数: 21
  • 图片数: 1
  • 建立时间: 2009-09-18
  • 更新时间: 2010-07-22

RSS订阅

Open Toolbar