企業のソフトウェア開発に対する自動プログラム修正技術適用の試み
内藤 圭吾1,a)

谷門 照斗1 柗本 真佑1 肥後 芳樹1
切貫 弘之2 倉林 利行2 丹野 治門2

楠本 真二1

概要：近年多くの自動プログラム修正の研究が行われている．その修正対象はほとんどの場合オープン
ソースソフトウェアや自動プログラム修正技術の評価用に用意されたデータセットであり，企業におけるソフトウェア開発においてそのツールおよびアルゴリズムが有効であるかどうかは示されていない．そこ
で本稿では，企業内で開発，利用されているシステムに対して既存の自動プログラム修正ツールを適用することで，企業のソフトウェア開発で発生したバグに対する自動プログラム修正ツールの有効性を調査した．また，本稿ではその調査結果と企業のソフトウェア開発に対する自動プログラム修正ツール適用の障壁についても議論する．
キーワード：デバッグ，プログラム自動修正，コード再利用

1. はじめにや，その他の自動プログラム修正技術の研究が行われてきた．その評価にはいずれも GenProg の評価同様オープン

ソフトウェア開発には様々な工程があり，その中でもデソースソフトウェアや，自動プログラム修正技術を評価す

バッグ作業に必要な時間はプログラミング工程の 50% 以上るために作成されたデータセットが用いられている [7][8]．

を占めるといわれている [1]. そこで，開発工程を短縮する

つまり，現在企業におけるソフトウェア開発に対して自動ためにデバッグ支援の研究が盛んに行われている．デバッ

プログラム修正技術を適用し，評価した研究は未だにない．

グはバグ同定とバグ修正の 2 つの工程に分けられる．これ

そのため，既存の自動プログラム修正技術が企業におけるまでに，デバッグ支援のためにバグ同定の自動化 [2][3][4]ソフトウェア開発において有効であるのか，また有効でなや，バグの理解支援の研究 [5] が行われてきた．そして近い場合どういった問題があり，解決すべきなのかが判明し年，バグの同定及び修正を自動で行う自動プログラム修正ていない．

技術の研究が盛んに行われている．

以上より，本研究では企業で開発運用されているシステ

自動プログラム修正技術の 1 つに，ソースコードの再利ムに対して自動プログラム修正技術を適用し，その有効性

用に基づく手法である GenProg がある [6]．GenProg は，及び実用化に向けての障壁を調査した．調査の結果，1 つ

バグを含むプログラムと，失敗テストを含むテストスイーのバグについて開発者の修正と同等の修正を自動プログラ

トを入力とし，全てのテストケースを通過するプログラム

ム修正によって行うことができた．また実用化に向けて以を出力する．その修正方法は，バグ同定された箇所に対し下の 4 つの障壁を明らかにした．

て行の挿入や削除，置換を遺伝的アルゴリズムに基づいて• 修正可能なバグの数

繰り返し行うことによってプログラムの修正を行う，とい• パラメータの調整

うものである．Le Goues らは GenProg を 8 個のオープン• 複数行の修正

ソースソフトウェアのバグ，合計 105 個に対して適用し，• テストケースの数

そのうち 55 個のバグについて修正に成功することでその以降 2 章では関連研究のアルゴリズムやその有効性につい有効性を示した [6]．その後も，GenProg を評価する研究て述べる．3 章では本研究の研究背景および調査項目について述べる．4 章では調査対象と，調査方法について述べ1
2a)

大阪大学大学院情報科学研究科 吹田市
日本電信電話株式会社 港区
k-naitou@ist.osaka-u.ac.jp

る．5 章では，実験，調査の結果および考察について述べる．6 章では実験，調査の結果に基づいた今後の課題につ入力 : バグを含むプログラム
テストスイート

バグを含む
プログラム

90%

80%

初期変異プログラム群生成

コピー
交叉

70%

第0世代
XX%

100%

85%

95%

75%

90%

変異

変異

評価関数による評価，選択

90%

第1世代

第2世代 第n世代: その変異プログラムのテスト通過割合

次世代の変異プログラム生成

図 2 遺伝的アルゴリズムによるの修正の流れ
終了判定

No

Yes
出力：全てのテストケースを通過するプログラム

GenProg では，プログラムを繰り返し変更する際に遺伝的アルゴリズムを用いている．遺伝的アルゴリズムによる修正の流れを図 2 に示す．以下，遺伝的アルゴリズムを用いた修正について述べる．

図 1

GenProg の修正の流れ

まず，バグを含むプログラムから複数の変異プログラムを生成する．その後，それぞれの変異プログラムに対していて述べる．7 章では妥当性の脅威について述べ，最後に全てのテストケースを実行し，成功したテストケースの数

8 章で本研究のまとめと今後の課題について述べる．

をその変異プログラムの評価として与える．そして，評価

2. 関連研究
近年多くの自動プログラム修正の研究が行われており，
それらは以下のように分類できる．

の良いものだけから次の世代を生み出す．次の世代の生成は以下の 3 通りの方法がある．
コピー 何も変更を加えずに次の世代に同じ変異プログ
ラムを残す．

• 再利用に基づく手法

変異 変更を追加して新たな変異プログラムを生成する．

• プログラム意味論に基づく手法

交叉 2 つの変異プログラムの変更内容を組み合わせて新• 修正パターンに基づく手法

たな変異プログラムを生成する．

これらの手法はいずれも，バグを含むプログラムと，失世代の生成を，全てのテストケースを通過する変異プロ

敗テストを含むテストスイートを入力とし，修正が完了しグラムが生成されるか，世代数が上限に達するまで繰りたプログラムを出力する．バグ同定及び，終了判定にはテ返す．

ストスイートを用いる．以下で，これらの手法の代表的なLe Goues らは GenProg を 8 個のオープンソースソフ

ものが，どういった方法で修正を行うのかを紹介する．

トウェアのバグ，合計 105 個に対して適用し，そのうち 55
個のバグについて修正を成功させることによってその有効

2.1 再利用に基づく手法
まず，再利用に基づく手法の 1 つである GenProg の修
正方法を説明する．GenProg は修正対象のプログラム中性を示した [6]．しかし，GenProg は変異プログラムの評
価時に全てのテストケースを実行するため，多くの計算コストを要する．

に存在しているソースコードを用いてバグ同定された箇所

そこで， Qi らは失敗するテストケースが見つかった場を変更したプログラム (以下，変異プログラム) を繰り返し合，その段階でテストケースの実行を打ち切り，次の変異生成，評価を行うことでバグの修正を行う．GenProg の修プログラムを生成することで修正を行う手法，RSRepair

正の流れを図 1 に示す．プログラムの変更方法は以下の 3を提案した [9]．Qi らは GenProg と同様の 8 個のオープ通りがある．

ンソースソフトウェアのバグを用いて RSRepair を評価

挿入 バグ同定行の次の行に修正対象のプログラム中に存在しているソースコードを挿入する．

し，GenProg と比較してより多くのバグを修正できたと報告している．しかし，1 つでも失敗するテストケース

削除 バグ同定行を削除する．

が見つかった段階でテストケースの実行を打ち切るため，

置換 バグ同定行を修正対象のプログラム中に存在してGenProg とは異なり RSRepair は単一行の修正しか行ういるソースコードと置換する．

ことができない．

2.2 プログラム意味論に基づく手法

した．

プログラム意味論に基づく手法である Nopol は，テス

本研究では，自動プログラム修正ツールを企業で開発運

トスイートからバグ同定された箇所が満たすべき制約を用されているシステムのバグに対して適用する. その際に，導出し，その制約を満たすプログラム文を生成する [10]．

GenProg と Nopol は実装したツールが公開されているた

Nopol と GenProg の修正手法以外の大きな違いとして，め，その 2 つのツールに関しては実験を行ったが，PAR

GenProg は修正するバグに特別な制約はないが，Nopol ははツールが公開されていないため，調査のみを行った．まif 文に関係するバグの修正しかできない点が挙げられる．

た，QACrashFix と HistoricalFix は，ツールやその使用

Xuan らは Nopol を 22 個のバグに適用し，そのうち 17

方法が公開されておらず，加えてその修正方法により修個のバグの修正に成功させることでその有用性を示した．

正可能性を論じることもできないため，紹介にとどめる．

また，その 17 個の正のうち，13 個の修正は開発者が対象

PAR と同じく修正パターンに基づく手法で，より新しいのバグに施した修正と機能的に等価であり，正しい修正でツールとして，HistoricalFix というツールが公開されてあったと報告している．

いる．しかし，本研究環境では正常に実験が行えず，またHistoricalFix は修正パターンが不明であるため，今回は対2.3 修正パターンに基づく手法

象から外した．

次に修正パターンに基づく手法である PAR の修正方法を説明する．PAR はあらかじめ 10 個の修正パターンを作

2.5 自動バグ同定手法

成しておき，それをバグ同定された箇所に適用することで今回実験に使用したツールは自動バグ同定に Ochiai と修正を行う．Kim らは PAR を 5 つのオープンソースソフ

いうフレームワークを用いているため，以下で Ochiai の

トウェアのバグに対して適用し，GenProg よりも多くのバ

自動バグ同定の方法を説明する [15]．Ochiai はバグを含む

グを可読性の高い形で修正に成功したことを報告している．

プログラムと，失敗するテストケースを含むテストスイー

しかし，用意されたパターンに当てはまらないバグは修正

トを入力として与え，出力には各行のバグが存在している

できないことや，修正パターンの作成に技術的に難しいも疑惑値を出力する．失敗テストケースと成功テストケースのが存在することが問題点として挙げられている [11]．まの実行経路を用いて疑惑値を 0〜1 の数値で計測する．i 行

た，実験対象や実験内容に対する批判も存在している [12]．

を実行する失敗テストケースの数を f ail(i)，i 行を実行す
る成功テストケースの数を pass(i)，失敗するテストケース

2.4 その他の手法
修正に Stack Overflow を利用する手法に QACrashFixの総数を totalf ail とおくと，i 行の疑惑値 suspicious(i)は以下の様になる．

がある [13]．QACrashFix では，エラーが発生した際に出力されるエラートレースを解析し，Stack Overflow で同suspicious(i) = √様のエラーを検索する．その後，その回答からコードス
ニペットを生成し，その修正コードスニペットをを含むプログラムに適用することで変異プログラムを生成する．

f ail(i)totalf ail ∗ (f ail(i) + pass(i))

Ochiai はこのメトリクスで，各行の疑惑値を計測し，全ての行の疑惑値を出力する．

QACrashFix は 24 個のバグの内，8 個のバグについて正Ochiai のようなテストを実行し，その実行経路に基づい

しい修正パッチを生成することで有効性を示した．また，て各行の疑惑値を計測する自動バグ同定手法を spectrum-

QACrashFix が修正に成功したバグは既存の自動プログラ

based といい，Ochiai の他に Tarantula[16] や，jaccard[4]ム修正ツールでは修正できないものであった．

といった自動バグ同定手法も存在する．しかし，複数の論

パッチのランク付けに過去の修正履歴を用いる手法と文で他の spectrum-based の自動バグ同定手法と比較して，して HistoricalFix がある [14]．HistoricalFix の修正方法

Ochiai の自動バグ同定の正確性とその一貫性は優れている

は，GenProg と大きくは違わないが，変異プログラムのと指摘されている [17][18]．今回用いた 自動プログラム修

評価順序が GenProg とは異なる．HistoricalFix ではまず正ツールにおいても，自動バグ同定ステップでは Ochiai

対象プログラムの過去のバグ修正履歴の収集を行う．そのが利用されている．

後 GenProg や PAR で使用された変更操作を用いて変異プログラムを生成し，生成した変異プログラムの変更内容
が対象プログラムの過去の修正履歴と類似しているものか
ら順に変異プログラムの評価を行っていく．HistoricalFix

3. 調査の目的
本章では自動プログラム修正技術の課題を示し，課題解決に向けた調査項目について述べる．

は 90 個のバグを対象に修正を行い，23 個のバグについて正しい変異プログラムを出力することでその有効性を示

3.1 自動プログラム修正技術の課題
関連研究で述べた通り，再利用に基づく手法の 1 つである GenProg を含む様々な自動プログラム修正技術はオー

テストや結合テストなどが挙げられる．今回対象言語とプンソースソフトウェアを用いることによって，手法の有して選んだ Java において，単体テストは JUnit というテ

効性を評価している．つまり，先行研究では本来の目的でスト実行，評価の自動化を行うためのフレームワークがある企業のシステムに対する修正の可否や，その有効性が実装されているが，結合テストは自動化がされていない．

示されていない．オープンソースソフトウェアと企業で開GenProg および Nopol は前述のアルゴリズムの通り，変発されたシステムでは，テストの方法や開発フローなどの異プログラムを生成するたびに全てのテストケースを実行点で違いがあるため，オープンソースソフトウェアで有効

し，テストケースが成功しているか判定を行うため，テスであるからといって，必ずしも企業で利用可能であるとはトの実行と成功か失敗かの判定が自動化されている必要がいえないと著者らは考えた．

ある．そこで，今回は対象バグとして単体テストで発見されているバグを選択した．今後，結合テストの自動化が実

3.2 調査項目

装された場合，結合テストで発見されたバグについても対本研究の目的は，企業におけるソフトウェア開発に対し象として実験を行うことができると考えられる．対象シスて自動プログラム修正技術が有効であるかどうか，およびテムにおいてバグはバグ票で管理されており，そこにどの

自動プログラム修正技術の実用化に向けた障壁を明らかにようにしてそのバグが発見されたかも記載してあったたすることである．そのため以下の調査項目を設定する．

め，その記述を参考にフィルタリングを行った．

RQ1 既存の自動プログラム修正は企業のソフトウェア
開発に対しても有効であるか

RQ2 自動プログラム修正の実用化にはどのような障壁が存在するか4. 調査
本章では調査の方法について述べる．

次に， バグ修正情報が取得できるバグについて述べる．自動プログラム修正ツールの出力は全てのテストケー
スを通過する変異プログラムであり，ここで気をつけなければならないことは，全てのテストケースを通過することと，バグが修正されたことは等価ではないということである．テストスイートが不十分であった場合，バグが修正されていないがテストケースは全て通過する，というプログ
ラムが出力されることもある．つまり，自動プログラム修

4.1 調査対象

正ツールが出力した変異プログラムが，全てのテストケー

本調査は企業から提供された 2 つのシステムのバグ，合スを通過するがバグは直っていない変異プログラムなの

計 408 個 ( 327 個 + 81 個 ) を対象に行う．対象のシステか，バグが正しく修正された変異プログラムなのかを評価

ムは共に Java で記述され，その規模はそれぞれ，約 19 万する必要があるということである．そこで，企業で利用さ

行，約 2.5 万行である．

れているバージョン管理システムから，そのバグの修正内

自動プログラム修正ツールとして，自動バグ同定のフ容が取得できるかどうかでフィルタリングを行った．バー

レームワーク Ochiai および， GenProg を Java に使用でジョン管理システムには以下の情報が管理されている．

きるように改変した jGenProg の 2 つを実装したツール• 修正日時Astor[8] と，Nopol を用いた．

• 修正した開発者名

実験，評価を行うために次のフィルタリングを行った．

• 修正したファイル名

括弧の中は，そのフィルタリングを行った後，残ったバグ• 修正内容の数である．

バグ票記載のバグには，修正したリビジョンが確認でき• 提供されたバグ( 327 個 + 81 個 )ないもの，複数のバグが 1 つのリビジョンで修正され修正
内容とバグが紐付けられないもの，機能の実装とバグの修• 単体テストで発見されたバグ

正が同時に行われているものなどが存在していたため，そ( 上記の内 132 個 + 38 個 )のバグの修正内容が取得でき，バグと修正内容が一意に紐• バグ修正情報を取得できるバグづけられるどうか手作業で確認することでフィルタリング( 上記の内 78 個 + 2 個 )• 修正が Java ファイルのみのバグ( 上記の内 22 個 + 2 個 )以下では，それぞれのフィルタリングの必要性とその方法について述べる．

を行った．
最後に

修正が Java ファイルのみのバグ

について述

べる．今回利用したツールには修正対象が Java ファイルのみという制約がある．しかし，今回実験対象としたシス
テムには，ソースコードである Java ファイル以外にも，

まず， 単体テストで発見されたバグ について述べる．

設定ファイルである .property ファイルや，入出力ファイ

ソフトウェアの開発中にバグを発見する方法として，単体ルである .xml ファイルなどが含まれていた．そこで，修行えていない．
今回の実験を通して 1 つのバグについて修正を行うこfor(int i; i < num; i++) {if(checkNum(num)) {list = new ArrayList<String>();+break; //開発者修正+
return list; // GenProg 修正}
list.add(num);}
return list;とができた．修正内容を図 3 に示す．ただし，企業内で運用されているシステムであるため，図 3 のコードは変数名
や，バグとは関係のない処理などが実際のコードとは異なる．図 3 を見ると，GenProg の修正は開発者の修正と同等の動作を行うことが分かる．また，その修正コードの可読性も十分なものといえる．よって，オープンソースソフト
ウェアと同様に，企業のソフトウェア開発においても既存の自動プログラム修正技術で修正可能なバグが存在し，その修正は有効であることが分かった．残りの 12 個は，バ

図 3 修正結果

グ同定の失敗，自動プログラム修正の失敗により，修正を行うことができなかった．実験結果を表 1 に示す．それぞ正内容が Java ファイルのみであるかどうかのフィルタリ

れ状態の意味は以下のとおりである．

ングが必要である．前述した バグ修正情報が取得できる

Succeeded: ツールによってバグの修正に成功した．

バグ のフィルタリングと同様に，バージョン管理システ

Failed (NoModPoint): プログラムの各行に疑惑値をムから，その修正ファイルが Java ファイルのみかどうか計測したが，どの行を改変することで修正可能か不明

手作業でフィルタリングを行った．

であった．このエラーはツールや環境の問題であり，さらなる調査が必要である．

4.2 調査方法

Failed (Exception): ツール実行時に ExecutionExcep-

本研究では各 RQ に回答するために以下の実験，調査おtion*1 で実行が停止してしまった. このエラーはツー

よび議論を行った．

ルや環境の問題であり，さらなる調査が必要である．

実験 企業で開発されたシステムのバグに対して自動プ

Failed (BugLocalization): 自動バグ同定によって同定

ログラム修正ツールを適用し，その修正可能性を実験された行に，人間の修正した行が含まれず，なおかつにより明らかにする．

修正に失敗した．

調査 公開されていないツールについては，そのアルゴリ

Failed (NoSolution): 探索空間をすべて調査したが，テズムの観点から各バグの修正可能性を調査する．

ストがすべて通る修正が発見されなかった．

議論 企業とのミーティングを通して自動プログラム修
正ツール実用化に向けての障壁について議論する．
今回，題材としたシステムでは，バグの修正内容についまた，実験結果について企業のレビューは以下のようであった．

FL• FL 結果をユーザーにわかりやすく通知する機構を作てはバージョン管理ツールで保存されているが，バグを発現させるテストケースの存在しないバグも存在した．そこ成すれば，FL だけでも現場で活用できる．

• 動作の近い成功テストと失敗テスト間でも，テストで，本研究ではバグを含むリビジョンのテストスイートにバグを発現させるテストケースを新たに追加することで，テストスイートの補完を行い，実験を実施した．追加テス

表 1 実験結果

トケースは筆者らが追加したものと企業に追加を依頼した

Bug ID

ASTOR

NOPOL

ものがある．筆者らが追加したテストケースに関しては，

BUG-1

Succeeded

Failed(NoSolution)

企業に確認を取り追加したテストケースに誤りがないこと

BUG-2

Failed(NoModPoint)

Failed(Exception)

BUG-3

Failed(BugLocalization)

Failed(Exception)

BUG-4

Failed(BugLocalization)

Failed(BugLocalization)

BUG-5

Failed(BugLocalization)

Failed(BugLocalization)

BUG-6

Failed(BugLocalization)

Failed(BugLocalization)

BUG-7

Failed(BugLocalization)

Failed(BugLocalization)

BUG-8

Failed(BugLocalization)

Failed(BugLocalization)

BUG-9

Failed(BugLocalization)

Failed(BugLocalization)

BUG-10

Failed(BugLocalization)

Failed(BugLocalization)

BUG-11

Failed(NoSolution)

Failed(NoSolution)

BUG-12Failed(NoSolution)

Failed(NoSolution)

BUG-13Failed(NoSolution)

Failed(NoSolution)を確かめた．

5. 結果
この章では実験，調査の結果と結果に対する考察について述べる．

5.1 実験結果
現在，24 個のバグのうち，13 個のバグについて実験を行っている．残りの 11 個バグは，バグを発現させるテス
トケースが作成できていない等の問題があるため，実験を*1

java.util.concurrent.ExecutionException

えでの制約がいくつかある．そこでフィルタリングを行，

for(int i; i < num; i++) {if(i >= num) {+if(str[i] != null && i >= num) {list.add(str[i]);}}対象バグの数が 408 個から 24 個にまで減少した．これは，全体のバグの数に対してわずか約 6% である．バグ修正情報を取得できるかどうかで，53 個のバグがフィルタリング
されたが，これは実験，調査を行う上で 自動プログラム修
正ツールが出力した変異プログラムを評価するためのフィ
ルタリングであるため，その 90 個のバグが修正可能であるかは未確認である．しかし，90 個のバグ全てが修正可能

図 4

理論上 PAR によって修正できるバグの一例

なバグであった場合でも，修正可能なバグの数は提供されたバグの 28% にとどまる．この修正可能なバグの数の少で使用するデータの作成方法が異なる場合，バグ原

なさが，実用化に向けての障壁の 1 つである．

因箇所以外にも失敗テストのみで実行される行が出

ただし，バグ修正情報が取得できるバグであるかどうか

現してしまう．その場合，関係のない行の疑惑値がのフィルタリングで多くのバグがフィルターされてしまっ

高い値を示してしまう．この問題を防ぐために，テたのは，あくまで今回実験の結果を評価するためのフィル

スト作成を専任のメンバーが行う，テスト作成にもタリングのため，実用化に対しての問題ではない．実用化

コーディング規約を設けるなどの対策が必要となる．

に向けての問題としては，その前後のフィルタリング， 単APR• ランダムに修正を行うため，「仕様書に適合していな

体テストで発見されたバグ ， 修正が Java ファイルのみのバグの 2 つにあると考えられる．前者は，結合テスい」，「余計な条件分岐や変数の追加が行われている」

トが自動化されていないという，自動プログラム修正ツー

等の問題があり，現時点では修正結果を開発現場でル以外にも問題が存在するが，後者はそうではない．シス

利用することは困難である．

テムはソースだけで構成されている場合は極稀で，ほとん• 再利用に基づくため，多くのコードクローンが生成され，保守性の面で課題が存在する．

• 修正方針のヒントを与える，という形ではデバッグ支援に活用できる．

どの場合は設定ファイルやプロパティファイルも含まれている．そうであるにも関わらず，自動プログラム修正の修
正対象がソースコードのみであるという点は，自動プログ
ラム修正ツールに閉じた問題である．実際，今回の実験でも， 修正が Java ファイルのみのバグ のフィルタリング

5.2 調査結果

でバグの数が 80 個から 24 個，実に 70% ものバグがフィ

5.2.1 PAR の修正可能性

ルターされてしまっている．

Kim らが示していた 10 個のパターン [11] を用いて今回

以上より，今後の 自動プログラム修正の課題は，その修のシステムを修正した場合，理論上 2 個のバグを修正でき

正対象をソースコードのみから，それ以外の設定ファイル

ることが明らかになった．ただし，システムごとにバグのやプロパティファイルにまで拡張することであると考えら

修正方法に傾向はみられたため，修正対象のソフトウェア

れる．

に合うよう適切にパターンを生成することで，この結果はGithub 上のプロジェクトの内スター数上位 100 件のプ向上すると思われる．理論上修正可能であったバグの一例

ロジェクトと，今回企業から提供されたシステムについを図 4 に示す．図 3 と同様の理由により，バグの修正内容て，それぞれ全バグ修正コミットに対する修正が Java のに関係のない変数名等は実際のコードとは異なる．また，

みのバグ修正コミットの割合を調査したところ，OSS で

もう一つのバグも図 4 と同様に条件式の修正であった．

約 60%，企業のシステムで約 50% と，約 10%の違いがみられた．したがって，この障壁については企業のシステム

5.3 自動プログラム修正実用化に向けた障壁
実験及び企業とのミーディングを通して，次の 4 点におにおいて顕著に現れていると考えられる．
パラメータの調整ける障壁が確認された．

今回用いた自動プログラム修正のツール Astor には，• 修正可能なバグの数

様々なパラメータが存在する．以下のパラメータはその一• パラメータの調整部である．

• 複数行の修正• ランダムに行を取得するシード値• テストケースの数• 遺伝的アルゴリズムにおける，1 世代あたりの変異プ

以下では，それぞれの障壁に関する詳細を述べていく．
修正可能なバグの数

4.1 節で述べた通り，今回用いたツールには適用するう

ログラムの数．

• 遺伝的アルゴリズムにおける，最大世代数．

こういったパラメータが合計 70 個存在し，最適な値が容易に求められないものも多く存在する．本来自動プログ

11:
12:
13:
14:
15:
16:

ラム修正技術の目的は開発工程の短縮であるにも関わらず，パラメータの調整に時間がかかってしまっては本末転倒である．したがって，このパラメータの調整の難度が 2
つ目の障壁である．
複数行の修正(a)成功テストケース

今回の実験において，修正できたバグはわずかに 1 件に留まってしまった．この原因はいくつかあるが，その中でも大きな原因として，複数行の修正を必要とするバグの修正が難しいことが挙げられる．今回実験対象としたシス
テムのバグにおいて，修正行が 1 行だけであったものは，
わずかに 2 件であり，その他のバグは修正に複数行の変更を必要としていた．従って，自動プログラム修正ツールを実用化するためには，複数行の修正が可能であることが必要不可欠である．しかし，今回実験に用いた自動プログ
ラム修正ツール Nopol は単一行の修正しか行うことはできない．そのため Nopol ではその 2 件以外のバグはアル
ゴリズム上開発者と同様の修正は不可能であった．また，

GenProg では遺伝的アルゴリズムを用いることで複数行の修正を可能としているが，GenProg にも複数行修正を行う上での問題がある．GenProg で遺伝的アルゴリズムを用いる場合，その評価関数として，変異プログラムのテス
トケースの通過率を用いている．しかし，Java のテスト
ケースを作る際に，1 行 1 行に対応したテストケースを作ることはない．それ故に，複数行の修正が必要なバグにおいて，バグの存在するすべての行を修正して初めて 1 つのバグ発現テストケースが通過するようになる．そのため，複数行の修正の修正が必要なバグの修正過程において，遺伝的アルゴリズムの評価関数がうまく働かない．従って，各行の修正により評価が上昇していく新たな評価関数を用意する，各行に対応するテストケースを作成する，複数行を一度に修正するアルゴリズムを導入する等の対策が必要
である．
以上の理由より，既存の自動プログラム修正ツールは複数行の修正を必要とするバグの修正が難しい．これが 3 つ目の障壁である．
テストケースの数企業においてテストケース作成の基準の 1 つにカバレッジがある．カバレッジとはプログラム全体のうち，テスト
ケースによって実行された命令や分岐の割合のことである．テストケースによって実行された命令の割合を命令カ
バレッジ，テストケースによって実行された分岐の組み合
わせの割合を分岐カバレッジという．カバレッジを指標とint b = 5;
if (a > b){
a = b;}else{
a = b – a;
}

図 5

11:
12:
13:
14:
15:
16:

int b = 5;
if (a > b){
a = b;}else{
a = b – a;}(b)失敗テストケース

テストによるプログラムの実行経路．網掛け部分が実行されたコード．

のフレームワークである Ochiai のメトリクスを紹介したが，自動バグ同定のメトリクスでは失敗か成功かに関わらずテストケースの数が疑惑値を決定する重要なファクターになっている．以下で，テストケースの数が疑惑値に大きく寄与する例を述べる．図 5 に 2 つのテストケースによる実行経路を示す．
テストケースがこの 2 つだけの場合と，(a) の成功テス
トケースと同様の実行経路の成功テストケースが 9 個，99個の場合について．各行の疑惑値を表 2 にまとめる．図 5の 2 つのテストケースだけで，命令カバレッジと分岐カバ
レッジはともに 100% になっている．しかし，表 2 を見ると，テストケース 2 つだけでは，失敗テストケースのみで実行されている 13 行目に加えて，11 行目と 12 行目の疑惑値も高い値を示している．11 行目，12 行目は成功テス
トケース，失敗テストケースともに実行されているため，直感的にはそこまで怪しくはないが，テストケースが少な
いため，11，12 行目も高い疑惑値になってしまっている．
表 2 を見ると，成功テストケースを 9 個，99 個に増やすと，11，12 行目の疑惑値が減っていくことが分かる．以上の例から分かるように，テストケースの数が疑惑値を決定する大きなファクターとなっている．そのため，テスト
ケースの数が不十分であった場合，自動バグ同定が正しく行われない．今回実験を行ったバグについても，自動バグ
同定がうまくいっていないために自動プログラム修正が行えなかったバグも存在する．
この障壁は少ないテストケースで高いカバレッジを達成する，という戦略をとっている場合のみに限った話ではない．例として，0〜9 の自然数を入力として，入力の値を四捨五入するプログラムを作成したとする．そのプログラム
に対して，代表的なテスト技法である同値分割や，境界値分析に基づきテストケースを作成したとする．その場合，
表 2 テストケースの数の違いによる疑惑値の値の変化
ソース \成功テストケース数
1999

してテストケースを作成した場合，一定数のテストケース

11: int b = 5;

0.7

0.3

0.1

が作成されるが，自動プログラム修正を行うためにはテス

12: if(a > b){

0.7

0.3

0.1

トケースの数が不十分な場合がある．2 章で自動バグ同定

13: a = b;

1

1

1

15: a = b - a;

0

0

0

正常系のテストケースとしては，0〜4 の範囲に含まれる自ロジェクトを対象とした場合結果が異なる可能性がある．

然数を入力とするテストケースと，5〜9 の範囲に含まれる

今回の結果はあくまで対象としたプロジェクトに特有のも

自然数を入力とするテストケースを高々 2 つずつ用意するのである可能性があるため，今後対象プロジェクトを増やと十分である．しかしこれは，あくまで人間が正しく機能

し結果の一般化を図る必要がある．

を実装できているか，バグが存在していないかを確かめるためのテストケースであるので，自動プログラム修正を行

8. おわりにうためには不十分である可能性がある．つまり，人間がプ本研究では，既存の再利用に基づく自動プログラム修正

ログラムの正しさを確かめるためのテストスイートと，自技術が，企業におけるソフトウェア開発に適用した際に有動プログラム修正において，正しくバグ同定を行うための効であるかどうか，実用化に向けてどのような障壁が存在

テストスイートは異なる，ということがこの障壁の本質でしているかを調査した．調査の結果，企業で開発運用されある．

ているシステムのバグのうち 1 つのバグについて開発者

以上より，各 RQ に対する回答は次の通りである．

による修正と同等の修正を行うことに成功した．また実用

RQ1 への回答 企業で開発されたシステムのバグにおい化に向けて 4 つの障壁を明らかにした．今後は，引き続ても，自動プログラム修正技術によって修正可能なバ

き 自動プログラム修正ツールの評価を行うとともに，対象

グは存在し，一部のバグについては有用である．

をソースコードのみから設定ファイル等まで拡張した自動RQ2 への回答 自動プログラム修正技術についての障壁

バグ同定および自動プログラム修正のツール開発を行ってとして，修正可能なバグの数の少なさ，パラメータ調

いく．

整の難度，複数行の修正の困難さという 4 点の障壁が明らかになった．また，開発者側の自動プログラム修

参考文献

正技術導入に向けた障壁として，人がソフトウェアの[1]

品質を確保するためのテストケースと自動プログラム
修正技術のためのテストケースに乖離があることが明らかになった．
[2]

6. 今後の課題
今回実験，調査を行う上で自動バグ同定及び自動プログ
ラム修正の対象がソースコードのみである点が修正可能なバグの数を少なくしていた原因の 1 つであった．そこで今[3]

後，対象をソースコードだけから設定ファイル等にまで拡張した自動バグ同定および自動プログラム修正ツールの実装が課題となる．
[4]

7. 妥当性の脅威
7.1 内的妥当性
本研究ではバグを発現させるテストケースを追加して，[5]

実験を実施した．その新たなテストケースの作成は，バグの内容やバグの修正内容を把握したうえで，恣意的にバグを発現させるテストケースの作成を行ったため，実際に開発者が手元でバグを発見した際のテストケースとは乖離し[6]ている可能性がある．開発者が手元でバグを発見した際のテストケースを用いて実験を行った場合，今回とは異なる実験結果や，障壁が明らかになる可能性がある．

[7]

7.2 外的妥当性
今回は特定の企業の 2 つのプロジェクトに対して既存ツールを適用したため，対象が他の企業のプロジェクトになった場合や，同一企業のプロジェクトにおいても他のプ[8]Baker,J.:
Experts
battleL192bnloss
tocomputerbugs,,
availablefrom⟨http://www.cambridgenews.co.uk/Expertsbattle192bn-loss-bugs/story-22514741detail/story.html⟩ (accessed 2015/06/09).
Saha, D., Nanda, M. G., Dhoolia, P., Nandivada, V. K.,
Sinha, V. and Chandra, S.: Fault localization for datacentric programs, Proceedings of the 19th ACM SIGSOFT symposium and the 13th European conference
on Foundations of software engineering, pp. 157–167(2011).
Jones, J. A. and Harrold, M. J.: Empirical evaluationof the tarantula automatic fault-localization technique,
Proceedings of the 20th IEEE/ACM international Conference on Automated software engineering, pp. 273–
282 (2005).
Chen, M. Y., Kiciman, E., Fratkin, E., Fox, A. andBrewer, E.: Pinpoint: Problem determination in large,
dynamic internet services, Dependable Systems andNetworks, 2002. DSN 2002. Proceedings. International
Conference on IEEE, pp. 595–604 (2002).
Zuddas, D., Jin, W., Pastore, F., Mariani, L. andOrso, A.: MIMIC: locating and understanding bugsby analyzing mimicked executions, Proceedings of the
29th ACM/IEEE international conference on Automated software engineering, pp. 815–826 (2014).
Le Goues, C., Dewey-Vogt, M., Forrest, S. and Weimer,
W.: A systematic study of automated program repair:Fixing 55 out of 105 bugs for $8 each, Software Engineering (ICSE), 2012 34th International Conference
on IEEE, pp. 3–13 (2012).
Nguyen, H. D. T., Qi, D., Roychoudhury, A. and Chandra, S.: Semfix: Program repair via semantic analysis,
Proceedings of the 2013 International Conference on
Software Engineering, pp. 772–781 (2013).
Martinez, M. and Monperrus, M.: ASTOR: a program
repair library for Java, Proceedings of the 25th International Symposium on Software Testing and Analysis,
pp. 441–444 (2016).

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

Qi, Y., Mao, X., Lei, Y., Dai, Z. and Wang, C.: The
strength of random search on automated program repair, Proceedings of the 36th International Conference
on Software Engineering, pp. 254–265 (2014).
Xuan, J., Martinez, M., Demarco, F., Clement, M.,
Marcote, S. L., Durieux, T., Le Berre, D. and Monperrus, M.: Nopol: Automatic repair of conditional statement bugs in java programs, IEEE Transactions on
Software Engineering, Vol. 43, No. 1, pp. 34–55 (2017).
Kim, D., Nam, J., Song, J. and Kim, S.: Automatic
patch generation learned from human-written patches,
Proceedings of the 2013 International Conference on
Software Engineering, pp. 802–811 (2013).
Monperrus, M.: A critical review of automatic patch
generation learned from human-written patches: essayon the problem statement and the evaluation of automatic software repair, Proceedings of the 36th International Conference on Software Engineering, pp. 234–
242 (2014).
Gao, Q., Zhang, H., Wang, J., Xiong, Y., Zhang, L.
and Mei, H.: Fixing recurring crash bugs via analyzing
q&a sites (T), Automated Software Engineering (ASE),
2015 30th IEEE/ACM International Conference on,IEEE, pp. 307–318 (2015).
Le, X. B. D., Lo, D. and Goues, C. L.: History Driven
Program Repair, 2016 IEEE 23rd International Conference on Software Analysis, Evolution, and Reengineering (SANER), Vol. 1, pp. 213–224 (online), DOI:
10.1109/SANER.2016.76 (2016).
Abreu, R., Zoeteweij, P. and Van Gemund, A. J.: An
evaluation of similarity coeﬃcients for software fault
localization, Dependable Computing, 2006. PRDC’06.
12th Pacific Rim International Symposium on IEEE,
pp. 39–46 (2006).
Jones, J. A., Harrold, M. J. and Stasko, J.: Visualization of test information to assist fault localization, Proceedings of the 24th international conference on Software engineering, ACM, pp. 467–477 (2002).
Abreu, R., Zoeteweij, P. and Van Gemund, A. J.: An
evaluation of similarity coeﬃcients for software fault
localization, Dependable Computing, 2006. PRDC’06.
12th Pacific Rim International Symposium on, IEEE,
pp. 39–46 (2006).
Abreu, R., Zoeteweij, P. and Van Gemund, A. J.: On
the accuracy of spectrum-based fault localization, Testing: Academic and Industrial Conference Practice andResearch Techniques-MUTATION, 2007. TAICPARTMUTATION 2007, IEEE, pp. 89–98 (2007).