Page 275 - 《软件学报》2024年第4期
P. 275

王尚文 等: 基于指针神经网络的细粒度缺陷定位                                                         1853


                    在评价指标上, 我们关注修复有效性和效率两方面. 在有效性方面, 除了广泛讨论的召回率                            (recall, 即能对多
                 少个缺陷生成语义正确的补丁), 我们着重关注近年来逐渐被研究人员重视的另一个方面, 修复的准确率
                 (precision, 即生成的通过所有测试用例的补丁中有多少是真正正确的). 假定一个程序修复工具对                        x 个缺陷程序生
                 成了能够通过所有测试用例的补丁, 其中             y 个补丁是与开发人员提供的标准补丁语义一致的, 而缺陷数据集中共
                 有  z 个缺陷, 则其准确率为     precision =  y   , 其召回率为  recall =  y  . 在修复效率方面, Liu  等人  [3] 指出时间开销这一
                                               x                 z
                 指标与机器配置、实验设置等因素具有强关联关系, 因此使用候选补丁数                        (number of patch candidates, NPC) 即修
                 复工具在搜索到第       1  个通过所有测试用例的补丁之前产生的候选补丁的数量, 是一个更加合理的选择. 因此, 在本
                 文中我们选用     NPC  值作为衡量修复效率的指标.
                    我们关注修复准确率和效率的原因在于, 缺陷修复准确率和效率能够从侧面反映出缺陷定位的有效性: 一方
                 面, 已有研究表明     [69] 超过  90%  的修复工具产生的正确补丁是在缺陷位置处生成的, 因此, 倘若缺陷令牌能够获得
                 较高的排名, 则修复工具能够较早生成正确补丁, 即取得高修复准确率; 反之, 若缺陷令牌排名靠后, 修复工具不能
                 够较早生成正确补丁, 且易于在排名靠前的非缺陷位置处生成过拟合补丁, 使修复准确率下降. 另一方面, 本文设
                 计的修复方法根据可疑值大小迭代式地依次对代码令牌进行修复尝试, 搜索空间较大且存在组合爆炸的可能, 将
                 缺陷令牌排在靠前的位置将大大提升修复方法的效率.
                  5.3   缺陷修复有效性分析
                    表  6  展示了基于细粒度缺陷定位信息的缺陷修复方法的修复有效性. 表中每个数据集下括号中的数字代表该
                 缺陷数据集包含的缺陷数, 诸如“m/n”形式的数据表示某一修复方法在某一数据集下对                          n  个缺陷生成了可疑补丁,
                 其中  m  个补丁是语义正确的. 根据第        5.2  节中的评价指标相关内容, m       值越大代表该修复工具的召回率越高, 而
                 m
                    的值即代表该修复工具的准确率. 我们将两种方法同两类已有技术进行比较, 一类是当前技术中具有较高准确率的
                 n
                 (如  CapGen、ACS), 一类是当前技术中具有较高召回率的            (如  TBar、CURE). 结果显示两种基于细粒度缺陷定位
                 信息的修复流水线都能够达到           100%  的准确率, 并且在人工检验生成的补丁的过程中, 我们发现由这两种方法生
                 成的能够通过所有测试用例的补丁都与标准补丁在相同位置完成修改. 进一步分析表明, 基于细粒度缺陷定位信
                 息的修复流水线能够取得         100%  准确率的关键因素在于其能够准确定位到缺陷令牌并进行令牌层面的操作, 从而
                 避免修改其他与缺陷无关的内容. 图           1  中所示的缺陷是一个相应的案例, BEEP          成功将包含缺陷令牌“<”以及代码
                 变换操作   UPDATE 的操作路径排在所有操作路径的第             3  位, 随后, 基于启发式的补丁生成方法将“<”替换为“<=”,
                 从而生成了正确的补丁, 避免了过拟合补丁的产生. 此处需要注意的是, 我们将代码中的每个操作符也视为代码令
                 牌、为每个操作符构建了操作路径             (一个直观的例子如图       3  所示) 并与其他构建的操作路径一同进行训练, 因此
                 我们的方法也可以准确定位缺陷操作符. 我们将在第                 5.5  节案例分析中分析更多被基于细粒度缺陷定位信息的修
                 复流水线成功修复的案例. 我们还注意到, 与第             1  类已有工具相比, 我们提出的修复方案能够修复数量大致相当的
                 缺陷, 即拥有大致相当的召回率. 例如, ACS          能够正确修复     18  个缺陷, 而我们的方案     (BEEP + 启发式) 能够正确修
                 复  21  个缺陷. 另一方面, 尽管第    2  类已有工具在能够修复的补丁数量上优于我们提出的方案, 即拥有较高的召回
                 率, 它们的准确率却低了很多. 例如, DLFix        的准确率甚至低于       50%, 说明在其生成的能通过所有测试用例的补丁
                 中, 不正确补丁要多于正确补丁. 进一步分析表明, 对于               21  个能被基于   BEEP  与启发式的修复流水线正确修复的
                 缺陷, 表中所示的     4  个第  2  类修复工具均对其中     2–3  个缺陷生成了过拟合补丁. 由于在实际中开发人员在将补丁
                 集成到系统中之前往往要检查补丁的正确性, 因此过低的准确率会加重开发人员使用程序修复工具的负担.
                    表  6 中括号里列出的数字代表提出的修复方案在该缺陷数据集上能够修复的未被已有修复方法                              (Jiang 等人  [45]
                 所列出的   26  个) 解决的缺陷个数. 我们注意到, 即使是在修复领域最广为使用的                  Defects4J 数据集上, 我们提出的
                 修复方案依然能够成功修复          2  个不能被当前任何一种修复技术解决的缺陷. 这表明, 基于令牌的程序修复在未来
                 是值得探索的方向. 此外, 在       4  个数据集上, 基于启发式的方案比基于代码补全的方案多成功修复了                      5  个缺陷, 这
                 表明, 对于程序修复而言, 在缺陷方法内部寻找合适的用于生成补丁的修复原料可能会优于利用大数据预测缺陷
                 代码中缺失的部分.
   270   271   272   273   274   275   276   277   278   279   280