【论文笔记】Towards Standardizing and Improving Classification of Bug-Fix Commits

论文概述

发表在2019ESEM-CCF-B（软件工程/系统软件/程序设计语言）
论文目的：判断一个github commit是不是bug-fix commit

作者提出的方法基于预先训练的深度神经网络的微调，该网络对语言(在我们的例子中是英语)中的双向单词关系进行编码，以解决Bug-Fix识别任务。

为了实现我们的方法，我们必须执行三个任务:a)定义我们希望模型遵守的语义规则，b)构造适当的数据集，c)针对我们的任务微调预先训练的BERT模型。当我们在注释阶段遇到不同类型的提交消息时，语义规则也随之发展。我们首先选择候选存储库并收集它们的提交消息。然后，我们从不同的项目中采样提交的子集，并手动将它们标记为bug修复(Positive)或非bug修复(Negative)。然后，我们将数据集分割为传统接受的85%-15%的训练测试分割，并针对我们的任务微调BERT。

充分利用NLP社区的最新研究进展。这些改进解决了传统NLP方法固有的许多关键限制。BERT是能够理解上下文的最先进的模型之一。我们使用预训练的BERT模型，并对其进行修改以用于我们的分类任务。这包括向模型添加最终的分类层，并针对我们的任务对其进行训练。

创新点：

• 充分利用NLP社区的最新研究进展。
• 提出的模型不仅可以跨领域，而且可以跨语言
• 相比关键词筛选，作者提出的方案是规则匹配，具体规则如下，规则中有些commit作者不认为是bug-fix相关的，但是有些论文认为是，存在这样的偏差

选择commit并形成数据集

以下是用来确定提交是否应该被标记为bug - fix- commit的规则:（规则匹配）

• 如果提交消息的文本只有“Fix Issue #[NUM]”。根据Herzig et al.[24]的研究，尽管可能存在一些假阳性，但他们发现33.8%的“问题”被错误分类。由于大多数问题仍然与bug相关，如果我们将这些提交归类为bug修复，那么最终将导致更低的错误。
• 如果提交消息说它正在修复一个错误，特别是与代码相关的错误。因为它可能引用了错误的函数或变量。
• 如果提交消息暗示它正在修复编译时错误。
• 如果提交消息说它正在修复GUI，这样就不是一个美观的更改。有时，在这些情况下，图形元素可能会消失或开始出现故障，修复该行为被认为是一个bug修复。
• 如果提交消息暗示提交正在修复内存泄漏。

以下是用来确定一个提交是否应该标记为not-a-bug- fixes -commit的规则:

• 如果提交消息是不可理解的。
• 如果提交是关于将一个库更新到一个较新的版本，或者将软件本身更新到一个较新的版本。
• 如果一个提交消息有一个模糊的close [#issue]。这并不一定意味着，有些东西是固定的。由于没有进一步的解释，我们认为最好把它看作不是一个bug修复提交。
• 如果提交与修复代码/库文档有关，或者它对注释进行了更改。文档存在于项目范围之外，对源代码没有功能影响;因此，修复它不应该被视为bug修复。
• 如果一个提交正在修复测试用例。我们相信测试用例是在项目范围之外的，并作为一个健全的检查。因此，修复项目范围之外的东西在技术上并不是bug修复。
• 如果一个提交是添加功能，因为添加功能通常被认为是完美的或自适应的。
• 如果提交应用的是编码风格的修复，可能包括命名约定或制表符而不是空格。检测错误/警告也不被认为是修复bug。
• 如果一个提交是重新版本控制或恢复到旧的提交。即使它可能是错误修复，在上一个提交中引入了一个错误，而这次提交撤消了它。然而，也可能是其他一些原因，因为提交消息通常没有详细说明这部分，而是说“恢复提交xxxx”，我们认为这不是一个bug修复。
• 如果一个提交说它是一个补丁。说它是一个补丁本身并不能保证它是一个bug修复。因为补丁也可能与性能有关。（表示疑问：直接排除所有patch不合适）
• 如果一个提交添加了一些异常处理。有时人们不是修复错误，而是将其封装在异常处理逻辑中。这是一个可能修复错误的极端情况，但人们使用它作为临时补丁。
• 如果提交只是在代码库中添加健全检查。

虽然这不是一份详尽的清单，也不能满足人们在野外遇到的每一种情况，但我们相信这是一个很好的起点，可以涵盖大多数常见的情况。在注释器面临的不明确的情况下，我们跳过了它，并抽样了另一个规则。我们这样做是因为这能让我们尽可能保持客观。

Commit Classification Model

• 在收集的数据集上训练出随机森林的分类器
• 使用迁移学习、TensorFlow框架来微调BERT模型，在模型的末尾添加了一个简单的密集层，其中包含一个sigmoid激活的单个神经元，以解决我们的任务作为一个二元分类问题。

结果

以上结果显示：作者提出的方案提升了准确性。

限制和未来工作

限制

• 在语义规则上缺乏共识:即使是在一个简单的任务中识别一个提交是否是错误修复，也没有普遍的共识，例如:“修复一个单元测试是否是错误修复?”，我们发现不同的解释[14]。我们希望我们的工作将推动其中一些术语的标准化。在这项工作中，我们使用了我们明智的决定，并以我们的理由记录了这些决定，但这将有助于达成更广泛的协商一致意见。
• 开源偏差:从开源存储库获取提交可能会导致偏差，因为大型公司可能对提交消息的设计有更严格的规则。
• 流行偏差:我们的结果可能会受到影响，因为我们只使用流行的存储库
• 语言偏差:不同语言之间的提交分布表明，很大一部分提交属于C语言

未来工作

• 分析任务中我们方法的有效性:我们的工作是在更广泛的背景下完成的，即改进GitHub数据的实证分析。我们已经独立地测试了我们的方法，但是我们还没有正式地将其作为完整分析工具链的一部分进行测试。我们假设，随着准确度的显著提高，我们将看到整体分析结果的提高。
• 扩展数据集:我们相信通过扩展数据集，我们可以覆盖更多的极端情况。我们也将能够覆盖更多的项目。这将允许我们发现特定于某个软件领域的词汇表使用情况。
• 标准化规则:在未来，我们计划结合社区反馈来确定一组具有更大共识的规则。这将使我们更有信心地建立更大的数据集。