[論文レビュー] Automatic Repair of Real Bugs: An Experience Report on the Defects4J Dataset

Matías Martínez, Thomas Durieux+3 more|arXiv (Cornell University)|May 26, 2015

Software Testing and Debugging Techniques参考文献 51被引用数 47

ひとこと要約

この論文は、224個の実際のJavaバグからなるDefects4Jデータセット上で、最先端の自動修復ツール—jGenProg、jKali、Nopol—の評価を行っている。47個のバグが自動修復可能であることが判明したが、生成された84個のパッチのうち実際に手作業で正しいと確認されたのは9個にとどまり、テスト・スイートに基づく修復手法に、不十分な仕様定義や過剰適合（overfitting）の問題が顕在している。

ABSTRACT

Defects4J is a large, peer-reviewed, structured dataset of real-world Java bugs. Each bug in Defects4J is provided with a test suite and at least one failing test case that triggers the bug. In this paper, we report on an experiment to explore the effectiveness of automatic repair on Defects4J. The result of our experiment shows that 47 bugs of the Defects4J dataset can be automatically repaired by state-of- the-art repair. This sets a baseline for future research on automatic repair for Java. We have manually analyzed 84 different patches to assess their real correctness. In total, 9 real Java bugs can be correctly fixed with test-suite based repair. This analysis shows that test-suite based repair suffers from under-specified bugs, for which trivial and incorrect patches still pass the test suite. With respect to practical applicability, it takes in average 14.8 minutes to find a patch. The experiment was done on a scientific grid, totaling 17.6 days of computation time. All their systems and experimental results are publicly available on Github in order to facilitate future research on automatic repair.

研究の動機と目的

• 大規模でピアレビューされたデータセットから得た実世界のJavaバグに対して、最先端の自動修復ツールの実用的効果を評価すること。
• テスト・スイートに基づく修復手法が、単にテストを通過するだけでなく、意味的に正しいかつ意味のあるパッチを生成するかどうかを調査すること。
• テスト・スイートが必要な動作を捉えられず、誤ったまたは単純なパッチが生成される原因となる、Defects4J内の不十分に定義されたバグ（under-specified bugs）を特定すること。
• 実際の工業的規模のコードベースにおける自動修復の計算コストを測定し、実用的応用可能性を評価すること。

提案手法

• GenProgおよびKaliのアプローチに基づき、Java向けに再実装した3つの修復ツール—jGenProg、jKali、Nopol—を用いた。
• 224個の実際のJavaバグ（各バグにテスト・スイートと少なくとも1つの失敗するテストケースを備える）をDefects4Jデータセットから抽出し、ツールを実行した。
• 17.6日分の合計計算時間を要する実験を、科学的グリッド（Grid’5000）上で実施した。
• 生成された84個のパッチを手作業で分析し、テスト・スイートの通過を超えた正しさを評価した。正しく、誤り、または専門的知識が必要と分類した。
• 修復空間内の探索を支援するため、ステートメントランク付けおよびパッチ検証技術を適用した。
• すべてのツール、設定、結果をGitHubに収集・公開し、再現可能性を確保するとともに、今後の研究を支援した。

実験結果

リサーチクエスチョン

• RQ1 RQ1: 最先端の修復技術は、Defects4Jデータセット内の実際のバグを自動で修正できるか？
• RQ2 RQ2: 生成されたパッチは意味的に正しいのか、それともテストケースに過剰適合し、実際のバグを正しく修正していないのか？
• RQ3 RQ3: Defects4J内のどのバグが不十分に定義されており、テスト・スイートのフィードバックのみで修復が困難なのか？
• RQ4 RQ4: これらのツールを用いて1つのバグを修復する平均実行時間はどのくらいか？

主な発見

• Defects4Jデータセットの224個のバグのうち、3つのツールのいずれかが47個を自動修復した。その中でNopolが最も多く（35個）を修復した。
• 生成された84個のパッチのうち、実際に手作業で正しいと確認されたのは11個にとどまり、パッチの72.6％が誤り、あるいはテスト入力に過剰適合していることが示された。
• 84個のパッチのうち12個は正当性の評価に専門的知識を要した。これは、自動的な正しさ評価の難しさを示している。
• 1バグあたりの平均修復時間は14.8分であり、実行可能ではあるが、工業的利用には計算コストが高すぎる傾向があることが示された。
• 12個のバグが3つのツールすべてによって修復されたことから、再現可能な修復のコアなセットが存在することが判明した。一方、35個のバグはNopolでのみ修復された。
• 結果から、テスト・スイートに基づく修復における根本的な欠陥が明らかになった。弱いテスト・スイートは、バグの意味的修復をしないままテストを通過する誤ったパッチを生み出す。