[论文解读] Critical Review of BugSwarm for Fault Localization and Program Repair

Thomas Durieux, Rui Abreu|arXiv (Cornell University)|May 22, 2019

Software Testing and Debugging Techniques参考文献 16被引用 7

一句话总结

本文对 BugSwarm 进行了批判性评估，该基准包含 3,091 个失败和通过的 CI 构建，用于自动程序修复（APR）和故障定位（FL）。尽管其设计初衷如此，但仅有 112 对（3.6%）适合用于 APR/FL，原因包括重复提交、非行为性失败和非错误修复，这引发了对基准质量及其在实证研究中误用的担忧。

ABSTRACT

Benchmarks play an important role in evaluating the efficiency and effectiveness of solutions to automate several phases of the software development lifecycle. Moreover, if well designed, they also serve us well as an important artifact to compare different approaches amongst themselves. BugSwarm is a benchmark that has been recently published, which contains 3,091 pairs of failing and passing continuous integration builds. According to the authors, the benchmark has been designed with the automatic program repair and fault localization communities in mind. Given that a benchmark targeting these communities ought to have several characteristics (e.g., a buggy statement needs to be present), we have dissected the benchmark to fully understand whether the benchmark suits these communities well. Our critical analysis has found several limitations in the benchmark: only 112/3,091 (3.6%) are suitable to evaluate techniques for automatic fault localization or program repair.

研究动机与目标

• 评估 BugSwarm 是否适合用于评估自动程序修复和故障定位技术。
• 识别并描述 BugSwarm 中损害其作为 APR 和 FL 基准有效性的缺陷。
• 基于对 BugSwarm 局限性的实证分析，为未来 APR 和 FL 基准设计提供指导。
• 通过强调其对 3,091 对中的大多数不适用，防止 BugSwarm 在实证研究中的误用。
• 提供一个经人工验证的 112 对有效错误修复对的精选子集，以支持可靠的评估。

提出的方法

• 对全部 3,091 个 BugSwarm 构建对进行人工检查，以评估其是否符合 APR/FL 的要求。
• 分析构建日志、差异文件和失败原因，对失败类型（如测试、编译、checkstyle）进行分类。
• 评估提交唯一性和差异唯一性，以检测重复或冗余的修复。
• 评估源代码可用性和测试套件完整性，以确保可重现性和有效性。
• 比较 BugSwarm 与传统代码库的基础设施开销（成本、时间、存储）。
• 识别出 163 个潜在相关对，随后对其中 112 个进行人工验证，确认其为真正的错误修复。

实验结果

研究问题

• RQ1 在 3,091 个 BugSwarm 构建对中，有多少对实际上适用于自动程序修复和故障定位？
• RQ2 BugSwarm 失败构建中，哪些类型的失败原因（如测试、编译、checkstyle）最为普遍？
• RQ3 重复提交和非错误修复在多大程度上损害了 BugSwarm 作为基准的可靠性？
• RQ4 基于本分析，高质量 APR 和 FL 基准的关键特征是什么？
• RQ5 BugSwarm 的基础设施开销与标准开发工作流相比如何？

主要发现

• 在 3,091 对中仅有 112 对（3.6%）适用于 APR 和故障定位，因为它们包含实际的行为错误。
• 62.32% 的失败构建因测试失败而失败，11.12% 因 checkstyle 错误，10.03% 因编译错误——这些均属于非行为性问题，不适合用于 APR/FL 评估。
• 1,182 对（38.2%）包含重复提交，表明存在冗余或非唯一的修复，降低了基准的多样性。
• 142 对未能满足原始标准中‘重复运行五次’的要求，引发了对其可靠性的担忧。
• BugSwarm 基础设施的开销显著：每对基准需花费 45.24 美元、2 天、18.8 小时和 3,680.45 GB 的存储空间。
• 尽管名称为 BugSwarm，但它实际上并非错误基准，而是构建基准，这导致了概念上的混淆，并在研究中被误用。