如图1所示：开发和测试人员共用一份调查问卷。问卷分为3部分：Bug报告的内容、Bug报告的问题、评论。

1、在Bug报告的内容部分：

开发人员会被调查到2道问题：

 D2:你认为哪3个选项最能帮助修改Bug？

测试人员会被调查到3道问题：

 R1:在提交Bug报告时，你会最先提交哪个选项？

 R2:你认为哪3个选项最难提交？

 R3:你认为，哪3个选项最能帮助开发人员修复Bug？

2、在Bug报告的问题部分，开发人员会被调查到2道问题：

 D3:你在修改Bug时，都遭遇过以下哪些问题？

 D4:你认为，哪3个问题会导致你修改Bug延期？

3、在评论部分，开发和测试人员被邀请谈一谈他们有趣的经验和想法。

图1 The questionnaire presented to developers and reporters.

  结果分析  

为保证问卷结果的有效性，研究人员对最终结果做了一致性检测。例如：D1的选项没有在D2中出现，则被认为此份问卷无效。经过筛选，共有130份开发者问卷和215分测试者问卷合格。调查结果如表2，3所示：

表2 开发者调查情况

观察表2，我们可以看出开发者最常使用(most widely used items)的选项是步骤重现(steps to reproduce), 实际及预期行为(observed and expected behavior), 堆栈追踪(stack traces)和测试用例(test cases)。很少被使用到的信息是硬件信息(hardware)和安全性(severity)。Eclipse和Mozilla的开发人员都喜欢使用屏幕截图(screenshots)，而Apache和Eclipse开发人员更经常使用代码示例(code examples)和堆栈追踪(stack traces)。

最重要(importance of items)的选项，步骤重现(steps to reproduce)占了很大比重。接下来是堆栈追踪(stack traces)和测试用例(test cases)，这两个选项帮助开发者缩小了搜索缺陷的范围。实际行为(observed behavior)尽管比重很小，但可以通过模仿测试行为帮助复现缺陷，这也是它为什么能被选为最重要选项的原因。截屏(Screenshots)的评分很高，但是它通常只能针对某些特定缺陷，例如GUI错误。调查还发现，这些选项重要性相对较低。预期行为(expected behavior), 代码示例(code examples), 概要(summary),强制字段( mandatory fields)例如：版本号(version), 操作系统(operating system), 产品(product), 硬件(hardware)。

表3 测试员调查情况

观察表3，测试者们最多提供(items provided by most reporters)的选项是实际和预期行为(observed and expected behavior)以及步骤重现(steps to reproduce)。只有很少报告者添加了堆栈追踪(stack traces), 代码示例(code examples)和代码示例(code examples)。

图示：

测试者们认为最难提交的选项(difficulty in providing these items)，依次是测试用例(test cases)，步骤重现(steps to reproduce)和组件(component)。在调查问卷最后的评论中，有部分测试者们提到，他们几乎无法定位发生缺陷的组件是哪一个。

测试者们认为最有助于开发者(considered to be most helpful to developers)的选项是步骤重现(steps to reproduce)和测试用例(test cases)。

我们发现测试用例(test cases)这个选项同时出现在了以上三个问题中，说明大部分测试者们认为测试用例非常的有用，但是确实很难被提交。所以研究人员建议在缺陷跟踪系统中应当加入测试用例的捕捉和回放工具。类似的还有堆栈追踪(stack traces)，这些信息往往隐藏在日志文件中，很难被发现。组件(component)也是这个问题。

研究人员发现，测试者和开发者之间存在着大量的供需信息不匹配问题。如图2所示，图(a)表示开发者认为重要的信息VS测试者认为重要的信息，图(b)表示对开发者最有用的信息VS测试者最先提供的信息，图(c)表示开发者认为的最有用信息VS测试者认为的最有用信息。

图二

a) Information used by developers versus provided by reporters.

(b) Most helpful for developers versus provided by reporters.

(c) Most helpful for developers versus reporters expected to be helpful.

第一列显示了使用infoZilla提取的所有信息项目。这些项目分为四类：预定义的字段，如产品和组件，补丁，截图和堆栈轨迹。 修补程序和堆栈追踪通常位于说明字段中或作为单独的附件。

第二列“Master”列出了原始主报告中每个信息项的平均计数。

第三列“Extended”列出扩展Bug报告中每个信息项的平均数。这个计数将对应于重复报告与主报告对比后保留的增强信息统计。

第四列“Change”代表“Extended”和“Extended”之间的差异，每个主报告中重复添加Bug信息的平均数量。

研究结果显示，重复报告可能会提供不同的观点和额外的信息来帮助开发人员修复Bug。 例如，有更多的堆栈信息可以帮助开发人员缩小检测范围。

那么是什么原因导致这些重复报告的产生呢？研究人员详细分析后发现原因。

 1 偷懒和没经验。有些人在提交Bug时，不愿意花时间去搜索一下，这个Bug是否曾经被提交过。或者有些人不知道要去搜索。

 2 搜索功能问题。有许多参与调查的人员反映，建议改进BUGZILLA的搜索功能。一个来自Eclipse的“内存不足”的bug＃24448，在近900天内，被33个用户反复提交。

 3 同一缺陷，多种表现。有时候，两个故障（程序执行错误）属于同一个缺陷（程序代码中的错误）。例如，Bug#3361，一共有39份重复报告由同一个用户提交。像#3361这种情况，因为报告是自动创建的，所以测试人员1分钟可以提交40份报告。

 4 故意重复提交。有些用户故意重复提交一个Bug，经常是因为提交的Bug至今未修复而造成的沮丧。例如，在创建Bug＃39064超过八个月后，提交重复Bug＃54603。用户写道“我多次提出这个问题，但仍然未解决”。

 5 意外重复提交。有些用户多次点击提交按钮，导致在10分钟内，出现了相同标题，相同内容的Bug报告。