Dealing with Noise in Defect Prediction

题目： Dealing with Noise in Defect Prediction
作者： Sunghun Kim, Hongyu Zhang, Rongxin Wu, Liang Gong
单位： Hongkong University of Science and Technology, Tsinghua University
出版： ICSE

---

解决的问题

提出了一种方法，用来解决缺陷信息中的噪声。首先研究了噪声对缺陷预测模型造成的影响，提出了可接受的噪声比例范围。然后提出了一个噪声检测和评估算法。

两个应用场景

预测buggy changes

假设对于一个文件，我们有上图所示的变更历史，那么通过学习从Revision 1到Revision n中有bug和无bug的change模式，change分类模型就能够预测是否Revision n+1引入了bug。
为得到change的标签，我们首先从项目历史中抽取change，当一个commit包含fix时，我们就可以向后追踪来确定这段需要修改的错误代码是何时引入系统的。
一个文件的change包含两个源码版本和一个记录了添加代码和删除代码的change delta。一个文件的change有相关联的元数据，例如chage log，作者，和commit日期。通过挖掘change历史，我们可以得到co-change数量，也就是一个commit中有多少和文件是一同修改的，还可以得到一个文件的作者数量，一个文件历史更改次数等等。我们将这些作为特征。

预测buggy files

另一种常见的缺陷预测是提前识别出文件中的bug，人们普遍认为软件的一些内部属性（例如度量元）与外部的属性（例如缺陷）是有关联的。近年来许多基于软件度量元的缺陷预测模型已被提出，这些缺陷预测模型以度量元为特征，利用已构建的模型来预测新项目模块的缺陷情况。

缺陷信息中的噪声

上述两种方法都需要标签来构建和评估模型。为将文件/change标记为有缺陷/无缺陷，很多研究人员对开源系统的bug数据库进行挖掘。有两种方法是人们广泛应用的：搜索关键词，例如”Fixed”，”Bug”，和搜索与bug report相关的引用，例如”#42233”。我们在实验中同时应用了这两种方法。
有一些开源项目为它们的change log制定了很强的规则。例如，Columba的100%的chage都有类似’[bug]’ , ‘[intern]’, ‘[feature]’, ‘[ui]’这样的tag。Eclipse的开发者通常会在他们的chage log中标有相关的bug report ID。
然而近期的一些研究发现通过挖掘软件仓库收集到的数据往往包含bug。他们发现关联的bug数量不等于所有已修改bug数量，有时甚至占不到50%，这说明缺陷数据集中有很大的漏报率。这是因为开发者在修改bug的revision中经常不写特定的关键词，或者没有留下bug report链接。最近的研究已经证明这样的噪声对缺陷预测结果会产生影响。

实验

研究问题

1. 一个缺陷预测模型对缺陷数据漏报的抵抗性(resistant)如何。
2. 一个缺陷预测模型对缺陷数据误报的抵抗性如何。
3. 一个缺陷预测模型对同时包含误报和漏报的缺陷数据抵抗性如何。

制造有噪声的数据

为解决我们的研究问题，我们需要一个标准数据集(golden set)，其中不含任何误报或漏报，同时我们需要有噪声的数据集。然而得到标准集是很难的，我们认真挑选了一些高品质的数据集，并假设它们是标准集。然后为得到包含噪声的数据集，我们为标准集添加噪声。具体做法是随机从标准集中选择样本，然后改变它们的标签（从有bug变为无bug，或从无bug变为有bug）。值得一提的是，我们只为训练集添加了噪声，而测试集继续利用标准集。
我们的实验利用贝叶斯网络作为分类器，并且利用10折交叉验证来保证准确性。

傀儡分类器

一个有效的分类器的分类效果至少应该强于随机猜测，我们将一个基于随机猜测的分类器叫做傀儡分类器。我们利用傀儡分类器的F分数作为我们度量缺陷预测模型噪声抵抗性的基准。我们假设傀儡分类器随机地将50%的样本分类为有缺陷，将另外50%样本分类为无缺陷，由此得到的傀儡分类器的F分数为0.375。

噪声抵抗性

Change Classifcation的噪声抵抗能力

目标项目

我们使用Columba, Eclipse JDT Core, Scarab作为我们实验的目标项目，因为这些项目有高品质的change log。对于前两个项目，我们直接使用 Classifying Software Changes: Clean or Buggy? 中收集的数据集作为基准集。数据集信息如下所示。

初始准确性

我们利用不加缺陷的数据集构建了基于change分类的缺陷预测模型，并且评估了它的性能如图所示。

漏报抵抗性

为添加漏报，我们随机选择含有bug的样本，将它们的标签改为无bug。下图显示了在包含不同比例漏报的数据集中得到的F分数。x轴表示我们人工添加的漏报比例。同时也显示了傀儡分类的F分数。

对这一结果的一个可能解释是表征bug的特征是较为普遍的，因此训练集中失去一些样本并不会对性能造成很明显的下降。

误报抵抗性

我们以类似方法为数据集添加误报，得到的结果如下图所示：

对Eclipse敏感性的一个可能解释是其数据集中buggy change的数量较小，在添加了众多FP(False Positive，误报)后，表征bug的特征变得不再明显。

误报与漏报的抵抗性

下图显示了同时为数据集添加误报和漏报后，缺陷预测模型的性能。

Buggy文件预测

目标项目

我们利用SWT和Eclipse 3.4中的Debug项目作为标准集。我们通过挖掘Eclipse Bugzilla和CVS仓库来收集缺陷信息。两个项目的信息如下表所示：

我们还为两个项目收集了以下度量元作为特征：

• 复杂度度量元，包括代码行数，平均圈复杂度，最大圈复杂度
• 面向对象的度量元(CK-OO度量元)
• change度量元，包括从上个主要版本增添和删除的代码的行数，文件被修改的次数
• 开发者度量元，即参与修改文件的开发者数量

我们对这两个项目进行了与上面类似的操作，得到下面三个图：

讨论

可接受的噪声比例

我们的实验显示，当有缺陷的实例足够多时，增加FP或FN并不会对预测性能有明显的影响。而对于既有FP又有FN的数据集，噪声增加时预测性能会减弱。当数据集中有bug的样本数较小时，模型的性能会受到较明显的影响。
在缺陷预测实践中，漏报往往更加常见。误报通常发生在开发者发布了一条消息称他修改了一个bug，然而实际上并没有时。
我们认为，我们的研究结果至少可以应用在chage分类和buggy文件分类问题上，建议研究者在构建分类模型之前先对数据进行采样和人工检查来衡量FP和FN比率，根据比率来判断缺陷数据是否可用。

不同机器学习方法的噪声抵抗性

在前面的部分我们通过贝叶斯网络得到了我们的结果，而本节我们会使用朴素贝叶斯，支持向量机和集成学习来重复实验，观察噪声对预测准确性的影响。我们利用SWT进行实验的结果如图所示：

处理缺陷数据中的噪声

识别噪声样本

我们提出了一个新颖的检测噪声的算法叫做Closest List Noise Identification(CLNI，我就不尬翻了)，算法由下图给出。

CLNI算法是这样工作的：对每一次迭代j，对每一个样本Insti，与它最近的样本被列出来，称为Listi。在Listi中，样本根据它们到Insti的欧式距离按升序排序。排名最高的N个样本中，与Insti类别不同的样本比例计为θ。如果θ大于或等于某个阈值δ，那么Insti很有可能就是一个噪声样本，应该被划分入噪声集Aj，重复上述步骤直到Aj和Aj−1间的相似度超过ε，此时返回Aj作为噪声集。研究表明，当N取5，δ取0.6，ε取0.99时，算法的效果最好。

评估

我们利用Eclipse 3.4 SWT和Debug来评估CLNI，我们通过随机选择n%的样本并改变其标签来创建噪声数据集，然后对其应用了CLNI，利用精确度，召回率和F分数来评估CLNI的性能。当噪声率为20%时，结果显示精确度超过0.6，召回率超过0.83，F值超过0.71，在不断增加噪声率的情况下精确度，召回率和F值的变化如图所示。

可能存在的问题

• 我们实验中用到的所有数据集都是从开源项目中收集的，商业公司软件缺陷管理中引入的噪声可能与开源项目不同。
• 论文中的标准数据集可能不够完美。
• 我们实验中的噪声数据仿真可能与实际的噪声模式不同。