Where Should the Bugs Be Fixed? 导读

该论文来自ICSE2012，点击下载该论文《Where should the bugs be fixed? More accurate information retrieval-based bug localization based on bug reports》

这篇Papper使用信息检索的方法来实现file level的BUG定位。那么BUG定位到底如何理解呢？举个列子来说，对于某个Project，突然上报了一个Bug Report，那么我们就要去找这个Bug Report中描述的问题到底是出在哪个/哪几个code file里呢？这就是所谓的Bug定位。关键问题就在于如何定位？

我们回忆一下信息检索的机制：给定一个文档集和一个查询，计算文档集中的文档与查询的相似度，按照计算的相似度降序排列，返回查询结果。那么我们类比到现有的BUG定位的场景中，工程的code files可以看做是文档集，而指定的Bug report可以看做一个查询，因此BUG定位可以看作是检索project中与bug report最相似的code files（注意可能不止一个）。为什么这样做可行能呢？我们看一下下面这个例子：

Figure1的分割线上面是BUG的描述（也就是bug report中的内容），分割线之下是这个bug对应的需要修改的源代码文件。我们发现在bug report中出现了Pin, console, display等词，而对应的代码文件中也出现了类似的词，正是这些共现词的出现很好的建立了Bug Report和code file之间的相关关系。

BUG定位的过程大致分为4步：1）分析语料，需要做的工作有分词，剔除常用词（包括一些类型标示符，操作符，分隔符等）和停用词；2）构建倒排索引；3）分析bug report，生成查询的空间向量；4）计算相似度得分并排序。表示文档的VSM中权重使用的是tf-idf指标：tf-idf = (1 + log(tf))log(#docs/df)。我们知道使用VSM计算余弦相似度来排序时对短小的文章更有优势，对长文来说计算得到相似度会很低，因此没有优势可言。但是在软件缺陷领域，研究表明越是长的code file存在BUG的概率越高。通常对于一个project来说，最长的20%的code file包含了绝大多数的BUG（大于60%）。因此在bug定位时，如果两个code file与bug report的余弦相似度相同，那么我们希望较大的那个文件的排名要比较小那个来的高。因此，在计算最终得分的时候需要考虑code file的长度(也就是词数)。我们看到本文提出的解决方案是在cosin相似度上乘一个文档长度得分g(#term)，从下式可以看出，code file长度越长g(#terms)的值就越高，从而调高最终的得分以使得长code file能够尽可能靠前。N(X)就不说了，就是用来将数值规范化到（0，1）之间。

 

单单考虑相似度并不能保证目标code file排名一定靠前，研究发现，对于某些BUG来说，他们的目标文件的排名非常靠后。因此需要引入另一种解决方案：考虑先前解决的与其类似的BUG. 具体方案如下图所示： 本文中将其表述为三层的异构图谱，其中第一层即为提交的BUG report， 第二层是与BUG report相似的所有fixed的BUG report，第三层是修复第二层中各个BUG所涉及到的code file，连线表示彼此之间存在关联。

Layer1中Bug report与Layer2 中的BUG reports的相似度采用cosin相似度来计算。则Layer3层中的每个文件Fj与Layer1层中的Bug report相关度得分由下式计算得到：

其中ni表示的是Layer2中的si关联的code file数目。至此又可以得到一个code file的排名列表。

为了使最终的预测结果更准确，我们将通过相似度计算得到的排名列表和通过相似的BUG得到的排名列表合并起来，每个code file的最终得分使用下式进行计算：

其中是取值在0-1之间的权重因子，最终得分是rVSMScore和SimiScore的线性插值。经验表明，取值在0.2-0.3时方法的性能最好。

那如何来评估预测结果呢？一般评估TOP1，TOP5，TOP10三种情况。 Top N表示的是对于某个bug report，如果最终预测结果的Top N中包含了至少一个目标code file，则认为对于该bug的定位是成功的。因此，我们通过统计所有bug report的Top N结果就可以得到最终Percision.