英语原文共 11 页，剩余内容已隐藏，支付完成后下载完整资料

将BUG报告映射到相关文件：排名模型、细化基准和功能评估

摘要-当收到新的bug报告时，开发人员通常需要复制bug并执行代码评审来找到原因，这是一个繁琐而耗时的过程。 一个对所有源文件进行排序的工具可以帮助开发人员缩小搜索范围，提高工作效率。 本文介绍了一种通过源代码的功能分解、库组件的API描述、bug修复历史、代码更改历史和文件依赖图来利用项目知识的自适应排序方法。 给定一个bug报告，每个源文件的排序分数被计算为一组特征的加权组合，其中权重被自动训练在以前解决的bug报告上学习使用排序技术。 我们使用项目的预修复版本的每一个bug报告对六个大规模开源Java项目进行排名系统评估。 实验结果表明，学习排名方法优于最近三种最先进的方法。 特别是，对于Eclipse Platform和Tomcat项目中超过70％的错误报告，我们的方法在排名前10位的源文件中都提出了正确的建议。

索引词-错误报告，软件维护，学习排名

1. 导言

软件错误或缺陷是一种编码错误，可能导致软件组件的 意外或意外行为。 当发现软件项目的异常行为时，开发人员 或用户将在文档中报告它，称为bug报告或问题报告。bug报告提供了有助于修复bug的信息，其总体目标是提高软件质量。 在软件产品的开发生命周期中，可以打开大量的bug报告。 例如，仅在2013年就为Eclipse平台产品创建了3389个bug报告。 在软件团队中，bug报告被管理人员和开发人员广泛使用-在他们的日常开发过程中。被分配bug报告的开发人员通常需要复制异常行为并执行代码评审以找到原因。 然而，bug报告中经常缺少基本信息，bug报告的多样性和不均匀的质量使这个过程变得不简单。 Bacchelli和Bird调查了165名管理人员和873名程序员，并报告说，发现缺陷需要对代码有很高的了解，并熟悉相关的源代码文件。 在调查中，798名受访者回答说，审查不熟悉的文件需要时间。 虽然项目中源文件的数量通常很大，但包含错误的文件数量是通常很小。 因此，我们认为，根据源文件与bug报告的相关性对其进行排序的自动方法可以通过将搜索范围缩小到更少的可能不熟悉的文件来加快bug查找过程。如果错误报告被解释为查询，并且软件存储库中的源代码文件被视为文档集合，那么查找与给定错误报告相关的源文件的问题可以建模为信息检索（IR）[41]中的标准任务。 因此，我们建议将其作为一个排序问题来处理，其中源文件（文档）相对于它们与给定的bug报告（查询）的相关性进行排序）。 在这种情况下，相关性等同于特定源文件包含错误报告中描述的错误原因的可能性。 排序函数被定义为功能的加权组合，其中功能大量地利用软件工程领域特有的知识，以度量bug报告和源代码文件之间的相关关系。 虽然bug报告可能与其相关的源文件共享文本令牌，但通常，bug报告中使用的自然语言与代码[7]中使用的编程语言之间存在着明显的内在不匹配。 基于简单词汇匹配分数的排序方法具有次优性能，部分原因是bug报告中的自然语言语句与软件系统中的技术术语之间的词汇不匹配。 我们的系统包含通过使用项目特定的API文档将bug报告中的自然语言术语与代码中的编程语言结构连接起来，从而弥合相应的词汇差距的特性。 此外，源代码文件可能包含大量的方法，其中只有少量可能导致错误。 相应地，源代码在语法上被解析为方法，并且这些功能旨在利用方法级别的bug报告相关性度量。 以前已经观察到，软件过程度量（例如，更改历史）在检测缺陷[59]方面比代码度量（例如代码的大小）更重要。 因此，我们使用源代码的更改历史记录作为将容易发生故障的文件与bug报告链接的强信号。 另一个有用的特定于域的观察结果是，错误源文件可能导致多个异常行为，因此可能导致类似的错误报告。 如果我们将bug报告与用户和源代码文件等同于用户可能喜欢或不喜欢的项目，那么我们可以与推荐系统进行类比[46]并采用协作过滤的概念。 因此，如果以前固定的bug报告在文本上与当前的bug报告相似，那么与类似报告相关联的文件也可能与当前报告相关。 我们期望复杂的代码比简单的代码更容易出现错误。 相应地，我们设计了与查询无关的功能，通过从文件依赖关系图派生的代理属性来捕获代码复杂性，例如源文件的页面排名[54]分数或文件依赖的数量。

生成的排序函数是功能的线性组合，其权重会使用学习排序技术在先前解决的bug报告上自动运行。 我们已经对六个大型开源软件项目进行了广泛的实证评估，这些项目的数量更多总共有22，000个错误报告。 为了避免污染培训数据与以前的错误报告上的修复信息，我们通过为每个错误报告检出项目的修复前版本来创建了细粒度的基准。 在修复前版本的实验结果表明，我们的系统明显优于一些强基准以及三个最近的最先进的方法。 特别是在Eclipse上进行评估时，平台UI数据集包含超过6400个解决的bug报告，“学习排名系统”能够成功在超过70%的bug报告的前10项建议中找到真正的bug文件，平均精度超过40%（MAP）。 总的来说，我们认为我们的自适应排序方法通常适用于软件项目，对于这些项目，足够数量的项目特定知识，如版本控制历史、错误修复历史、API文档和语法解析代码，都是现成的。

本文的主要贡献包括：将源文件映射到bug报告的问题的排序方法，该方法能够无缝地集成广泛的特性；利用先前固定的bug报告作为拟议排序模型的培训示例，并结合学习排序技术；使用文件依赖图来定义捕获代码复杂性度量的特性；通过检查每个bug报告的源代码包的修复前版本而创建的细粒度基准数据集；与现有最先进方法的广泛评估和比较；以及对特征对排序精度的影响的彻底评估。 论文的其余部分结构如下。 第2节概述了系统体系结构。 在第3节中，接下来详细描述了排序函数定义中使用的特性。 细粒度基准数据集在第4节中介绍，然后在第5至第7节中描述实验评估设置和结果。 第8节描述了特征选择过程的结果，然后是旨在阐明每个特征在最终系统性能中的重要性的实验。 在第10节讨论了相关工作后，本文以今后的工作和总结发言结束。

图1： 用于培训和测试的系统架构

2.排名模型

图1显示系统的高级架构。 对排序模型进行训练，以计算任何bug报告r和源代码文件s组合的匹配分数。 评分函数feth;r；sTHORN;定义为k个特征的加权和，其中每个特征fieth;r；sTHORN;度量源文件s与接收到的bug报告r：之间的特定关系：

feth;r；sTHORN;frac14;w^t Feth;r；sTHORN;frac14;w_i m fieth;r；sTHORN;

1. 给定任意错误报告ri作为测试时间的输入模型计算分数feth;r；sTHORN;软件项目中的每个源文件，并使用此值按降序对所有文件进行排序。 然后向用户展示一个排列顺序的文件列表，期望列表中出现较高的文件更有可能与bug报告相关，即更有可能包含bug的原因。

模型参数w_i 使用学习排序技术对先前解决的bug报告进行培训。 在这个学习框架，优化程序尝试找到一组得分函数排序的参数的文件那个都是已知去是相关的为了a报告在列表的顶部为该错误报告。

3 特征表示

所提出的排序模型要求错误报告-源文件对eth;r；sTHORN;表示为k个特征Feth;r的向量；sTHORN;frac14;frac12;fieth;r；sTHORN;]_1le;我le;k。 排名模型中使用的19个特征的总体集合总结在表1中。 如图所示在表中的最后一列，我们区分二主要类别的 特点：查询 依赖。 这些特征 fieth;r；依赖于错误报告r和源代码的sTHORN;与查询相关的特性表示bug报告和bug报告之间的特定关系源文件，因此可能有助于确定直接说明源代码文件s是否包含与bug报告r相关的bug。

独立查询。 这些特性只依赖于源代码文件，即它们的计算不需要了解bug报告查询。 因此，可以使用独立查询特性来估计源代码文件包含bug的可能性，而不管bug报告如何。

我们假设这两种类型的特征在组合在一个整体排序模型中是有用的。 第8节关于特征选择的实验结果证实了这两种类型的特征的效用，尽管一些特征的影响将被证明是与项目相关的。

本节的其余部分详细描述了表1所示的19个特征。 特征f1 到f6 最初是由我们在[70]引入的，而特征f7 到f14 适用于Saha等人的结构IR方法。 [62]. 新提出的特征f15 到f19 是与查询无关的特性，它们利用文件依赖图的属性，这些属性被认为与检测可能包含bug的文件相关。

矢量空间表示

如果我们将bug报告作为查询，将源代码文件作为文本文档，那么我们可以使用经典的向量空间模型（VSM）进行排序，这是一种用于信息检索的标准模型。 在该模型中，查询和文档都表示为项权重向量。 给定任意文档d（bug报告或源代码文件），我们计算术语权重w_t；d 对于词汇中的每个术语t，基于经典的tf.idf加权方案，其中术语频率因子是 标准化，AS 以下：

术语频率因子tf_t；d 表示文档d中出现术语t的次数，而文档频率因子DF_t 表示存储库中包含术语tN的文档数量是存储库中文档的总数，而IDF. _t 指的是逆文档频率，它是用对数计算的，目的是抑制文档频率因子在整个术语权重中的影响。

表面词汇相似性

对于bug报告，我们使用它的摘要和描述来创建VSM表示。 对于源文件，我们使用它的全部内容-代码和注释。 为了对输入文档进行标记，我们首先使用空格将文本分成一袋单词。 然后，我们删除标点符号、数字和标准IR停止词，如连词或限定词。 复合词，如“工作台”，根据大写字母分为其组成部分，尽管更复杂的方法，如[23]，[62]也可以在这里使用。 然后，文档的一袋单词表示被添加了由此产生的标记-在本例中是“Work”和“Bench”-同时也保留了原始单词作为令牌。 最后，使用Porter steer将所有单词简化为它们的词干，如在NLTK中实现的那样¹ 包裹。 这一过程将把派生相关的词，如“编程”和“程序”减少到相同的词干“程序”，这已知对最终系统的召回性能有积极的影响。

让V成为bug报告和源代码文件中出现的所有文本令牌的词汇表。 让rfrac14;frac12;w_t；rJT 2 v ] 和S的frac14; frac12;w_t；sJT 2 v ] 是 的 vsm 矢量 代表 的 的 错误报告r和源代码文件s，其中术语权重

• • • 1. http://www.nltk.org/api/nltk.stem.html

无花果。 2. Eclipse bug报告339286。

w_t；r 还有 w_t；s 都是 计算 使用 的 TF.idf 公式 作为 显示在里面 方程式 （2） 以上。 一次 的 矢量 空间 表示被计算，源之间的文本相似性代码文件和bug报告可以使用它们对应之间的标准余弦相似度来计算 载体：

r^t S

simeth;r；sTHORN;frac14;coseth;r；sTHORN;frac14;克克斯克 :（(）)

这只是两个向量的内积，由它们的欧氏范数归一化。

在方程（1）中的评分函数的计算中，VSM余弦相似性可以直接用作特征）。 然而，这将忽略一个事实，即错误通常定位在代码的一小部分中，例如一个方法。 当源文件较大时，其对应的范数也会较大，这将导致与bug报告的余弦相似度较小，尽管文件中的一种方法实际上可能与同一bug报告非常相关。 因此，我们使用Eclipse JDT2中的AST解析器并将源代码分割成方法，以便com-每种方法与bug报告的相似性。 我们con-将每个方法m作为一个单独的文档，并使用该方法计算其与bug报告的词汇相似性一样余弦 相似之处 公式。 我们 那么 计算 a 表面 词汇相似性特征为 以下：

f1eth;r；sTHORN;frac14;maxeth;fsimeth;r；sTHORN;g[fsimeth;r；mTHORN;jm2sgTHORN;； （4）

i.，每种方法的相似性和整个文件相似性的最大值。 这显然是一个依赖查询的特性。

API-丰富的词汇相似性

一般来说，bug报告中的大多数文本是用自然语言（例如英语）表示的，而源代码文件的大部分内容是用编程语言（例如Java）表示的）。 由于余弦相似度函数中使用的内积仅对bug报告和源文件之间常见的令牌具有非零项，这意味着前一节中描述的表面词汇相似特征只有在何时才会有帮助

1. 源代码有广泛的、全面的注释，或者2）bug报告包括代码片段或编程语言结构，例如类或方法的名称。 在实践中，bug报告和相关bug文件共享的令牌（如果有的话）很少。 例如，图。 下面2显示了来自错误报告的示例³ 从
2. http://www.eclipse.org/jdt/
3. https://bugs.eclipse.org/bugs/show_bug.cgi？id=339

   剩余内容已隐藏，支付完成后下载完整资料

   ---

   资料编号：[606350]，资料为PDF文档或Word文档，PDF文档可免费转换为Word