51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

楼主: scotsmanflying
打印 上一主题 下一主题

[原创] Bug描述的常见问题

[复制链接]

该用户从未签到

21#
发表于 2005-4-19 14:00:24 | 只看该作者
能不能提交一个例子给大家看看 阿。谢谢阿
回复 支持 反对

使用道具 举报

该用户从未签到

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

使用道具 举报

该用户从未签到

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

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

使用道具 举报

该用户从未签到

24#
发表于 2005-4-28 11:43:02 | 只看该作者
你们好!我是个新手,在测试时,一份好的测试报告怎么写?还有我在网上搜到不少测试报告,但他们的格式各不一样。是否需要分得很细?
回复 支持 反对

使用道具 举报

该用户从未签到

25#
发表于 2005-4-28 11:46:42 | 只看该作者
同时我想问一下大侠们,CQ中处理缺陷窗体在什么地方出现,因为,提交缺陷的窗体和处理缺陷的窗体我都已创建,并且提交的缺陷能在SQL中体现,但处理缺陷我一直摸不到头脑!!

请大侠们指点一下
回复 支持 反对

使用道具 举报

该用户从未签到

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

如:
步骤:
1.....
2.....
3....
   此时产生错误,系统提示........, 如附件所示
回复 支持 反对

使用道具 举报

该用户从未签到

27#
发表于 2005-6-13 13:04:46 | 只看该作者

支持!

支持!呵....
回复 支持 反对

使用道具 举报

该用户从未签到

28#
发表于 2005-6-16 08:57:58 | 只看该作者
不错,不错,
回复 支持 反对

使用道具 举报

该用户从未签到

29#
发表于 2005-7-4 07:49:46 | 只看该作者
同意楼主的意见,写缺陷最主要写明模块入口,描述扼要,结构清晰。否则,别人是看不懂的。
回复 支持 反对

使用道具 举报

  • TA的每日心情
    开心
    2016-2-18 15:03
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    30#
    发表于 2005-7-7 12:53:21 | 只看该作者
    呵呵,不错!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    31#
    发表于 2005-7-22 13:08:36 | 只看该作者
    测试员本身不能有bug。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    32#
    发表于 2005-7-22 14:25:34 | 只看该作者
    对以后的工作很有帮助。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    33#
    发表于 2005-7-27 14:43:15 | 只看该作者
    深有感触。一点注意提高
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    34#
    发表于 2005-8-12 09:51:45 | 只看该作者
    支持一下
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    35#
    发表于 2005-8-12 17:11:13 | 只看该作者
    很对的,支持
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    36#
    发表于 2005-8-14 11:55:03 | 只看该作者
    同意flyingnow的两种方法
    简明,准确,又能节约时间
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    37#
    发表于 2005-8-14 11:55:17 | 只看该作者
    同意flyingnow的两种方法
    简明,准确,又能节约时间
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2016-6-1 15:56
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    38#
    发表于 2005-8-14 22:38:45 | 只看该作者
    “位置,操作,对象”------楼主提出的这3要素记下了!非常有帮助的,对我来说。
    也许做测试最可悲的就是发现了bug,却又说不清楚到底是什么bug。害得大家费了很大劲去搞清。你做的发现bug的测试用例可能要重测了!
    正好问一下大家,此类发现bug 的测试用例是不是要重测好几遍才能提交?(1确定范围,2确定确实是这个问题,3确定描述问题时的准确性;1 2 3里选哪个,还是都要,都不要??)
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    39#
    发表于 2005-9-6 09:38:55 | 只看该作者
    Originally posted by clear_jiang at 2005-6-3 10:42 AM:
    我平常就要求测试人员描述时要按错误产生的步骤,及错误现象,简洁清楚的描述下来,反对将一个错误没有条理的写三四行,让人摸不着头脑

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



    想问一下,你举的这个例子是好的,还是不好的呢?
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    40#
    发表于 2005-9-12 23:35:31 | 只看该作者
    如果bug与测试用例的工具集成了,可以不必详细的描述bug,只需给出测试用例的定位即可。比如bugzilla+test runner
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-11-22 07:37 , Processed in 0.081205 second(s), 20 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表