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

ひとこと要約

この論文は、自動プログラム修復（APR）および障害局所化（FL）のための3,091件の失敗および正常なCIビルドからなるベンチマークであるBugSwarmを批判的に評価している。設計意図にかかわらず、重複するコミット、非動作的障害、バグ以外の修正などによる問題のため、APR/FLに適したのはわずか112件（3.6％）にとどまり、ベンチマークの質と実験的研究における誤用について懸念を呈している。

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が自動プログラム修復および障害局所化手法の評価に適しているかどうかを評価すること。
• APRおよびFLのベンチマークとしての有効性を損なうBugSwarmの欠陥を特定・特徴づけること。
• BugSwarmの制限を実証的分析に基づいて踏まえ、APRおよびFLにおける将来のベンチマーク設計のガイドラインを提示すること。
• 3,091組のうちの大部分に対して不適切であることを強調することで、BugSwarmの実験的研究における誤用を防ぐこと。
• 信頼できる評価が可能な、手作業で検証された112組の正当なバグ修正ペアを提供すること。

提案手法

• APR/FL要件を満たすかを評価するため、3,091組すべてのBugSwarmビルドペアを手作業で点検すること。
• ビルドログ、差分、障害理由の分析により、障害タイプ（例：テスト、コンパイル、checkstyle）を分類すること。
• コミットの一意性および差分の一意性の評価により、重複または冗長な修正を特定すること。
• ソースコードの可用性およびテストスイートの整合性の評価により、再現可能性と妥当性を確保すること。
• BugSwarmと従来のリポジトリとの間で、インfraストラクチャのオーバーヘッド（コスト、時間、ストレージ）を比較すること。
• 163組の潜在的に関連するペアを特定し、そのうち112組を真のバグ修正として手作業で検証すること。

実験結果

リサーチクエスチョン

• RQ1 3,091組のBugSwarmビルドペアのうち、実際に自動プログラム修復および障害局所化に適しているのは何組か？
• RQ2 BugSwarmの失敗ビルドにおいて、最も一般的な障害理由（例：テスト、コンパイル、checkstyle）は何か？
• RQ3 重複するコミットや非バグ修正が、BugSwarmがAPRおよびFLのベンチマークとしての信頼性をどの程度損なっているか？
• RQ4 本分析に基づき、APRおよびFLのための高品質なベンチマークの主な特徴は何か？
• RQ5 BugSwarmのインfraストラクチャのオーバーヘッドは、標準的な開発ワークフローと比べてどの程度か？

主な発見

• APRおよび障害局所化に適しているのは、3,091組中わずか112組（3.6％）にとどまり、実際に動作上のバグを含んでいる。
• 失敗ビルドの62.32％がテスト障害によるもので、11.12％がcheckstyleエラー、10.03％がコンパイルエラーによるものであり、これらはAPR/FL評価に不適切な非動作的障害である。
• 1,182組（38.2％）が重複するコミットを含んでおり、これは冗長または一意でない修正を示しており、ベンチマークの多様性を低下させている。
• 142組が元の基準である「5回再現可能であること」を満たしておらず、信頼性に懸念が生じる。
• BugSwarmのインfraストラクチャは顕著なオーバーヘッドを伴う：1組あたり平均で45.24ドル、2日、18.8時間、3,680.45 GBのストレージを要する。
• 名前とは異なり、BugSwarmはバグのベンチマークではなくビルドのベンチマークであるため、概念的混乱を招き、研究分野での誤用が生じている。