[论文解读] How to Design a Program Repair Bot? Insights from the Repairnator Project

Simon Urli, Zhongxing Yu+2 more|arXiv (Cornell University)|Nov 24, 2018

Software Testing and Debugging Techniques参考文献 34被引用 46

一句话总结

本文介绍 Repairnator，一个基于持续集成（CI）的程序修复机器人，它监控失败、复现错误、运行修复工具并报告补丁，在 11,523 次失败、涉及 1,609 个 GitHub 项目的实证结果中，生成了 15 个补丁（全部存在过拟合）。

ABSTRACT

Program repair research has made tremendous progress over the last few years, and software development bots are now being invented to help developers gain productivity. In this paper, we investigate the concept of a " program repair bot " and present Repairnator. The Repairnator bot is an autonomous agent that constantly monitors test failures, reproduces bugs, and runs program repair tools against each reproduced bug. If a patch is found, Repairnator bot reports it to the developers. At the time of writing, Repairnator uses three different program repair systems and has been operating since February 2017. In total, it has studied 11 317 test failures over 1 609 open-source software projects hosted on GitHub, and has generated patches for 17 different bugs. Over months, we hit a number of hard technical challenges and had to make various design and engineering decisions. This gives us a unique experience in this area. In this paper, we reflect upon Repairnator in order to share this knowledge with the automatic program repair community.

研究动机与目标

• 探索与 CI 工作流集成的自主程序修复机器人端到端的设计。
• 在大规模开源 Java 项目上进行实证评估，评估 Repairnator 复现错误和生成补丁的能力。
• 识别在构建和运行 Repairnator 过程中遇到的实际工程决策与挑战，并为未来的修复机器人提取可操作的建议。
• 提供数据与见解，弥合程序修复研究与工业实践之间的差距。

提出的方法

• 描述三阶段的 Repairnator 流水线：CI 构建分析、错误复现和补丁综合。
• 使用三个程序修复系统（NPol、NPEFix、Astor）为复现的故障生成补丁。
• 使用基于 Maven 的构建和隔离的依赖管理，在本地复现故障。
• 在将补丁报告给开发人员之前，由人类参与的补丁分析师进行理性性检查。
• 归档补丁及复现/修复日志，以支持开放科学和未来研究。

实验结果

研究问题

• RQ1 在真实世界的 CI 环境中，自动程序修复机器人的可行性和有效性如何？
• RQ2 在大规模实践中，错误重现和补丁综合的经验特征（数量、成功率、失败类型）有哪些？
• RQ3 哪些核心挑战（例如过拟合、可重复性）限制端到端的修复，以及设计选择如何应对它们？
• RQ4 可以推导出哪些可操作的建议来指导未来的程序修复机器人开发？

主要发现

• Repairnator 在 2017 年 2 月至 2018 年 1 月之间，在 1,609 个开源 Java 项目中处理了 11,523 次 CI 失败。
• 为 15 个不同的错误生成了补丁，但由于过拟合（补丁修复了失败的构建但并未修复真实的错误），没有一个被提交给开发者。
• Repairnator 成功在 11,523 次失败构建中复现了 3,551 次（30.82%）。
• 在复现的错误中，三个修复工具共产生了 1,307 个补丁，表明存在一个庞大的搜索空间，存在大量测试套件可接受的补丁，但其中大多数存在过拟合。
• 观察到的最常见的失败类型是 AssertionError 和 NullPointerException，它们共同构成失败的相当大一部分（在前十类中占比超过 70%）。
• 构建的可复现性高度依赖于项目（例如 druid-io/druid：62% 可复现； prestodb/presto：19.40%），凸显了项目层面在修复潜力上的变异性。