ソフトウェア・シンポジウム2018 in 札幌

不具合誘発パラメータ組み合わせ特定三手法の比較評価
渡辺

大輝

西浦

生成

京都工芸繊維大学 大学院工芸科学研究科

京都工芸繊維大学 大学院工芸科学研究科

博士前期課程 情報工学専攻

博士後期課程 設計工学専攻

d-watanabe@se.is.kit.ac.jp

k-nishiura@se.is.kit.ac.jp

水野 修
京都工芸繊維大学 情報工学・人間科学系

o-mizuno@kit.ac.jp

要旨

いに存在する．この不具合が現代社会に及ぼす影響は大きいものであるがゆえに，その不具合を検出するテスト

組み合わせテストによる不具合誘発パラメータ組み合

手法の一つである組み合わせテストは重要な役割を果

わせの特定は，ソフトウェア開発者が不具合誘発の原因

たす．

となる要因を特定する上で重要な役割を果たす．近年，

ソフトウェアにおける不具合は，ある単一のものから様々な研究者によって組み合わせテストの手法が数多く誘発されるとは限らず，ある条件の組み合わせが存在す

提案されている．一方で，不具合の個数や不具合誘発条ることによって不具合が誘発されるということが起こり

件の複雑さ，用いるシステムの規模などで示されるある

うる．ソフトウェアにおいて不具合が誘発されることが特定の状況下において，実際どの手法を用いれば最も効発覚したとき，我々はどの組み合わせが不具合を誘発さ

率よく正確に不具合誘発パラメータ組み合わせを特定でせているのかどうかを特定する必要がある．近年，多くきるのかという疑問が抱かれる．本論文では，これまでの研究者がパラメータ集合を元に，それらを全て正確にに提案された 3 種類の従来手法を用いて，組み合わせテ導き出し，不具合誘発パラメータ組み合わせとして出力ストにかかる処理時間，必要な追加テストケースとそのする組み合わせテストの手法を様々に提案している．そ実行回数，不具合特定成功率といった 3 つの観点を中心の手法は，元のテストスイートに大量にテストケースをに比較評価を行った．実験の結果，用いたテストスイー

追加していき不具合誘発パラメータ組み合わせを特定

トの変化による同一手法内でのデータの変化や，同一のする手法から，たった一つのテストケースからそのパラ

テストスイートにおける 3 種類の従来手法の実験結果

メータを変更していき不具合誘発パラメータ組み合わせの差異について収集することが出来た．また，得られたを特定する手法まで様々である．一般に，組み合わせテ

データを元に比較を行い，3 種類の従来手法の有用性のストによって不具合誘発パラメータ組み合わせを特定す差別化や，テストスイートの変化が引き起こす影響につることを FIL（Fault Interaction Location）と呼ぶ．では，いての結論を示した．

実際に FIL を行うとなったとき，一体どの手法を選択すればいいのだろうか．例えばあるテストスイート下に1

おいて 100%正しく FIL を正確に行うことが出来る手法はじめにがあったとしても，テストの実行にかかる時間が長ければ使用者のストレスの増加や作業の非効率化が予測されソフトウェアの開発は，必ずしも最初から最後まで思る．逆にどんなに速やかに FIL を行うことが出来る手法

い通りに進むとは限らない．開発を行っている最中，まがあったとしても，その出力結果の正確さが欠けている

たは世の中に出回った後に不具合が見つかる可能性も大

47

SEA

ソフトウェア・シンポジウム2018 in 札幌と不具合修正の容易さに悪影響を及ぼしてしまう．ゆえ
表 1. パラメータの仕様に，対象とするテストスイートの性質に対して最適な手法を選択することが出来れば，組み合わせテストの効率

parameter

value化を図ることが出来ることが期待される．

X
Y
Z

1,2,3
1,2
1,2

そこで本論文では，次の 3 つの従来手法の実装を行った: 2016 年に Zheng らによって提案された comFIL（com-plete Fault Interaction Location）[1]，2011 年に Zhang らによって提案された FIC（Faulty Interaction Characterization）[2]，2012 年に Ghandehari らによって提案された
identifying inducing combinations [3]．また，20 種類のテストスイートを用意し，それぞれを処理時間，成功率，
テストの実行回数の 3 つの観点から比較を行い，3 手法の有用性を調査した．

2

表 2. 表 1 の 2-way 組み合わせテスト

準備

テストケース

X

Y

Z

t1
t2
t3
t4
t5
t6

1
1
2
2
3
3

1
2
1
2
1
2

1
2
2
1
1
2

構成されることもあれば，複数パラメータ (組み合わせ)によって構成されることもある．この論文では，FI を次

2.1 組み合わせテストのように表記する．

組み合わせテストは，パラメータが取る値の組み合わ• FI が単一のパラメータであるとき，(変数名=パラ
メータ値)

せに注目し，ある組み合わせ数のパラメータ間で取る値のパターンの全てを網羅するテストのことであり，組み• FI が複数のパラメータであるとき，(変数名=パラメータ値, 変数名=パラメータ値, ...)

合わせ数を t としたとき，t-way テストや t-wise テストと呼ぶ．以後，あるパラメータが取る値のことをパラメー
タ値と表記する．例えば，表 1 のパラメータ仕様が与えまたこれ以後，FI を含んでいるときの実行結果を Fail，
FI を含んでいないときの実行結果を Pass と表記する．更に，この論文では「誘発」という言葉を「FI を含んでいることが原因となってテストの実行結果が Fail となること」という意味で定義している．

られたときの 2-way テストを生成する．まず総テスト
ケースなら，3 パターンのパラメータ値を取るパラメー
タが 1 つ，2 パターンのパラメータ値を取るパラメータが 2 つなので，テストケース数は 3 × 2 × 2 = 12 となる．
対して 2-way テストの組み合わせテストなら，表 2 のテ
ストスイートになり，テストケース数は 6 となる．考え2.3 従来手法

られる全ての 2 つの組み合わせ (X, Y)，(Y, Z)， (Z, X) の2.3.1 comFIL(complete Fault Interaction Location)

パラメータ値を確認すると，確かに全てパターンを網羅している．組み合わせテスト生成ツールには，Microsoft

comFIL(complete Fault Interaction Location) [1] は，
2016 年に Zheng らによって提案された組み合わせテス
トの一種である．以後，comFIL で統一する．
この手法では，まずテストスイートを入力する．例えば，2 パターンのパラメータ値を取るパラメータが 2 つ，
3 パターンのパラメータ値を取るパラメータが 1 つ，4 パ
ターンのパラメータ値を取るパラメータが 1 つの 2-way
テストの入力は表 3 のテストスイートになる．同時に，そのテストケースが FI を含んでいるかどうかを一つずつ判定していく．表 3 の実行結果は，FI が (a = 0, c = 0)，(a = 0, d = 3) であったときを示している．

社の Czerwonka ら [4] が開発した PICT1 ，産業技術総合研究所の Choi ら [5] が開発した pricot，Bryce ら [6] が開発した DDA などがある．

2.2 FI(Fault Interaction)
FI (Fault Interaction) とは，テストケースにおける，不具合を誘発させる原因となる組み合わせのことである．
以後，FI で統一する．FI は単一のパラメータによって1 https://github.com/Microsoft/pict

48

SEA

ソフトウェア・シンポジウム2018 in 札幌

表 4. 表 3 の FI 候補

表 3. 2-way テストの実行結果
テストケース

a

b

c

d

実行結果

1
2
3
4
5
6
7
8
9
10
11
12

0
1
0
1
0
1
0
1
0
0
1
1

0
1
1
0
0
1
1
0
0
1
0
0

0
1
2
0
1
2
0
1
2
0
1
2

0
0
0
1
1
1
2
2
2
3
3
3

Fail
Pass
Pass
Pass
Pass
Pass
Fail
Pass
Pass
Fail
Pass
Pass

次に，Fail したテストケースの部分集合を考える．その中から，Pass した全てのテストケースの部分集合でないものが，FI の候補となる．例えば，(a = 0, b = 0) はPass したテストケ ースの部分集合になっているので FIの候補とはならないが，(a = 0, d = 0) は Pass したテス
トケースの部分集合でないので FI の候補となる．この場合，全ての FI の候補は表 4 の通りになる．
次に，FI の候補を元にテストケースを追加していく．
追加テストケースの条件は以下の通りである．

FI 候補

a

b

c

d

t1
t2
t3
t4
t5
t6
t7
t8
t9
t10
t11
t12
t13
t14
t15
t16
t17
t18
t19
t20
t21
t22
t23

0
0
0
0
0
0
0
0
0
0
0
0
0

0
0
0
0
0
1
1
1
1
1
1
1
1
1
1

0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
-

0
0
0
0
0
0
2
2
2
2
2
2
3
3
3
3
3
3
3

的に取り除かれることなく残った FI 候補が真の FI として特定される．

• 最初に入力したテストスイートとは被らないようにする．

2.3.2 FIC (Faulty Interaction Characterization)• 追加テストケースに真の FI が追加されることはな
いものとする．例えば，表 4 の T 11 には a = 0 は追加されない．

FIC(Faulty Interaction Characterization ) [2] は，2011 年に Zhang らによって提案された組み合わせテストの一種である．以後，FIC で統一する.

• 複雑化を防ぐため，追加テストケースを作成したときに新たな FI は生まれないものとする．

この手法では，最初に入力するテストケースはたった 1つであり，テストケースのパラメータ値そのものを変更
していくことによってその中に含まれる FI を特定する．

FI の候補を 1 つずつ取り出し，追加テストケースを作成したあとに実行する．Fail だった場合，その FI 候補を部分集合に持つ他の FI 候補を FI 候補から取り除く．例
えば，表 4 の T 1 は実行後 Fail となり，T 1 を部分集合に持つ T 8 が FI 候補から取り除かれる．Pass だった場合，その FI 候補自身とその FI 候補自身の部分集合を FI 候
補から取り除く．例えば，表 4 の T 2 は実行後 Pass とな
り，T 2 自身と T 2 の部分集合である T 6 が FI 候補から取り除かれる．なお，この T 6 や T 8 のように追加テスト
ケースを作成する前に取り除かれる FI 候補には追加テ
ストケースを作成しない．これを順番に繰り返し，最終

他に，テストケースの要素数と，パラメータ値のパターン数を入力する．今回の例では，入力したテストケース
を [1, 2, 2, 1, 2, 2, 1, 1](このときテストケースの要素数は8)，パラメータ値のパターン数は 8 個とも 2 パターンとする．また，FI は (c = 2, f = 2)，(d = 1) とする．
次に，FI を特定するためにテストケースのパラメータ
値を順番に変更していき，1 回ずつ実行していく．その実行結果が Fail のときは，変更したパラメータ値はそのままに次の要素のパラメータ値を変更していく．Pass のときはパラメータ値を変更する前に戻し，次の要素のパラメータ値を変更していく．今回の例での推移を表 5 に

49

SEA

ソフトウェア・シンポジウム2018 in 札幌

表 5. FIC の推移例

表 6. 表 3 の FI 候補 (IIC)

テストケース

実行結果

FI 候補

a

b

c

d

t1
t2
t3
t4
t5
t6
t7
t8
t9

0
0
-

1
1
1
0

0
0
0
0
0
-

0
3
2
3
3
2
0

a

b

c

d

e

f

g

h

1

2

2

1

2

2

1

1

Fail(Skip)

2
2
2
2
2
2
2
2

2
1
1
1
1
1
1
1

2
2
1
1
1
1
1
1

1
1
1
2
1
1
1
1

2
2
2
2
1
1
1
1

2
2
2
2
2
1
1
1

1
1
1
1
1
1
2
2

1
1
1
1
1
1
1
2

Fail
Fail
Fail
Pass
Fail
Fail
Fail
Fail

1

2

2

1

2

2

1

1

Fail

1 にそれぞれ変更し，テストケースを [1, 2, 1, 2, 2, 1, 1, 1]

2
2
2

2
1
1

2
2
1

2
2
2

2
2
2

2
2
2

1
1
1

1
1
1

Fail
Fail
Pass

とする．その後再度実行すると結果は Pass となるため，

2

1

2

2

1

2

1

1

Fail

2

1

2

2

1

1

1

1

Pass

2

1

2

2

1

2

2

1

Fail

2

1

2

2

1

2

2

2

Fail

1

2

1

2

2

1

1

1

Pass

くために c のパラメータ値を 1 に，f のパラメータ値を

このテストケースには FI が存在していないことになる．
以上から，真の FI は (c = 2, f = 2)，(d = 1) と特定される．

2.3.3 Identifying Inducing Combinations
Identifying Inducing Combinations [3] は，2012 年にGhandehari らによって提案された組み合わせテストの一種である．以後，IIC で統一する．
この手法は，FI 候補となる組み合わせを，ある計算式によって真の FI である可能性をランク付けし，その可能性の高いものから順に追加テストケースを作成していくというものである．
まずテストスイートを入力する．今回は 2.3.1 節で使用したテストスイートと同じものを使用するものとし，
FI も 2.3.1 節と同様に (a = 0, c = 0)，(a = 0, d = 3) とする．このとき，テストスイートとそれぞれの実行結果は
表 3 に示される．
次に，comFIL と同様に，Fail したテストケースの部
分集合の中から，Pass した全てのテストケースの部分集
合でないものを，FI の候補とする．しかし，comFIL は部分集合のパラメータ数に決まりがなかったのに対し，
IIC では部分集合のパラメータ数は t-way テストの t の値のものに限る．つまり，今回の例ではパラメータ数が2 である部分集合を考える．この場合，全ての FI の候補
は表 6 の通りになる．
次に，FI 候補の構成パラメータ一つ一つを，後述の式
1 によって，その疑わしさを値として算出する．

示す．まず最初に a のパラメータ値を 2 に変更し，その後再度実行する．実行結果は Fail のため，a のパラメー
タ値は 2 のままに，次は b のパラメータ値を 1 に変更する．これを繰り返していくと，d を 2 に変更したときに初めて実行結果が Pass になる．よって，d のパラメータ値は 1 に戻され，再び e からパラメータ値を変更していく．その後は最後まで Fail であり続けるため，これにより一つ目の FI が (d = 1) と特定される．

1 週目が終了した後，元のテストケースより FI である(d = 1) を取り除くため，d のパラメータ値を 2 に変更し，
テストケースを [1, 2, 2, 2, 2, 2, 1, 1] とする．その後再度実行すると結果は Fail となるため，このテストケースにはまだ FI が存在しているということになる．よって，再びこのテストケースのパラメータ値を順番に変更していく．しかし，d のパラメータ値を 1 に変更してしまうとFI である (d = 1) を含んでしまうため，d のパラメータ値の変更は行わない．すると表 5 に示された通り，c とf のパラメータ値を変更したときに実行結果が Pass になる．よって二つ目の FI が (c = 2, f = 2) と特定される．
2 週目が終了した後，今度は (c = 2, f = 2) を取り除

50

SEA

ソフトウェア・シンポジウム2018 in 札幌

1(u(o) + v(o) + w(o))(1)
3
ここで，u(o)，v(o)，w(o) は以下の式で算出される．

表 7. IIC のランク付け

ρ(o) =u(o) =|{ f ∈ Fi |r( f ) = f ail ∧ o ∈ f }||{ f ∈ Fi |r( f ) = f ail}|(2)v(o) =|{ f ∈ Fi |r( f ) = f ail ∧ o ∈ f }||{ f ∈ Fi |o ∈ f }|(3)|{c|o ∈ c ∧ c ∈ π}|
|π|

(4)

ρ(o) =

t1
t2
t3
t4
t5
t6
t7
t8
t9

u(o) は，Fail したテストケースに含まれている総数の∑ρ(o), ∀ f ∈ F)

Re

Rc + ReR

0.67130.6176
0.53240.55090.53240.45370.40000.38150.2460

1
2
4
3
4
5
6
7
8

0.24600.43520.38490.52040.52040.6176
0.67130.67130.6713

1
3
2
4
4
5
6
6
6

2
5
6
7
8
10
12
13
14

1
2
3
4
5
6
7
8
9

次に，R の値の低い FI 候補から順に追加テストケースを作成し，実行を行う．実行自体は全ての FI 候補に対して行う．追加テストケースの作成方法は以下の通りである．

• 最初に入力したテストスイートとは被らないように
する．

1
3 5
ρ(c ← 0) = ∗ (1 + + ) = 0.7685
(5)
3
4 9
同様に，全ての FI 候補の構成パラメータについて式
1 の値を算出する．その結果を表 6 に示す．
次に，真の FI である可能性をランク付ける 2 つの値を算出する．それらは式 6 と式 7 で与えられる．

ρe (c) = Min(ρe

とめた結果を表 7 に示す．

v(o) は，Fail したテストケースに含まれている総数の値から，全てのテストケースに含まれている総数の値を除算する．w(o) は，FI 候補に含まっている総数の値から，
FI 候補自体の総数の値を除算する．例えば，ρ (c → 0)
は式 5 の通りに算出される．

1 ∑
ρ(o)
|c| ∀o∈c

Rc

可能性が高いものとして疑われることになる．以上をま値から，Fail したテストケースの総数の値を除算する．

ρc (c) =

ρc

FI 候補

• 追加する部分のパラメータ値は，ρ(o) の値が 1 番低
いものを採用する．
これにより，真の FI を特定する．

3

(6)

実験
本節では，研究設問，実験環境の詳細な明記，テスト

スイートなどの実験対象の説明，実験手順や留意点，得(7)o∈ f ∧o<c

られた実験結果について説明する．

ρc は，ある FI 候補の構成パラメータ 1 つ 1 つの ρ(o)の平均値を取る．例えば，ρc (a → 0, c → 0) は，ρ(a → 0)

3.1 研究設問と ρ(c → 0) の値の平均値を取る．また，ρe は，ある FI 候
本実験を行うにあたって，以下の研究設問を設定した．

補の構成パラメータ以外で構成されている ρc の中の最小値を取る．例えば，ρe (a → 0, c → 0) は ρc (b → 0, d → 0)，• RQ1:同一の手法のなかで，パラメータ数の大小とパラメータ値の種類数が与える影響は何か．

ρc (b → 1, d → 2)，ρc (b → 1, d → 3) の中から最小の値を取る．これらを全ての FI 候補について算出し，ρc はその値の高い順に，ρe はその値の低い順にそれぞれランク付けを行う．以下，その結果をそれぞれ Rc ，Re と呼ぶこととする．
次に，Rc と Re の値を加算した値を算出し，その値の低い順にそれぞれランク付けを行う．これを R と呼ぶこととする．この R の値の低い FI 候補が，真の FI である• RQ2:異なる手法のなかで，それぞれのテストスイー
トを用いるときの他の手法との差は何か．
これらを回答するために，まず 1 つの従来手法において様々なテストスイートとシステムモデルを用いて実行し，それと全く条件で他の 2 つの従来手法においても実行すればいいことが分かる．

51

SEA

ソフトウェア・シンポジウム2018 in 札幌

今回はそれぞれのテストスイートにおいて，以下の 3

表 8. t-way テストのテストケース数つの観点について測定を行い，これらから 3 種類の従来手法の有用性について差別化を行う．

2-way

3-way

4-way

13
24
19
31

43
111
69
163

127
455
233
795

システム A
システム Bシステム Cシステム D• 処理時間• 成功率• 追加テストの実行回数

表 9. 対象システムモデルの詳細

3.2 実験準備
3.2.1 実験環境
本実験で用いたプログラミング言語，開発環境，PC

システム

パラメータ数

A
B
C
D

10
10
20
20

パラメータ値のパターン数

2,2,2,2,2,3,3,3,3,3
3,3,3,3,3,4,4,4,4,4
2,2,2,2,2,2,2,2,2,2,3,3,3,3,3,3,3,3,3,3
3,3,3,3,3,3,3,3,3,3,4,4,4,4,4,4,4,4,4,4は以下の通りである．
組み合わせテストのテストスイート設計法の 1 つであ• PC:MacBook Pro(Retina 13-inch，Late 2013)，
Sierra(バージョン 10.12.6)，2.8 GHz Intel Core i7，
8 GB 1600 MHz DDR3る直交表を利用したテストは，指定の大きさの組み合わせ因子を網羅しつつテストケース数をできるだけ少なくする点で t-way テストと同じであり，目的とする役割がt-way と同じであるため本実験では使用しなかった．
また，使用する対象システムモデルを表 9 に示す通りに設定する．このシステムは，本実験用に作成した架空のものである．例えば，システム A は 2 種類の値を取るパラメータを 5 個，3 種類の値を取るパラメータを 5個，合計 10 個のパラメータを持つ．

• 言語:Python 3.6.3

3.2.2 実験対象
用いるテストスイートのパラメータ数，パラメータ値のパターン数の 2 つの要素の設定をシステムモデルと表記する．本実験では，4 種類のシステムモデルに対してそれぞれ 5 通りの方法で作成された計 20 種類のテスト

3.2.3 実験手順

スイートを実験対象として用いる．

2 節で述べた通り，既存の FIL 手法である comFIL，
FIC，IIC の 3 手法を用いて比較を行う．
まずプログラムを実行する前に，FI の数，FI の大きさ，FI のパラメータ値の設定を行う．FI の数は全てのテストにおいて 1 から 3 までの値でランダムに設定する．
FI の大きさはランダムテストは 3，t-way テストは t で統一する．FI のパラメータ値は各対象システムモデルにおいて設定されているパラメータ値のパターン数の中からランダムに与える．ただし，少なくとも 1 つのテスト
ケースは失敗するように選択する．
FI の設定後，それらに対して各手法を適用させて設定した FI を特定した．その後，処理時間，成功回数，追加
テストケースの実行回数を測定した．これらの 1000 種
類のテスト結果のサンプルを用意し，処理時間とテストの実行回数の平均値，最小値，第 1 四分位数，中央値，第 3 四分位数，最大値を算出した．成功率は百分率で値• ランダムテスト (100 個)• ランダムテスト (500 個)• 2-way テスト• 3-way テスト• 4-way テスト
ここで，ランダムテストとは，ランダムにパラメータの値を決定して作成された n 個のテストケースをテスト
スイートとしたものである．本実験では n = 100 の場合と n = 500 の場合を用いる．また，t-way テストの生成には Microsoft の組み合わせテスト生成ツールである PICTを用いた．t-way のそれぞれのテストケース数を表 8 に
示す．

52

SEA

ソフトウェア・シンポジウム2018 in 札幌を算出した．このテスト結果はランダムに設定された FI

4

考察による作用である．
また，comFIL では本来その大きさに関わらず，Fail し

4.1 研究設問への回答

たテストケースに部分集合として含まれ，かつ Pass し考察は表 10 の実験結果を元に行う．

たテストケースには部分集合として含まれないパラメー

RQ1：同一の手法のなかで，パラメータ数の大小とパタの全ての組み合わせを FI 候補とするが，テストケー

ラメータ値の種類数が与える影響は何か．

スのパラメータ数が大きいほど組み合わせ数は膨大になり処理に大きな時間がかかると予想される．そこで本実

最初に，comFIL について考える．ランダムテストに

験では実験と比較の簡易化のため，それぞれ対象とする

おいては，4 種類全てのシステムにおいて，テストケー

テストスイートが網羅する組み合わせの大きさ以下の部

スを多く用いる場合に処理時間と追加テストの実行回数

分集合のみを考える．

が減少することが分かった．comFIL は実行前に全てのまた，FI の数は分かっていないことを前提とし，IIC

テストケースを Fail したテストケースと Pass したテスにおいては全ての FI が特定出来たとしても追加テスト

トケースに分類し，その後 Fail したテストケースのみのケースを作成していない FI 候補が残っている場合は全部分集合になっているパラメータ値の組み合わせを FIて終わるまで実行を続けることとする．

候補とするが，本実験では FI の個数は多くても 3 つであるため，テストケースの数が多くなると同時に Fail し

3.3 実験結果

たテストケースと比べて Pass したテストケースの個数が相対的に増える幅が大きいことが予想される．これに実験結果を表 10 に示す．ここで，ave(t)[s] は平均処理より，FI 候補の数が減少することが必然的に予想され，時間を，ave(n)[回] は追加テストの平均実行回数を表す．

その結果追加テストケースの個数が減少したことで処理成功率は，各従来手法の出力によって導き出された FI

時間と追加テストの実行回数が減少したと考えられる．

と，予めランダムで決定されて与えられた FI が完全に

次に，t-way テストは処理時間についてはシステム B

一致している場合を成功とし，その割合を算出する．テにおいてのみ，2-way テストが最も処理時間が大きい結ストケースの実行回数は初めにテストケースを Fail した果となった．それ以外のシステムにおいては t の値が大ものと Pass したものに分けるための実行は含めず，追きくなるにつれて大きくなる傾向が見られた．また，追加のテストケースを実行した回数を測定する．以下，実加テストの実行回数においては 4 種類全てのシステムに

行回数と表記されているものも同様である．また，今回

おいて t の値が大きくなるにつれて多くなる傾向が見らは 3 種類の従来手法全てにおいて，追加のテストケースれた．これは，組み合わせ数が大きい方が Pass したテを実行するためにかかる時間を 0.1 秒と仮定する．しかストケースの部分集合になりにくくなり，FI 候補の数がし，そのままソースコードに 0.1 秒待機する命令を加え増加するためであると考えられる．異なるシステム間にてしまうと本実験に費やされる時間が膨大になることをおいては，パラメータ数とパラメータ値のパターン数が予測し，本実験では効率化のため実行回数に 0.1 を乗算

多いほど処理時間と追加テストの実行回数が増加するこ

した値を測定された処理時間に加算し，その値を処理時とが分かった．またシステム B と C を比較すると，パ間として算出した．

ラメータ値のパターン数が与える影響よりもパラメータ

実験結果では，同じ従来手法でもテスト種類によって数が与える影響の方が大きいことが分かった．これは，大きく異なる結果が得られた．また，それぞれの従来手

パラメータ値のパターン数が増加するよりもパラメータ法においても大きく異なる結果が得られた．

数が増加する方が，考えなければならない部分集合の数

また，テストの成功率は全て 100%を記録していた．こが爆発的に多くなることからこのような結果になったとのことから，3 種類の手法は全て FI を正確に特定出来て考えられる．

いることが分かった．

次に，FIC について考える．同一のシステム内においては 5 種類全てのテストにおいてほぼ全く同じ結果が得られた．また，パラメータ数が同一のシステム A，B とシステム C，D において，処理時間と追加テストの実行

53

SEA

ソフトウェア・シンポジウム2018 in 札幌

表 10. 実験結果 (3 手法のシステム毎の処理時間と追加テストの実行回数の平均値)
システム

A

B

C

D

手法

テスト

ave(t)

ave(n)

comFIL

ran100ran500
2-way
3-way
4-way

2.797
1.723
5.769
7.710
8.007

27.66815.86957.56576.83979.410comFIL

ran100ran500
2-way
3-way
4-way

8.878
2.580
11.3107.430
8.285

88.42824.76156.50373.97181.512

comFIL

ran100ran500
2-way
3-way
4-way

13.7584.203
12.50512.74225.705135.257
31.051124.434
195.257
239.703

comFIL

ran100ran500
2-way
3-way
4-way

67.331
5.955
15.77622.85631.988664.08652.162157.012225.418275.066

手法

テスト

ave(t)

ave(n)

FIC

ran100ran500
2-way
3-way
4-way

2.241
2.228
2.174
2.204
2.207

22.39622.24221.73622.03322.055FIC

ran100ran500
2-way
3-way
4-way

2.089
2.167
2.235
2.176
2.238

20.867
21.63722.34121.74722.341

FIC

ran100ran500
2-way
3-way
4-way

4.192
4.148
4.122
4.086
4.052

41.89541.41241.20240.84540.488FIC

ran100ran500
2-way
3-way
4-way

3.904
4.271
4.214
4.140
4.258

39.01842.65142.12641.37042.483

手法

テスト

ave(t)

ave(n)

IIC

ran100ran500
2-way
3-way
4-way

1.391
0.274
4.139
4.094
4.238

13.8442.062
41.32140.82842.253IIC

ran100ran500
2-way
3-way
4-way

4.267
0.254
3.663
4.174
4.385

42.5202.323
36.57441.63243.698IIC

ran100ran500
2-way
3-way
4-way

4.301
0.338
4.702
4.490
4.380

42.5172.039
46.75244.14342.532IIC

ran100ran500
2-way
3-way
4-way

4.324
0.210
4.887
4.494
4.202

35.9381.280
48.50144.08740.510

回数の値も同様な結果が得られた．FIC はテストケース

テストケース数が少ないので，FI の個数が多いと Passのパラメータ値を 1 つずつ順番に変えて実行をしていき，したテストケースの割合が他のテストに比べて減少する

FI を 1 つ特定する手法なので，追加テストの実行回数はパラメータ数の値と FI の個数に完全に依存するものである．このことから，得られる結果の固定化を招いたと考えられる．また，システム A，B と比べてパラメータ数が 2 倍であるシステム C，D は処理時間と追加テストの実行回数もほぼ 2 倍になっていることから，処理時間と追加テストの実行回数はパラメータ数と比例していると考えられる．
最後に，IIC について考察する．comFIL と同じく，ランダムテストを対象とした場合には，4 種類全てのシス
テムにおいて，テストケースを多く用いる場合に処理時間と実行回数が減少することが分かった．これは，実験
前に FI 候補を割り出す手順が comFIL と同じであるため，同様の理由でこのような結果が得られたと考えられ
る．t-way テストにおいては，comFIL と比べると t の値によって明白な差が生まれることはなかった．しかし，この論文の表中には示していないが，2-way テストでは処理時間と追加テストの実行回数のデータに大きなばらつきが見られた．特に，データの最大値が 3-way テストと 4-way テストに比べて高くなっていることが分かった．
2-way テストは他のテストと比べてテストスイートの総傾向にあると考えられる．これにより，FI 候補の数が多くなる可能性があることが予測される．IIC は comFILと違い，最終的に FI 候補は全て追加テストケースを作成し実行する．よって，FI 候補の増加が必然的に処理時間と追加テストの実行回数に直結することになる．これが最大値を突出させた原因であると考えられる．異なる
システム間においても，処理時間と追加テストの実行回数に明白な差は生まれなかった．これにより，パラメー
タ数とパラメータ値のパターン数は生成される FI 候補の数には依存しないことが分かった．comFIL は本実験
では FI の大きさの値以下の要素数を持つパラメータ組
み合わせを全て考えている．対して，IIC は FI の大きさの値と同等の要素数を持つパラメータ組み合わせのみを考える．このことから，comFIL と比べて考える部分集
合の数の伸びが少なくなることからこのような結果が得られたと考えられる．

RQ2：異なる手法のなかで，それぞれのテストスイー
トを用いるときの他の手法との差は何か．
本実験の結果から，ほぼ全てのテストスイートを対象とした場合において，処理時間と追加テストの実行回数が最も少なくなるのは FIC であることが分かった．先述

54

SEA

ソフトウェア・シンポジウム2018 in 札幌の通り，FIC の処理時間と追加テストの実行回数は追加

4.2 処理時間と追加テストの実行回数で行うテストのテストケースのパラメータ数に依存し，本実験の結果から，処理時間と追加テストの実行回数

comFIL と IIC は FI 候補の数に依存する．仮にパラメー
タ数が 1 増加したとすると，FIC の実行回数は 1×（FIの個数）回しか増加しない．これに対し，comFIL と IIC
はパラメータ数が 1 増加するだけでも考えなければならない部分集合の数が膨大に増加するため，追加テストの実行回数も大きく増加する．このことから，多くの場合においてはテストケースをどんどん追加していく手法を用いるより，1 つのテストケースを用いて FIL を行う手法を用いる方が効率が良いことが分かった．しかし，テストケースが多量のランダムテストにおいてはその限りではないことが分かった．
次に，comFIL と IIC を比較し，その差別化について考察する．本実験の結果では，一般的に全てのテストにおいて，IIC の方が処理時間と追加テストの実行回数が少なかった．これは先述の通り，IIC が FI の大きさの値と同等の要素数を持つパラメータ組み合わせのみを考えるのに対し，comFIL は FI の大きさの値以下の要素数を持つパラメータ組み合わせを全て考えているので，考えなければならない部分集合の数が IIC の方が少なくなることからこのような結果となった．しかし，これは今回のように FI の大きさが事前に見当がつく場合に限り，
現実のソフトウェア開発においては必ずしも FI の大きさが事前に見当がつくとは限らない．その場合においては，IIC とは違い全ての部分集合を考えることの出来る
comFIL を用いる方が汎用的に優れていると考えられる．
以上のことから，本実験から得られた 3 種類の従来手法の差別化は以下の通りに考えられる．

は正の相関関係があることが分かった．従って，追加テストの実行回数の削減が処理時間の削減に直結することが分かる．本実験では追加テストの実行時間を 0.1 秒と仮定しているが，もしこの実行時間が更に長くなったとき，テストにかかる総時間は追加テストの実行回数が多ければ多いほど大幅に長くなることが予測される．このような状況下で本実験で用いた 3 種類の従来手法から 1つを選ぶときは，次の 2 つの判断基準が考えられる．

• FI の大きさに見当がつく場合，IIC を用いてランク付けを行い，順番に実行していく．FI を全て特定をし終えたら実行をやめる．そうすると残りを実行しなくて済むので，追加テストの実行回数の削減に繋がる．
• 本実験のほぼ全てのテストにおいて最も優れており，かつ処理時間がある程度予測できる FIC を用いる．
comFIL はどうしても追加テストの実行回数が多くなってしまうので，実行時間が長くなったときには不向きであると考えられる．
4.3 妥当性の検証
4.3.1 ランダム性
今回の実験では，FI の数，FI のパラメータ値を１回のループごとにランダムに与えている．FI の数が大きくな
ればなるほど，どの手法でも処理時間は長くなるので，与えられた FI の数に偏りが生じれば，テスト結果に少• IIC: FI の大きさに見当がつき，多量のランダムテス
トケースを扱うとき．

なからず影響が及ぶと考えられる．また，ランダムテス
トに用いたテストスイートにも偏りが生じている可能性• comFIL: FI の大きさに見当がつかず，多量のランダ
ムテストケースを扱うとき．

も考えられる．総テストケースは 1 番少ないシステム A• FIC: t-way テストや少量のランダムテストケースを扱うとき．

だとおよそ 619 億通りにも及ぶ．ランダムテストに用いまた，成功率については 3 種類全ての手法で 20 種類

る可能性は十分に存在する．

でも 25 × 35 = 7776 通り存在する．1 番多いシステム D
たテストケース数の 100 や 500 という数はこれに比べるとかなり小さい値なので，テストスイートに偏りが生じ全てのテストスイートにおいて 100%となった．このことから，得られる出力結果の精度についてはどの従来手

4.3.2 アルゴリズムの正当性法も同等であると考えられる．

3 種類の従来手法の各アルゴリズムの実装は，他言語で記載されているアルゴリズムを参考に，Python 3.6.3

55

SEA

ソフトウェア・シンポジウム2018 in 札幌

で書き換えた．論文に記載されているアルゴリズムは大3 つの観点に関するデータを収集した．得られた結果か
ら，それぞれの従来手法がどのような状況下において有用性が生まれるかについての結論の考察を行った．
考察の結果，comFIL は FI の大きさに見当がつかず多量のランダムテストケースを扱うとき，FIC は t-way テ
ストや少量のランダムテストケースを扱うとき，IIC はFI の大きさに見当がついており多量のランダムテスト
ケースを扱うときに有用性が生まれることが分かった．
今後の課題として，より正しいデータを得るために，与える FI などといったランダム性のある要因を消去出来るような実装や，有用性をより詳細に示すために他の比較すべき観点の探索が挙げられる．

まかに記載されており部分が少ないため，我々が実装したソースコードと異なってしまっている可能性がある．
その場合も，得られる実験結果に誤差が生じる可能性が存在する．

4.3.3 comFIL の簡易化
本実験では実験の簡易化のため，comFIL で作成する

FI 候補の要素数に FI の大きさの値までという制限をかけた．本来であれば，comFIL は FI の大きさに寄らずに考えられうる部分集合全てを元に FI 候補を作成するため，この制限により実験結果に誤差が生じる可能性が存
在する．

参考文献
[1] D.H. Wei Zheng, Xiaoxue Wu, and Q. Zhu, “Locating minimal fault interaction in combinatorial testing,”
Advances in Software Engineering, vol.2016, pp.1-10,
2016.

4.3.4 出現する FI の大きさ
本実験では出現する FI の大きさをランダムテストでは 3，t-way テストでは t と固定した値を用いている．しかし，例えば 2-way テストにおいて FI の大きさが 3 以[2] Z. Zhang and J. Zhang, “Characterizing failure-causingparameter interactions by adaptive testing,” Proceedings of the 2011 International Symposium on Software
Testing and Analysis, pp.331-341, ISSTA ’11, ACM,
New York, NY, USA, 2011.

上のものが出現した場合，これは必ずしも特定できるとは限らない (テストスイートにその FI が含まっていない
可能性があるため)．これはテストの成功率に影響を及ぼすと考えられる．

[3] L. S. G. Ghandehari, Y. Lei, T. Xie, R. Kuhn, and R.
Kacker, “Identifying Failure-Inducing Combinations in
s Combinatorial Test Set,” Proceedings of the IEEE International Conference on Software Testing, Verification and Validation (ICST), pp.370-379, 2012.

4.4 今後の課題
本実験における今後の課題として，与える FI の大きさなどといったランダム性の強い部分を出来るだけ平等になるような実装をすることが挙げられる．また，本実験では比較する要因として処理時間，成功率，テストの[4] J. Czerwonka, “Pairwise testing in the real world: Practical extensions to test case generators,” Microsoft Corporation Software Testing Technical Articles, 2008.

実行回数の 3 つを測定したが，この他にも従来手法の有用性を差別化できる要因を多く探し出すことが挙げられる．

5[5] E. Choi, T. Kitamura, C. Artho, A. Yamada, and Y.
Oiwa. “Priority integration for weighted combinatorial
testing,” Proc. of 39th Annual International Computer
Software and Applications Conference, pp. 242-247,
2015.

まとめ
本論文では，これまでに発表された 3 種類の組み合

わせテストによる不具合誘発パラメータ特定の従来手法について，処理時間，成功率，テストの実行回数の結果[6] R. Bryce and C. Colbourn, “Prioritized intersction
testing for pair-wise coverage with seeding and constraints,” Information and Software Technology, Vol.
48, No. 10, pp.960-970, 2006.

からの比較を行い，それぞれの有用性について差別化を行った．それぞれの従来手法のアルゴリズムの実装を行い，計 20 種類のテストスイートを用いて測定し，この56

SEA