缺陷报告的问题

我的看法：做了三个月的缺陷报告的评审活动了，一些小小的看法。从最初开始的关注点，我们是强调了格式和内容，那么根据模版我们修改了CQ系统，现在格式基本上都是统一的。那么我们现在在看一个缺陷报告的时候，应该关注的是什么呢？

如果是我来看，应该是强调了这个缺陷的简洁和完整，并能够很明确的展示问题在哪里。

关于标题：这个不用多说了，强调缺陷的问题，要客观的描述系统的反应，能吸引人的眼球，不需要过多思考这到底是什么错误是最好的。

关于步骤：

1）这里可能会有两种情况，那么一种情况是如果按照操作步骤一步一步下去，的确是可以重现，但是有一些步骤是明显不需要的，还有就是遗漏了一些前提条件的，或者省略了一些步骤的。这两种情况都不好，但第一种好过第二种。这需要我们学会去过滤一些测试步骤，最好是学会自己去定位错误。

2）如果用到了一些数据，尽量不要用你测试的数据。因为开发人员在他本地进行调试的时候，可能没有你用到的数据，那么他重现的时候可能还需要去创建你的数据。这种情况应该尽可能用一些数据特征代替比较好。如果可能，最好是写上你用的数据是否是一些特殊数据。比如登陆用户就不要写具体的你测试用的名称和密码，你可以用管理员代替。

3）关于前置条件，如果是不必要的前置条件，就不需要写上去了。

4）如果开发人员的确是需要访问测试服务器来重现，最好给一个详细的配置，让他们能更高效的重现问题

关于语句：

1）当然是要客观，不要用模糊的词语，也不要用将来时态，也不要出现I，She之类的词语，因为描述的都是系统的反应，主语一般来说没有或者是System

 2）还是老观点，一个bug report只能提交一个缺陷，并且所有的步骤都应该是不可以拆分。别一句话里面包含了两个问题

 3）语句尽量精确一点。比如你说在输入产品ID的时候输入了20个字符，系统崩溃，这种说法其实有点问题，那么别人可能会思考，如果输入30个字符，15个字符会不会出错。所以这里最好是能把问题定位准确了，描述上去。

关于提交：

 1）如果你发现的缺陷在多个地方出现，结果都是一样的，最好是作为一个bug提交。比如打印功能，可能是一个控件的问题，但很多地方都有打印，那么就作为一个问题提交上去。

 2）但是如果你发现的缺陷在某个地方可以，某个地方不可以，但功能是类似的，那么最好作为多个bug提交上去。比如在报表中打印可用，但参数配置的打印不可用。那么不可用的地方的问题都提交上去。

关于检查：最好在提交一个bug之后，自己重现的读一遍，看看是否有遗漏或者需要补充的地方。我觉得如果时间允许的话，可以尝试着去定位一下是错误，这个错误可能是什么问题引起的，是否会引起其他地方的错误，这样可以让思路更加开阔。