TBar:重新访问基于模板的自动程序修复

TBar:重新访问基于模板的自动程序修复

摘要

我们回顾了基于模板的APR的性能，以构建关于修复模式有效性的全面知识，并强调了补充步骤(如故障定位或提供者代码检索)的重要性。为此，我们首先对文献进行调查，收集、总结和标记常用的修复模式。在调查的基础上，我们构建了tbar，一个简单的APR工具，系统地尝试将这些修复模式应用于程序错误。我们在Defects4J基准上对TBar进行了全面的评估。特别地，我们评估了修复模式的实际定性和定量多样性，以及它们在生成似是而非或正确斑块方面的有效性。最终，我们发现，假设一个完美的错误定位，TBar正确/合理地修复 74/101错误。复制一个标准和实际的APR评估管道，我们证明TBar正确地修复 43个来自defts4j的bug，这是文献中前所未有的性能(包括所有方法，即基于模板、基于随机突变或基于合成的APR)。

1.介绍

自动程序修复(APR)已逐渐成为一个重要的研究领域。APR的研究确实有希望通过减少与程序调试任务相关的时间和成本来改善现代软件开发。特别是，考虑到软件中的故障会给软件行业造成巨大的财务损失[8,54]，有一种趋势是通过APR将修复间隔时间最小化。最近，各种APR方法被提出，旨在通过自动生成补丁来减少手动调试的工作量。
APR的一个早期策略是基于fix模式23生成具体的补丁。这种策略现在在文献中很常见，并且已经在几个APR系统中实施了[13,17,23,24,38ś40,50,62]。Kim等人的[23]显示了fix模式在par中的有用性。Saha等人[62]后来通过在par[23]上添加三个新模式提出了delixirm。Durieux等人[13]提出了NPEfjxto修复空指针异常错误，使用9个预先定义的fjx模式。Long等人设计了genesis[41]来推断特定三类缺陷的fjx模式。Liu和Zhong[40]研究了Stack Overfmow的帖子来挖掘APR的fix模式。Hua等人提出了dsketchfix[17]，这是一个运行时按需的APR工具，具有6个预定义的fix模式。最近，Liu等人的[39]使用了FindBugs静态违反[35]到fix语义错误的fjx模式。同时，Ghanbari和Zhang[15]表明，直接在Java字节码上应用fix模式(即mutators)可以有效地修复。然而，它们并不提供由每个实现的突变体产生的修复性能的全面评估。
虽然文献报道了基于fix模式的APR有很好的结果，但就我们所知，没有对各种模式的有效性进行广泛的评估。一些最近的方法[17,39,40]报告了每个模式都添加了哪些基准测试错误。然而，许多关于fix模式有效性的相关问题仍然没有得到解答。

这篇论文。我们的工作彻底调查了fix模式在多大程度上对程序修复是有效的。特别地，我们强调在APR的一些模式的复发，解剖它们的实际贡献的修复性能。最后，我们探讨fix模式的三个方面:
•多样性:最先进的fix模式有多多样化?我们回顾了文献，以明确的分类来识别和总结可用的模式。
•修复效果:不同模式的效果如何?特别地，我们研究了现实世界中各种可以被修复的bug，剖析修复结果，以及它们产生合理或正确补丁的倾向。
•对故障定位噪声的敏感性:所有fix模式对故障定位工具产生的误报是否同样敏感?我们通过评估似是而非的补丁以及正确修正的bug位置的可疑等级来研究敏感性。

为了实现本研究，我们实现了一个自动补丁生成系统TBar(基于模板的自动程序修复)，其中包含了从文献数据中收集、总结、整理和标记的fix模式的超集。我们在defts4j[20]基准上评估TBar，并在公共存储库https://github.com/SerVal-DTF/TBar中提供复制包。

总的来说，我们的调查有以下发现:
(1)记录性能:tbar创建了一个新的更高的修复性能基线:74/101错误正确地/貌似地使用完美的故障定位信息进行了修复, 43/81bug用实际的故障定位输出进行了修复。
(2)修复模式选择:大多数bug只被一个fjx模式正确修复，而其他模式生成可信的补丁。这意味着适当的模式优先级可以防止看似合理/不正确的补丁。否则，APR工具可能会在看似合理但不正确的补丁中被忽略。
(3)修复成分检索:对于基于模板的APR来说，选择合适的捐赠者代码是一个挑战，这是使用fjx模式生成patch的一个成分。不恰当的提供程序代码可能导致看似合理但不正确的补丁生成。这激发了一个新的研究方向:捐赠者代码优先排序。
(4)故障定位噪声:当在APR中使用fix模式时，故障定位精度对修复性能有很大的影响(例如，将fjx模式应用到错误的位置会产生似是而非的补丁)

2. 修复模式

在本研究中，我们系统地回顾了APR文献，以确定利用fix模式的方法。具体来说，我们以程序修复网站[3]、APR[52]的文献综述、软件工程会议场所的会议记录和期刊作为相关文献的来源。我们关注处理Java程序错误的方法，并从论文描述以及相关的工件中手动收集明确提到的所有模式实例。表1总结了已确定的相关文献和已确定的针对Java程序的fix模式的数量。注意，在前四篇论文(即HDRepair、ssFix、CapGen和SimFix论文)中描述的技术并没有直接使用fix模式:它们利用了代码更改操作符或规则，我们认为这与使用fix模式类似。

2.1修复模式推理

通过以下四种方式探索了修复模式:、
（1）手工汇总
（2）挖掘:Long等人[41]提出Genesis，从现有的补丁中推断出三种缺陷的fjx模式。Liu和Zhong[40]从Stack Overfmow的问答帖子中探索了fjx模式。Koyuncu等人[24]通过使用代码更改区分工具[14]在AST级别从补丁中挖掘fjx模式。Liu等人[35]和Rolim等人[60]提出挖掘静态分析违规的fjx模式。通常，挖掘方法会产生大量的fjx模式，这些模式并不总是关于解决程序行为中的偏差。
（3）预定义:Durieux等人[13]通过统一前人研究中提出的相关fix模式，预定义空指针异常的9个修复动作[12,22,45]。在par[23]的基础上，Saha等[62]进一步定义了3种新的fix模式以提高修复性能。Hua等人[17]提出了一个带有6个预先定义的所谓代码转换模式的APR工具。我们还认为算子突变[49]是预先定义的fix模式，因为算子的数量和突变可能性是有限的，并且是预先设定的。Xin和Reiss[74]提出了一种在AST级别使用34个预定义代码更改规则来修复bug的方法。其中10条规则不是用于转换有缺陷的代码，而是用于简单地替换多语句代码片段。我们在研究中抛弃这些规则以限制偏见。
（4）统计学:除了格式化的修复模式外，研究人员[18,69]还探索了使用在现有补丁中统计上反复出现的代码更改指令(在抽象语法树级别)自动修复程序[18,37,48,68,81]。然后，策略是选择最频繁的代码更改指令作为修复成分来合成补丁。

2.2解决模式分类

我们根据代码上下文(例如，一个强制类型转换表达式)、代码更改动作(例如，插入一个if语句)以及目标(例如，确保程序不会抛出一个ClassCastException)确定了15个类别的模式。

一个给定的类别可能包括一个或几个专门的子类别。下面，我们展示了已标记的类别，并提供了用简化的GNU difg模式描述的相关的35个代码更改模式，以便于理解。

FP1。插入检查程序。如果语句包含至少一个未检查的强制转换表达式，则在有错误的语句之前插入instanceofcheck。实现在:PAR, Genesis, A V ATAR, SOFix†，HDRepair†，SketchFix†，CapGen†，和SimFix†。
FP2。插入空指针检查器。
FP3。插入检查范围。
FP4。插入了声明。在有错误的语句之前、之后或周围插入缺失的语句。该语句要么是带有方法调用的表达式语句，要么是return/trycatch/ifstatement。
FP5。修改类实例创建。如果类实例创建在被覆盖的克隆方法中，则使用castsuper.clone()方法调用替换类实例创建表达式。
FP6。变异条件表达式。通过更新一个返回布尔值(即true或false)的条件表达式，或者删除一个子条件表达式，或者在其中插入一个新的条件表达式，来改变一个条件表达式。
FP7。改变数据类型。用另一种数据类型替换变量声明或强制转换表达式中的数据类型。
FP8。变异整数除法操作。修改整型除法表达式以返回浮点值，方法是将其除数或除数修改为float类型。由liu et al.[35]发布，它还没有在任何APR工具中实现。
FP9。变异的文字表达。
FP10。改变方法调用表达式。
FP11。变异操作符。
FP12。变异返回语句。
FP13。变异变量。
FP14。移动语句。
FP15。去除缺陷语句。

2.3 收集模式的分析

我们根据定量(整体集合)和定性(每个fix模式)方面提供了收集到的fix模式的研究。表2根据四个定性维度评估了fix模式:
(1)变更行动:在一个有bug的代码实体上应用了哪些高层操作?一方面，Update操作用检索到的捐赠方代码替换bug代码实体，而Delete操作只是从程序中删除bug代码实体。另一方面，插入操作插入一个否则缺失的代码实体到程序中，而移动操作改变有bug的代码实体的位置到程序中更合适的位置。
(2)变更粒度:哪些类型的代码实体直接受到变更行为的影响?这个实体可以是一个完整的方法，一个完整的语句，或者专门针对语句中的一个表达式。
(3)Bug上下文:代码实体的AST节点用于匹配fix模式。
(4)Change Spread:每个fix模式影响的语句数。

从数量上看，如表3所示，17种修复模式与更新更改操作相关，4种fix模式实现删除操作，13种fix模式插入额外的代码，只有1种fix模式与移动更改操作相关。在更改粒度方面，21和17个fix模式分别应用于表达式和语句代码实体级别。只有一种fix模式适合于方法级别。
总的来说，我们注意到30个fix模式适用于单个语句，而7个fix模式可以同时改变多个语句。在这些模式中，fp14和fp15.1既可以突变单个语句也可以突变多个语句。

3.修复实验设置

为了评估fix模式在分类中的有效性，我们设计了以fix模式为主要成分的程序修复实验。生成的APR系统然后在修复社区广泛使用的基准上进行评估，以便与最先进的进行可靠的比较。

3.1TBar:基线APR系统

基于对经常使用的fix模式的调查，我们构建了tbar，一个基于模板的APR工具，它集成了第2节中介绍的35种fix模式。我们期望APR社区将tbar作为一个基线APR工具:新的方法必须提出新的技术来解决辅助问题(例如，修复精度，搜索空间优化，故障位置重新优先化)，提高自动程序修复的性能，超越普通fix模式的直接应用程序所能提供的性能。
图1概述了我们在TBar中实现的工作流。我们在以下小节中描述每个流程的角色和操作以及所有必要的实现细节。

重温基于模板的自动程序修复

3.1.1故障定位

故障定位对于基于模板的APR来说是必要的，因为它允许识别一系列可疑的代码位置(例如，bug语句)，在这些位置上应用fix模式。TBar利用GZoltar[9]框架自动执行每个有bug的程序的测试用例。在这个框架中，我们使用Ochiai[4]排序度量来计算可能是错误代码位置的语句的可疑性得分。这个排序指标已经在一些实证研究中被证明[56,65,73,78]是面向对象程序中错误定位的有效指标。故障定位的GZoltar框架也广泛用于APR的文献[18,24,34,38,39,49,69,74,76,77]，允许对tbar的性能进行公平的评估。

3.1.2修复模式选择

在执行修复管道时，一旦故障定位过程产生了一个可疑代码位置列表，TBar就依次尝试从它的fix模式数据库中为位置列表中的每条语句选择已编码的fix模式。fix模式的选择是基于每个可疑语句的AST上下文信息以一种简单的方式进行的。具体地说，TBar顺序地从第一个子节点到最后一个叶节点遍历可疑语句AST的每个节点，并尝试根据fix模式的上下文AST匹配每个节点。
如果一个节点可以匹配Table2中显示的任何bug上下文，那么将匹配一个相关的fix模式，以生成具有相应代码更改模式的补丁候选。如果节点不是叶节点，tbar会继续遍历它的子节点。例如，如果一个可疑语句的第一个子节点是一个方法调用表达式，那么它将与fp10匹配。突变方法调用表达式修复模式。如果方法调用的子节点从变量引用开始，它将与fp13匹配。变异可变fix模式。其他fix模式遵循相同的方式。在可疑语句的所有表达式节点都与fix模式匹配之后，TBar分别从语句和方法级别进一步匹配fix模式。

3.1.3 补丁生成和验证

当找到匹配的fix模式时(例如，为可疑的语句选择模式)，通过改变语句生成一个补丁，然后针对测试套件运行打过补丁的程序。如果补丁程序成功通过所有测试，则将候选补丁视为可信的补丁[58]。一旦确定了这样一个可信的补丁，TBar就会停止为这个bug生成其他候选补丁，以标准和实用的程序修复工作流程[38,39,49,76,77]来修复 bug，但不会为每个bug生成所有可信补丁，不像PraPR[15]。否则，模式选择和补丁生成过程将继续，直到遍历所有有bug代码的AST节点。当几个fix模式上下文匹配一个节点时，它们的操作将用于排序:TBar将Update优先于Insert, Insert优先于Delete, Delete优先于Move。对于一个给定的fix模式，如果有多个捐赠方代码选项，候选补丁(每个都由一个特定的jc捐赠方代码生成)将根据捐赠方代码节点和有缺陷的代码文件 AST中的bug代码节点之间的距离进行排序:优先级为较小的距离。由于篇幅有限，在复制包中发布了以算法伪代码说明的详细步骤。
考虑到一些有缺陷的程序有几个有缺陷的位置，如果一个补丁候选程序可以使一个有缺陷的程序通过以前失败的测试用例的子集而不失败任何以前通过的测试用例，那么这个补丁就被认为是这个有缺陷程序的一个可能的子补丁。TBar将进一步验证其他候选补丁，直到生成一个可信的补丁，或者验证所有候选补丁，或者TBar耗尽修复尝试的时间限制设置(即三个小时)。
如果生成了一个可行的补丁，我们将进一步手动检查这个补丁和开发人员提供的、在Defects4J基准测试中可用的基本事实补丁之间的等价性。如果可信补丁在语义上与ground-truth补丁等价，则认为可信补丁是正确的。否则，它只被认为是可信的。我们提供了一个复制包，其中包含了TBar中模式实现的大量细节。源代码在前面提到的GitHub存储库中是公开的。

3.2评估基准

对于我们的经验评估，我们选择了Defects4J[20]数据集作为tbar的评估基准。这个基准测试包括了带有相关开发人员fixes的有bug的Java程序的测试用例。Defects4J是本研究目标的理想基准，因为它已被大多数针对Java程序缺陷的最新的最先进的APR系统广泛使用。表4提供了有关缺陷和测试用例的汇总统计信息，这些测试用例是我们在本文中使用的defects s4j的1.2.0[1]版本中提供的。

总的来说，我们注意到，到目前为止，101Defects4J错误已经被至少一个在文献中出版的APR工具正确地修正了。尽管如此，我们还记得SimFix[18]目前持有单个工具修复 bug的记录数量，即34。

4.评估

本节介绍并讨论了tbar修复实验的结果。特别地，我们进行了两个实验:
•实验#1:**评估在TBar中实现的各种fix模式的有效性。**为了避免故障定位误报带来的偏差(cf.[38])，我们直接向TBar提供完美的定位信息。
•实验#2:**评估tbar在正常程序的修复场景。**我们特别研究fix模式产生或多或少错误补丁的趋势。

4.1修复模式的适用性

我们的第一个实验的重点是评估fix模式生成补丁的性能，以解决真正的bug。特别地，我们在实验1中调查了三个研究问题。
RQ1。我们的分类法中的fix模式可以正确地修复来自Defects4J的多少真正的bug ?
RQ2。每个Defects4J bug可以通过不同的fix模式进行修复吗?
RQ3。fix模式的哪些特性被成功地用于修复 bug ?

在最近的一项研究中，Liu等人报道了故障定位技术实质上是如何影响APR工具的修复性能的。鉴于在本实验中，APR工具(即TBar)仅作为应用fix模式以评估其有效性的手段，我们必须消除故障定位偏差。因此，我们假设语句级的bug位置是已知的，我们直接将其提供给TBar的补丁生成步骤，无需运行任何故障定位工具(这是正常APR工作模式的一部分，参见图1)。为了确保整个实验的可读性，我们将APR系统的这个版本标记为TBarp(这里代表完美的本地化)。表5总结了TBarp的实验结果。

在Defects4J基准测试的395个bug中，TBarp可以为101个bug生成可信的补丁。其中有74个bug是通过正确的补丁修复的。我们还注意到，TBarp可以通过看似合理的补丁部分地fix20 bug，其中8(7？)个是正确的。在之前的研究中，当假定完美的本地化时，kPAR[38]基线工具(即，PAR[23]重要的基于模板的APR工具的Java实现)正确地/似是而非地fjxing 36/55 Defects4J bug。
虽然TBarp的结果很有希望，但有79%(=314/395)的bug不能用可用的fix模式正确地fix。我们手工调查了这些非fix bug，并将以下观察结果作为改进fix率的研究方向:
(1)不足fix模式。TBarp无法消除许多bug，仅仅是因为缺少匹配的fix模式。这表明在文献中收集的fix模式远远不能代表真实的bug。因此，社区必须继续为从现有补丁中挖掘fix模式提供有效的技术。
(2)对修复成分的无效搜索。基于模板的APR是一种基于搜索的APR[69]:一些修复模式需要施主代码(即修复成分)来生成实际的补丁。例如，如图2所示，要应用相关的修复patternFP9.2，需要将修复成分imagemaputilties.htmlescape标识为生成补丁所必需的。TBar的当前实现将捐赠者代码的搜索空间限制在bug本地化的本地文件中。**找到正确的供体代码是一个限制，但它减少了搜索空间爆炸的风险。**此外，TBar利用有bug的代码上下文来删除不相关的修复成分。因此，尽管TBar的修复模式可以与代码更改操作相匹配，但仍有一些错误无法通过TBar修复。使用更有效的搜索策略(例如，更大的搜索空间，比如[34]中来自其他项目的修复成分)，可能会有更多的机会修复更多的bug。

**RQ1:收集的修复模式可以用于正确修复来自Defects4J数据集的74个真正的bug。**然而，数据集的很大一部分仍然没有被tbarp修复，主要是由于(1)修复模式集的局限性和(2)从模式中寻找相关修复成分以构建具体补丁的幼稚搜索策略。
图3总结了一个或多个修复模式可以修复的bug数量的统计数据。y轴表示修复模式的数量(例如，n=1、2、3、4、5和>5)，可以为许多bug生成可信的补丁(x轴)。图中表示“P”表示TBarp(即TBarp)生成的可信补丁的数量（那些被发现是不正确的)。k（1，2，3，4）#表明仅通过k个修复模式就可以正确地修复一个bug(尽管可以通过更多的修复模式进行修复)。考虑图3中最底部的条:66 (=28+38)bug可以通过单一模式(y轴值为1)看似合理地修复;结果只有38个是正确固定的。注意，有几种模式可以为一个bug生成(可信的)补丁，但并不是所有的补丁都是正确的。例如，在图3中最上面的栏中，5个bug似乎都被5个以上的修复模式所消除。然而，3个修复模式只正确修复了1个bug。

总之，86%(38+10+5+3+10+4)/(74+7)正确修复的bug(74完全和7部分fixed bug)是完全通过单一模式正确修复的。换句话说，通常，几个修复模式可以生成能够通过所有测试用例的补丁，但是，在大多数情况下，只有一个模式可以正确地修复bug。这一发现表明，在尝试修复bug时，有必要仔细选择合适的修复模式，以避免可能通过停止修复过程而阻止发现正确补丁的可信补丁(假定所有测试都通过了可信补丁)。

RQ2:有些bug可以通过不同的修复模式进行修复。然而，在大多数情况下，只有一个修复模式足以生成正确的补丁。这一发现表明需要对固定模式的优先级进行新的研究。
表6详细说明了哪个bug由哪个修复模式修复。我们注意到，五个修复模式(即，FP3、FP4.3、FP5、FP7.2和FP11.3)不能用于为任何缺陷4j bug生成一个可信的补丁。两种修复模式(即FP9.2和FP12)导致了一些bug的貌似合理的补丁，但没有一种是正确的。这并不一定意味着前面提到的修复模式在PAR是无用的(或无效的)。相反，有两个原因可以解释它们的性能:
•对于寻找应用这些模式的相关成分，寻找捐助者代码的效率可能很低
•Defects4J数据集不包含这些修复模式可以解决的错误类型。

此外，二十(20)个修复模式可以为一些bug生成正确的补丁。这些修复模式中的大多数都涉及到可能的补丁(结果是不正确的)的生成。有趣的是，我们发现六(6)个修复模式可以为相同的10个bug生成几个候选补丁，其中一些是正确的，其他的只是可能的(如表6中的“g#”所示)。这一观察结果进一步强调了为合成补丁选择相关的捐赠代码的重要性:选择不恰当的捐赠代码可能导致生成一个合理(但不正确)的补丁，这将阻碍在典型的修复管道中生成正确的补丁。
除了修复模式外，在施主代码中收集的修复成分对于正确选择补丁至关重要，以避免看似合理但可能不正确的补丁。

我们进一步检查修复模式的属性，例如更改操作、粒度和补丁中更改语句的数量。统计数据如图4所示，突出显示了不同属性维的可信(但不正确)和正确补丁的数量，通过这些补丁可以对修复模式进行分类。

Update更改操作修复的bug比任何其他操作都多。类似地，针对表达式的修复模式比针对语句和方法的模式能正确修复更多的bug。然而，改变整个语句的修复模式在其看似合理的生成补丁中有更高的正确率。最后，只更改单个语句的修复模式比更改多个语句的修复模式可以正确修复更多的错误。然而，针对多语句的修复模式有更高的正确率。

RQ3:根据与实现的更改操作、更改粒度和更改扩展相关的属性，修复模式之间的成功修复存在显著差异。

4.2修复性能比较:TBar和最先进的APR工具

我们的第二个实验评估TBar在一个真实的环境中生成补丁，允许与文献中最先进的技术进行可靠的比较。具体地说，我们在实验2中调查了两个研究问题。
RQ4。在标准和实际的修复场景中，TBar可以实现什么性能?
RQ5。在故障定位(例如，发现有bug的代码位置)中，不同的修复模式在多大程度上对噪声敏感?
在这个实验中，我们实现了一个现实的场景，对缺陷4j bug使用正常的故障定位(例如，不假设TBarp是完美的定位)。为了与文献中记录的性能结果进行公平的比较，TBar利用了文献[38]中的标准配置和GZoltar[9]和Ochiai[4]。此外，TBar不使用任何其他技术来提高故障定位的准确性，例如崩溃堆栈跟踪(ssFix[74]使用)、谓词切换80或测试用例净化79。
关于补丁生成步骤,与试验TBarp（所有的位置(cf Section4.1)的多个位置错误都知道）相反,TBar适应“最初和首选”战略逐步应用修复模式,一次,在各种可疑代码位置:TBar生成一个补丁pi,使用与给定错误匹配的修复模式。如果pi通过了以前失败的测试用例的子集，而没有失败任何以前通过的测试用例，那么TBar选择pi作为bug的一个可能的补丁。然后，TBar继续验证另一个补丁pi+1(它可以由相同的修复模式在具有其他成分的相同代码实体上生成，或者在另一个代码位置上生成)。当pi+1通过与pi一样的测试用例子集时，如果pi+1是为与pi相同的错误代码实体生成的，pi+1将被放弃;否则，TBar也将pi+1作为另一个可能的补丁。通过这个过程，TBar创建一个补丁集P= {pi,pi+1，…貌似可信的补丁。在这里，只要任何一个补丁能够通过针对一个给定错误的所有给定测试用例，TBar就会把它当作针对这个给定错误的一个可能的补丁，认为它已经完全修复了bug，所有的pi∈P将被抛弃。否则，我们的工具将生成P，这是一组看似合理的补丁，每个补丁都可以部分地修复给定的错误。

我们针对缺陷4j数据集的错误程序运行TBar APR系统。表7展示了TBar与文献中最新的先进APR工具的性能比较。TBar可以用看似合理的补丁修复81个bug，其中43个已经被正确修复。没有其他APR工具达到这个数量的修正错误。然而，它的精确度(正确与可信补丁的比率)低于一些最近的工具，如CapGen和SimFix，后者使用复杂的技术来选择补丁成分。然而,值得注意的是,尽管使用修复模式记录在文献中,我们可以解决三个错误(即cl - 86、L-47 M-11)从未被任何APR系统修复的:
M-11是由一个独立的修复模式挖掘工具[35]发现的模式修复的，但它还没有被任何APR系统编码。
cl86和L-47是通过没有应用到Defects4J的模式修复的。

RQ4:TBar优于所有在Defects4J数据集上评估的最新的最先进的APR工具。它正确地fjxes 43个错误，而亚军(SimFix)据说正确地修复了34个错误。
值得注意的是，TBar执行的bug比TBarp要少(43个vs. 74个正确地fixed bug)。这一结果与最近的一项研究[38]一致，该研究表明，故障定位不精确不利于APR的修复性能。表6总结了关于每个修复模式在TBarp中修复的bug数量的信息。虽然只有4个修复模式，但在假设完美定位的情况下，并没有产生任何可信的补丁。使用TBar, 13个修复模式就是这样(见表8)。这一观测结果进一步证实了故障定位噪声的影响。
我们建议检查TBar应用修复模式生成看似合理但不正确的补丁的位置。如图5所示，TBar对38个完全修复的bug中的24个和16个部分修复的bug中的15个在不正确的位置(即没有bug的位置)做出了更改。

即使TBar将修复模式应用于精确的bug位置，生成的补丁也可能是不正确的。如图5所示，完全修复了Defects4J bug的14个补丁改变了正确的位置:在3种情况下，修复模式是不合适的;在另外两个案例中，TBar无法找到相关的捐赠者代码;对于其余的，TBar不支持所需的修复模式。
最后，图6说明了故障定位性能的影响:未修复的bug(但被TBarp正确修复)通常比正确修复的bug本地化得更差。类似地，我们注意到，许多看似合理但不正确的补丁是为没有很好地本地化的bug生成的(例如，几个假阳性的bug位置发生突变，导致看似合理但不正确的补丁)。

在可疑语句的故障定位列表中错误代码位置的分布。c和P分别表示正确地和似地(但不正确地)fjxed bug。F和U表示已修复和未修复的bug。

表8还提供了平均位置bug(故障定位可疑列表)。看来，一些修复模式(例如，FP2.1, FP6.3, FP10.2)可以正确修复本地化程度较差的bug，对故障定位噪声的敏感性较低。

RQ5:故障定位噪声对TBar性能有显著影响。修复模式对被推荐为bug位置的假阳性位置有不同的敏感性。

5.讨论

总的来说，我们的调查显示，一个大目录的修复模式可以帮助提高APR性能。然而，与此同时，还有其他一些需要解决的挑战:更准确的故障定位、有效搜索相关捐赠代码、修复模式优先级排序。虽然我们将在未来的工作中致力于其中的一些研究方向，但我们将在本节中讨论一些对研究有效性的威胁和TBar的实际局限性。

5.1威胁的有效性

外部有效性的威胁包括本研究的目标语言，即Java。本文所研究的修复模式只涵盖了针对最新的基于模式的APR系统所发布的Java程序bug的修复模式。然而，我们相信本研究中提出的大多数修复模式可以应用于其他语言，因为修复模式是作为抽象语法树级别来说明的。对外部有效性的另一个威胁可能是固定模式的多样性。我们的研究可能没有考虑到目前文献中所有可用的修复模式。为了减少这种威胁，我们系统地回顾了文献中关于基于模式的程序修复的研究。然而，我们承认集成更多的修复模式不一定会导致正确修复的bug数量的增加。如果修复模式太多，修复模式和候选补丁的搜索空间将会爆炸。最终，APR工具将产生大量看似合理的补丁，其中许多可能在正确的补丁之前被验证[69]。未来的研究方向是建立和管理APR固定模式数据库。
我们的修复模式选择策略可能会威胁到内部有效性:它天真地基于围绕有bug的位置的AST上下文匹配模式。更高级的策略将更有可能选择合适的模式来修复更多的bug。我们寻找捐助者代码的方法也带来了一些对有效性的威胁:TBar专注于本地的bug文件，而以前的工作已经表明，对于某些bug，足够的捐助者代码在其他文件中可用[18,69]。在未来的工作中，我们将研究超越本地文件的捐助者代码搜索，同时使用启发式来应对潜在的搜索空间爆炸。最后，所选择的评估基准对评估的外部有效性构成了另一个威胁。TBar在Defects4J上实现的性能可能无法在更大、更多样化和更有代表性的数据集上实现。为了解决这一威胁，应该调查新的基准，如bug .jar[61]和Bears[46]。

5.2局限性

TBar以一种简单的方式选择修复模式，因此有必要为修复模式选择设计一种复杂的策略(例如缺陷症状、缺陷类型或来自缺陷报告的其他信息)，以减少不适当的修复模式带来的干扰。搜索合成补丁的捐赠代码是TBar的另一个限制，因为修复某些bug的正确捐赠代码位于不包含bug的代码文件中[18,69]。如果TBar将捐赠者代码搜索扩展到其他没有bug的代码文件，将导致搜索空间爆炸。

6.相关工作

**故障定位。**一般来说，大多数APR管道从故障定位(FL)开始，如图1所示。一旦有bug的位置被本地化，ARP工具可以改变有bug的代码实体来生成补丁。为了识别程序中的缺陷位置，已经提出了几种自动FL技术[72]:基于切片的[47,71]，基于频谱的[6,57]，基于统计的[32,33]等。基于频谱的FL在APR系统中被广泛采用，因为它们在语句级别识别错误的位置。它依赖于排名指标(例如，Trantula [19]， Ochiai[5])来计算每个语句的可疑程度。GZoltar[9]和Ochiai已经被广泛地整合到APR系统中，因为它们的有效性已经在一些实证研究中得到了证明[56,65,73,78]。Liu等人的报道和本文的研究表明，这种FL配置在定位bug位置方面仍然有一定的局限性。因此，研究人员试图用新的技术来增强FL技术，如谓词切换[76,80]和测试用例纯化[18,79]。，。

补丁生成。APR管道的另一个关键过程是在所有可能方案的空间中寻找另一个方案的形状(即补丁)[30,43]。如果搜索空间太小，它可能不包含正确的补丁。[69]。为了减少这种威胁，一个直接的策略是扩大搜索空间，然而，这可能会导致另外两个问题:(1)在最坏的情况下，仍然没有正确的补丁;(2)扩展后的搜索空间包含了更多的似是而非的patch，使得在正确的patch之前生成似是而非的patch的可能性增大[34,69]。
为了提高修复性能，许多APR系统已经被探索解决搜索空间问题。基于合成的APR系统[42,76,77]探索通过合成新的条件表达式和从错误代码中识别的变量来限制条件bug修复的搜索空间。基于模式的APR工具[13,17,18,23,25,29,39ś41,62]的设计是为了净化搜索空间，通过遵循修复模式来突变有缺陷的代码实体与检索的捐赠代码。其他的APR管道专注于捐赠者代码或补丁合成策略的特定搜索方法，以解决搜索空间问题，例如基于契约的[10,66]，基于符号执行的[53]，基于学习的[7,16,44,59,64,70]，以及捐赠者代码搜索[21,51]APR工具。各种现有的APR工具已经在修复真正的bug上取得了有希望的结果，但仍然有机会提高性能;例如，挖掘更多的修复模式，改进模式选择和捐赠方代码检索策略，探索补丁生成的新策略，以及确定bug位置的优先级。

补丁的正确性。APR系统的最终目标是自动生成一个可以解决程序缺陷的正确补丁。一开始，通过所有测试用例[23,29,67]来评估补丁的正确性。然而，这些补丁可能会过度拟合[27,58]，甚至比bug[63]还要糟糕。此后，APR系统以生成正确斑块的精度进行评估[18,39,69,76]。最近，研究人员开始探索自动识别APR系统补丁正确性的框架[28,75]。

7.结论

已经在各种场景中研究了修复模式，以了解在野外的bug修复。他们进一步实现在不同的APR管道自动生成补丁。尽管基于模板的APR工具已经取得了有希望的结果，但没有对有效性修复模式进行广泛的调查。**我们通过一项系统研究来评估从文献中总结的各种修复模式的有效性，从而通过回顾修复模式的修复性能来填补这一空白。**特别地，**我们构建了一个简单的基于模板的APR工具，TBar，我们在缺陷4j基准上对其进行评估。一方面，假设一个完美的错误定位，TBar可以正确/合理地修复74/101个错误。另一方面，在一个正常/实际的APR管道中，TBar正确地修复了43个错误，尽管存在故障定位误报的噪声。**这构成了一个记录性能的文献中关于Java程序的修复。我们期望TBar能够被建立为新的基线APR系统，引导研究者提出更好的技术来实质性改善目前的水平。