Repairnatorを使用した自動プログラム修復における人間と競合するパッチ

Repairnatorはボットです。オープンソースソフトウェアの継続的な統合中に発見されたソフトウェアバグを常に監視し、自動的に修正しようとします。有効なパッチの合成に成功すると、Repairnatorは、偽の人間のアイデンティティに偽装して、人間の開発者にパッチを提案します。これまで、Repairnatorは人間の開発者に受け入れられ、コードベースに永続的にマージされた5つのパッチを作成することができました。これは、自動プログラム修復に関するソフトウェアエンジニアリング研究における人間の競争力のマイルストーンです。この投稿では、KTHロイヤルインスティチュートオブインリア、リール大学、バレンシエンヌ大学で行われたこの研究についてのストーリーをお伝えします。

プログラム修復の研究は、アルゴリズムが人間を置き換えてソフトウェアのバグを修正できるという考えを追求しています[4]。バグ修正は、ソースコードを挿入、削除、または修正するパッチです。たとえば、次のパッチでは、開発者がifステートメントの条件を変更しています。

-if(x <10)
+ if(x <= 10)
foo();

プログラム修復ボットは、ソースコードのパッチを合成しようとする人工エージェントです。ソフトウェア保守活動に関与する人間の開発者と同じ方法で、バグを分析し、パッチを作成します。今日の人間はバグを修正する責任があるため、プログラム修復ボットのこのアイデアは破壊的です。言い換えれば、退屈なタスクのために人間の開発者を(部分的に)置き換えることを意図したボットについて話している。

ボットが通常人間によって行われるタスクを達成しようとするとき、それは人間競争タスクとして知られています[1]。プログラム修復研究の経験的評価[3]は、現在のプログラム修復システムが実際のプログラムの実際のバグに対するパッチを合成できることを示しています。ただし、これらのパッチはすべて、過去、通常は数年前に人間の開発者によって修正されたバグのために、過去のバグ用に合成されました。これは、プログラム修復の技術的な実現可能性を示していますが、プログラム修復が人間の競争力があることを示すことはできません。

人間の競争力

プログラム修復が人間と競合できることを示すために、プログラム修復ボットは、人間がそうする前に高品質のパッチを見つける必要があります。これに関連して、パッチは、適時性と品質の2つの条件を満たす場合、人間の競争力があると見なすことができます。適時性とは、システムが人間の開発者の前にパッチを見つけなければならないという事実を指します。つまり、プロトタイプシステムは、日ではなく、数分のオーダーでパッチを作成する必要があります。また、ボットによって生成されたパッチは、人間が作成したパッチと比較して、十分に正確で、同じ品質(正確で読みやすい)である必要があります。ボットの観点からは正しく見えても、正しくないパッチがあることに注意してください(これは文献[6、3]で過剰適合パッチとして知られています)。これらのパッチは、人間がコードベースでそれらを受け入れることはないため、おそらく人間の競争力はありません。

その結果、パッチが人間と競合するためには、1)ボットは人間の開発者よりも速くパッチを合成する必要があります。2)パッチは人間の開発者によって十分に判断され、コードベースに永続的にマージされる必要があります。

考慮すべきもう1つの側面があります。人間のエンジニアは、厳密に同一であっても、他の人間からの貢献ほど簡単にボットからの貢献を受け入れないことが示されています[5]。その理由は、人間は機械に対して先験的な偏見を持つ傾向があり、人間の仲間からの貢献であればエラーに対してより寛容だからです。これは、プログラムの修復のコンテキストでは、開発者がパッチがボットからのものであることを知っている場合、パッチの品質をより高く設定できることを意味します。これは、プログラム修復のコンテキストでの人間の競争力の証明の探求を妨げます。

この問題を克服するために、プロジェクトの早い段階で、すべてのRepairnatorパッチが偽の人間のアイデンティティの下で提案されることを決定しました。 Luc EsapeというGitHubユーザーを作成しました。このユーザーは、研究室でソフトウェアエンジニアとして紹介されています。 Lucはプロフィール写真を持っており、GitHubでオープンソースに貢献することに熱心なジュニア開発者のように見えます。次に、Luc Esapeがパッチを提案しているように見せかけたRepairnatorを想像してください。このカモフラージュは、人間の競争力に関する科学的仮説を検証するために必要です。現在、倫理のために、Lucの本当のアイデンティティは、彼のプルリクエストのそれぞれで明らかにされています。

自動修復と継続的統合

CIと呼ばれる継続的インテグレーションは、サーバーがコードをコンパイルし、ソフトウェアプロジェクトのバージョン管理システム(Gitなど)で行われたコミットごとにすべてのテストを実行するという考え方です。 CIの用語では、コミットごとにビルドがあります。ビルドには、使用されるソースコードスナップショットに関する情報(Gitコミットへの参照など)、コンパイルとテストの実行結果(失敗や成功など)、および実行トレースログが含まれます。コンパイルが失敗した場合、または少なくとも1つのテストケースが失敗した場合、ビルドは失敗したと言われます。 4つのビルドのうち約1つが失敗し、ビルド失敗の最も一般的な原因はテストの失敗であることが示されています[8]。

Repairnatorの重要なアイデアは、ビルドの失敗を修復するパッチを自動的に生成し、それを人間の開発者に見せて、最終的にそれらの人間の開発者がコードベースへの有効な貢献として受け入れるかどうかを確認することです。これが発生した場合、それはプログラム修復における人間の競争力の証拠になります。

継続的インテグレーションで発生するビルド障害を自動的に修復するこのセットアップは、次の理由から特に適切でタイムリーです。第一に、ビルドの失敗は、テストスイートベースのプログラム修復[4]のコア問題ステートメントを満たします。バグは失敗したテストケースとして指定され、失敗したテストケースはパッチの自動合成を駆動するために使用されます[4]。次に、ボットと人間を公平に比較​​できます。継続的統合サーバーで失敗したテストが発見されると、人間の開発者とボットに正確に同時に通知されます。このテスト失敗通知は、人間対ボットの競争の出発点です。

Repairnatorはビルドの失敗に焦点を当てていますが、ソフトウェア用のインテリジェントボットの全体像に適合しています[2]。たとえば、Facebookには自動テストで見つかったバグを修復するSapFixというツールがあります。また、関連して、DARPA Cyber​​ Grand Challengeボットの攻撃者と防御者は、セキュリティの専門家に関して人間の競争力を保とうとします。

一言で言えば修理

2017〜2018年に、プログラムの自動修復を行うボットであるRepairnatorを設計、実装、および運用しています。 Repairnatorは、継続的インテグレーション中に発生するビルド障害を修復することに特化しています。 GitHubコードホスティングプラットフォームにプッシュされる数千のコミットを常に監視し、対応するビルドを分析します。毎分、人間の開発者の前にバグを修正するために、新しい修復の試みを開始します。レースに参加するため、可能な限り高速に動作するように設計されています。Repairnatorが人間の開発者の前にパッチを見つけた場合、人間の競争力があります。

ここで、Repairnatorボットがどのように機能するかの概要を説明します。

Repairnatorの主な入力は、GitHubプロジェクト(a)に基づいて開発者(図の上部、(a)および(b))が行ったコミットによってトリガーされる継続的な統合ビルドです。 Repairnatorの出力は2つあります。(1)失敗したビルドを修復するためのパッチを自動的に生成します(g)(ある場合)。 (2)将来のプログラム修復研究(h)および(k)のために貴重なデータを収集します。 Repairnatorは恒久的に、GitHubプロジェクト©からのすべての継続的なアクティビティを監視します。 CIビルドは、3段階のパイプラインへの入力として提供されます。(1)最初の段階では、CIビルドログを収集および分析します(e)。 (2)第2段階は、CIで発生したビルドの失敗をローカルで再現することを目的としています(f)。 (3)第3段階では、最新の学術研究からのさまざまなプログラム修復プロトタイプを実行します。パッチが見つかると、Repairnatorプロジェクトメンバーは、オープンソース開発者の貴重な時間を無駄にしないように、迅速な健全性チェックを実行します。 (i)彼女はパッチが縮退していないことに気付いた場合、プロジェクトの元の開発者にGitHub(j)のプルリクエストとして提案します。その後、開発者は通常のコードレビューとマージのプロセスに従います。

Repairnatorは、特定のソフトウェアエコシステムで動作する必要があります。過去の研究プロジェクトにおけるJavaの専門知識により、Repairnatorのプロトタイプ実装は、Travis CI CI継続的統合プラットフォームを使用するGitHubでホストされるオープンソースプロジェクトで、Mavenツールチェーンで構築されたJavaプログラミング言語で記述されたソフトウェアの修復に焦点を当てています。

遠征の実績

2017年1月から3つの異なるフェーズでRepairnatorを運用しています。 2017年1月の1か月間に、プロトタイプの初期バージョンでパイロット実験を行いました。 2017年2月1日から2017年12月31日まで、14,188件のプロジェクトの固定リストを使用してRepairnatorを実行しました。これを「Expedition#1」と呼びます。 2018年1月1日から2018年6月30日まで、RepairnatorはTravis CIビルドストリームをリアルタイムで監視しています。これを「Expedition#2」と呼びます

パイロット実験の主な目標は、設計と初期実装を検証することでした。私たちのプロトタイプは、コンピューティングリソースを考慮して、1日に約30回の修復試行を実行できることがわかりました。さらに重要なことは、このパイロット実験がコア技術の前提を検証したことです。人気のあるオープンソースプロジェクトのかなりの割合がTravisを使用し、その大部分がビルドテクノロジーとしてMavenを使用しています。これは、そのコンテキストで人間と競合するパッチを合成するという目標を達成する可能性が十分にあることを意味していました。

結果が[7]で詳細に示されている第1遠征中に、Repairnatorはテストの失敗を伴う11,523ビルドを分析しました。 3,551人(30.82%)について、Repairnatorはテストの失敗をローカルで再現できました。 3,551回の修復試行のうち、RepairnatorはCIビルドをパスできる15個のパッチを見つけました。ただし、パッチ分析の結果、これらのパッチはいずれも遅すぎるため(人間の開発者の後にパッチを作成したため)、または低品質(偶然にビルドを成功させたため)であるため、人間と競合しません。

探検#2は成功です。プログラム修復技術が人間の競争力のフロンティアを超えたことを示しています。 Repairnatorは、上記で定義された人間の競争力の基準を満たす5つのパッチを作成しました。1)人間のパッチより前に作成されたパッチ、2)人間の開発者が有効な貢献としてパッチを受け入れ、パッチがメインコードベースにマージされました。

Githubでの人間の競争による貢献、Repairnatorロボットによって合成され、人間の開発者によって受け入れられたパッチ:

  • 2018年1月12日、aaime / geowebcache / pull / 1、「パッチをありがとう!」
  • 2018年3月23日、parkito / BasicDataCodeU […] / pull / 3「コミット140a3e3をparkito:developにマージしました」
  • 2018年4月5日、dkarv / jdcallgraph / pull / 2「ありがとう!」
  • 2018年5月3日、eclipse / ditto / pull / 151「クール、Eclipseプロセスの通過と修正に感謝します。」
  • 2018年6月25日、donnelldebnam / CodeU […] / pull / 151「ありがとう!!」

私たちのプログラム修復ボットによってマージされた最初のパッチは、2018年1月12日に人間の開発者によって受け入れられました。ストーリーは次のとおりです。 -ci.org/GeoWebCache/geowebcache/builds/328076497。 2つのテストケースにエラーがあったため、ビルドは2分の実行後に失敗しました。 40分後、2018年1月12日午後1時8分に、Repairnatorは定期的な監視中に失敗したビルドを検出し、Repairnatorで構成された利用可能なプログラム修復システムの実行を開始しました。 10分後、午後1時18分にパッチが見つかりました。

2018年1月12日、午後1時35分に、RepairnatorチームのメンバーがRepairnatorによって生成されたパッチを取得し、GitHubで対応するプルリクエストの開始を検証しました。 2018年1月12日の午後2時10分に、開発者はパッチを受け入れ、コメントとマージしました。「奇妙なことに、すでにこれを修正したと思った…多分他の場所でした。パッチをありがとう!」これは、Repairnatorが作成した最初のパッチであり、人間の開発者によって有効な貢献として受け入れられ、コードベースに明確に統合されました。言い換えれば、Repairnatorは初めて人間の競争力を持ちました。

さらに6か月運用した後、Repairnatorには人間の開発者がマージした5つのパッチがあります。

全体として、Repairnatorプロジェクトはその使命を果たしました。プログラム修復は、人間と競合するものと見なすことができることが示されています。Repairnatorは、1)人間よりも前に、2)人間自身が良質とみなすパッチを見つけました。

未来

プログラム修復が人間の競争力があることを示すことに加えて、Repairnatorプロジェクトは、[7]に示されているバグと継続的な統合、およびプログラム修復研究の現在の欠点に関する豊富な情報を提供しました。

特に1つのポイント、つまり知的財産の問題に​​焦点を当てましょう。 2018年5月3日に、RepairnatorはGitHubプロジェクトeclipse / dittoに適したパッチを作成しました。パッチを提案した直後に、開発者の1人が「Eclipse Foundation Contributor License Agreementに署名したユーザーからのプルリクエストのみを受け入れることができます」と尋ねました。ボットは物理的または道徳的にライセンス契約に署名することができず、おそらくそうする資格がないため、私たちは困惑しました。ロボットオペレーター、ボットの実装者、または修復アルゴリズムの設計者など、ボットの貢献の知的財産と責任を所有しているのは誰ですか?これは、Repairnatorプロジェクトによって明らかにされた興味深い質問の1つです。

Repairnatorは、ボットと人間がソフトウェアアーティファクトでスムーズに協力し、協力するソフトウェア開発の特定の未来を予感させると考えています。

Repairnatorコミュニティに参加したいですか? Repairnatorに関する定期的なニュースを受け取るには、repairnator.subscribe @ 4open.scienceにメールを送ってください!

—マーティン・モンペルラス、サイモン・ウルリ、トーマス・デュリュー、マティアス・マルティネス、ブノワ・ボードリー、ライオネル・セイントリエ

メディアで:

  • バグフィクサー並みはずれたLuc Esapeの不思議な生活。彼の大きな秘密は?彼は人間ではありません(Thomas Claburn、The Register)

参照資料

  • [1] J. R. Koza(2010)遺伝的プログラミングにより生成された人間と競合する結果。遺伝的プログラミングと進化可能な機械11(3–4)、pp。251–284。によって引用: 。
  • [2] C. Lebeuf、M。D. Storey、およびA. Zagalsky(2018)ソフトウェアボット。 IEEEソフトウェア35、18〜23ページ。引用元:自動修復および継続的インテグレーション。
  • [3] M. Martinez、T。Durieux、R。Sommerard、J。XuanおよびM. Monperrus(2016)Javaの実際のバグの自動修復:Defects4jデータセットの大規模実験。経験的ソフトウェアエンジニアリング、pp。1–29。引用元:人間の競争力
  • [4] M. Monperrus(2017)自動ソフトウェア修復:参考文献。 ACMコンピューティング調査。引用元:自動修復および継続的インテグレーション。
  • [5] A. Murgia、D。Janssens、S。Demeyer、およびB. Vasilescu(2016)マシンの中:ソーシャルQ&A Webサイトでの人間とロボットの相互作用。 2016 CHI会議の議事録で、コンピューティングシステムのヒューマンファクターに関する抄録の拡張、pp。1272–1279。引用元:人間の競争力。
  • [6] E. K.スミス、E。T.バー、C。ルゴース、Y。ブラン(2015)治療法は病気よりも悪いですか?自動プログラム修復の過剰適合。ソフトウェア工学の基礎に関する2015年第10回合同会議の議事録、pp。532–543。外部リンク:引用文献:人間の競争力。
  • [7] S. Urli、Z。Yu、L。Seinturier、M。Monperrus(2018)プログラム修復ボットの設計方法Repairnatorプロジェクトからの洞察。 ICSE 2018–40th International Conference on Software Engineeringで、実際のソフトウェアエンジニアリングの追跡、外部リンク:Link Cited by:Expedition Achievements、The Future。
  • [8] C.ヴァッサーロ、G。シャーマン、F。ザンペッティ、D。ロマーノ、P。レイトナー、A。ザイドマン、M。ディペンタ、S。パニケラ(2017)CIビルド失敗の物語:オープンソース金融機関の視点。ソフトウェアのメンテナンスと進化に関する国際会議で引用:自動修復と継続的統合。