51Testing软件测试论坛

标题: Bug描述的常见问题 [打印本页]

作者: scotsmanflying 时间: 2004-10-26 10:56
标题: Bug描述的常见问题
最近在工作中注意到了这样一个现象，我们测试小组的人员经常会去给开发人员解释自己写的Bug是什么意思，一个Bug来来回回的改了好几遍，于是我大致的浏览了一下测试人员添加的一些Bug，发现了一些比较有意思的描述，现列出几个：
1.××模块：如果把打开公文附件，而下点一下“关闭”按钮，然后再点“保存“，则页面条转到空白页面，并且无任何出错提示。
这个描述我在看时也如丈二和尚般迷茫了半天，仔细看看原来是里面的错别字在捣乱。如：“而下点一下关闭按钮”应为“而且点一下关闭按钮”；“则页面条转到空白页面”应为“则页面跳转到空白页面”；打开公文附件那句中多了个“把”字，这样以来再看看就明白是什么意思了。为什么会这样？因为测试人员在输入完后没有检查就提交了，为什么不检查呢，在我们强调开发人员加强自测的同时，自己也应对自己提交的Bug负责。
2.××模块：新增后，“合同金额”过大时不应用科学技术法来显示。
为了找到究竟是那里用了科学计数法显示数字，我分别在记录列表页面、浏览页面、修改页面进行了查看，最终定位在了修改页面而其余2处都没有这种错误，那么明明有具体位置为什么当初在描述中不写具体？如果每个Bug都要让修改者如此定位的话，是不是很耗时呢？另外“合同金额过大”，这个过大究竟是多少？输入的数字超过了几位就会出现这种现象，测试时输入的数据是多少这里都没有明确的说明。Bug描述不清晰，开发人员在修改时势必要找测试人员问个究竟，这样一来大家的时间不就都浪费了么？（这里面也有错别字：“科学技术”应为“科学计数”）。

那么该如何描述一个Bug呢？过去上学老师在教大家写议论文时都会强调论点、论据、论证三要素，只要这三样齐备了那么写出的文章总归是不差的。同样我们的Bug描述中同样也要包括以下三要素：位置、操作、现象。具体来说：
1.位置：首先应说明操作进行的位置，通常是系统中的某一模块。另外是具体的出错位置，可能是某一字段、某一页面...
2.操作：详细的、有次序的、每一步的操作步骤，包括输入的数据
3.现象：具体的错误描述，包括界面显示、错误信息

Bug的记录是测试人员工作的基本内容，也是测试和开发交流的基础，确保了Bug描述的有效性，即可提高Bug的修改速度，也可提高Bug的修改质量。而作为测试人员在Bug描述中出现错别字就如同开发人员在程序中出现界面上的Bug一样，完全是不细心造成的，对于测试人员来说是不应该出现的。

[ Last edited by scotsmanflying on 2004-10-26 at 13:48 ]

作者: testing 时间: 2004-10-29 08:28
填写一份内容全面，条理清晰的问题单，使测试人员的基本功底。从论坛上很多人发帖的模糊标题就可以看出，在具体的工作中，bug报告单填写的也肯定不好。

作者: pktest 时间: 2004-11-13 23:07
标题: 还有测试的环境/使用工具

作者: ginkgo 时间: 2004-12-2 16:42
测试人员给开发人员提供的bug信息要尽可能的有用、详细，而且要避免模糊的表达。

作者: lsh 时间: 2004-12-10 10:25
标题: right

作者: babycrystal 时间: 2005-1-2 18:47
确实

作者: beiyue 时间: 2005-1-3 21:24
标题: 提供bug出现的位置，简洁明了的BUG描述，很重要

作者: kelen.wen 时间: 2005-1-18 21:46
写得很有针对性！

作者: simple 时间: 2005-1-19 15:07
向有实际测试经验的人请教，有没有那么一个好用的bug管理工具，可以很好的管理bug和规范bug。请赐教！

作者: simple 时间: 2005-1-19 15:08
或者说对于bug的管理，大家都在使用一种什么方式？

作者: txqxc 时间: 2005-2-5 15:59
提交bug时主管可以先review一下！

作者: richard2008 时间: 2005-2-5 16:40

Originally posted by txqxc at 2005-2-5 15:59:
提交bug时主管可以先review一下！

review 就不用的吧，如果来这个都搞不定如何开展工作呢。特别是碰到bug高发期，如果每个tester都去找主管review，那我看那个主管就什么都不用做了。个人意见，不针对任何人 ;)

作者: cx0744 时间: 2005-2-10 11:03
不才写的还是很详细的，不过还是要学习

作者: hxf 时间: 2005-2-16 15:10
缺陷描述应该要明确、简洁

作者: ting_yt2 时间: 2005-2-16 15:49
写得很好
作为测试人员怎么能容忍自己写下错别字呢？

至于描述不清的问题可能很多人都遇到过最初我写bug就比较模糊，后来经过指点（在此非常感谢那位给予指点的朋友），我在写bug的时候就比较注意了，当然现在仍需要不断地改进

然而，描述清楚的同时，我们又比较容易遇到另一个问题，就是冗长，开发者看到一堆文字就头大了不愿意花时间去仔细读（自己回头再看也容易晕）所以我们写bug描述一定要清晰明确且简明扼要

这些应该是测试人员自己需要把握的基本的东西，就不需要主管来review吧

作者: xihong2004 时间: 2005-3-3 17:05
顶

作者: xihong2004 时间: 2005-3-3 17:09
顶

作者: ive 时间: 2005-4-1 18:36
恩，努力提高水平！

作者: meizi 时间: 2005-4-19 13:59
谢谢阿，受益菲浅

作者: meizi 时间: 2005-4-19 14:00
能不能提交一个例子给大家看看　阿。谢谢阿

作者: flyingnow 时间: 2005-4-27 16:57
bug报表第一次写详细点其实是给自己节省时间。试想如果有20个模棱两可的bug描述，而这20个又对应若干个开发人员，这些开发人员不在一间屋子，又不可能同时看到bug，如果每个人都要问你一遍再演示一遍的话，测试人员一天就别干其他事情了。当然，估计一天的运动量也够了，呵呵。

作者: flyingnow 时间: 2005-4-27 17:14
如果再现bug需要的操作比较多，可能会造成冗长描述，我觉得可以有2种方法给出描述：
1. 用“->”表示经过的操作。
比如：打开用户登录页面->输入用户名密码XXX->选择VIP用户->点击“登录”按钮->选择“个人设定”->进行某项操作，出错......
2. 用列表的形式。还是上面的操作
1)在用户登录页面输入用户名密码XXX
2)选择VIP用户
3)登录后选择“个人设定”
4)进行某项操作，出错......

上面的例子里的操作步骤不是太长，我只是抛砖引玉觉得用这2种方法来描述问题会比较直观，让开发人员不会因为步骤复杂产生排斥心理。而且还有一个作用就是自己看起来也很清楚，碰上需要看自己很久以前写的bug报告也不会一头雾水琢磨半天。
啰嗦了这么多，就是一个意思，既然文档是用来交流的，让人不容易看懂的文档就不是好文档。
呵呵。

作者: fucc 时间: 2005-4-28 11:43
你们好！我是个新手，在测试时，一份好的测试报告怎么写？还有我在网上搜到不少测试报告，但他们的格式各不一样。是否需要分得很细？

作者: fucc 时间: 2005-4-28 11:46
同时我想问一下大侠们，CQ中处理缺陷窗体在什么地方出现，因为，提交缺陷的窗体和处理缺陷的窗体我都已创建，并且提交的缺陷能在SQL中体现，但处理缺陷我一直摸不到头脑！！

请大侠们指点一下

作者: clear_jiang 时间: 2005-6-3 10:42
我平常就要求测试人员描述时要按错误产生的步骤，及错误现象，简洁清楚的描述下来，反对将一个错误没有条理的写三四行，让人摸不着头脑

如：
步骤:
1.....
2.....
3....
此时产生错误,系统提示........, 如附件所示

作者: jasminechinadl 时间: 2005-6-13 13:04
标题: 支持!
支持!呵....

作者: 木乃伊 时间: 2005-6-16 08:57
不错，不错，

作者: ghl5502 时间: 2005-7-4 07:49
同意楼主的意见，写缺陷最主要写明模块入口，描述扼要，结构清晰。否则，别人是看不懂的。

作者: xiaohong0527 时间: 2005-7-7 12:53
呵呵，不错！

作者: stiff 时间: 2005-7-22 13:08
测试员本身不能有bug。

作者: kyonei 时间: 2005-7-22 14:25
对以后的工作很有帮助。

作者: sally313 时间: 2005-7-27 14:43
深有感触。一点注意提高

作者: joanna_king 时间: 2005-8-12 09:51
支持一下

作者: sandra.sheng 时间: 2005-8-12 17:11
很对的，支持

作者: 惠馨 时间: 2005-8-14 11:55
同意flyingnow的两种方法
简明，准确，又能节约时间

作者: B2CPC 时间: 2005-8-14 22:38
“位置，操作，对象”------楼主提出的这3要素记下了！非常有帮助的，对我来说。
也许做测试最可悲的就是发现了bug，却又说不清楚到底是什么bug。害得大家费了很大劲去搞清。你做的发现bug的测试用例可能要重测了！
正好问一下大家，此类发现bug 的测试用例是不是要重测好几遍才能提交？（1确定范围，2确定确实是这个问题，3确定描述问题时的准确性；1 2 3里选哪个，还是都要，都不要？？）

作者: name-jj 时间: 2005-9-6 09:38

Originally posted by clear_jiang at 2005-6-3 10:42 AM:
我平常就要求测试人员描述时要按错误产生的步骤，及错误现象，简洁清楚的描述下来，反对将一个错误没有条理的写三四行，让人摸不着头脑

如：
步骤:
1.....
2.....
3....
此时产生错误,系统提示...... ...

想问一下，你举的这个例子是好的，还是不好的呢？

作者: ni_xh 时间: 2005-9-12 23:35
如果bug与测试用例的工具集成了，可以不必详细的描述bug，只需给出测试用例的定位即可。比如bugzilla+test runner

作者: cherry8163 时间: 2005-10-27 15:15
需要向大家好好地认真学习啊！

作者: chenxi8320 时间: 2005-10-27 17:48
很值得学习一下，顶

作者: forestzh2002 时间: 2005-11-9 13:01
顶！！学习哈。。。。。。。。。。。。。。

作者: 爱情鸟 时间: 2005-11-10 13:29

Originally posted by name-jj at 2005-9-6 09:38:

想问一下，你举的这个例子是好的，还是不好的呢？

是好的，她叫你按照她说的那样写比较好。

作者: ch5787048 时间: 2005-11-25 18:06
报bug主要是要写好重现步骤：
首先注明需要哪些必备的环境，
接着是执行操作的步骤，
指明什么地方出错，
期望应当是什么结果，
添加必要的附件作为补充。

作者: jane10625 时间: 2005-11-28 17:38
我平时就很注意这个问题
支持flyingnow说的方法

作者: lizanhong 时间: 2005-12-1 16:21
标题: BUG的要素
作者提到BUG三要素:位置\操作\现象,是很基本的.我也做了几年测试,凭我的经验我觉得一个好的BUG还要应具备以下要素:预期的结果\实际的结果\问题分析
要写出预期结果就要熟悉了解被测东东的需求,了解客户的需求，或者对产品多年的积累.
要写出实际结果就比较容易了,包括出错的现象,还有问题所在
要分析问题就比较有挑战了,这也是衡量测试人员水平的要素.分析错误大概出在哪里.从两个方面来分析,技术上分析:使程序员更容易定位问题.业务上分析:因为有的程序员没有经验,他只知道一个模块,有深度,但是没有广度,他不知道整个项目的需求,更不知道客户的要求.他很有可能不知道要如何去修改这个BUG,如果你给他思路他会很感激的.

所以测试人员需要了解的东西需要比较广泛最好做过程序员,另外业务知识很重要,对于做项目测试尤其明显.业务知识的积累有很多途径,如去项目现场参观.

作者: xiaoye_china 时间: 2005-12-1 16:42
标题: 写出自己填写BUG 票的步骤,给大家参考!

填写BUG 票可以参考以下步骤:
1.测试的日期,版本,工具等填写完整.
2.要对BUG进行概括性的总结-----描述问题所在.
3.将测试手顺(测试的顺序)描述清楚.可以采用1.2.3....等罗列出来.
4.列出测试出现的错误概率.

作者: xiaoye_china 时间: 2005-12-1 16:48
PS:我现在没有什么管理BUG 的工具,平时就是用EXCEL 来填写BUG 票,还要用英文填写.
希望大家多多讨论.互相学习.集体进步

作者: joyzym 时间: 2005-12-8 15:50
个人觉得用英文提交BUG比中文来得准确！！

作者: 雪儿185 时间: 2006-1-24 14:21
标题: 回复 #16 ting_yt2 的帖子
说得很对，我感觉自己现在提交的BUG虽然写的很详细，但有时候觉的很冗长。

作者: pierre0505 时间: 2006-8-11 13:59

原帖由 testing 于 2004-10-29 08:28 发表
填写一份内容全面，条理清晰的问题单，使测试人员的基本功底。从论坛上很多人发帖的模糊标题就可以看出，在具体的工作中，bug报告单填写的也肯定不好。

testing 的回复中也有错别字，“ 填写一份内容全面，条理清晰的问题单，使测试人员的基本功底。”其中的“使”应该是“是”，如果我没有理解错的话。sdlkfj2

作者: pierre0505 时间: 2006-8-11 14:03

原帖由 stiff 于 2005-7-22 13:08 发表
测试员本身不能有bug。

对于stiff的说法，个人觉得有点绝对，测试人员也不是神，怎么可能没有bug呢，只能说，不能犯低级错误，不能有比较明显的bug。纯属个人意见。呵呵sdlkfj2

作者: 青青 时间: 2006-9-5 17:39
我觉的还要站在别人的角度来看问题了。
填写Bug后，你要以别人的身份来审视你的bug，看是否清楚。
我觉的几个错别字还是可以理解。只要不影响理解！

作者: rlyxx2915 时间: 2006-9-8 11:29
我觉得错别字是要不得
这样很容易让别人误解你的意思

作者: rlyxx2915 时间: 2006-9-8 11:31
我觉得这里还可以用贴图

作者: yxd2006 时间: 2007-3-8 16:56
言简意赅,清晰明了

作者: 周谦 时间: 2007-10-19 15:58
位置、操作、现象三要素不仅要在bug描述中体现，同时还要在bug主题中体现
可以把对bug描述的要求整理成规范文档，这样测试人员都能把握尺度，主管只需在最初稍加指导不用全部review。

作者: 孤独无心 时间: 2007-10-31 16:32
支持

作者: 燕子东南飞 时间: 2007-11-2 08:46

对于bug的描述直接影响到整个开发进度,在描述bug时应准确,详细.

作者: dizhu 时间: 2008-2-27 11:53
bug描述需要自己经常去摸索的，希望楼主多写一些BUG的实例。》》》》》呵呵！

作者: www888 时间: 2008-3-22 13:10
xiexie.

作者: 王爬爬 时间: 2008-3-24 22:46
呵呵，对外的"接口"很重要！

作者: zhangnalzj94 时间: 2008-4-15 09:34
确实有同感，刚开始测试时写的ｂｕｇ描述，现在看起来的确很糟糕，也需要技巧和语言的组织能力的。

作者: yu_meng123 时间: 2009-7-9 15:37
以后要注意~

作者: shenxw602 时间: 2009-10-27 13:50
写得很好

作者: freedom_me 时间: 2009-12-30 10:43
呵呵有个好的bug管理工具能效率大大提升~bug标题-主要描述/重现步骤/预期结果/实际结果的模式能避免LZ提到的很多问题。

作者: testbanana 时间: 2010-1-28 15:49
确实，提的BUG一定要简明

作者: 丢了朵朵 时间: 2010-2-5 17:38
恩现在我们公司的测试人员写bug报告也不是很规范~

作者: FENHUA927 时间: 2010-2-8 16:48
规范的问题还是需要重视呀，质量提高效率

作者: 向上de蜗牛 时间: 2010-2-20 21:09

作者: luoluolan 时间: 2010-4-13 12:00
恩很有道理呢

作者: lqadnggw 时间: 2010-8-18 18:25
如果有一个bug管理工具的话，写起来会规范很多。因为在新建一个bug记录的时候，工具一般会要求填写bug所属的模块、版本、测试机的操作系统、浏览器等，还有bug重现，以及具体的描述等

如果用的是excel或者是word之类的，最起码应该有bug所属模块和测试使用的数据，以及测试的关键步骤，最好能有bug截图。有的时候有可能是因为测试环境和开发环境不兼容而引起的

作者: 若诗 时间: 2010-9-25 23:09
顶好

作者: 守候日落 时间: 2011-12-26 16:13
恩，是的，在初期的时候我自己也经常犯这样的错

作者: zangwenjie 时间: 2013-6-18 15:24
最应该避免，也最容易避免滴bug。

作者: king860921 时间: 2017-3-17 10:22
因为错别字导致开发看不懂BUG，这个问题确实有点……

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)