引用

Koyuncu A , Liu K , Tegawendé F. Bissyandé, et al. iFixR: Bug Report driven Program Repair[C]// the 2019 27th ACM Joint Meeting. ACM, 2019.

摘要

在现代软件开发中，问题跟踪系统通常用于收集用户和开发人员的反馈。软件维护的一个最终自动化目标就是为用户报告的 bug 生成补丁。尽管这一雄心壮志与自动化程序修复的势头相一致，但到目前为止，文献主要集中在生成和验证设置上，其中故障定位和补丁生成由定义良好的测试套件驱动。然而，一方面，关于存在相关测试用例的常见假设在大多数开发设置中并不成立：许多 bug 被报告，而可用的测试套件无法揭示它们。另一方面，对于许多项目来说，bug 报告的数量通常超过了对它们进行分类的可用资源。为了提高补丁生成工具的使用率，我们研究了一种由缺陷报告驱动的新修复流程 iFixR：(1)缺陷报告被输入到基于 IR 的故障定位器中；(2)由修复模式生成补丁并通过回归测试进行验证；(3) 向开发人员提出了生成补丁的优先顺序列表。我们在 Defects4J 数据集上评估 iFixR，我们对该数据集进行了扩充(即错误与 bug 报告相关联)和精心的组织(即测试用例的时间轴是自然分割的)。iFixR 使用基于 IR 的故障定位器为 21/44 个 Defects4J 错误生成真实/可信补丁。iFixR 准确地将一个真实的/合理的补丁放在了其中 8/13 个故障的前 5 个建议中。

1 简介

这篇论文。我们提出研究一个由错误报告驱动的程序修复系统的可行性，从而用基于信息检索(IR)的故障定位取代传统的基于频谱的故障定位。最后，我们提出了一个新的程序修复工作流 iFixR，它通过模拟手动调试的基本步骤来考虑实际的修复设置。iFixR 在以下约束下工作：当错误报告被提交到问题跟踪系统时，再现该错误的相关测试用例可能不容易获得。

因此，iFixR 在本研究中被用来评估 APR 在有限测试套件的实际限制下的可行性。iFixR 使用自然语言编写的错误报告作为主要输入。最终，我们做出以下贡献：

(1)我们提出了一个程序修复系统的体系结构，以适用于维护人员处理用户报告的缺陷的约束。特别是，iFixR 用基于信息检索(IR)的故障定位取代了传统的基于频谱的故障定位。

(2)我们提出了一种策略，优先考虑补丁，以便向开发人员推荐。事实上，假设只有回归测试用例的存在来验证补丁候选，许多补丁可能会在与报告 bug 相关的未来测试用例上失效。我们会按照补丁的顺序，先呈现正确的补丁。。

(3)我们评估和讨论 iFixR 在 Defects4J 基准测试上的性能，以便与最先进的 APR 工具进行比较。为此，我们为 APR 针对 bug 报告提供了一个改进的 Defects4J 基准。bug 被小心地与相应的 bug 报告联系起来，对于每一个 bug，我们能够分离出在相关修复之后引入的未来测试用例。

总体而言，实验结果表明，在实际的软件开发周期中，自动补丁生成的集成是一个很有前途的研究方向。特别是，我们的研究结果表明，与基于频谱的故障定位错误相比，基于 IR 的故障定位错误导致的过拟合补丁较少。此外，iFixR 提供的结果可与大多数最先进的 APR 工具相媲美，尽管它是在修复后知识(即未来测试用例)不可用的约束下运行的。最后，iFixR 的优先级策略倾向于将更正确/合理的补丁放在推荐列表的顶部。

2 动机

我们通过回顾 APR 的两个基本步骤来阐述我们工作的动机：

(1)在故障定位过程中，相关程序实体被识别为必须更改的可疑位置。通常，最先进的 APR 工具利用基于频谱的故障定位(SBFL)，它使用通过和失败测试用例的执行覆盖信息来预测错误语句。我们剖析了 Defects4J 数据集，以突出针对用户报告的 bug 进行故障定位的实际挑战。

(2)一旦生成了一个补丁候选，补丁验证步骤确保它实际上与修复程序相关。目前，广泛使用的基于测试的 APR 技术使用测试套件作为修复预言。然而，这受到测试套件不完整性的挑战，并且在修复过程中可能进一步不符合开发人员的需求和期望。

3 方法

图 2 概述了我们提出的 iFixR 方法的工作流程。对于有缺陷的程序，我们考虑以下问题：

(1)bug 在哪里？我们将程序用户提交的自然语言 bug 报告作为输入。我们依赖于此报告中的信息来定位 bug 位置。

(2)我们应该如何改变代码？我们应用在实际错误修复中反复出现的修复模式。修复模式是按照抽象语法树的结构选择的，该树表示所识别的可疑代码的代码实体。

(3)哪些补丁是有效的？我们对在发现缺陷时编码功能需求的正面测试用例的可用性没有任何假设。然而，我们利用现有的测试用例来确保，至少补丁不会使程序倒退。

(4)我们首先推荐哪些补丁？在没有完整的测试套件的情况下，我们不能保证所有通过回归测试的补丁都能修复错误。我们依靠启发式来重新排列已验证补丁的优先级，以增加将正确补丁放在列表顶部的概率。

图 2 FixR 程序修复的工作流

3.1 输入：错误报告

问题跟踪系统被开源和商业领域的软件开发社区广泛使用。尽管开发人员可以使用问题跟踪系统跟踪他们遇到的 bug 和要实现的功能，问题跟踪系统允许用户参与，作为收集生产中软件执行情况反馈的通信渠道。

表 3 说明了当 LANG 库代码的用户在使用 NumberUtils API 时遇到问题时的一个典型错误报告。提供了错误行为的描述。有时，用户可能会在错误描述中包含一些关于如何重现 bug 的信息。通常，用户只需插入代码片段或转储执行堆栈跟踪。

表 3 bug 报告示例

在这项研究中，在 162 个 bug 报告的数据集中，我们注意到只有 27 个是由同时也是项目开发人员的用户报告的。报告了 15 个错误，并再次由同一个项目贡献者修复。这表明在大多数情况下，bug 报告确实是由需要项目开发人员注意的软件用户真正提交的。

给定有缺陷的程序版本和错误报告，iFixR 必须展开工作流程，以精确识别(在语句级别)错误代码的位置。在这一步中，不能依赖未来的测试用例。我们认为，如果这样的测试用例能够触发该 bug，那么在软件向用户交付之前，持续集成系统将帮助开发人员处理该 bug。

3.2 不带测试用例的故障定位

为了识别程序源代码中有缺陷的代码位置，我们求助于基于信息检索(IR)的故障定位(IRFL)。总的目标是利用 bug 报告中使用的术语和源代码之间的潜在相似性来识别相关的错误代码位置。文献包括大量关于 IRFL 的工作，研究人员系统地从给定的 bug 报告中提取标记，以在由源代码文件集合形成的文档搜索空间中生成匹配的查询，并通过从源代码中提取的标记索引。IRFL 方法然后根据相关性的概率(通常用相似性得分来衡量)对文档进行排序。高排名的文件被预测为可能包含错误代码的文件。

在这项工作中，我们开发了一种算法，根据最先进的 IRFL 工具的输出(即文件)对可疑语句进行排序，从而生成一个基于 IR 的细粒度故障定位器，该定位器随后将容易地集成到具体的补丁生成管道中。

3.2.1 对可疑文件进行排名。

我们利用现有的 IRFL 工具。考虑到从大量 bug 报告中提取标记的代价高昂，常常是调优 IRFL 工具的必要条件，我们选择了一个由作者提供数据集和预处理数据的工具。我们使用 D&C 作为在线可用的文件级 IRFL 的具体实现，这是一个基于机器学习的 IRFL 工具，使用 70 维特征向量(缺陷报告中的 7 个特征和源代码文件中的 10 个特征)的相似矩阵：D&C 使用多个分类器模型，每个分类器模型针对特定的 bug 组进行训练报告。给出一个错误报告，不同分类器的不同预测被合并，生成一个可疑代码文件列表。我们的 D&C(算法 1 中的第 2 行)的执行是可处理的，因为我们只需要预处理那些必须定位的 bug 报告。已提供经过培训的分类器。我们确保不会导致数据泄漏(也就是说，分类器没有使用我们希望在这项工作中定位的 bug 报告进行训练)。

3.2.2 可疑陈述

补丁生成需要有关必须更改的代码实体的细粒度信息。对于 iFixR，我们建议为基于频谱的故障定位生成标准输出，以便于集成和重用最先进的补丁生成技术。首先，我们基于最近一项大规模的错误修复研究的结论，将可疑位置的搜索空间限制在更容易出错的语句中。在详细调查了来自 Java 项目的 16000 多个实际补丁的基于抽象语法树(AST)的代码差异之后，以下特定的 AST 语句节点比其他节点更容易出错：IfStatements、ExpressionStatements、FieldDeclarations，ReturnStatements 和 VariableDeclarationStatements。算法 1 的第 7-17 行详细说明了生成可疑语句的排序列表的过程。

算法 1 描述了我们在 iFixR 中使用的故障定位方法的过程。在返回的 IRFL 可疑文件列表中选择前 k 个文件及其计算的可疑度得分。然后对每个文件进行解析，只保留从中提取文本标记的相关易出错语句。bug 报告的摘要和描述也会被分析(词法上)以收集它的所有标记。由于 bug 报告中可能出现的堆栈跟踪和其他代码元素的具体性质,我们使用正则表达式检测堆栈跟踪和标记代码元素改进分词过程,它基于标点符号,驼峰式大小写分裂(例如 findNumber 分裂成 find 和 number)以及蛇形命名法分裂(例如 find_number 分裂成 find 和 number)。然后在对所有标记执行词干分析之前，使用停止词删除，以创建与术语的根的同质性(即通过合并相同术语的变体)。每个标记包(用于 bug 报告和每个语句)最终用于构建一个特征向量。我们使用向量之间的余弦相似度来对与 bug 报告相关的文件语句进行排序。

考虑到 k 个文件，每个文件的语句对于 bug 报告都有自己的相似性分数，我们用关联文件的可疑度评分来加权这些分数。最后，我们使用加权得分对语句进行排序，并生成一个代码位置(即文件中的语句)的排序列表，以推荐作为候选故障位置。

3.3 基于修复模式的补丁生成

在自动程序修复中，一个常见且可靠的策略是基于修复模式(也称为修复模板或程序转换模式)生成具体的补丁。在这项工作中，我们考虑 Kim 等人的 PAR 系统。具体地说，我们建立在 kPAR 上，一种开源的 PAR java 实现。表 4 提供了本工作中使用的修复模式的枚举。如图 3 所示，修复模式对更改操作的配方进行了编码，这些操作应用于改变代码元素。

表 4 在 iFixR 中实现的修复模式


图 3 “Insert Cast Checker”固定模式示意图

对于给定的报告错误，一旦我们的故障定位器生成可疑语句的列表，iFixR 会反复尝试为每个语句选择修复模式。修复模式的选择是基于每一个可疑语句的上下文信息(即抽象语法树 AST 中的所有节点)进行的。具体地说，iFixR 解析代码并以广度优先的策略遍历可疑语句 AST 的每个节点，从其第一个子节点遍历到最后一个叶节点。如果一个节点与上下文修复模式匹配(即，相同的 AST 节点类型)，那么该修复模式将应用于通过改变修复模式中配方后匹配的代码实体来生成修补程序候选。无论节点是否匹配修复模式，iFixR 都会不断遍历其子节点，并搜索修复模式以依次生成候选修补程序。此过程将迭代执行，直到遇到叶节点为止。

3.4 带回归测试的补丁验证

对于每一个报告的 bug，基于模式匹配的故障定位和代码变异将产生一组候选补丁。在一个典型的基于测试的 APR 系统中，这些候选补丁必须让程序通过所有测试用例(包括一些正面测试用例，这些测试用例编码了与 bug 相关的实际功能需求)。因此，补丁候选集被积极修剪，以删除所有不符合这些要求的补丁。在我们的工作中，根据我们的调查结果，这些测试用例可能在报告错误时不可用，我们假设 iFixR 无法推理未来的测试用例来选择候选补丁。

相反，当 bug 被报告时，我们只依赖于代码库中可用的过去的测试用例。这样的测试用例被用来执行回归测试，这将确保，至少被选中的补丁不会阻碍已经存在的、未更改的软件部分的行为，这些部分已经被开发人员在他们当前的测试套件中明确编码。

3.5 输出：补丁推荐列表

最终，iFixR 会为开发人员生成一个补丁程序建议的排名推荐列表。到目前为止，修补程序的顺序主要受工作流中两个步骤的影响：

(1)定位：我们的语句级 IRFL 生成一个要优先修改的语句的排序列表。

(2)模式匹配：错误代码实体的 AST 节点被分解成子节点，并以广度优先的方式迭代导航，以连续生成候选补丁。

最终，生成的补丁列表具有一定的顺序，该顺序带有故障定位的偏差，并通过预先设置的修复模式匹配的广度优先策略进行噪声处理。

我们建议采用以下启发式方法重新排列候选修补程序的优先级：

(1)最小变化：我们喜欢最小化补丁程序和有缺陷程序之间的差异的补丁。

(2)故障定位可疑度：当两个候选补丁具有相同的编辑脚本大小时，使用基于 IR 的故障定位过程中产生的怀疑分数(相关语句的)来打破这种平局

(3)受影响的代码元素：在对修复模式和相关 APR 的性能进行手动分析之后，我们发现一些更改操作与 bug 修复无关。在对文献中的修复模式和相关 APR 的性能进行人工分析后，我们发现有些更改操作与 bug 修复无关。因此，对于相应的预定义模式，iFixR 系统性地将其生成的补丁相对于任何其他补丁的优先级降低。这些补丁是由以下方式产生的：(i) 突变一个文字表达式，(ii) 将一个变量突变为一个方法调用或最终静态变量，或 (iii) 插入一个没有参数的方法调用。

4 研究问题

评估的目标是评估为用户报告的 bug 自动生成补丁的可行性，同时调查预期的瓶颈以及社区为实现这一长期努力必须接受的研究方向。为此，我们重点关注以下与 iFixR 工作流中不同步骤相关的研究问题。

• RQ1：故障定位。基于 IR 的故障定位在多大程度上能够为 APR 场景提供可靠的结果？我们研究比较了我们的细粒度 IRFL 实现与经典的基于频谱的定位时的性能差异。

• RQ2：过拟合。基于 IR 的故障定位在多大程度上能指向受过拟合影响较小的位置？我们特别研究了不完整测试套件通常对过拟合问题的影响。

• RQ3：补丁排序。iFixR 的补丁排序策略的有效性如何？我们通过重新模拟软件维护周期的真实案例，研究了 iFixR 的整体工作流程，当一个 bug 被报告时：未来的测试用例无法用于补丁验证。

5 评估结果

在这一部分中，我们将呈现之前列举的研究问题的调查结果。为了评估 iFixR，我们依赖于 Defects4J，它在 Java APR 文献中被广泛用作基准。此外，为了真实地评估 iFixR，我们重新组织了数据集测试套件，以准确地模拟用户提交 bug 报告时的上下文。

5.1 RQ1：故障定位

故障定位是程序修复的第一步，我们评估了在 iFixR 中开发的基于 IR 的故障定位的性能。正如 Liu 等人最近研究的那样，不应该期望 APR 工具能够修复当前故障定位系统无法定位的错误。尽管如此，通过 iFixR，我们必须证明我们的细粒度 IRFL 提供了与 APR 文献中使用的 SBFL 工具相当的性能。

表 5 提供了关于 bug 定位的性能测量。SBFL 是基于 GZoltar 测试框架的两个不同版本进行的，但总是基于 Ochiai 排名指标。最后，由于故障定位工具会输出一个可疑语句的排名列表，因此结果是以是否将正确的位置放在前 k 个可疑语句下为标准。在本工作中，我们认为如果有任何一个错误语句被定位，则该错误被定位。

表 5：错误定位结果。

总的来说，结果表明，当应用于 Defects4J bug 数据集上时，我们的 IRFL 实现与常见的基于频谱的故障定位实现相当。虽然性能结果相似，但 SBFL 是通过考虑未来的测试案例来应用的。为了突出 IRFL 的实际意义，我们为每个可定位在前 10 名的 bug 计算了从 bug 报告日期到该 bug 提交相关测试用例日期之间经过的时间。根据图 6 所示的分布，平均而言，IRFL 可以将这个时间缩短 26 天。

图 6：从 bug 报告到提交测试用例之间的运行时间分布

最后，为了强调未来测试用例对基于频谱的故障定位的重要性，我们考虑了所有 Defects4J 的 bug，并计算了有和没有未来测试用例的定位性能。表 6 中列出的结果证实，在大多数 bug 情况下，定位是不可能的。只有 10 个 bug(395 个中)可以在报告 bug 时 SBFL 的前 10 个可疑语句中被定位。相比之下，我们的 IRFL 在没有相关测试用例触发 bug 的相同条件下，定位了 72 个 bug。

表 6 缺陷定位报告

在 iFixR 中，基于 IR 的细粒度故障定位与基于 Spectrum 的故障定位在定位 Defects4J 错误方面一样准确。此外，它没有要求测试用例的限制，而这些测试用例在报告错误时可能是不可用的。

5.2 RQ2：过拟合

补丁生成试图用合适的修复模式来突变可疑的 bug 代码。APR 的一个共同挑战在于如何有效地选择错误的语句。在典型的基于测试的 APR 中，测试用例驱动这些语句的选择。然而，测试套件的不完整性目前被怀疑经常会导致生成的补丁的过度拟合。

我们执行补丁生成实验来研究本地化偏差的影响。我们将我们的 IRFL 实现与基于测试的 APR 文献中常用的 SBFL 实现进行比较。我们回顾一下，这些实验中的补丁验证步骤没有对未来的测试用例做任何假设(即，所有的测试用例都像在经典的 APR 流水线中一样被利用)。对于每个 bug，根据故障定位系统(IRFL 或 SBFL)得出的可疑语句中 bug 语句的等级，补丁生成可以产生更多或更少的相关补丁。表 7 详细介绍了修复性能与错误语句在故障定位输出中的位置的关系。结果是以考虑故障定位器返回的 top-k 语句所能找到的可信和正确补丁的数量来提供的。

表 7 IRFL 与 SBFL 对 Defects4J 的 bug 生成的正确/合理补丁数量的影响

总的来说，我们发现 IRFL 和 SBFL 的定位信息导致了相似的修复性能。实际上 IRFL 支持的 APR 在 Lang 项目 bug 上的表现优于 SBFL 支持的 APR，在 Math 项目 bug 上的表现也优于 SBFL 支持的 APR。总体而言，有 6 个使用 IRFL 输出修复的 bug，不能使用 SBFL 输出修复(尽管假设有 bug 触发测试用例可以运行 SBFL 工具)。

我们调查了两种定位方案中可信补丁的情况，以描述这些补丁看起来只对测试套件进行过拟合的原因。表 8 详细列出了两种场景的过拟合原因。

表 8 分析补丁看似合理但不正确的原因

对 Defects4J 数据集的实验表明，基于 IR 的故障定位所提供的代码位置比基于频谱的故障定位所建议的代码位置导致的过拟合补丁更少。

5.3 RQ3：补丁排序

前面的实验集中在补丁生成上，而我们最后的实验则评估了 iFixR 的完整流程，因为它被想象成可以满足开发者在实践中可能面临的限制：未来的测试用例，即那些编码了错误程序没有满足的功能要求的测试用例，在错误被报告时可能无法获得。因此，我们抛弃了 Defects4J 数据集的未来测试用例，并生成必须推荐给开发人员的补丁。因此，评估协议包括评估在多大程度上正确/合理的补丁被放置在建议列表的顶部。

5.3.1 整体性能

表 9 详细介绍了 iFixR 推荐补丁的性能：我们介绍了在推荐补丁列表的前 k 名中生成并呈现正确/合理补丁的 bug 数量。在没有未来的测试用例来驱动补丁验证过程的情况下，我们使用启发式方法对补丁候选者重新进行优先级排序，以确保最先推荐的补丁最终是正确的(或者至少在相关测试用例被执行时是可信的)。我们将介绍不重排优先级和重排优先级两种情况的结果。

表 9 iFixR 在 Defects4J 基准上的补丁推荐的总体性能

回顾一下，鉴于重新组织的基准单独包括了未来的测试用例，我们可以利用它们来系统化评估补丁的合理性。然而，补丁的正确性仍然是通过与开发者提供的、基准中可用的实际错误修复进行比较来手动决定的。总的来说，我们注意到 iFixR 的性能是很有希望的，因为对于 13 个 bug，iFixR 能够在每个 bug 的前 5 个推荐补丁中提出一个可信的补丁。在这些可信的补丁中，有 8 个最终被发现是正确的。

5.3.2 与最先进的基于测试的 APR 系统的比较

为了客观地定位 iFixR 的性能(它不需要未来的测试用例来定位 bug、生成补丁并呈现分类的补丁推荐列表)，我们统计了 iFixR 能够提出正确/可信补丁的 bug 数量。我们考虑 iFixR 的三种情况。

(1)开发者将只得到前 5 个推荐的补丁，这些补丁只经过回归测试验证：在这种情况下，iFixR 在用合理或正确的补丁修复的 bug 数量上比最先进的技术要好一半。

(2)向开发者提供所有(即，不仅是前 5 名)生成的补丁，并通过回归测试进行验证：在这种情况下，只有 4 种(16 种中的)最先进的 APR 技术优于 iFixR.all。

(3)开发人员看到的是所有生成的补丁，这些补丁已经用增强的测试套件进行了验证(即用未来的测试用例乐观地进行验证)：在这种配置下，iFixR 的性能优于所有最先进的，除了 SimFix，SimFix 使用复杂的技术来提高故障定位精度和搜索修复成分。应该注意的是，在这种情况下，我们的优先级策略并没有应用到生成的补丁中。iFixR 代表了我们实验的参考性能，它评估了优先级。

表 10 提供了比较矩阵。当我们考虑到 Defects4J bug 的数量时，iFixR 在补丁推荐方面提供了合理的性能，这些错误在前 5 名中被成功修补(在我们假设没有相关测试案例来验证补丁候选者的情况下)。性能结果甚至可以与文献中许多最先进的基于测试的 APR 工具相媲美。

表 10 iFixR 与最先进的 APR 工具的比较

5.3.3 iFixR 补丁的特性

在表 11 中，我们描述了 iFixR 推荐的正确和合理的补丁的特征 5。总的来说，更新和插入的修改是成功的；大多数补丁影响的是一条语句，并且精确地影响了一个语句中的表达式实体。

表 11 改变 iFixR 的正确补丁的属性

5.3.4 iFixR 所修复的 bug 的多样性

最后，在表 12 中，我们剖析了 iFixR5 能够为其推荐正确或合理补丁的 bug 的性质。关于 bug 报告的优先级信息是从问题跟踪系统中收集的，而根本原因则是通过分析 bug 报告和修复来推断的。

总的来说，我们注意到 13 个 bug 中，有 9 个被标记为主要问题。解决了 12 个不同的 bug 类型(即根本原因)。相比之下，R2Fix 只关注了 3 种简单的 bug 类型。

表 12 剖析 iFixR 成功修复的 BUG

6 结论

在这项研究中，我们研究了从错误报告中自动生成补丁的可行性。为此，我们实现了 iFixR，一个 APR 的变体，适应了用户报告错误时测试用例不可用的限制。所提出的系统重新审视了基本步骤，特别是故障定位、补丁生成和补丁验证，这些步骤都紧紧依赖于基于测试的 APR 系统中的正向测试用例。

在不对测试用例的可用性做任何假设的情况下，我们在重新组织 Defects4J 基准后，证明了 iFixR 可以为不同的用户报告的 bug 生成和推荐优先正确的(和更可信的)补丁。我们甚至发现 iFixR 的修复性能与 Defects4J 数据集上的大多数基于测试的 APR 系统相当。

致谢

本文由南京大学软件学院 2020 级硕士吴青衡翻译转述。