３パラメータ間の組み合わせのばらつき具合を比較する
直交表の利点の１つとして「３パラメータ間の組み合わせも均等に出現する」と言われています。このことはよく言われていることなので多くの人が知っていると思われます。それでは実際の直交表で３パラメータ間の組み合わせのばらつき具合を調べてみましょう。
まずは、４つの値を持つパラメータが９個ある L32 の直交表を取り上げてみます。この直交表の3-Wayカバレッジは４８．８％ です。
パラメータ間の組み合わせのばらつき具合を調べるには、Excelのピポッドテーブルの機能を使用します。表２はパラメータ１と４と９の３パラメータについてのピポッドテーブルです。この表では、３パラメータ間の組み合わせのばらつき具合が分かりやすいように、網羅されている組み合わせを青色に、網羅されていない組み合わせを黄色に塗りつぶしています。
この表を見ると、なるほどばらつきが均等に表れていることがよくわかります。どの２つのパラメータの特定の値に着目しても、かならずもう１つのパラメータの値と２つづつ組み合わされています。総計の欄を見ると、２パラメータのすべての値と、もう１つのパラメータの特定の値との組み合わせ数が、８，８，８，８と、８，８，８，８という具合に完璧に均等です。
続いてPictMasterで同じモデルの組み合わせを見てみます。最小テストケース生成を行なったところ、テストケース数が２８で、3-Wayカバレッジは４０．１％でした。
ここでは直交表とPairwise法（All-Pair法）について、３パラメータ間の組み合わせのばらつき具合を比較するために、同じ3-Wayカバレッジで比較を行なわないと、ばらつき具合の正しい比較ができません。そこでPictMasterの、希望する3-Wayカバレッジを確保した組み合わせを生成する機能を使用して、3-Wayカバレッジに４９％を指定して組み合わせを生成しました。
生成された組み合わせは３５件、3-Wayカバレッジは４９．２％となりました。
この組み合わせのピポッドテーブルを次に示します。
やはりばらつきが大きいですね。総計の欄を見ると、２パラメータのすべての値と、もう１つのパラメータの特定の値との組み合わせ数が、９，７，９，８と、９，８，９，７という具合にばらついています（重複した組み合わせは１つと数えます）。
ここまでは、これまでよく言われていることと同じことを確認しただけでした。ところで表２をよく見ると、４×４×４＝６４個の升目のうち、網羅されているのは３２個の升目です。そうすると3-Wayカバレッジは５０％でなければなりません。しかし、PictMasterの「既存テストケースのカバレッジを表示」の機能を使用して算出した3-Wayカバレッジは４８．８％でした。１．２％だけ少ないのです。３パラメータの組み合わせを色々替えて確認してみましたが、どの組み合わせでも３２個の升目が網羅されています。
これはPictMasterの3-Wayカバレッジ算出の処理にバグがあるのか？！ という思いまででてくる始末です。それでも粘り強く組み合わせを替えて見たところ、パラメータ３，４，９の組み合わせでおかしなことに気がつきました。網羅されている組み合わせがそれまでの半分の１６個しかないのです。
次に別の直交表を取り上げてみます。４つの値を持つパラメータが２１個ある L64 の直交表です。この直交表はサイズが大きいのでここでは掲載できません。この直交表の3-Wayカバレッジは８８．６％です。この直交表のピポッドテーブルの例を示します。
この表から分かる通り、このパラメータの組み合わせでは3-Wayカバレッジは１００％です。他の組み合わせも確認してみましたが、いずれもすべての組み合わせが網羅されています。しかし、PictMasterで測定した3-Wayカバレッジは８８．６％でした。１１．４％の食い違いがあります。この食い違いは、表５の場合と同様に一部の３パラメータの組み合わせで3-Wayカバレッジが大幅に減少しているためだと考えられます。
３パラメータの組み合わせを様々に替えて見たところ、パラメータ４，８，１３で3-Wayカバレッジが２５％となっていることが分かりました。これ以外でも分かっただけでパラメータ７，８，１３、パラメータ８，１３，１５でも同様に3-Wayカバレッジが２５％でした。
同じモデルについてPictMasterで生成した組み合わせの件数は３７件、3-Wayカバレッジは４８．１％という結果でした。3-Wayカバレッジを直交表とできるだけ同じ値とするために、希望する3-Wayカバレッジに８０％を指定して生成した組み合わせ数は７９件、3-Wayカバレッジは８０．６％となりました。
この組み合わせのピポッドテーブルの例を示します。
２つのパラメータの組み合わせに対応するもう１つのパラメータの値の個数の合計は、１２，１２，１２，１２と、１２，１１，１１，１４とばらついています（重複した組み合わせは１つと数えます）。他の組み合わせも同様なばらつきかたです。確かにばらつきはありますが、直交表の場合に極端に網羅率が減少する組み合わせがあるケースも考慮すると、Pairwise法（All-Pair法）でのばらつきの程度は許容範囲に収まっているという印象を受けました。
直交表とPairwise法（All-Pair法）について３パラメータ間の組み合わせ網羅のばらつき具合を比較するために、表２と表４を並べてみます。
L32直交表とPairwise法（All-Pair法）の3-Wayカバレッジは約４９％でほぼ同じです。直交表は組み合わせ網羅が均等であるのに対し、Pairwise法（All-Pair法）ではばらついています。２つの組み合わせを比較して、どちらが３パラメータの組み合わせに起因するソフトウェアの欠陥検出効果が高いと考えられるでしょうか。この組み合わせを見ると、「３パラメータ間の組み合わせも均等に出現する」から、直交表の方が３パラメータの組み合わせに起因するソフトウェアの欠陥検出効果が高い、と見なすことはできないように思われます。
３パラメータの組み合わせに起因するソフトウェアの欠陥検出効果については、3-Wayカバレッジが同じであれば、組み合わせにばらつきのあるPairwise法（All-Pair法）でも、「３パラメータ間の組み合わせも均等に出現する」直交表と明確な違いは認められないと考えられます。
PictMaster以前のPairwise法（All-Pair法）のツールでは、3-Wayカバレッジを指定することはできませんでした。過去にこうした状況が続いたため、Pairwise法（All-Pair法）で生成された組み合わせは3-Wayカバレッジが低く、したがって３パラメータの組み合わせのばらつき方が大きいため、直交表の「３パラメータ間の組み合わせも均等に出現する」という点が、Pairwise法（All-Pair法）に対するアドバンテージとして主張されることになったのだと思います。
そうした直交表の利点も、Pairwise法（All-Pair法）のツールで3-Wayカバレッジを指定できるようになったことで、それほど意味のあることではなくなったと言えるでしょう。
今回もう一つ明らかになったことは、直交表によってはどの３パラメータと組み合わせるかによって、3-Wayカバレッジに大きな違いがあるという点です。例えば、ある３パラメータの組み合わせでは１００％だが、別の３パラメータの組み合わせでは４分の１の２５％になる、といったことです。直交表がこのような大きなばらつきを内包しているということについて、なぜかこれまで語られたことがなかったようです。
上にあげた以外の直交表でも同じばらつきを持つ直交表が見つかっています。直交表の場合は、表面的な3-Wayカバレッジだけでなく、その直交表がどの３パラメータと組み合わせるかによってカバレッジに大きな違いのでる直交表なのか、そうでない直交表なのかを検討する必要があるように思います。
直交表とPairwise法のテストケース数と3-Wayカバレッジを比較する
今回は、直交表とPairwise法（All-Pair法）の生成テストケース数と3-Wayカバレッジ（３パラメータ間の組み合わせ網羅率）を比較してみます。Pairwise法（All-Pair法）のツールはたくさんありますが、無償で使うことができて、実務のテスト業務で実用になるかどうかという点ではやはりPICT（PictMaster）だけのようです。
直交表とPairwise法（All-Pair法）の比較結果を表１に示します。パラメータの値の欄の意味は次の通りです。3X4 は、値が３つのパラメータが４つあることを意味します。4X3+2X6 は、値が４つのパラメータが３つ、値が２つのパラメータが６つあることを意味します。
直交表の選定にあたっては、できるだけバリエーションが多くなるようにしました。直交表のライブラリが掲載されているサイトから多くを引用しています。Pairwise法（All-Pair法）のテストケース数は、PictMasterで最小テストケース生成を１００回繰り返した結果です。
比較結果を見ると、全体的な傾向として、直交表でのテストケース数が多く、Pairwise法（All-Pair法）でのテストケース数は少ないことが分かります。3-Wayカバレッジは、直交表が高く、Pairwise法（All-Pair法）は低い傾向となっています。この傾向は、これまで直交表とPairwise法（All-Pair法）との違いとして言われてきた通りです。
Pairwise法（All-Pair法）は2-Wayカバレッジ１００％を確保したうえで、テストケース数が最小となる組み合わせを生成することに専念しているだけあって多くの場合、直交表よりもテストケース数が大幅に少なくなっています。これに対して直交表の場合は、あらかじめモデルの大きさにあう既存の表を探し、それに値を当てはめる作業となるため、使用する直交表によってテストケース数が多くなりがちです。その反面、テストケース数が多いということは、結果として3-Wayカバレッジが高くなることにつながります。
PictMasterでは、希望する3-Wayカバレッジを確保したテストケースを生成できるため、特に重要と考えるテスト対象については、テストケース数をそれほど増加させずに、高い3-Wayカバレッジを確保したテストケースを生成することができます。3-Wayカバレッジ１００％では、テストケース数の増加が大きくなってしまい現実的なテストではなくなってしまう場合があります。そのような場合には、3-Wayカバレッジに８０％程度を指定し、テストケースを生成することでテストケース数増加の問題を回避することができます。１００％とまではいきませんが、3-Wayカバレッジ８０％程度を確保できれば十分でしょう。
このようにPictMasterを使用することで、直交表の利点をPairwise法（All-Pair法）でも実現することができます。今までPairwise法（All-Pair法）の弱点と言われてきた3-Wayカバレッジの少なさは、希望する3-Wayカバレッジを確保したテストケースを生成する機能により、解決することができるようになります。
PictMaster 5.3 をリリースしました
PictMaster 5.3 をリリースしました。
このバージョンでは、「既存TCのカバレッジを表示」に関するバグ修正のほか、使用するうえで制約の大きい「全数組み合わせと比較」の機能を削除しました。
おもな変更点は次の通りです。
【バグ修正】
・「既存TCのカバレッジを表示」で、ワークシートの名称が “a” でなかった場合にVBAのエラーとなるバグを修正した。
・「既存TCのカバレッジを表示」で、モデルファイル a.txt と テストケースファイル a.xls が一致していない場合にVBAのエラーとなる場合があったバグを修正した。
【その他】
・「全数組み合わせと比較」の機能を削除した。
PictMaster 5.3 は以下のサイトからダウンロードすることができます。
http://sourceforge.jp/projects/pictmaster/
PictMaster 5.2 をリリースしました
PictMaster 5.2 をリリースしました。
バグフィックスがメインのバージョンです。
主な変更点は次の通りです。
【機能改善】
・編集用のショートカットメニュー使用時のワークエリアとして、セルではなく定義したデータエリアを使用するように変更した。
【バグ修正】
・環境設定で「サブモデルを使用」と「全数組み合わせと比較」が同時に指定されていた場合、内容が空きの全数組み合わせが表示されるバグを修正した。
・制約表で値を指定するワイルドカードに “?” を使用する場合、全角の値の名称１文字を２文字の “??” で指定できるように修正した。
・結果表で、重み付けされた値を指定する際に、逆条件の “#” で指定すると、正しく処理されなかったバグを修正した。
PictMaster 5.2 は次のサイトからダウンロードすることができます。
どうすれば市場障害を防げた か
総合テストで検出しきれなかった障害は、製品出荷後にユーザ先で市場障害として発見されることになります。最後のテスト皇帝である総合テストでは、すべての欠陥を発見しようと努めるわけですが、１００％発見することは不可能であり、いくつかの欠陥は発見されることなく市場に出荷されてしまいます。
市場障害の内容を調査することで、市場障害に至った欠陥を事前に発見するにはどうすればよかったかが分かります。ここでは細かい分類ではなく、おおまかな対策を取り上げてみます。
次のグラフは、実際にある製品の市場障害の内容を調査した結果、どのような対策をとっておれば市場障害を防げたかを分析したものです。
「設計工程でのレビュー強化」が５４％で最も多くなっています。これに該当する市場障害は、総合テスト工程では発見することが事実上不可能な欠陥です。例えば、初期化されていない特定のアドレスの内容が特定の値の場合に発生する障害などは、この障害に該当します。システムの電源をオンした時、メモリエリアの値は不定となるわけですが、多くの場合、一定のパターンにしたがった値となります。しかし、ハードウェア特性のわずかな違いにより、このパターンとは異なる値をとるシステムがあります。このシステムで障害が発生する場合、総合テストで事前に発見することはかなり困難です。テスト用に数百システムもテストできれば別ですが。
このような障害は、ソフト設計工程でのレビューの強化で発見するように努めるしか防ぐ手段はありません。「テスト項目の充実」が２９％で２番目に多くなっています。１００％完璧なテスト項目ができれば別ですが、どうしてもテスト漏れが生じてしまいます。市場障害を分析することにより、テスト漏れのないテスト項目を作成できるよう改善を行なうことになります。
設計工程でのレビュー強化で発見すべきとされる市場障害のうちのいくらかは、総合テスト段階での「エラー推測テストの強化」によって発見することが期待できます。レビュー強化といっても限界があるため、事前に発見できない欠陥が残ることになります。こうした欠陥を発見する有効な手段としてエラー推測テストがあります。エラー推測テストの強化で発見が期待できることを含めた市場障害対策を次のグラフで示します。
エラー推測テストの強化で発見できる欠陥として２１％が対象となりました。エラー推測テストはテスター個人の能力に依存する面が大きく、誰にでもできるテスト技法ではありませんが、実施するだけの価値がある方法です。
なお、エラー推測テストに似たテスト技法として「探索的テスト」がありますが、エラー推測テストが、テスト仕様書では網羅しきれない、ソフト設計者が「考慮漏れ」をおこしやすい側面に焦点を当てるテスト技法であるのに対して、探索的テストは、テスト仕様書が存在しない状況で実施するテスト技法であるという違いがあります。
エラー推測テストで発見される欠陥が多いことはよいことではありません。それだけ設計工程でのレビューが不足していることを意味しているからです。レビューが完璧に行なえれば、エラー推測テストの出番はなくなるわけですが、なかなかそういうわけにはいかないようです。