能不能提交一个例子给大家看看　阿。谢谢阿

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

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

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

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

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

请大侠们指点一下

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

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

支持!呵....

不错，不错，

同意楼主的意见，写缺陷最主要写明模块入口，描述扼要，结构清晰。否则，别人是看不懂的。

呵呵，不错！

测试员本身不能有bug。

对以后的工作很有帮助。

深有感触。一点注意提高

支持一下

很对的，支持

同意flyingnow的两种方法
简明，准确，又能节约时间

同意flyingnow的两种方法
简明，准确，又能节约时间

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

引用:

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

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

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

如果bug与测试用例的工具集成了，可以不必详细的描述bug，只需给出测试用例的定位即可。比如bugzilla+test runner