欠陥限局および自動プログラム修正のための
自動テスト生成と実行経路を用いたテスト選択
入山 優1,a)

肥後 芳樹1,b)

楠本 真二1,c)

概要：デバッグ作業の負担を軽減することを目的として，欠陥限局に関する研究が盛んに行われている．
欠陥限局とはプログラム中の欠陥箇所を特定する技術である．Spectrum-Based Fault Localization（以下 SBFL）は欠陥限局の手法の 1 つで，各テストケースの成否と実行経路をもとに欠陥箇所を特定する．
SBFL の精度はテストケースの品質に影響され，テストケースを追加することで SBFL の精度は向上する．
しかし，SBFL は自動プログラム修正にも利用されるため，無作為にテストケースを追加するとバグ修正に時間がかかったり時間切れにより修正できなかったりする可能性がある．そのため SBFL に役立つテス
トケースのみを利用するべきである．本研究では，既存のテストケースと自動生成されたテストケースから実行経路が重複しないようにテストケースを選択することで，テストの実行時間の増加を抑えつつ，欠陥限局の精度を向上させる手法を提案する．実バグのデータセット Defects4J を対象に実験を行い，提案手法により選択されたテストケースを用いることで，56.8%の欠陥において精度が向上することを確認した．テストの実行時間の増加は中央値で最大でも 7.0 秒の増加に抑えられ，既存のテストケースと自動生成されたテストケースを全て用いた場合と比べて 4.9 秒短縮できた．また提案手法により選択されたテス
トケースを用いることで，既存のテストケースと自動生成されたテストケースを全て用いた場合と比べて，より多くのバグにおいてパッチを生成できることを確認した．

1. はじめにソフトウェア開発において，デバッグは負担の大きい作業である．ソフトウェア開発に必要コストのうち，半分以報を用いて欠陥限局を行っているため，SBFL の精度は入力として与えられるテストケースの影響を受ける．そのた
め SBFL の精度を向上させることを目的としてテストケースの最適化に関する研究が行われている [6], [7], [8]．

上をデバッグ作業が占めているという報告もある [1], [2]．

また SBFL の精度は自動プログラム修正の精度にも影響

そのためデバッグの負担を軽減するための研究が盛んに行する [9]．自動プログラム修正とはバグを含むプログラム

われている．

とテストケースを受け取ると自動的にバグを修正する技術

デバッグの作業の負担を軽減する技術の 1 つとして欠陥である．自動プログラム修正では欠陥限局の結果をもとに限局という技術がある．欠陥限局とはプログラム中の欠陥プログラムの修正箇所を決定するため，高い精度で欠陥を箇所を特定する技術である．欠陥限局の手法は様々で，こ特定することは重要である．

れまでに多くの手法が提案されている [3], [4], [5]．その 1

既存のテストケースに自動生成されたテストケースを追つに Spectrum-Based Fault Localization（SBFL）という加することで SBFL の精度は向上するが，テストの実行時手法がある．SBFL は各テストケースの成否と実行経路を間は増加してしまう．自動プログラム修正では，プログラ

もとに欠陥箇所を特定する．失敗したテストケースで実行

ムが生成されるたびに欠陥が修正されたかをテスト実行にされた文は欠陥箇所の可能性が高く，成功したテストケーより検証する．テストの実行時間が必要以上に増加してしスで実行された文は欠陥箇所の可能性が低いというアイデ

まうと，自動プログラム修正においてバグを修正するまで

アに基づいている．SBFL はテスト実行により得られる情に時間がかかったり，時間切れのために修正できなかった
りする．そのため SBFL の精度を向上させるテストのみを

1

a)
b)
c)

大阪大学大学院情報科学研究科
Graduate School of Information Science and Technology, Osaka University
m-iriyam@ist.osaka-u.ac.jp
higo@ist.osaka-u.ac.jp
kusumoto@ist.osaka-u.ac.jp

利用すべきである [10]．
図 1 はテストケースの選択により SBFL の精度が向上する例である．図 1 に示されるプログラムは 6 行目が欠陥箇所である．この行は return b; となっているが，正しくテストケース
疑惑値
t1 t2 t3 a1 a2 {t1,t2,t3} {t1,t2} {t1,t2,a1} {t1,t2,a2}✓ ✕ ✓ ✓ ✓1 public class Util {2
float max(float a, float b){
3
if (Float.isNaN(a))
4return b;
5else if(Float.isNaN(b))
6return b; //return a;7else
8
return Math.max(a, b);
9
}
...
17
float min(float a, float b)
18
...
19
}
20 }
図 1

●
●

●
●
●

●
●

●

●
●

●

0.58

0.71

0.58

0.58

1.00
1.00

1.00
1.00

0.71
1.00

1.00
1.00

●

●

テストケースの選択により SBFL の精度が向上する例

は return a; である．t1，t2，t3 は既存のテストケース

に関する実行経路が重複しないようにテストケースを選択

であり，a1 と a2 は自動生成されたテストケースである．

する．実バグのデータセット Defects4J を対象に実験を行

既存のテストケースを全て用いた場合，疑惑値が最も高く

い，提案手法により選択されたテストケースを用いることなる文は 5 行目と 6 行目である．t1 と t2 のみを用いた場

で，56.8%の欠陥において精度が向上することを確認した．

合も同様に 5 行目と 6 行目の疑惑値が最も高くなる．t3

テストの実行時間の増加は中央値で最大でも 7.0 秒の増加を利用しなくても欠陥箇所の疑惑値の順位は変わらないのに抑えられ，既存のテストケースと自動生成されたテストで，t3 は SBFL の精度には影響しないテストケースであケースを全て用いた場合と比べて 4.9 秒短縮できた．またる．t3 のようなテストケースを選択すると不必要に実行提案手法により選択されたテストケースを用いることで，時間が増加してしまう．既存のテストケースである t1 と既存のテストケースと自動生成されたテストケースを全て

t2 に加えて自動生成されたテストケースである a1 を用い用いた場合と比べて，より多くのバグにおいてパッチを生た場合，疑惑値が最も高くなる文は 6 行目のみである．欠成できることを確認した．

陥箇所を 1 つに絞り込むことができているので，既存のテストケースだけを用いるよりも SBFL の精度は向上してい2. Spectrum-Based Fault Localization

る．一方で t1，t2，a2 を用いた場合，既存のテストケー

欠陥限局とはプログラム中の欠陥箇所を推測する技術

ス全てを用いた場合と同じ結果になる．t3 と a2 の実行経である．欠陥限局の手法の 1 つに，Spectrum-Based Fault

路は異なっているが，失敗テストの t2 で実行される max

Localization（SBFL）という手法がある．この手法では，メソッドに関する実行経路のみに注目すると t3 と a2 の実欠陥を含むプログラムとテストケースを受け取ると各テス

行経路は同じである．失敗テストで実行されるメソッドにトケースの成否と実行経路を収集し，その情報をもとに疑関する実行経路は疑惑値に影響を与えるが，失敗テストで惑値を算出する．疑惑値とは欠陥箇所の可能性の高さを表

実行されないメソッドに関する実行経路は疑惑値に影響をす数値である．疑惑値の計算手法には様々な種類がある．

与えないため，t1，t2，t3 を用いた場合と t1，t2，a2 をAbreu らは，7 つの疑惑値の計算手法を比較し，Ochiai[11]用いた場合の結果が同じになったと考えられる．a2 のよが優れた手法であると結論付けている [12]．そのため，本

うなテストを選択しても SBFL の精度には影響を与えず，研究では疑惑値の算出に Ochiai を利用する．Ochiai の計

不必要に実行時間が増加してしまう．

算式は以下の式で表される．

本研究では，既存のテストケースと自動生成されたテス
トケースから実行経路が重複しないテストケースを選択することで，テストの実行時間の増加を抑えつつ，欠陥限局の精度を向上させる．失敗テストの選択では，既に選択されたテストケースと異なる実行経路のテストケースのみを選択する．成功テストの選択では，選択するテストケースの数を少なくするために失敗テストで実行されるメソッド

susp(s) = √f ail(s)totalf ails × (f ails(s) + pass(s))

式中の各変数は以下の意味を表す．

s: 疑惑値計算対象のプログラム文
susp(s): s の疑惑値
f ail(s): s を実行した失敗テストの数
pass(s): s を実行した成功テストの数(1)

Step 1
テストケースの⽣成✓✕✕✓✓✓

Step 2実⾏経路の収集

Step 3
テストケースの選択

⾏番号
⽋陥を含む
プログラム

t1

t2

t3

a1

a2

✓

✕

✓

✓

✓

3

●

●

●

●

●

4

●

⽣成された
テストケース

●

✓✕✓
✕✓✓

●

選択された
テストケース

●

5

●

6

●

●

7
8
18

✓✓✕
✓✓✓

●

全テストケースの成否と実⾏経路

テストケース
図 2

提案手法の概要

3. 提案手法( 2 ) テストケースの入力値と期待値の両方を自動生成する
本研究では，テストケースの生成に必要なコストを削減

本研究では，テストの実行時間の増加を抑えつつ，SBFLするために 2 つ目の手法を用いた．この手法では正しい期の精度を向上させることを目的として，既存のテストケー

待値を生成するために，テストケース自動生成ツールにバスと自動生成されたテストケースから実行経路が重複しな

グを含まないプログラムを入力する必要がある．そのため

いようにテストケースを選択する手法を提案する．既に選バグが発生する直前のリビジョンのプログラムをテスト

択されたテストケースと同じ実行経路のテストケースを追

ケース自動生成ツールの入力として与えた．

加しても，新しい情報を得ることができない．それに対し

また全クラスのテストケースを生成するのではなく，既て既に選択されたテストケースと異なる実行経路のテスト

存の失敗テストで実行されるクラスのテストケースのみを

ケースを追加することで，各文の疑惑値を詳細に計算する生成するようにした．これらのクラスはバグを含む可能性ことができる．そのため実行経路が重複しないようにテスがあるためである．

トケースを選択することで，テストスイートの肥大化を防ぎつつ，SBFL の精度を向上させることができると考えられる．提案手法の概要を図 2 に示す．提案手法は以下の 3

3.2 Step 2: 実行経路の収集
欠陥を含むプログラムに対して，既存のテストケースとつのステップで構成されている．

自動生成されたテストケースを実行し，全テストケースの

Step 1 テストケースの生成成否と実行経路を収集する．

Step 2 実行経路の収集
Step 3 テストケースの選択
以降，各ステップについて説明する．

3.3 Step 3: テストケースの選択
既存のテストケースと自動生成されたテストケースから実行経路が重複しないように以下の手順に従ってテスト

3.1 Step 1: テストケースの生成
テストケースの生成に必要なコストを削減するために，ケースを選択する．

( 1 ) 既存の失敗テストと自動生成された失敗テストに対しテストケース自動生成ツールを用いる．テストケース自動て，以下の処理を行う．

生成ツールによるテストケースの生成は以下の 2 つの方法

( a ) 1 つ目の失敗テストであれば選択が考えられる．

( b ) 2 つ目以降の失敗テストについて，既に選択された( 1 ) テストケースの入力値のみを自動生成し，期待値を手動で入力する全ての失敗テストと実行経路が異なる場合は選択( 2 ) 既存の成功テストと自動生成された成功テストに対し

1 public class Util {2
float max(float a, float b){
3
if (Float.isNaN(a))
4return b;
5else if(Float.isNaN(b))
6return b; //return a;7else
8
return Math.max(a, b);
9}10float max(float[] array){
11
...
12
float max = array[0];13for(int j = 1; j < array.length; j++)14
max = max(array[j], max);
15
return max;
16}
17
float min(float a, float b)
18
...
19
}
20 }
選択するか否か（選択する=T，選択しない=F）
図 3

t1
✓

t2
✕

●
●

●

テストケース
疑惑値
t3 a1 a2 a3 a4 {t1,t2,t3} {t1,t2,a1,a3} {t1,t2,t3,a1,a2,a3,a4}✓ ✓ ✓ ✕ ✕

●
●

●
●

●

●
●

●

●

●

0.58

0.71

0.65

●
●

●
●

1.00
1.00

0.82
1.00

0.87
1.00

0.71
0.71
0.71
0.71
0.71

0.58
0.58
0.58
0.58
0.58

●

●
●
●
●
●

●

T

T

F

T

F

T

F

テストケースの選択例て，以下の処理を行う．

れの場合でも疑惑値が最大となる文は欠陥箇所の 6 行目で( a ) 既に選択された全てのテストと実行経路を比較し，ある．

失敗テストで実行されるメソッドに関する実行経路が異なる場合は選択
既に選択された全ての失敗テストと異なる実行経路の失4. Research Question
提案手法を評価するために，以下の 2 つの Research

敗テストは新しい情報を持っているため選択する．失敗テ

Question（以下 RQ）を設定した．

ストで実行されないメソッドに関する実行経路は疑惑値にRQ1 提案手法が SBFL にどのような影響があるのか影響しない．それに対して失敗テストで実行されるメソッ

RQ2 提案手法が自動プログラム修正にどのような影響がドに関する実行経路は疑惑値に影響する．選択するテスト

あるのか

ケースの数を少なくするために，成功テストの選択では疑惑値に影響のある実行経路のみを比較する．

RQ1 では，SBFL の精度やテストケースの数，テストの実行時間への影響を調査する．提案手法により選択された

図 3 はテストケース選択の例である．t1，t2，t3 は既テストケースを用いることでテストの実行時間の増加を抑存のテストケースであり，a1，a2，a3，a4 は自動生成さえつつ，SBFL の精度を向上させることができるかを確認れたテストケースである．a4 は失敗テストであり，t2 とする．

同じ実行経路なので a4 は選択されない．t3 は成功テスト

RQ2 では，提案手法により選択されたテストケースを用であり，t1 と同じ実行経路なので t3 は選択されない．a2

いることで，既存のテストケースと自動生成されたテスト

は成功テストであり，同じ実行経路のテストケースは存在

ケースを全て用いるよりも多くのバグにおいてパッチを生しない．しかし，失敗テストで実行される 2 行目から 16成できるかどうかを確認する．

行目に注目すると，a2 は t1 と同じ実行経路なので a2 は選択されない．そのため図 3 の例において，提案手法により選択されるテストケースは t1，t2，a1，a3 である．既存のテストケースだけを用いた場合，疑惑値が最大となる箇所は 5 行目と 6 行目だが，提案手法により選択されたテストケースを用いた場合，疑惑値が最大となる箇所は 6 行
目のみである．提案手法により選択されたテストケースを

4.1 実験 1
実験 1 では，RQ1 の SBFL への影響について調査する．

5. 評価実験
提案手法の評価実験として，2 つの実験を行った．以下
では各実験について説明する．

用いることで欠陥箇所を 1 つに絞り込むことができている
ので，既存のテストケースだけを用いるよりも SBFL の精

5.1 実験対象度は向上している．提案手法により選択されたテストケー

本実験では，実バグのデータセットである Defects4J[13]スを用いた場合と既存のテストケースと自動生成されたテに含まれるプロジェクトのうち表 1 に示すプロジェクトをストケースを全て用いた場合で疑惑値に差があるが，いず

実験対象とした．Defets4J には表 1 以外のプロジェクトも

Codec

Csv

8.0%

Exam

6.0%

Lang

15.0%

1.5%

10.0%

1.0%

Math
4.0%
3.0%

4.0%

2.0%

2.0%
0.0%

5.0%

0.5%

0.0%

0.0%

Torig
Tslct
Tall
Toriginal
Tselect
Tall

Torig
Tslct
Tall
Toriginal
TselectTall
図 4

含まれているが，著者らの環境では Java のバージョンの

1.0%
0.0%
Torig
Tslct
Tall
Toriginal
Tselect
Tall

Torig
Tslct
Tall
Toriginal
Tselect
Tall

EXAM

5.1.2 EXAM の比較違いなどによって正しく動作しなかった．そのため，本研
Codec
Csv

Toriginal ，Tselect ，Tall それぞれ用いた場合のLangMath EXAM に

究では表 1 のプロジェクトを実験対象とした．著者らの環

対する箱ひげ図を図 4 に示す．縦軸は EXAM を表してい

境では正しく動作しなかったバグは除外した．失敗テスト

る．Toriginal と Tselect の中央値を比較すると，全てのプロで実行されない欠陥箇所は疑惑値が算出されない．そのよ150

ジェクトにおいて Tselect の EXAM は Toriginal の EXAM

うな欠陥箇所は除外した．

より小さいことが確認できる．また Tselect と Tall の中央

テストケースの数

300

200

200

100

5.1.1 実験設定
10050
提案手法ではテストケース自動生成ツールとして
Evo-

1,500

1,500
1,000

1,000

値を比較すると，Codec と Csv において Tselect の EXAM

500

500

は Tall の EXAM より小さくなった．

Toriginal ，Tselect それぞれ用いた場合の EXAM を比較
0
0
Torig
Tslct
Tallall
TorigTslct
Tallalloriginal
selcetoriginal select
精度が低下した欠陥の個数を示した結果が表 2 である．全

suite[14] を利用した．Evosuite へ与えるシード値は 1 と0
0
し，テストケースの生成の制限時間は20 分とした．このToriginal
TselectTall
Tall
Toriginal
TselectTall
Tall
Torig
Tslct
Torig
Tslct
時間内に生成された全てのテストケースを Step 1 で生成し，精度が向上した欠陥箇所，精度が変化しなかった欠陥，
T
T
T
T
T
T

されたテストケースとして利用する．Evosuite により生成てのプロジェクトにおいて精度が低下した欠陥箇所の数よされたテストケースを用いて以下の 3 つのテストスイート

り精度が向上した欠陥箇所の数は多く，過半数以上の欠陥を用意する．

箇所において精度が向上した．全体では，56.8%の欠陥箇

Toriginal : 既存の全てのテストケース

所において精度が向上した．

Tselect : Tall から提案手法により選択されたテストケース

5.1.3 テストケースの数の比較

Csv
Codec
Tall : Toriginal+ 生成された全てのテストケース

Math
Lang
Toriginal ，Tselect ，Tall それぞれのテストケースの数に対

これら 3 つのテストスイートを用いてSBFL を適用し，8

する箱ひげ図を図 5 に示す．80
Tselect のテストケースの数

SBFL の精度，テストケースの数，テストの実行時間を比は Toriginal のテストケースの数より多くなったが，Tall の実⾏時間（秒）8

6
6
較する．精度の評価指標としてEXAMを用いる．EXAMは以下の式で定義される．

4

(2)

0
0 により算出された疑欠陥箇所の疑惑値の順位は，
SBFL
T

60
30
テストケースの数より少なくなった．
Lang において Tallの中央値が 253.5 であり，Tselect40 の中央値は 30 であった．

4

欠陥箇所の疑惑値の順位
EXAM=
× 100%
2
2
総ステートメント数

T

40

T

T

T

T

Torig
Torig
Tslct
originalTslct
selectTallall
original
select Tallall惑値の値が高い順に文を順位づけしたときの欠陥箇所の順位である．欠陥箇所と疑惑値の値が同じ文が複数存在する
場合，欠陥箇所の疑惑値の順位はそれらの中で最も低い順位とした．この評価指標は値が小さいほど欠陥限局の精度が高いことを表す．

20
Math では Tall の中央値が 321 であり，Tselect の中央値は2010であった．この 2 つのプロジェクトでは提案手法により
56

テストケースの数を大幅に削減できたことが確認できる．
0
0

5.1.4 Torig
テストの実行時間の比較
T
TselectTall
Tall
Tslct
original

ToriginalTslct
Tselect Tall
Tall
Torig
Toriginal ，Tselect ，Tall それぞれ用いた場合のテストの実行時間に対する箱ひげ図を図 6 に示す．Tselect と Tall を比較すると，提案手法によりテストの実行時間の増加を抑制できたことが確認できる．Codec や Csv については Lang
表 2 EXAM
プロジェクト名

表 1 実験対象のプロジェクト
プロジェクト名

精度向上

変化なし

精度低下

14（37.8%）

バグの数

欠陥箇所の行数

Codec

19（51.4%） 4（10.8%）

commons-codec（Codec）

15

37

Csv

9（52.9%） 2（11.8%）

6（34.1%）

commons-csv（Csv）

8

17

Lang

55（62.5%）3（3.4%）

30（34.1%）

commons-lang（Lang）

36

88

Math

148（55.8%） 21（7.9%）

96（36.2%）

commons-math（Math）

91

265

合計

231（56.8%） 30（7.4%） 146（35.9%）

TorigTslct
Tall
Toriginal
Tselect
Tall

Torig
Tslct
Tall
Toriginal
Tselect
Tall

テストケースの数
テストケースの数

Codec
200

200 Codec

150

300
100

100
200

Toriginal
TselectTall
Tall
Torig
Tslct

100

50

0

Csv

Toriginal
TselectTall
Tall
Torig
Tslct

実⾏時間（秒）
実⾏時間（秒）

1,500
500

1,000
0

1,000
0

500

Toriginal
Tselcet
Tall
Torig
Tslct
Tall

500
0

Toriginal
Tselcet
Tall
Torig
Tslct
Tall

Csv

ToriginalTselectTallTorigTslct
Tall

Math

Lang
80

40

6

30

Csv

60

Lang

4
8

4
8

20
40

40
80

2
6

2
6

10
30

20
60

0
4
2

ToriginalTslct
TselectTall
Tall
Torig

0

0
4
2

ToriginalTselectTallTorigTslct
Tall

テストケースの数

8
Codec

Math

1,000

0

Codec

6

Lang

1,500
500

Toriginal
TselectTall
Tall
Torig
Tslct
図 5

8

1,500

1,000

0
Toriginal
TselectTall
Tall
Torig
Tslct

Math

1,500

50
150
0
100

Torig
Tslct
Tall
Toriginal
Tselect
Tall

Lang

Csv

300

200
0

Torig
Tslct
Tall
Toriginal
Tselect
Tall

Toriginal
Tselect Tall
Tall
Torig
Tslct
図 6

0
20
10

0
40

Toriginal
TselectTall
Tall
Torig
Tslct

20

テストの実行時間

0

MathToriginalTslct
Tselect Tall
Tall
Torig

0

0

ToriginalTslct
TselectTall
Tall
Toriginal
Tselect Tall
Tall
Torig
Torig
Tslct
や Math ほど実行時間の増加を抑制することができなかっ

Toriginal
TselectTall
Tall
ToriginalTslct
Tselect Tall
Tall
Torig
Tslct
Torig
ム修正を行い，パッチ生成可能なバグの数を比較する．本た．Tall について Codec や Csv におけるテストケースの数実験では，自動プログラム修正ツールとして kGenProg[15]は Lang や Math におけるテストケースの数より少なく, テを利用した．kGenProg は遺伝的アルゴリズムを用いてバストの実行時間も短い．そのため Codec や Csv では Lang

グを自動修正する GenProg[16] を Java 言語向けに再実装

や Math と比べると提案手法の有効性は小さかったと考えしたツールである．制限時間は 30 分とし，この間にパッられる．
RQ1 への回答：提案手法によりテストの実行時間の増チを生成できたバグの数を比較する．kGenProg へ与える
パラメータを表 3 に示す．その他の遺伝的アルゴリズムの加を抑えつつ，SBFL の精度を向上させることができ動作に必要なパラメータは kGenProg のデフォルト値を用た．提案手法により 56.8%の欠陥において精度が向上

いた．

し，テストの実行時間の増加は中央値で最大でも 7.0 秒

5.2.2 パッチ生成可能なバグの数の比較の増加に抑えられた．

Tselect と Tall を用いて kGenProg を実行したときのパッチ生成可能なバグの数を表 4 に示す．各プロジェクトの5.2 実験 2

バグの数をプロジェクト名の列にある括弧の中に記述して

実験 2 では，RQ2 の自動プログラム修正への影響についいる．Codec や Lang では Tselect と Tall においてパッチて調査する．

生成可能なバグの数は等しくなった．Lang や Math では

5.2.1 実験設定

Tselect を用いることで Tall を用いるよりも多くのバグにお実験 1 で作成した Tselect と Tall を用いて，自動プログラ

いてパッチを生成することができた．しかし Tall を用いた

表 3 kGenProg へ与えるパラメータ
パラメータ
個体あたりのテストの制限時間
最大世代数

表 4
値

4秒
10,000

プロジェクト名

パッチ生成可能なバグの数
両方でTselect のみ

生成可能

生成可能

Tall のみ
生成可能

Codec（15）000

一世代あたりの個体生存数

5

Csv（8）100

交叉によって生成される一世代あたりに個体数

0

Lang（36）3

10seed 値1

Math（91）2

42

Complex.java
1 public class Complex implements Serializable {2...
3
public boolean equals(Object other) {4...
5
if (rhs.isNaN()) {6
ret = this.isNaN();7} else {ret = (Double.doubleToRawLongBits(real)== Double.doubleToRawLongBits(rhs.getReal()))&& (Double.doubleToRawLongBits(imaginary)
8== Double.doubleToRawLongBits(rhs.getImaginary()));//ret = (real == rhs.real)&& (imaginary == rhs.imaginary);
9
}
10
}
11
public Complex multiply(Complex rhs) {12...
return createComplex(real * rhs.real
13- imaginary * rhs.imaginary,
14
real * rhs.imaginary + imaginary * rhs.real);
15
}
16
...
17 }
選択されなかった既存のテストケース
1 public void testAtan() {2Complex z = new Complex(3, 4);3Complex expected = new Complex(1.44831, 0.158997);
4
TestUtils.assertEquals(expected, z.atan(), 1.0e-5);
5 }

図 7

Tselect を用いることで SBFL の精度が低下したバグの例

場合のみパッチ生成可能なバグも存在した．
RQ2 への回答：提案手法により選択されたテストケー

UniformRealDistribution.java
1 public class UniformRealDistribution
2
extends AbstractRealDistribution {3...
4/** {@inheritDoc} */5public boolean isSupportUpperBoundInclusive() {6
return false; //return true;
7
}
8
...
9 }
選択されたテストケース
1 @Test(expected=NumberIsTooLargeException.class)2 public void testPreconditions2() {3
new UniformRealDistribution(1, 0);
4 }選択されなかったテストケース
1 @Test(expected=NumberIsTooLargeException.class)2 public void testPreconditions1() {3
new UniformRealDistribution(0, 0);4 }図 8Tall を用いた場合のみパッチ生成可能なバグの例

6.2 Tall を用いた場合のみパッチ生成可能なバグ
実験 2 において Tselect を用いた場合ではパッチを生成できなかったが，Tall を用いた場合ではパッチを生成できたバグが存在した．本節ではその原因について考察する．

スを用いることで，既存のテストケースと自動生成されTall を 用 い た 場 合 の み パ ッ チ 生 成 可 能 な バ グ の 例

たテストケースを全て用いるよりも，多くのバグにおい（Math の 欠 陥 ID22）を 図 8 に 示 す ．提 案 手 法 に よ りてパッチを生成できた．

testPreconditions1 は testPreconditions2 と実行経路が重複しているとみなされ，testPreconditions1 は選

6. 考察

択されなかった．自動プログラム修正では生成された個体をテスト実行により評価し，次の世代に残すべき個体を選Tselect を用いることで Toriginal を用いるよりも SBFL の択する．提案手法によって SBFL の精度向上に役立たな精度が低下したバグについて考察する．また Tall を用いたいテストケースとして選択されなかったテストケースが自場合のみパッチ生成可能なバグについても考察する．

動プログラム修正における個体の選択に役立つ可能性がある．Tall を用いることで Tselect を用いるよりも良い個体が6.1 提案手法により SBFL の精度が低下したバグ
実験 1 において Tselect を用いることで Toriginal を用い
るよりも SBFL の精度が低下したバグが存在した．本節ではその原因について考察する．

選択され，パッチを生成できたと考えられる．

7. 妥当性の脅威
7.1 テストケースの生成

Tselect を用いることで SBFL の精度が低下したバグの例

本研究では，テストケースの自動生成に Evosuite を利用（Math の欠陥 ID96）を図 7 に示す．Toriginal を用いた場

した．他のテストケース自動生成ツールを用いた場合，実合の欠陥箇所の疑惑値の順位は 5 位であったが，Tselect を験結果が異なる可能性がある．また Evosuite のテストケー

用いた場合，13-14 行目の順位が上位にきたことで欠陥箇スの生成には乱択の操作が含まれる．seed 値やテストの生

所の疑惑値の順位は 6 位になった．失敗テストは equals

成時間を変えた場合．実験結果が変化する可能性がある．

と multiply を実行し，提案手法により選択されなかった
成功テスト testAtan は equals を実行せず，multiply を実行した．multiply を実行する成功テストの数が少なくなったことで，13-14 行目の疑惑値が大きくなり，SBFL の

7.2 疑惑値の計算本研究では，疑惑値の計算式に Ochiai を用いた．他の計算式を用いた場合，実験結果が変化する可能性がある．

精度は低下したと考えられる．テスト選択により実行する
失敗テストと成功テストの数が既存のテストスイートと大7.3 自動プログラム修正ツール

きく変化する行がある．このような行の疑惑値は大きく変

本研究では，自動プログラム修正ツールとして kGenProg

化するため，SBFL の精度が向上する場合もあるが，精度を用いた．他の自動プログラム修正ツールを用いた場合，が低下する場合もある．

実験結果が変化する可能性がある．また kGenProg へ与えるパラメータの値を変えた場合，実験結果が変化する可能
性がある．
[7]

7.4 実験対象
本研究では，Defects4J に含まれるバグを実験対象とした．他のバグを対象にして実験を行なった場合，実験結果が変化する可能性がある．

[8]

8. おわりに本研究では，テストの実行時間の増加を抑えつつ SBFLの精度を向上させるために，既存のテストケースと自動生[9]成されたテストケースから実行経路が重複しないように
テストケースを選択する手法を提案した．実バグのデータ[10]

セット Defects4J を対象に実験を行い，提案手法により選択されたテストケースを用いることで，56.8%の欠陥において精度が向上することを確認した．テストの実行時間の増加は中央値で最大でも 7.0 秒の増加に抑えられ，既存の[11]

テストケースと自動生成されたテストケースを全て用いた場合と比べて 4.9 秒短縮できた．また提案手法により選択されたテストケースを用いることで，既存のテストケースと自動生成されたテストケースを全て用いた場合と比べて，[12]

多くのバグにおいてパッチを生成できることを確認した．
今後の課題としては，他の自動プログラム修正ツールを用いた場合でも提案手法により選択されたテストケースを[13]用いることで，既存のテストケースと自動生成されたテス
トケースを全て用いた場合と比べて，パッチを生成できるかを調査することが挙げられる．
謝 辞

[14]

本 研 究 は JSPS 科 研 費（JP20H04166，

JP21K18302，JP21K11820，JP21H04877，JP22H03567，
JP22K11985）の助成を得て行われた．
[15]

参考文献
[1]

[2]

[3]

[4]

[5]

[6]

Britton, T., Jeng, L., Carver, G. and Cheak, P.: Quantify the time and cost saved using reversible debuggers, Technical report, Cambridge Judge Business School(2012).
Hailpern, B. and Santhanam, P.: Software debugging,testing, and veriﬁcation, IBM Systems Journal, Vol. 41,
No. 1, pp. 4–12 (2002).
Jin, W. and Orso, A.: F3: Fault Localization for Field
Failures, the proceedings of the International Symposium on Software Testing and Analysis, pp. 213–223(2013).
Korel, B.: PELAS-program error-locating assistant system, the proceedings of IEEE Transactions on Software
Engineering, Vol. 14, No. 9, pp. 1253–1260 (1988).
Liu, C., Yan, X., Fei, L., Han, J. and Midkiﬀ, S. P.:
SOBER: Statistical Model-Based Bug Localization, theproceedings of the European Software Engineering Conference Held Jointly with ACM SIGSOFT International
Symposium on Foundations of Software Engineering,pp. 286–295 (2005).
Dandan, G., Tiantian, W., Xiaohong, S. and Peijun,[16]

M.: A test-suite reduction approach to improving faultlocalization eﬀectiveness, Computer Languages, Systems & Structures, Vol. 39, No. 3, pp. 95–108 (2013).
Wu, Y., Liu, Y., Wang, W., Li, Z., Chen, X. and Doyle,P.: Theoretical Analysis and Empirical Study on the Impact of Coincidental Correct Test Cases in Multiple Fault
Localization, IEEE Transactions on Reliability, Vol. 71,
No. 2, pp. 830–849 (2022).
Perez, A., Abreu, R. and van Deursen, A.: A Test-Suite
Diagnosability Metric for Spectrum-Based Fault Localization Approaches, the proceedings of IEEE/ACM International Conference on Software Engineering, pp.
654–664 (2017).
Assiri, F. Y. and Bieman, J. M.: Fault localization forautomated program repair: eﬀectiveness, performance,
repair correctness, Software Quality Journal, Vol. 25,
No. 1, pp. 171–199 (2017).
Kuma, T., Higo, Y., Matsumoto, S. and Kusumoto, S.:
Improving the Accuracy of Spectrum-Based Fault Localization for Automated Program Repair, the proceedingsof International Conference on Program Comprehension, pp. 376–380 (2020).
Abreu, R., Zoeteweij, P. and Van Gemund, A. J.: An
Evaluation of Similarity Coeﬃcients for Software Fault
Localization, the proceedings of Paciﬁc Rim International Symposium on Dependable Computing, pp. 39–46(2006).
Abreu, R., Zoeteweij, P., Golsteijn, R. and van Gemund,A. J. C.: A Practical Evaluation of Spectrum-BasedFault Localization, J. Syst. Softw., Vol. 82, No. 11, pp.
1780–1792 (2009).
Just, R., Jalali, D. and Ernst, M. D.: Defects4J: A
Database of Existing Faults to Enable Controlled Testing
Studies for Java Programs, the proceedings of the International Symposium on Software Testing and Analysis,
pp. 437–440 (2014).
Fraser, G. and Arcuri, A.: EvoSuite: Automatic Test
Suite Generation for Object-Oriented Software, the proceedings of ACM SIGSOFT Symposium and European
Conference on Foundations of Software Engineering,pp. 416–419 (2011).
Higo, Y., Matsumoto, S., Arima, R., Tanikado, A.,
Naitou, K., Matsumoto, J., Tomida, Y. and Kusumoto,S.: kGenProg: A High-Performance, High-Extensibilityand High-Portability APR System, the proceedings ofAsia-Paciﬁc Software Engineering Conference, pp. 697–
698 (2018).
Weimer, W., Nguyen, T., Le Goues, C. and Forrest, S.:
Automatically ﬁnding patches using genetic programming, the proceedings of IEEE International Conference
on Software Engineering, pp. 364–374 (2009).