設定ファイルを考慮した自動バグ限局手法の拡張
肥後 芳樹1

柗本 真佑1
切貫 弘之2

内藤 圭吾1
倉林 利行2谷門 照斗1
丹野 治門2

楠本 真二1

概要：自動バグ限局とは，バグの原因箇所を自動で推定する手法である．既存手法として，テストケース
による実行経路を用いてバグ限局を行う手法が提案されている．この手法では，失敗テストケースによって実行される行はバグの原因箇所である可能性が高く，成功テストケースによって実行される行はバグの原因箇所である可能性が低い，というアイデアに基づいて推定を行う．既存手法はテストケースを実行することによりバグ限局を行うため，設定ファイル等の直接実行されない箇所にバグが存在していた場合には，正しくバグ限局できないという課題がある．そこで本研究では，ソースコード以外の直接は実行されない箇所がバグの原因である場合でもより正しくバグ限局できるように既存手法を拡張した．拡張した手法の有効性を確かめるため，Java 言語のプロパティファイルを対象とした実装を行った．実験では，既存手法（Java のソースコードのみを対象としたバグ限局手法）と提案手法（Java ソースコードとプロパティ
ファイルを対象としたバグ限局手法）を比較した．実験の結果，バグの原因箇所がプロパティファイルにある場合には，提案手法は既存手法に比べてより正確にバグ限局ができていること，およびバグの原因箇所がソースコードにある場合には，提案手法は既存手法に比べてバグ限局の精度がほとんど変わらないことを確認した．

1. はじめにに基づいてバグ限局を行う．具体的には，各プログラム文
が失敗テストケース，及び成功テストケースで何回実行さソフトウェア開発において，デバッグは多大な労力とれたかという情報を用いて，そのプログラム文がバグの原コストを必要とする作業である．デバッグ作業がソフト

因箇所である可能性 (以下，疑惑値) を計算する．これまで

ウェア開発コストの過半数を占めるとの報告もある [4, 7]．

に多くの SBFL 手法が提案されている [5, 6, 9]．

NIST*1 は，米国においてソフトウェアのバグが原因となり，

しかし，SBFL はテストケースによる実行経路に基づき年間約 595 億円の損失が生じていると報告している [12]．

バグの原因箇所の推定を行うため，テストケースによってこのような状況から，デバッグを支援する研究が活発に行直接実行されるプログラム文のみが疑惑値の付与対象であわれている．

る．そのため，設定ファイル等にバグが含まれていた場合，デバッグ支援における研究のトピックとして自動バグ

SBFL では正しくバグ限局することができない．そこで本限局がある．自動バグ限局とは，なんらかの情報を用いる研究では，既存手法を拡張することで，ソースコード以外

ことにより，発生したバグの原因箇所を推定する技術でのファイルに対する疑惑値の計算を試みる．提案手法の評ある．これまで様々な自動バグ限局手法が提案されてい価実験として，2 つ企業のシステムと 2 つのオープンソー

る [8,10,11]．その中で近年最も盛んに研究されている手法

スソフトウェアに対して提案手法を適用した．その結果，のひとつとして，テストケースによる実行経路の情報を用い

3 つのバグについて提案手法は既存手法より正確にバグのて自動バグ限局を行う Spectrum-Based Fault Localization

原因箇所を推定することに成功した．また，既存手法と比（以降，SBFL と略す） がある [16]．SBFL は，失敗テスト

較して提案手法の実行時間は最大で 4.5%の増加であった．

ケースで実行されたプログラム文はバグの原因箇所である可能性が高く，成功テストケースで実行されたプログラム
文はバグの原因箇所である可能性が低い，というアイデア

2. 研究動機
本研究を行うに先立って，バグ修正においてどのようなファイルが変更されるのかを調査した．調査対象は，ある

12*1

大阪大学大学院情報科学研究科 大阪府吹田市
日本電信電話株式会社 東京都港区
National Institute of Standards and Technology, アメリカ国
立標準技術研究所

企業の 2 つのシステム開発プロジェクトにおける 1,245 のコミット，および 100 個のオープンソースソフトウェア*2

100%

ミットである．いずれのプロジェクトもソースコードはJava で記述されている．
それらのコミットから，まずバグ修正コミットを特定し，そして特定されたコミットにおいて変更されているファイルの拡張子を調査した．バグ修正コミットの特定は，企業システムと OSS では異なる方法で行った．
企業システム

企業から提供されたシステムのバグは，バJaaファイルのみが変更された
バグ修正コミットの割合（OSS）（以降，OSS）開発プロジェクトにおける約 830,000 のコ
80%

60%

40%

20%

グ票によって管理されていた．そこで，バグ票に記載0%されたバグ ID と紐づけられているコミットをバグ修

1

10

正コミットとみなした．

OSS コミットメッセージに “fix” もしくは “repair” を含むコミットをバグ修正コミットとみなした．

100

1000

10000

100000

バグ修正コミット数

図 1 各 OSS プロジェクトにおいて，Java ファイルのみが変更されたバグ修正コミットの割合

企業システムでは，合計で 91 個（79 個＋ 12 個）のバグ
修正コミットが存在しており，そのうちの 46 個（39 個＋7 個）が Java ファイルのみを修正しているバグであった．

PORT_NUMBER = 4000
HOST_NAME = local host

OSS については結果を図 1 に示す．この図より，プロジェ

図 2

クトに存在するバグ修正コミット数の多寡に関わらず，Java
ファイル以外のファイルが修正されているバグ修正コミッ
トが存在していることがわかる．これら 100 の OSS において，バグ修正コミットに占める Java ファイルのみが修正されたコミットの割合の中央値は 62.1%であった．これ
ら以外のコミットにおいて修正されたバグについては，既存手法ではバグの原因箇所に疑惑値を付与できない．そのため，既存手法を利用したバグ限局では不十分な場合がある．例えば，図 7 のように，メソッドの引数で与えられた変数の値に応じて読み込むプロパティファイルのキーが異なる場合は，ソースコードのキーを読み込む箇所（図 7 の6 行目）を見ても，どのキーを読み込んでいるかわからな
いためソースコードのみを対象としたバグ限局では不十分である．
次に，バグ修正コミットで修正された Java ファイル以外のファイルについて，どの種類のファイルが修正されているかを調査した．企業システムでは，最も変更されたファ
イルはプロパティファイルであり，バグ修正コミットで 26
回変更されていた*3 ．二番目に多く変更されたファイルはXML ファイルであり，その回数は 10 回であった．

プロパティファイルの一例

正コミットにおいて修正したプロジェクト数を表す．第三カラムは，その拡張子のファイルがバグ修正コミットにおいて変更された回数の 100 プロジェクトにおける合計値を表す．また，括弧内の数字は，Java ファイル以外の全てのファイルがバグ修正コミットで変更された回数のうち，その拡張子のファイルが変更された割合を示す．例えば，

xml ファイルは 90 の OSS プロジェクトにおいてバグ修正
コミットで変更されており，それらの変更回数の合計値は34,923 回である．そしてこの変更回数は，Java 以外の全ファイルの変更回数のうち，12.39%を占める．
本研究では，SBFL 手法のソースコード以外への拡張の第一歩として，企業システムで最も多く変更されていたプ
ロパティファイルを対象とする．プロパティファイルはプ
ログラムの設定ファイルとして用いられることが多い．プ
ロパティファイルの例を図 2 に示す．プロパティファイル
は，各行が key = value の形式で記述され，その構造は単表 1OSS におけるバグ修正コミットで変更されたファイル（プロジェクト数が多い上位 10 種類のみ）

表 1 は，100 の OSS プロジェクトに対する調査結果を表

拡張子

プロジェクト数

総変更回数（割合）す．約 700 種類のファイルがバグ修正コミットにおいて変

xml

90

34,923 (12.39%)

更されていた．スペースの都合上，表 1 はバグ修正コミッ

拡張子無し

87

22,771 (8.08%)

トにおいて変更したプロジェクト数が上位 10 件となって

md

80

8,688 (3.08%)

properties

71

8,674 (3.08%)

gradle65

4,740 (1.68%)

gitignore

56

515 (0.18%)

png

52

23,701 (8.41%)

yml

51

1,963 (0.70%)

html

44

44,179 (15.67%)

txt

44

14,715 (5.22%)

いるファイルの拡張子のみを示している．この表において，第二カラムはその拡張子のファイルを一度でもバグ修*2*3

GitHub で “Java” のラベルがついたプロジェクトのうち，ス
ター数が上位 100 件のプロジェクトが対象．
各バグ修正コミットにおいて変更されたファイル数をカウント
し，全てのバグ修正コミットにおける変更回数をその合計値として算出した．

純である．

totalF ail: 失敗テストケースの総数
f ail(k): キー k を読み込む失敗テストケースの数

3. プログラムの実行経路情報を利用した
自動バグ限局

pass(k): キー k を読み込む成功テストケースの数

バグの原因箇所を自動的に特定する自動バグ限局手法が4.1 実装研究されており，その中の一手法としてプログラムの実行

提案手法の実装は以下の 4 つの要素に分けられる．

経路情報を利用したバグ限局手法*4 がある [16]．SBFL 手• ライブラリの拡張法を利用するためにはテストケースが必要である．テスト• ソースコードの加工

ケースを利用して，対象プログラムを実行し実行経路情報• テストスイートの実行を収集する．プログラムの実行経路情報とは各テストケー• 疑惑値の計算スにおいて対象プログラムの各文が実行されたか否かを表以降ではそれぞれの実装方法を述べる．

す情報である．実行経路情報と各テストケースの成否情報を利用し，対象プログラムの各文に対してバグの原因箇所

ライブラリの拡張

Java で は ，プ ロ パ テ ィ フ ァ イ ル の 読 み 込 み に は ，である可能性を表す数値*5 を付与する．SBFL 手法の基本的な考え方は，失敗テストケースで実行されたプログラム
文はバグが存在する可能性が高く，成功テストケースで実行されたプログラム文は正しい可能性が高い，である．

Ochiai と呼ばれている疑惑値の計算方法がある [3]．
式 (1) は Ochiai の計算式を表す．なお，s は疑惑値の計算

ス*7 が利用されることが多い．しかし，これらのライブ
ラリにはテスト実行時にどのキーが何回読み込まれたか記録する機能はない．そこで，これらのライブラリクラスを継承したクラスを作成し，そのクラスで各キーの読み込み回数を記録する機能を実装した．

対象の文である．

suspicious(s) = √Properties ク ラ ス*6 ，も し く は ResourceBundle ク ラ

f ail(s)totalF ail ∗ (f ail(s) + pass(s))(1)

ソースコードの加工
各プログラム文の実行回数や，各キーの読み込み回数を

式中の変数の意味を以下に示す．
totalF ail: 失敗テストケースの総数計測するために，対象プロジェクトへコードの埋め込みを

f ail(s): 文 s を実行する失敗テストケースの数

トにコードを手動で埋め込むのは現実的ではない．提案手

pass(s): 文 s を実行する成功テストケースの数
Ochiai は SBFL 手法の他の計算式よりもバグ限局の性能法では，対象プロジェクトの抽象構文木を構築し，その抽が優れていることが示されている [1, 2]．本研究でもバグ
限局に Ochiai を用いる．

行う．しかし，提案手法を適用するたびに対象プロジェク

象構文木に対して自動で加工を行う．加工は以下の 2 つの種類がある．

( 1 ) 各プログラム文の後に，その文が実行されたことを記録するプログラム文を追加する．

4. 提案手法( 2 ) プロパティファイルを読み込むライブラリのインスタ本研究では，既存の自動バグ限局手法を拡張し，プロパ

ンスを，本手法で拡張したクラスのインスタンスに換

ティファイルの各キーに対しても疑惑値の計算を行う手法

える．

を提案する．提案手法の入力は Java プロジェクトとテス
トケースである．提案手法の出力は，対象プロジェクトに

テストケースの実行
プロパティファイルの読み込みはプログラムの処理中に含まれる各プログラム文およびプロパティファイルに含まれる各キーに対する疑惑値である．

行われることもあるが，フィールド変数の初期化として読提案手法は，SBFL の疑惑値を計算する式を Java ソー

み込まれることもある．静的なフィールド変数*8 に対して

スコードとプロパティファイルに適用することで，それらプロパティファイルの読み込みが行われた場合，その処理のどこにバグの原因箇所があるのかを推測する．疑惑値のは全てのテストケースの実行前に一度だけ行われる．しか計算には Ochiai [3] の計算式を用いた．プロパティファイ

し，それでは静的なフィールドの初期化で読み込まれた

ルのキー k の疑惑値 suspicious(k) を計算する際，以下にキーの疑惑値が正しく計算されない．そこで，提案手法で示すように Ochiai の計算式を応用した．

は各テストメソッドを個別に実行する．このように変更すf ail(k)ることで，各テストケースの実行前に静的なフィールド変

totalF ail ∗ (f ail(k) + pass(k))

数に対してプロパティファイルの読み込みが行われるた

suspicious(k) = √

式中の変数の意味を以下に示す．
*4*5Spetrum-Based Fault Localization．以降，SBFL 手法と呼ぶ．
以降，疑惑値と呼ぶ．疑惑値は一般的に 0∼1 の値をとる．

*6
*7
*8

java.lang.Properties
java.util.ResourceBundle
static キーワードが付与されたフィールド変数

め，キーの疑惑値を計算できる．

のソースコード行数およびプロパティファイル行数を表している．単体テストのテストケースを利用してバグを限局

疑惑値の計算提案手法では 2 つの方法で疑惑値の計算を行う．1 つ目は，プログラムの各プログラム文に対する疑惑値の計算である．プログラムの各行に対する疑惑値の計算には，SBFLするため，各バグで限局対象となるソースコード行数やプ
ロパティファイル行数が異なる．なお，全てのバグは，プロパティファイルもしくは Java ソースファイルの単一行の変更で修正可能であり，その行をバグの原因箇所とした．

の 1 つ，Ochiai の計算式を用いた．2 つ目は，プロパティ
ファイルの各キーに対する疑惑値の計算である．プロパ
ティファイルの各キーに対する疑惑値の計算には本章の冒頭で述べた，Ochiai の計算式を変更した計算式を用いた．

5. 実験

5.2 手順実験は以下の手順で行った．

( 1 ) バグ修正コミットの 1 つ前のコミットをチェックアウ
トする．

( 2 ) そのコミットでテストケースを実行する．
本章では，提案手法を評価するために行った実験と，その結果について述べる．

( 3 ) バグが原因となる失敗テストケースが含まれない場合，
著者らがそのような失敗テストケースを作成する．

( 4 ) 対象プロジェクトに対して，提案手法と既存手法を実5.1 準備
実験対象とするバグの収集を行った．この実験では，2 つの企業システムのバグと，2 つの OSS（Apache Commons

Math と Closure Compiler) から，対象となるバグを収集し行する．
手順 (1) でバグ修正コミットの 1 つ前のコミットをチェッ
クアウトしたのは，バグを含んだ状態を用意するためである．企業のシステムのバグについて，手順 (3) で作成した

た．企業システムのバグは，2 章で特定したバグ修正コミッ

テストケースは，企業の開発者にそのテストケースの正しトから，対象バグを収集した．Apache Commons Math とさを確認して頂いた．

Closure Compiler は，数多くの研究で利用されているバグのデータセット Defects4J*9 のバグ収集対象であるプロジェクトである．本研究では，プロパティファイルに含ま評価指標として，2 つの指標を用いた．1 つ目は，バグの存在する箇所の疑惑値の順位である．より高い順位にバ
グ原因箇所が順位付けされている手法が，よりバグ限局のれているバグを実験対象とするため，Defects4J に含まれ精度が高いと評価する．既存手法では プロパティファイているバグそのものは利用できないが，Defects4J のバグ

ルのキーに含まれるバグは見つけることができない．その収集対象になっている OSS プロジェクトはテストケース

ため，既存手法の評価では，バグの原因であるプロパティを多く含むプロジェクトであるため，これらのプロジェク
トを利用した．
以下の条件を満たすバグが今回の実験対象である．

• そのバグが修正されたコミットが特定できる．
• Java ファイルおよびプロパティファイルのみが修正されている．

Apache Commons Math と Closure Compiler からのバ

ファイルのキーを読み込んでいる行をバグ原因箇所として評価を行った．この指標は，疑惑値の高いプログラム文から手作業により調べていった場合，バグ原因箇所を見つけるために調査しなければならないプログラム文の数およびキーの数を表している．そこで，複数のプログラム文やキーが同じ疑惑値を持つ場合，それらの順位は最も悪くなるように評価する．例えば，2 つのキーが 1 位に順位づけ

グ収集手順は以下の通りである．

( 1 ) コミットを解析し， “fix” もしくは “repair” がコミッ
トメッセージに含まれるコミットをバグ修正コミット

バグ ID

表 2 対象バグ
バグ箇所
Java 行数として収集した．

#1

プロパティ

5,848

3

#2

プロパティ

47

1

#3

プロパティ

47

1

#4

プロパティ

53

1

#5

プロパティ

1,845

707

( 3 ) 抽出したコミットについて，コミットメッセージおよ

#6

プロパティ

130

50

び修正内容を目視確認し，バグ修正であると著者らが

#7

プロパティ

73

7

判断できた場合に実験対象のバグとした．

#8

プロパティ

243

56

( 2 ) それらのコミットから，修正ファイルが Java ファイ
ルおよびプロパティファイルのみのコミットを抽出した．

表 2 は収集したバグの情報を表している．第二カラムはバグの原因箇所がプロパティファイルか Java ソースファイ
ルかを表している．第三および第四カラムはバグ限局対象*9https://github.com/rjust/defects4j

プロパティ行数

#9

Java

267

56

#10

Java

305

63

#11

Java

202

55

#12

Java

326

59

#13

Java

115

13

度疑惑値の算出に長い時間が必要となるのかを評価する．

130

100
90

50

この図では，Y 軸はバグ原因箇所がランキングの上位何%

に
存
在
し
た
か

40

に存在していたかを示している．棒の上にある数字は，そ

(%)

10

%

バ
グ
原
因
箇
所
が
上
位
何

80

5.3 結果

70

118
28 27

60

まず，バグ原因箇所の順位に関する結果を図 3 に示す．

28 27

16 15

30

れぞれ何位にバグ原因箇所が位置していたかを示してい

16

20
2 1

2 1

4

4 8

る．図 3(a) に含まれるバグは，プロパティファイルが原#7#8

因箇所であるバグである．実験の結果，3 件のバグ（#6，

0
#1

#2

#3

#4

#5

#6

バグID
提案手法

#7，#8）について，提案手法により順位が改善した．提既存手法

案手法によって最も順位が改善したもので，34%の改善が(a) 設定ファイルのバグに対する結果見られた．一方で，提案手法によって最も順位が悪化した

100

バグで，1.3%の悪化が見られた．しかし，この悪化は提案

80

手法がプロパティファイルの行数も加味して精度を計算し60ていることに依るものであり，実質的な悪化ではない．

40

%

バ
グ
原
因
箇
所
が
上
位
何
に
存
在
し
た
か

次に，バグ原因箇所が Java ファイルであるバグに対す

46 41

る実験の結果を図 3(b) に示す．図 3(b) より，いずれのバ

69 58

20
5

21 18

33 33

#11

#12

グについても，順位の大きな違いは見られなかった．#10

4

(%)

0
#9

#10

や#13 のバグでは若干ではあるが，提案手法は既存手法に

#13

バグID

比べてうまく限局できなかった．これは，プロパティファ

既存手法

イルを読み込む周辺の Java コードにバグがあったことに提案手法(b) Java ソースコードのバグに対する結果
図 3より，プロパティファイルにおいて読み込まれたキーにつ提案手法および既存手法を用いたバグ限局の結果．グラフのY 軸はバグ限局の精度（バグの原因箇所がバグ限局結果の上
位何％の位置に存在したのか）を表す．なお，既存手法では
限局対象は Java ソースコードのみなのに対して提案手法ではいても高い疑惑値が付与されてしまったことが原因である．
次に，実行時間についての結果を図 4 に示す．いずれの
バグについても，提案手法と既存手法で実行時間に大きなJava ソースコードおよびプロパティファイルであるため，バ差は見られなかった．提案手法による時間の増加が最も大グ限局の精度を出す際に利用する全体行数の値が異なる．つまきかったバグで，その増加量は約 8.5 秒であった．実行時

り既存手法では表 2 の第三カラムの値のみを用いるが，提案間が長くなっている割合は最大で約 4.5%，最小で 0.3%と手法は第三カラムと第四カラムの合計値を用いる．また，各棒少ない．つまり，プロパティファイルに対する疑惑値の付グラフの上の数値はバグ限局におけるバグの原因箇所の順位を表す．

与に必要な時間は全体の実行時間のうちの小さい割合であることがわかる．

6. 考察

2000
1900

(s)

実
行
時
間

600

本章では，提案手法により順位が改善したバグおよび順500

位が悪化したバグについて考察を述べる．なお，説明を簡400単化するため，実際のバグそのもの用いて考察するのでは

300

なく，実際のバグの特徴から作成した疑似バグを用いて説

200

明を行う．

100
0
#1

#2

#3

#4

#5

#6

#7

#8

バグID
提案手法平均

既存手法平均6.1 提案手法により順位が改善したバグ
提案手法により順位が改善した例を図 5 に示す．図 5 (a)のメソッドは，引数に言語の略称を取り，その言語に対応

図 4 提案手法および既存手法による実行時間

したファイルの中身を返すメソッドである．各言語に対応するファイルには，図 5 (b) に示したように，その言語にられていた場合，それらの順位は 2 位として評価する．

おける “私” を意味する単語が格納されている．この例に2 つ目の指標は実行時間である．既存手法と提案手法を，は，“char.properties” に含まれているキー，“CHARAC-

それぞれのバグに対し 5 回ずつ実行し，その実行時間の平TER CODE” が本来は “UTF-8” であるべきだが，“UTF-

均を比較した．これにより，提案手法の導入によりどの程char.properties
CHARACTER_CODE = UTF-81
ERROR_MESSAGE

テスト1
lang = ja
期待値
{私}

テスト2
lang = hoge
期待値
{I}

✔

✔

= error

テスト3
lang = null
期待値
{error}

疑惑値
1.0

✔

0.0

Localization.java
1: public List<String> localizedText(String lang) throws Exception {2:

List countries = Arrays.asList("en", "ja", "fr");

✔

✔

✔

0.8

3:

ResourceBundle bundle = ResourceBundle.getBundle("char");

✔

✔

✔

0.8

if(lang == null)

✔

✔

✔

0.8

✔

0.0

4:
5:
6:

return Arrays.asList(bundle.getString(“ERROR_MESSAGE”));

7:8:

if (countries.contains(lang)) {

✔

1.0

✔

9:

String cs = bundle.getString(“CHARCTER_CODE”);

✔

0.7

10:

Path path = Paths.get(“resource/localize_“ + lang + “.txt”); ✔

0.7

11:

return Files.readAllLines(path, Charset.forName(cs));

0.7

12:

✔

} else {13:

String cs = bundle.getString(“CHARCTER_CODE”);

✔

0.7

14:

Path path = Paths.get("resource/localize_en.txt");

✔

0.7

15:

return Files.readAllLines(path, Charset.forName(cs));

✔

0.7

16:
17:

}
}
返り値
Exception

返り値
Exception

返り値{error}

NG

NG

OK

(a) 対象のソースコード
localize_en.txt
1: I
localize_ja.txt
1: 私
localize_fr.txt
1: je(b) 入力ファイル
図 5 提案手法により順位が改善した例

81” になっている，というバグが含まれている．そのため，

6.2 提案手法により順位が悪化したバグ“CHARACTER CODE” を用いて，入力ファイルを読もう

提案手法により順位が悪化した例を図 6 に示す．図とするテスト 1 とテスト 2 が失敗している．テスト 1 では

6(a) のメソッドは，Path を引数に取り，そのパスのファ

9 行目で，テスト 2 では 13 行目で “CHARACTER CODE”

イルが存在する場合は，そのファイルの中身を返し，存が読み込まれている．

在しない場合は，空のリストを返すメソッドである．図式 (1) より，失敗テストケースのみで実行された行であっ6(a) のテスト 1 で読み込まれている，“in.txt” の中身を図ても，その行を実行しない失敗テストケースも存在してい6(b) に示す．この例も，6.1 と同様に，“char.properties”

ると疑惑値が低下することが分かる．そのため，“CHAR-の “CHARACTER CODE” がバグ原因箇所である．このACTER CODE” を読み込んでいる 9 行目および 13 行目

例では，“CHARACTER CODE” が読み込まれている行の疑惑値は，テスト 1 およびテスト 2 で実行される 8 行目

が，6 行目のみである．そのため，“CHARACTER CODE”

よりも低くなってしまう．その一方で，提案手法では，9が読み込まれる回数と，“CHARACTER CODE” の読み行目および 13 行目のどちらでも “CHARACTER CODE”

込み行の実行回数が一致する．したがって，“CHARAC-を読み込んでいるため，バグを含むキーが最も高い疑惑値

TER CODE” と，“CHARACTER CODE” の読み込み行となる．このように，バグの原因箇所となっているプロパが同じ疑惑値，順位になる．5.2 で述べたように，同一順

ティファイルのキーが複数箇所で読み込まれていた場合，位に複数順位付けされていた場合，その順位は最も悪くな提案手法により順位の改善が見られた．

るように評価する．そのため図 6 のような例では順位が悪テスト1
path = in.txt
期待値{Hello World}char.properties
CHARACTER_CODE = UTF-81

テスト2
lang = hoge
期待値
{}

疑惑値
1.0

✔

FileIO.properties
1:

public List<String> read(Path path) throws Exception {2:

ResourceBundle bundle = ResourceBundle.getBundle("char");3:

if (!Files.exists(path)) {

4:

✔

✔

0.7

✔

✔

0.7

✔

0.0

return Collections.EMPTY_LIST;

5:

}

6:

String cs = bundle.getString("CHARACTER_CODE");✔

1.0

return Files.readAllLines(path, Charset.forName(cs));

✔

1.0

7:
8:

}

返り値
Exception

返り値
{}

NG

OK

(a) 対象のソースコード
In.txt1: Hello World(b) 入力ファイル
図 6 提案手法により順位が悪化した例
テスト1
Country = USA
期待値{Hello}hello.properties

テスト2
country = foo
期待値
{}

疑惑値

FRENCH = Bonjour

0.0

ITALY

= Ciao0.0

USA= Hell1.0✔

Localize.java
1:

Public String localizedHello(String country) {2:

List countries = Arrays.asList("FRENCH", "ITALY", "USA");

✔

✔

0.7

3:

ResourceBundle bundle = ResourceBundle.getBundle("hello");

✔

✔

0.7

if(countries.contains(country))

✔

✔

0.7

4:
5:
6:

return bundle.getString(country);

7:

else

8:
9:

1.0

✔

return "";

✔

}

返り値
{Hell}

返り値
{}

NG

OK

0.0

図 7 提案手法が有用な例

化した．
しかし，順位が悪化したにも関わらず，提案手法が有用であると考えられる例もあった．その例を図 7 に示す．

字列をキーとしてプロパティファイルを読み込んでいるた
め，6 行目がバグ原因箇所と推定された場合でも，プロパ
ティファイルのどのキーの値がバグ原因箇所であるか開発

図 7 のメソッドは，引数に国名をとり，その国における者はわからない．提案手法では，“USA” というキーをバ“こんにちは” を意味する単語を返すメソッドである．こグ原因箇所として推定するため，開発者はバグ原因箇所がの例では，キー “USA” が本来は “Hello” であるべきとこどこであるか明確にわかる．このように， プロパティファ

ろが，“Hell” になっている，というバグが含まれている．

イルを読み込むキーが変数であった場合，提案手法により

キー “USA” は，6 行目だけで読み込まれている．そのた

順位が悪化しても，提案手法が有用であると考えられる．

め，前述の理由でキー “USA” と，6 行目の疑惑値，順位が一致している．しかし，6 行目は，引数で与えられた文6.3 実行時間

ストケースの追加を行って提案手法を適用した．そのた

図 4 で示したように，既存手法と比較して提案手法のめ，追加したテストケースは開発者がバグを発見したもの

時間の増加は十分に小さなものであった．提案手法の実行とは異なる．開発者の作成したテストケースを用いて実験時間をさらに短縮する方法ついて考察を行っていく．最もを行った場合，異なる結果が得られる可能性がある．

オーバーヘッドが大きかったバグ#3 を 5 回実行して，提案手法の各工程が占める実行時間を調査した．表 3 にその結果を示す．

7.2 プロパティファイルのバグに対する既存手法のバグ
限局の扱い

表 3 より，提案手法の実行時間の 85%はビルドとテスト

本実験では，プロパティファイルのバグについては，既によって占められていることが分かる．また，今回の提案

存手法はプロパティファイルのキーを読み込んでいる箇所

手法で追加された工程である，ソースコードの加工と，プをバグの原因箇所として評価を行った．しかし，図 7 の 6

ロパティファイルのバグ限局は合計で 6%であった．よっ

行目のように，読み込むキーが動的に決まる場合は，ソーて，今後提案手法の実行時間を短くするためには，提案手スコードにおいてプロパティファイルのキーを読み込んで法で追加された工程ではなく，ビルドとテストの短縮のいる箇所をバグの原因箇所として扱うのは不十分である．

方が効果的であると考えられる．テスト実行時間の短縮

しかし，プロパティファイルの全てキーをバグを検出する方法として，バイトコードの最適化が挙げられる．バイト

ために調査必要な行として計上するのは，提案手法に有利

コードの最適化の研究として Raja による SOOT [15] や，に働きすぎる場合があると著者らは考えたため，このようPominville によるもの [13] がある．こういったツールをな評価を行った．

用いてバイトコードの最適化を行うことで，提案手法のテ
スト実行時間を短縮できると考えられる．

7.3 テストケースの実行
4.1 節で述べたように，提案手法では各テストケースは6.4 関連研究

個別に実行される．そのため，従来は全てのテストケース

Zhang らはソフトウェアの進化に伴い変更すべき設定の実行前に一度だけ実行されていた静的なフィールド変数

ファイルのキーを自動的に特定する手法を提案していの初期化が，提案手法では各テストケースの実行時に行わる [17]．この手法では，新旧のソフトウェアの実行経路をれることになる．よって，テストケースが非常に多い場合比較することにより，その経路に影響を与えているプロパ

や，静的なフィールド変数の初期化が時間を要する処理をティファイルのキーを特定している．また，Rabkin らも，伴う場合は，提案手法を適用するにあたり長い時間を必要

バグの原因となっている設定ファイルのキーを自動的に特とする場合もありうる．

定する手法を提案している [14]. Zhang らの手法が制御フ
ロー解析を利用しているのに対して，Rabkin らの手法は7.4 実験対象

データフロー解析を利用している．これら手法は，プロパ

本研究では，提案手法を 2 件の企業のシステムと 2 件のティファイルの設定が間違っているがどのキーが間違ってオープンソースソフトウェアに対して適用した．他の企業

いるかわからない状態で利用する手法であるのに対して，のシステムや，オープンソースソフトウェアに対して適用提案手法はソースコードやプロパティファイルのどこにバした場合，異なる結果が得られる可能性がある．

グがあるのかわからない状態でも利用できる．

7. 妥当性の脅威

8. おわりに本研究では，自動バグ限局の既存手法をプロパティファ

7.1 追加したテストケース

イルまで拡張した手法を提案した．提案手法では，対象プ

本研究では，提案手法を 2 件の企業のシステムと 2 件

ログラムとそのテストスイートを入力として与えることのオープンソースソフトウェアに対して適用した．その際で，ソースコードの各行とプロパティファイルの各キーへに，バグを原因として失敗テストケースが存在しないバグ

疑惑値を計算する．

があった．そういったバグに対して，バグによって失敗テ

提案手法を，企業のシステムのバグとオープンソースソ
フトウェアのバグに対して適用し，既存手法と比較した．

表 3 実行時間の内訳
処理内容

割合

ビルド

53%

見られた．また，順位が改善しなかったバグでも，実用上

テスト実行

32%

提案手法の方が優れていると考えられるバグも存在した．

ソースコードのバグ限局

9%

実行時間は，最大 4.5%の増加であったが，増加した時間はソースコードの加工

5%

十分に小さなものであった．

プロパティファイルのバグ限局

1%

その結果，3 件のバグについて既存手法より順位の改善が今後の取り組みとして，対象とするファイルの種類を増やしていくことが挙げられる．次の目標としては，最も多くのリポジトリで修正されていた XML ファイルが挙げら

[16]

れる．
参考文献
[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

Abreu, R., Zoeteweij, P., Golsteijn, R. and
Van Gemund, A. J.: A practical evaluation ofspectrum-based fault localization, Journal of Systems
and Software, Vol. 82, No. 11, pp. 1780–1792 (2009).
Abreu, R., Zoeteweij, P. and Van Gemund, A. J.: An
evaluation of similarity coeﬃcients for software fault
localization, Proceedings of Pacific Rim International
Symposium on Dependable Computing (PRDC), IEEE,
pp. 39–46 (2006).
Abreu, R., Zoeteweij, P. and Van Gemund, A. J.: On
the accuracy of spectrum-based fault localization, Proceedings of Testing: Academic and Industrial Conference Practice and Research Techniques (TAIC PART),
IEEE, pp. 89–98 (2007).
Britton, T., Jeng, L., Carver, G. and Cheak, P.: Reversible Debugging Software Quantify the time andcost saved using reversible debuggers (2013).
Chen, M. Y., Kiciman, E., Fratkin, E., Fox, A. andBrewer, E.: Pinpoint: Problem determination in large,
dynamic internet services, Proceedings of the International Conference on Dependable Systems and Networks (DSN), IEEE, pp. 595–604 (2002).
Dallmeier, V., Lindig, C. and Zeller, A.: Lightweightdefect localization for java, Proceedings of European
Conference on Object-Oriented Programming (Ecoop),
Springer, pp. 528–550 (2005).
Hailpern, B. and Santhanam, P.: Software debugging,testing, and verification, IBM Systems Journal, Vol. 41,
No. 1, pp. 4–12 (2002).
Jin, W. and Orso, A.: F3: fault localization for field
failures, Proceedings of the International Symposium on
Software Testing and Analysis (ISSTA) (2013).
Jones, J. A., Harrold, M. J. and Stasko, J.: Visualization of test information to assist fault localization,
Proceedings of the International Conference on Software engineering (ICSE), ACM, pp. 467–477 (2002).
Korel, B.: PELAS-Program Error-Locating AssistantSystem, IEEE Transactions on Software Engineering(TSE), Vol. 14, pp. 1253–1260 (1988).
Liu, C., Yan, X., Fei, L., Han, J. and Midkiﬀ, S. P.:
SOBER: statistical model-based bug localization, ACM
SIGSOFT Software Engineering Notes, Vol. 30, No. 5,
ACM, pp. 286–295 (2005).
NIST: Software Errors Cost U.S. Economy $59.5 Billion Annually, http://www.abeacha.com/NIST_press_
release_bugs_cost.htm.
Pominville, P., Qian, F., Vallée-Rai, R., Hendren, L.
and Verbrugge, C.: A framework for optimizing Java
using attributes, Proceedings of Conference of the Centre for Advanced Studies on Collaborative Research(CASCON), IBM Press, p. 8 (2000).
Rabkin, A. and Katz, R.: Precomputing Possible Configuration Error Diagnoses, Proceedings of the 2011
26th IEEE/ACM International Conference on Automated Software Engineering, pp. 193–202 (2011).
Vallée-Rai, R., Co, P., Gagnon, E., Hendren, L., Lam,
P. and Sundaresan, V.: Soot: A Java bytecode opti-[17]

mization framework, Proceedings of Conference of theCentre for Advanced Studies on Collaborative Research(CASCON), IBM Corp., pp. 214–224 (2010).
Wong, W. E., Gao, R., Li, Y., Abreu, R. and Wotawa,
F.: A survey on software fault localization, IEEE
Transactions on Software Engineering (TSE), Vol. 42,
No. 8, pp. 707–740 (2016).
Zhang, S. and Ernst, M. D.: Which Configuration Option Should I Change?, Proceedings of the 36th International Conference on Software Engineering, pp. 152–
163 (2014).