ループを含む関数の制御パステストにAll-Pair法を適用する（その２）
12月16日の記事で「ループを含む関数の制御パステストにAll-Pair法を適用する」と題してループが１つの関数への適用例を紹介しました。適用例としてはあまりにも小粒すぎたので今回はループを２つ含む関数の制御パステストにAll-Pair法を適用した例を紹介します。
例として取り上げる関数は周期的に実行されるタイマを処理する関数です。各タイマエリアはメモリブロックとして確保され、タイマカウント中のタイマはカウント中タイマキューのヘッドポインタである Tmrp に片方向キューとしてキューイングされています。
関数はこのキューイングされている各タイマのチェーンをたどりながらタイマ値を－１します。その結果、０となったタイマがあればカウント中タイマキューから外し、T.Oタイマキューヘッドポインタ Totmrp のキューにキューイングします。
以上の処理の一例を図１に示します。
図１．タイマ処理関数の実行結果
この関数のソースリストをリスト１に示します。
リスト１．タイマ処理関数のソースリスト
ソースリストの関数にはコーディングミスがあるかもしれません。;^_^
それと説明の本質には関係ないのでintとポインタの型の違いは無視しています。
この関数の制御パステストを行なう際に取り上げるパラメータには次のものがあります。
B1：4行目のif文
R1：10行目のfor文
B2：11行目のif文
B3：15行目のif文
R2：20行目のfor文
B4：21行目のif文
これらのパラメータのうち、B2、B3およびB4のパラメータにどのような値を採用するかで制御パステストの「深さ」が違ってきます。単にすべての分岐の真と偽の両方を通るテストといった「浅い」テストでは、この関数のバグをすべて見つけ出すことは難しいでしょう。例えば15行目のif文B3で、「すべてのタイマが同時にタイムアウトした」という場合のテストを実施しておく価値はあるでしょう。このように単に分岐網羅のテストだけでは見つけ出せないバグに対しては、パラメータの値に必要な条件を追加することで「深い」制御パステストを行なうことができます。
この関数で制御パステストにAll-Pair法を適用した場合のモデルと制約表の例を図２に示します。
図２．制御パステストにAll-Pair法を適用した場合のモデルと制約表の例
この制約表では制約が8個となっていますが、ソースリストを見ながら制約表に記入した段階では制約の数は10個以上となりました。制約表を見直すと制約の中には複数の制約を1つの制約にまとめられるものがいくつかあり、最終的に8個となりました。
簡単な結果表を図３に示します。この例ではリターンコードしか対象としていませんが、パラメータの値によってキューの状態がどのようになるか記述することも可能です。
図３．結果表の例
以上の条件で生成されたテストケースを表１に示します。
表１．制御パステストにAll-Pair法を適用した場合のテストケース
この例では12通りとなりました。単純な分岐網羅のテストケースではもっと少ない値になるはずです。この例では、各キューの状態別に値を採用したためテストケース数が多くなっています。しかしこの関数をテストするにはもっと多くの異なる条件でのテストケースが必要だと思われます。
どこまで深くテストするかは、パラメータの値の数で決まります。こうしたモデルと制約表の記述は、ソースリストを見ながら行なうことが可能です。
例として取り上げる関数は周期的に実行されるタイマを処理する関数です。各タイマエリアはメモリブロックとして確保され、タイマカウント中のタイマはカウント中タイマキューのヘッドポインタである Tmrp に片方向キューとしてキューイングされています。
関数はこのキューイングされている各タイマのチェーンをたどりながらタイマ値を－１します。その結果、０となったタイマがあればカウント中タイマキューから外し、T.Oタイマキューヘッドポインタ Totmrp のキューにキューイングします。
以上の処理の一例を図１に示します。
この関数のソースリストをリスト１に示します。
ソースリストの関数にはコーディングミスがあるかもしれません。;^_^
それと説明の本質には関係ないのでintとポインタの型の違いは無視しています。
この関数の制御パステストを行なう際に取り上げるパラメータには次のものがあります。
B1：4行目のif文
R1：10行目のfor文
B2：11行目のif文
B3：15行目のif文
R2：20行目のfor文
B4：21行目のif文
これらのパラメータのうち、B2、B3およびB4のパラメータにどのような値を採用するかで制御パステストの「深さ」が違ってきます。単にすべての分岐の真と偽の両方を通るテストといった「浅い」テストでは、この関数のバグをすべて見つけ出すことは難しいでしょう。例えば15行目のif文B3で、「すべてのタイマが同時にタイムアウトした」という場合のテストを実施しておく価値はあるでしょう。このように単に分岐網羅のテストだけでは見つけ出せないバグに対しては、パラメータの値に必要な条件を追加することで「深い」制御パステストを行なうことができます。
この関数で制御パステストにAll-Pair法を適用した場合のモデルと制約表の例を図２に示します。
この制約表では制約が8個となっていますが、ソースリストを見ながら制約表に記入した段階では制約の数は10個以上となりました。制約表を見直すと制約の中には複数の制約を1つの制約にまとめられるものがいくつかあり、最終的に8個となりました。
簡単な結果表を図３に示します。この例ではリターンコードしか対象としていませんが、パラメータの値によってキューの状態がどのようになるか記述することも可能です。
以上の条件で生成されたテストケースを表１に示します。
この例では12通りとなりました。単純な分岐網羅のテストケースではもっと少ない値になるはずです。この例では、各キューの状態別に値を採用したためテストケース数が多くなっています。しかしこの関数をテストするにはもっと多くの異なる条件でのテストケースが必要だと思われます。
どこまで深くテストするかは、パラメータの値の数で決まります。こうしたモデルと制約表の記述は、ソースリストを見ながら行なうことが可能です。
PictMaster2.7.4 AllPairII1.1.1をリリースしました。
PictMasterとAll-PairIIのバージョンアップのお知らせです。
PictMaster 2.7.4、All-PairII 1.1.1をリリースしました。
https://sourceforge.jp/projects/pictmaster からダウンロードすることができます。
今回はバグフィックスが中心です。おもな変更点は以下のとおりです。
PictMaster 2.7.4
【バグ修正】
・PICTが出力したエラーメッセージのウインドウをドラグすると、画面の再描画が行なわれなかったバグを修正した。
・最少テストケース生成中のプログレスバーをドラグすると、画面の再描画が行なわれなかったバグを修正した。
・値の並び欄で、無効値（~）でかつエイリアス（|）でかつエイリアスの縦棒の間に半角空白があると、結果表でそのエイリアスを指定した場合、正しく処理されていなかったバグを修正した。
AllPairII 1.1.1
【バグ修正】
・確認表の値が未定義の場合のエラーメッセージの表示内容が正しくないバグを修正した。
・値の重み付けが「値の並び欄」で31個目以降の値にあると、値の重み付けが行われないバグを修正した。
・最少テストケース生成中のプログレスバーをドラグすると、画面の再描画が行なわれなかったバグを修正した。
・生成エンジンがPICTの場合、値の並び欄で、無効値（~）でかつエイリアス（|）でかつエイリアスの縦棒の間に半角空白があると、結果表でそのエイリアスを指定した場合、正しく処理されていなかったバグを修正した。
・生成エンジンンがJennyの場合、値にPICTの無効値（~）が指定されたとき、エラーメッセージを表示すべきところをそのまま処理してしまい不適切な動作となっていたバグを修正した。
【その他】
・「確認表」という名称を「結果表」に変更した。（ユーザーズマニュアルの記述は未修正です。）
P.S. JaSST'08東京で組み合わせテストツール開発事例の発表を行ないます。
制約表の使い方とツールの幅広い適用事例の紹介を中心に発表する予定です。
実際にツールも使い聴講の方にとって有益な内容にしたいと思っています。
１月２８日のＤ４－２のコマです。
それでは、また。
PictMaster 2.7.4、All-PairII 1.1.1をリリースしました。
https://sourceforge.jp/projects/pictmaster からダウンロードすることができます。
今回はバグフィックスが中心です。おもな変更点は以下のとおりです。
PictMaster 2.7.4
【バグ修正】
・PICTが出力したエラーメッセージのウインドウをドラグすると、画面の再描画が行なわれなかったバグを修正した。
・最少テストケース生成中のプログレスバーをドラグすると、画面の再描画が行なわれなかったバグを修正した。
・値の並び欄で、無効値（~）でかつエイリアス（|）でかつエイリアスの縦棒の間に半角空白があると、結果表でそのエイリアスを指定した場合、正しく処理されていなかったバグを修正した。
AllPairII 1.1.1
【バグ修正】
・確認表の値が未定義の場合のエラーメッセージの表示内容が正しくないバグを修正した。
・値の重み付けが「値の並び欄」で31個目以降の値にあると、値の重み付けが行われないバグを修正した。
・最少テストケース生成中のプログレスバーをドラグすると、画面の再描画が行なわれなかったバグを修正した。
・生成エンジンがPICTの場合、値の並び欄で、無効値（~）でかつエイリアス（|）でかつエイリアスの縦棒の間に半角空白があると、結果表でそのエイリアスを指定した場合、正しく処理されていなかったバグを修正した。
・生成エンジンンがJennyの場合、値にPICTの無効値（~）が指定されたとき、エラーメッセージを表示すべきところをそのまま処理してしまい不適切な動作となっていたバグを修正した。
【その他】
・「確認表」という名称を「結果表」に変更した。（ユーザーズマニュアルの記述は未修正です。）
P.S. JaSST'08東京で組み合わせテストツール開発事例の発表を行ないます。
制約表の使い方とツールの幅広い適用事例の紹介を中心に発表する予定です。
実際にツールも使い聴講の方にとって有益な内容にしたいと思っています。
１月２８日のＤ４－２のコマです。
それでは、また。
ループを含む関数の制御パステストにAll-Pair法を適用する
制御パステストへのAll-Pair法の適用についてはこれまで何度か話題にしてきましたが、いずれもループを含まないプログラムでした。今回はループを含むプログラムへAll-Pair法を適用して制御パステストのテストケースを生成します。
All-Pair法を制御パステストに適用した場合、組み合わせるパラメータの数を２とした場合は、すべての分岐の真と偽の両方を通る分岐網羅のテストケースが生成されます。
今回テスト対象としたプログラムのリストを以下に示します。
リスト１．配列内のデータを扱う関数のリスト
この小さな関数は、入力パラメータp1が0の場合、配列データArea[10]の、これも入力パラメータp2でインデックスされたエリアをゼロクリアします。入力パラメータp1が0でない場合、配列データArea[10]を順番にサーチし、最初に見つかった0のエリアに入力パラメータp2の値を設定します。0のエリアが見つからなかった場合、リターンコードrcに1を設定しリターンします。それ以外の場合はrcに0を設定してリターンします。
この関数にはfor文があり、ループを含んでいます。プログラムとしてはとても小さなものですが、この関数にAll-Pair法による制御パステストが適用できれば、より大きなプログラムでも同様に適用可能となります。
この関数に対応したモデルと制約表、それに結果表を以下に示します。
図１．関数のモデルと制約表と結果表
このモデルでは入力パラメータp2が省略されていますが、追加するなら境界値の0と9でよいでしょう。
関数のfor文はモデルのパラメータrepeat1とcond1で表されています。
repeat1の値repeatは繰り返しを意味します。cond1のend loopはfor文を最後まで繰り返したことを表します。同じくbreak loopはbreak文でループから抜け出したことを表します。パラメータArea(i)の0はループの最初で0のエリアが見つかったことを表します。not 0 → 0はループの途中で0のエリアが見つかったことを表します。not 0は最後まで調べても0のエリアが見つからなかったことを表します。
パラメータendの値が２つあるのはPICTの値は２つ以上必要というPICTの制限に合わせただけです。
制約表の記入内容には、ループを表現するためにパラメータrepeat1とcond1が追加されています。簡単な結果表も用いています。
この条件で生成した結果を以下の示します。
表１．ループを含む関数func1の制御パステストのテストケース
この関数の分岐文はパラメータp1とArea(i)が対応します。for文のループ部分は、ループせずに通り抜けた場合、何回かループした後ループからbreak文で抜け出した場合、および最後までループを繰り返した場合の３通りをカバーしています。この関数のテストケースとしては４通りとなります。
制約表を記述する上で気をつける部分が制約2のパラメータrepeat1のセルです。ここは繰り返す場合と素通りする場合があるので空白にしておきます。
今回はループを含む場合の制御パステストをAll-Pair法で行なうということでしたが、目的は達成したと思います。例えばループが入れ子になっている場合は、パラメータrepeat2とcond2を追加すれば済みます。ただし、パラメータrepeatとcondは人が生成されたテストケースを見て、理解しやすくするために設けたもので、パス制御テストにとってはなくてもかまわないものです。
パラメータの値は、何をどこまでテストするのかをはっきりさせておけば、おのずと決まってきます。この値の決め方でパス制御テストの粒度が決まります。慣れるに従ってソースリストからモデルと制約表への記入が速くなってくるでしょう。
それでは、また。
All-Pair法を制御パステストに適用した場合、組み合わせるパラメータの数を２とした場合は、すべての分岐の真と偽の両方を通る分岐網羅のテストケースが生成されます。
今回テスト対象としたプログラムのリストを以下に示します。
この小さな関数は、入力パラメータp1が0の場合、配列データArea[10]の、これも入力パラメータp2でインデックスされたエリアをゼロクリアします。入力パラメータp1が0でない場合、配列データArea[10]を順番にサーチし、最初に見つかった0のエリアに入力パラメータp2の値を設定します。0のエリアが見つからなかった場合、リターンコードrcに1を設定しリターンします。それ以外の場合はrcに0を設定してリターンします。
この関数にはfor文があり、ループを含んでいます。プログラムとしてはとても小さなものですが、この関数にAll-Pair法による制御パステストが適用できれば、より大きなプログラムでも同様に適用可能となります。
この関数に対応したモデルと制約表、それに結果表を以下に示します。
このモデルでは入力パラメータp2が省略されていますが、追加するなら境界値の0と9でよいでしょう。
関数のfor文はモデルのパラメータrepeat1とcond1で表されています。
repeat1の値repeatは繰り返しを意味します。cond1のend loopはfor文を最後まで繰り返したことを表します。同じくbreak loopはbreak文でループから抜け出したことを表します。パラメータArea(i)の0はループの最初で0のエリアが見つかったことを表します。not 0 → 0はループの途中で0のエリアが見つかったことを表します。not 0は最後まで調べても0のエリアが見つからなかったことを表します。
パラメータendの値が２つあるのはPICTの値は２つ以上必要というPICTの制限に合わせただけです。
制約表の記入内容には、ループを表現するためにパラメータrepeat1とcond1が追加されています。簡単な結果表も用いています。
この条件で生成した結果を以下の示します。
この関数の分岐文はパラメータp1とArea(i)が対応します。for文のループ部分は、ループせずに通り抜けた場合、何回かループした後ループからbreak文で抜け出した場合、および最後までループを繰り返した場合の３通りをカバーしています。この関数のテストケースとしては４通りとなります。
制約表を記述する上で気をつける部分が制約2のパラメータrepeat1のセルです。ここは繰り返す場合と素通りする場合があるので空白にしておきます。
今回はループを含む場合の制御パステストをAll-Pair法で行なうということでしたが、目的は達成したと思います。例えばループが入れ子になっている場合は、パラメータrepeat2とcond2を追加すれば済みます。ただし、パラメータrepeatとcondは人が生成されたテストケースを見て、理解しやすくするために設けたもので、パス制御テストにとってはなくてもかまわないものです。
パラメータの値は、何をどこまでテストするのかをはっきりさせておけば、おのずと決まってきます。この値の決め方でパス制御テストの粒度が決まります。慣れるに従ってソースリストからモデルと制約表への記入が速くなってくるでしょう。
それでは、また。
状態遷移テストへのAll-Pair法の適用
状態遷移図のテストは、状態遷移図から状態遷移表を作成し、状態遷移表をもとに状態とイベントの組み合わせをテストします。今回はこの状態遷移図のテストにAll-Pair法を適用してみようというものです。
例として図１の状態遷移図を示します。この図では、状態S0～S3があり、イベントe1～e5で状態を遷移します。状態S0以外ではイベントe0で状態S0に遷移します。状態S1とS3および状態S2とS3との間はイベントによって往復できます。All-Pair法で扱うには、状態をパラメータとし、イベントを値とします。こうしてある状態のとき、あるイベントにより、次の状態に遷移する、ということを表現することができます。
この状態遷移図でポイントとなるのが、状態S1とS3および状態S2とS3との間で往復できるということです。この図のままではAll-Pair法で状態をパラメータとすることができません。状態を戻るということが取り扱いできないためです。そこでこの状態を往復できることを表現するために状態遷移図を以下のように展開します。
この図では、状態S3から前の状態に戻り、再び状態S3に戻ることを表現しています。パラメータ名が重複しないように状態の名称にダッシュ（'）を付加しています。この状態遷移図を表現するモデルと制約表を以下に示します。
制約表の内容は単純なルールで記述されています。制約条件にイベントを記入し、次に遷移する状態に対応するパラメータに制約対象としてその状態で有効なイベントを記入します。それらのイベントは１つづつ異なる制約で制約条件として記入します。あとはこれのくり返しです。なお、モデルで最後の状態S0'の値が２つあるのはPICTの制限に合わせるためです。
以上のモデルと制約表で生成された状態遷移の組み合わせ結果を以下に示します。
この表では12個の状態遷移のルートが表わされています。状態遷移表では9個になりますが、状態遷移図で状態の往復が表現されているため3個増えています。
今回の例はごく単純な例にすぎませんが、状態の往復がない状態遷移図の場合はそのままAll－Pair法で取り扱い可能です。しかし現実には状態の往復がある場合がほとんどですが...。
それでは、また。
日本人はなぜ直交表により興味を抱くのか？
組み合わせテスト技法にはAll-Pair法と直交表を利用する方法の２種類があります。面白いことに日本では直交表をベースとした方法に関心を抱く人が圧倒的に多いのです。なぜAll-Pair法は関心をもたれないのでしょうか。その理由を解明する前に、現状のそれぞれの手法に対する関心度の高さをWebページの数で比較して見ましょう。
Googleで検索した結果を示します。" "で囲んだ用語などが検索した用語です。" "で囲むことで正確な検索ができます(ヒット件数は日によっていくらか変化します）。
国内（日本語）での各用語のGoogleヒット件数
"直交表" ソフト テスト 10,500件
"HAYST法" 10,100件
----------------------------------
合計： 20,600件
比率： 98.9%
"All-Pair法" 72件
"All-Pairs法" 9件
"オールペア法" 88件
"Pairwaise法" 30件
"ペアワイズ法" 40件
-----------------------------------
合計： 239件
比率： 1.1%
直交表のあるページにはHAYST法もある可能性が高く、２重にカウントしている可能性が高いですが、All-Pair法も同時にPairwaise法もある可能性があるため、そのままカウントしています。
次に全世界での直交表とAll-Pair法の関心度の高さをWebページの数で比較してみましょう。直交表は Orthogonal で検索しました。
全世界（すべての言語）での各用語のGoogleヒット件数
Orthogonal Software test 187,000件（直交表）
----------------------------------
合計： 187,000件
比率： 46.6%
All-Pairs software test 33,900件
Pairwise software test 180,000件
-----------------------------------
合計： 213,900件
比率： 53.4%
以上の結果から、少なくとも国内（日本）においては、直交表やHAYST法が占める割合は、All-Pair法などの手法よりおおよそ９０倍注目されている、ということになります。あくまでもWebページ数の単純合計からの推測ですが。この差は非常に大きなものがあります（"直交表"単独では実験計画法関係の多くのページがヒットしてしまうため"ソフト"と"テスト"という単語を追加しました）。それに対して全世界での直交表の占める割合は半分以下であり、All-Pairs法関係が過半数を占めています。
日本でソフトウェアの組み合わせテスト技法として直交表に多くの関心が集まる理由として、田口玄一博士の存在は無視できないでしょう。博士は1924年生まれ。1980年、田口博士はＡＴ＆Ｔのベル研究所を訪れ品質保証部の仕事を手伝いました。また米国のゼロックス社でも品質工学の手法について議論を行ないました。田口博士の優れた手法は「タグチメソッド」として紹介され、米国の主力産業界に大きな影響を与えました。
田口博士の業績の１つとして、直交表を使いやすくした点にあります。直交表は少ない実験回数で結果に最も大きな影響を与える因子を見つけ出す方法としてタグチメソッドを取り入れることで、より使いやすいものとなりました。
直交表の用途が少ない実験回数で結果に最も大きな影響を与える因子を見つけ出すことにあるため、実験の組み合わせには同じ２因子間の組み合わせが同一回数現れるという性質があります。このことは２因子間のみならず３因子間の組み合わせもバランスよく現れること、実験に影響を与えるノイズの存在を検出できること、などの特徴につながっています。
こうした直交表の特徴をソフトウェアの組み合わせテストにも適用できないかということで1980年代の半ばから直交表を使った組み合わせテストの研究が発展してきました。こうした歴史的経緯から、日本では直交表ベースの組み合わせテストに注目が集まってきたということが言えると思います。
それにしても日本におけるAll-Pair法に対する関心のなさは異常と言ってもいいようです。そういう私も最初は直交表に関心を持ったものでした。３因子間の組み合わせもある程度網羅できることが直交表のメリットとして私には意識されました。直交表をめぐる話題には特有の専門用語が数多く出現しますが、そういった手法をマスターしようとすることが魅力的に思えるのかもしれません。直交表ベースの組み合わせテストツールを作成するには実験計画法の知識が必要とされますが、これが１つの難関になっていると思います。直交表ベースのツール開発には多大なコストが必要となり、そうして開発したツールを無償で公開するなどということは考えられないことです。
All-Pair法は1990年代の初めから主として米国で研究・発展してきました。直交表が実験計画法から生まれたのに対し、All-Pair法は最初からソフトウェアの組み合わせテスト技法として研究されてきました。米国ではAETGなどに代表されるように優れたAll-Pair法の有償のツールが有名です。All-Pair法のツールは何よりも２因子間の網羅率を100%とすることを最優先にしています。直交表ベースのツールでは制約の関係にある因子間では通常の重要性の場合、網羅率を80%程度とすることにしています（HAYST法の場合）。
All-Pair法では、制約の関係があっても２因子間の網羅率は100%保障されます。またAll-Pair法では多くのツールが無償で公開されています。これは直交表ベースのツールでは考えられないことです。無償で公開されているAll-Pair法のツールは玉石混交ですが、中にはPICTのように制約をサポートしており、テスト業務で活用可能な優れた組み合わせ生成エンジンもあります。これらを利用して使いやすい組み合わせテストツールを作成することは難しくはありません。コストの面でも生成エンジンを自社開発する場合に較べて大幅にコストダウンとなります。もしもHAYST法のように制約をサポートした直交表ベースの組み合わせテストツールを自社開発しようとするならば、その開発コストは相当多額なものとなるはずです。
直交表ベースのツールも、All-Pair法のツールもそれぞれ一長一短があります。具体的な比較は差し控えますが、全体的に見てどちらがより優れているという判断はできないと思います。そうであるならば後は開発コストが焦点となるでしょう。
PictMasterは組み合わせ生成エンジンにMicrosoftの開発したPICTを使用しています。PICTそのものだけでは日本語が文字化けするなど実用的に使用することはできませんが、ExcelベースのBookであるPictMasterを利用することで極めて使いやすく実用的なツールとなっています。しかも無償です。
以下のURIからダウンロードすることができますので一度試してみてはいかがでしょうか。
http://sourceforge.jp/projects/pictmaster/
それでは、また。
Googleで検索した結果を示します。" "で囲んだ用語などが検索した用語です。" "で囲むことで正確な検索ができます(ヒット件数は日によっていくらか変化します）。
国内（日本語）での各用語のGoogleヒット件数
"直交表" ソフト テスト 10,500件
"HAYST法" 10,100件
----------------------------------
合計： 20,600件
比率： 98.9%
"All-Pair法" 72件
"All-Pairs法" 9件
"オールペア法" 88件
"Pairwaise法" 30件
"ペアワイズ法" 40件
-----------------------------------
合計： 239件
比率： 1.1%
直交表のあるページにはHAYST法もある可能性が高く、２重にカウントしている可能性が高いですが、All-Pair法も同時にPairwaise法もある可能性があるため、そのままカウントしています。
次に全世界での直交表とAll-Pair法の関心度の高さをWebページの数で比較してみましょう。直交表は Orthogonal で検索しました。
全世界（すべての言語）での各用語のGoogleヒット件数
Orthogonal Software test 187,000件（直交表）
----------------------------------
合計： 187,000件
比率： 46.6%
All-Pairs software test 33,900件
Pairwise software test 180,000件
-----------------------------------
合計： 213,900件
比率： 53.4%
以上の結果から、少なくとも国内（日本）においては、直交表やHAYST法が占める割合は、All-Pair法などの手法よりおおよそ９０倍注目されている、ということになります。あくまでもWebページ数の単純合計からの推測ですが。この差は非常に大きなものがあります（"直交表"単独では実験計画法関係の多くのページがヒットしてしまうため"ソフト"と"テスト"という単語を追加しました）。それに対して全世界での直交表の占める割合は半分以下であり、All-Pairs法関係が過半数を占めています。
日本でソフトウェアの組み合わせテスト技法として直交表に多くの関心が集まる理由として、田口玄一博士の存在は無視できないでしょう。博士は1924年生まれ。1980年、田口博士はＡＴ＆Ｔのベル研究所を訪れ品質保証部の仕事を手伝いました。また米国のゼロックス社でも品質工学の手法について議論を行ないました。田口博士の優れた手法は「タグチメソッド」として紹介され、米国の主力産業界に大きな影響を与えました。
田口博士の業績の１つとして、直交表を使いやすくした点にあります。直交表は少ない実験回数で結果に最も大きな影響を与える因子を見つけ出す方法としてタグチメソッドを取り入れることで、より使いやすいものとなりました。
直交表の用途が少ない実験回数で結果に最も大きな影響を与える因子を見つけ出すことにあるため、実験の組み合わせには同じ２因子間の組み合わせが同一回数現れるという性質があります。このことは２因子間のみならず３因子間の組み合わせもバランスよく現れること、実験に影響を与えるノイズの存在を検出できること、などの特徴につながっています。
こうした直交表の特徴をソフトウェアの組み合わせテストにも適用できないかということで1980年代の半ばから直交表を使った組み合わせテストの研究が発展してきました。こうした歴史的経緯から、日本では直交表ベースの組み合わせテストに注目が集まってきたということが言えると思います。
それにしても日本におけるAll-Pair法に対する関心のなさは異常と言ってもいいようです。そういう私も最初は直交表に関心を持ったものでした。３因子間の組み合わせもある程度網羅できることが直交表のメリットとして私には意識されました。直交表をめぐる話題には特有の専門用語が数多く出現しますが、そういった手法をマスターしようとすることが魅力的に思えるのかもしれません。直交表ベースの組み合わせテストツールを作成するには実験計画法の知識が必要とされますが、これが１つの難関になっていると思います。直交表ベースのツール開発には多大なコストが必要となり、そうして開発したツールを無償で公開するなどということは考えられないことです。
All-Pair法は1990年代の初めから主として米国で研究・発展してきました。直交表が実験計画法から生まれたのに対し、All-Pair法は最初からソフトウェアの組み合わせテスト技法として研究されてきました。米国ではAETGなどに代表されるように優れたAll-Pair法の有償のツールが有名です。All-Pair法のツールは何よりも２因子間の網羅率を100%とすることを最優先にしています。直交表ベースのツールでは制約の関係にある因子間では通常の重要性の場合、網羅率を80%程度とすることにしています（HAYST法の場合）。
All-Pair法では、制約の関係があっても２因子間の網羅率は100%保障されます。またAll-Pair法では多くのツールが無償で公開されています。これは直交表ベースのツールでは考えられないことです。無償で公開されているAll-Pair法のツールは玉石混交ですが、中にはPICTのように制約をサポートしており、テスト業務で活用可能な優れた組み合わせ生成エンジンもあります。これらを利用して使いやすい組み合わせテストツールを作成することは難しくはありません。コストの面でも生成エンジンを自社開発する場合に較べて大幅にコストダウンとなります。もしもHAYST法のように制約をサポートした直交表ベースの組み合わせテストツールを自社開発しようとするならば、その開発コストは相当多額なものとなるはずです。
直交表ベースのツールも、All-Pair法のツールもそれぞれ一長一短があります。具体的な比較は差し控えますが、全体的に見てどちらがより優れているという判断はできないと思います。そうであるならば後は開発コストが焦点となるでしょう。
PictMasterは組み合わせ生成エンジンにMicrosoftの開発したPICTを使用しています。PICTそのものだけでは日本語が文字化けするなど実用的に使用することはできませんが、ExcelベースのBookであるPictMasterを利用することで極めて使いやすく実用的なツールとなっています。しかも無償です。
以下のURIからダウンロードすることができますので一度試してみてはいかがでしょうか。
http://sourceforge.jp/projects/pictmaster/
それでは、また。