[論文レビュー] 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

ひとこと要約

この論文は、Failureを監視し、バグを再現し、修復ツールを実行し、パッチを報告するCIベースのプログラム修復ボットRepairnatorを提示する。実証結果は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の構築・運用における実践的な設計判断と課題を特定し、今後の修復ボットの実用的な推奨を抽出する。
• プログラム修復研究と産業実践のギャップを埋めるデータと洞察を提供する。

提案手法

• 3段階のRepairnatorパイプラインを説明する: CIビルド分析、バグ再現、パッチ合成。
• 再現された失敗に対して、3つのプログラム修復システム（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%）。
• 再現されたバグの中で、3つの修復ツールをまたいで1,307個のパッチが生成され、テストスイート適合のパッチが多い大規模な探索空間を示すが、その大半は過剰適合だった。
• 最も一般的な失敗タイプはAssertionErrorとNullPointerExceptionで、トップ10タイプ全体で失敗の重要な部分を占めている（70%以上）。
• ビルドの再現性はプロジェクトに強く依存している（例: druid-io/druid: 62% 再現; prestodb/presto: 19.40%）ことが、修復ポテンシャルのプロジェクトレベルのばらつきを示している。