３つ以上の任意のパラメータのみ３パラメータの組み合わせとする方法 （パラメータの重み付け）
これまで任意のパラメータのみ３パラメータの組み合わせとする方法については何度か取り上げてきましたが、何らかの制限があったり、方法が複雑だったりしました。今回は特に制限なしで簡単な方法を取り上げてみます。
すべてのパラメータについて３パラメータの組み合わせとした場合、テストケース数が多くなりすぎ現実的でなくなる場合がよくあります。こうした場合、特に重要だと考えられるパラメータに限定して３パラメータ間の組み合わせを網羅することができれば、むやみにテストケース数が多くなりすぎることを防ぎ、かつ網羅度の高いテストケースを実用的な範囲で生成することができます。
基本的な手順は以下の通りとなります。
１．３パラメータの組み合わせとしたい３つ以上のパラメータについてサブモデルで３パラメータの組み合わせを指定します。同時に環境設定で組み合わせるパラメータ数に１を指定します。
２．以上の条件でテストケースを生成します。このときのテストケース数を控えておきます。
３．生成されたテストケースを原型シートのワークシートに貼り付けます。
４．環境設定で組み合わせるパラメータ数に２を指定します。そして原型シートを使用する設定とします。同時にサブモデルを使用しない設定とします。
５．以上の条件でテストケースを生成します。このときのテストケース数が２項でのテストケース数より多いことを確認します。
ここで生成されたテストケースの集合は、指定した任意のパラメータのみが３パラメータの組み合わせとなり、残りのパラメータは２パラメータの組み合わせとなります。このときのテストケース数はすべてを３パラメータの組み合わせとした場合より顕著に少ない数となります。
モデルの構成によっては、この手順で最後の５項のテストケース数が２項でのテストケース数よりも少ない場合がありえます。この場合は必要な組み合わせが得られていないので、３パラメータの組み合わせとしたい３つ以上のパラメータ以外の任意のパラメータにダミーの値を１つだけ追加し、もう一度テストケースを生成します。そうすると生成されるテストケース数は、２項でのテストケース数よりも多くなるのでこの生成結果を最終的なテストケースとします。ダミーの値は任意の値に置き換えます。
具体的なモデルの例を図１に示します。このモデルではパラメータ A, B, C, D の４つのパラメータのみ３パラメータ間の組み合わせとし、残りのパラメータ E, F, G, H は２パラメータ間の組み合わせとします。
このとき環境設定で組み合わせるパラメータ数を１とします。
以上の条件で生成されたテストケースを示します。このときのテストケース数は２８となります。（最少テストケース生成で生成しているため、必ずしも２８となるわけではありません）
次にＭＴＧに新規ワークシートを作成し、それをＭＴＧのワークシートの右側に移動し、原型シートとします。そして先ほど生成した３パラメータの組み合わせ結果を原型シートに貼り付けます。
続いて環境設定でサブモデルを使用しないに設定し、原型シートを使用するに設定します。また組み合わせるパラメータ数に２を設定します。
この条件で生成されたテストケースを示します。
このときのテストケース数は３０となります。このテストケースはパラメータ A, B, C, D のみ３パラメータの組み合わせとなり、残りのパラメータは２パラメータの組み合わせとなっています。
こうした方法ではなく、単純に組み合わせるパラメータ数に３を指定した場合のテストケース数は５７となり、２倍近くのテストケース数となります。
Pairwise法（All-Pairs法）のヒューリスティックアルゴリズムを試してみる
PICTが採用しているPairwise法（All-Pairs法）のヒューリスティックアルゴリズムについては2009年10月09日の記事 で説明しました。今回は、PICTのヒューリスティックアルゴリズムを実際のモデルに適用し、すべてのペアの組み合わせを網羅する具体的な方法を説明します。
この説明に用いるモデルでは、パラメータが６個あり、それぞれが３個の値を持っています。それでは順を追って説明します。
（１）すべてのペアを網羅した全ペア配列を定義します。この配列自体は簡単に定義することができます。このモデルでは９×１５＝１３５個のペアの値を持つ配列となります。
（２）生成したテストケースを格納するテストケース配列を定義します。このモデルでは１行が６列からなる配列が１７行ほどもあれば十分でしょう。
（３）ここから１つのテストケースを生成する方法の説明となります。
１）全ペア配列からランダムに１つのペアを取り出し、それぞれの値をそのパラメータの列のテストケース配列に格納します。配列に格納できたら全ペア配列の当該ペアをマーキングします。
２）すでにテストケース配列に他の値があるときは格納できないので、全ペア配列の当該ペアの位置から下に移動し、テストケース配列に配置できるペアの値を探します。一番下まで探しても見つからないときは右側の列の配列を上から下に探します。最も右側の列を探してもテストケース配列に配置できるペアの値が見つからないときは最も左側の上から下に探します。以降同様に空きのテストケース配列に配置できる値が見つかるまで検索を繰り返します。最後まで検索しても見つからないときは空きのテストケース配列に任意の値を格納します。（※ ここで示した方法はPICTの処理方法とは異なります）
３）テストケース配列に格納できたら、そのテストケースに配置されたペアの値によって、他のパラメータの値との関係で新たにマーキング可能な全ペア配列のペアがあるかをしらべ、ある場合は、その全ペア配列上の当該ペアをマーキングします。
４）１つのテストケース配列のすべてのパラメータの列に値が格納されるまで以上の操作を繰り返します。
（４）以上で１つのテストケースが生成できたので、（３）に戻り、次のテストケースを生成します。全ペア配列のすべてのペアがマーキングされたら生成は終了します。このとき、テストケースに空きの値がある時は、任意の値を格納します。
言葉だけの説明では分かりにくいと思いますので図で説明します。このモデルでの全ペア配列とテストケース配列を以下に示します。このモデルでは値の数がすべてのパラメータで同じなので全ペア配列は長方形になりますが、パラメータにより値の数が異なる場合は長方形の下辺がでこぼこした形になります。
この図は、最初のテストケースを生成しているところで、全ペア配列から５行目１１列目のペア（C=２、E=２）を取り出し、テストケース配列に格納し、全ペア配列の当該ペアの文字色を赤色にマーキングしたところです。テストケース配列を基に全ペア配列上のテストケース配列に格納されたすべてのペアの値を赤色にマーキングするのは、人手では間違いやすいので、「マーク」というボタンを設け、このボタンを押すと、テストケース配列で値が格納された最も下のテストケースを調べ、その行に格納されたパラメータの値で構成されるすべてのペアを全ペア配列上で文字色を赤色にマーキングするようにしています。「実行」ボタンは全ペア配列上からランダムにペアを取り出すために、行番号と列番号を決定します。
この図では、パラメータCとEの値がテストケース配列に格納されています。ここで実行ボタンをクリックして全ペア配列からランダムにペアの値を決めます。例えば、B=１、C=１のペアが該当したら、テストケース配列のパラメータCの列には既にC=2の値が格納されているので、B=１、C=１のペアは格納できません。そこで全ペア配列を下に調べて、すぐ下にB=1、C=2のペアがあることが分かります。このペアはテストケース配列に格納することができます。実際に格納するのはB=1だけになります。格納したら、全ペア配列のB=1、C=2のペアの文字色を赤色にマーキングします。
この結果、テストケース配列に格納されている値は、B=1、C=2、E=2の３つとなります。この３つの値から網羅されるペアは、B=1、C=2 と B=1、E=2 と C=2、E=2 の３つのペアとなります。B=1、E=2 はまだ全ペア配列上の値をマーキングしていないのでマーキングを行ないます。このようにテストケース配列に、あるパラメータの値を格納することで、新しく網羅されるペアが発生することがよくあります。
以上の方法（以降、簡易法という）で生成した組み合わせと同じモデルをPICTで生成した組み合わせを並べて示します。簡易法での生成結果がすべてのペアを網羅していることは確認済みです。
PICTでは１３個、簡易法では１５個となりました。簡易法もランダムな値を用いているので組み合わせの個数が若干変動しますが、何回か試してみた結果、１５個が最少でした。
パラメータの個数が同じ６個、パラメータの値が４個の場合でも試してみました。
PICTでは２３個、簡易法では２７個となりました。PICTの方が少ない個数で済んでいるのはグリーディ（貪欲）なアルゴリズムを採用しているためだと考えられます。簡易法では、テストケース配列に格納するペアをランダムに選んでいますが、グリーディな方法では、テストケース配列に格納できるペアのうち、格納した結果として最も多くのペアを網羅できるペアを選択するようにしています。
簡易法では生成される組み合わせの個数が多くなりがちですが、ランダムな条件で多くの回数生成を繰り返すことによってより少ない組み合わせの個数となることが期待できるかもしれません。
時間のかかるテストケースを少なくする
先日は、環境パラメータの考え方をサブパラメータに適用してテスト全体にかかる作業時間を短縮する方法を説明しました。今回は値の重み付けの機能を使用して、テスト作業時間を短縮する方法について説明します。
パラメータの値によってはテストに時間のかかる場合があります。例えばパラメータがタイマ値で値として１秒と２５５秒の２つがある場合、２５５秒の場合はタイムアウトするまで、４分以上待たなければなりません。
例として図１のモデルがあるとします。
このモデルの生成結果は表１のようになります。
生成結果では、タイマ値が２５５秒のテストケースが８件あります。このテストケースだけでテスト実施に３０分以上かかることになります。
値の重み付けを使って、タイマ値が１秒のテストケースを２５５秒のテストケースより、多く生成することで、テストケース全体の作業時間を短縮することができます。具体的にはタイマ値が１秒の値に重み付けを行い、通常より約２倍多く生成されるようにします。その結果、タイマ値が２５５秒のテストケースは約２分の１に減少することになります。
そのモデルを図２に示します。
このモデルの生成結果を表２に示します。
重み付けを行なった生成結果では、タイマ値が２５５秒のテストケースが８件から５件に減少しています。５件に減少してもすべてのペアは網羅されています。
値の重み付けによる選択的なテストケースの削減は、対象となるパラメータの値の個数が、最も多くの値を持つ２つ以上のパラメータが持つ値の個数より少ない場合です。そうでない場合、生成されるテストケース数が通常の生成の場合よりも増加します。そのことに注意して適用すれば、効率的なテストを行なうことができます。
テスト設計用ドキュメントの例
テスト仕様書のフォーマットをどのようにするかは大きな問題です。テストに関するドキュメントについての標準規格に IEEE 標準規格 829-1998 の IEEE Standard for Software Test Documentation があります。この規格ではスクリプトテストにおけるドキュメントを総合的に網羅しており、現時点で最も優れたテストドキュメントの標準規格だと思われます。
この標準規格では、以下の８つのドキュメントを定義しています。
・テスト計画書
・テスト設計仕様書
・テストケース仕様書
・テスト手順書
・テスト項目移管レポート
・テストログ
・テスト不具合レポート
・テストサマリレポート
このうち、テスト設計に関係するドキュメントは以下の３つです。
・テスト設計仕様書
・テストケース仕様書
・テスト手順書
IEEE 829 標準規格では、必ずしもすべてのドキュメントを作成する必要はないとしています。わたしたちのチームでは、テスト手順書の内容はテスト設計仕様書とテストケース仕様書で記述されているので、テスト手順書は作成していません。テスト設計仕様書とテストケース仕様書をまとめて「テスト仕様書」と呼びます。
IEEE 829 標準規格の詳細については、日経BP社の「体系的ソフトウェアテスト入門」や、同 「はじめて学ぶソフトウェアのテスト技法」などの書籍に明記されています。ただし、各ドキュメントの概念的な説明だけで具体例などは書かれていません。
この記事ではわたしたちのチームが使用している実際のテストドキュメントの例を示します。ここで示すドキュメントはオフィスなどで使われる大型のビジネスホンシステム（512台までの内線電話機を収容可能）を対象とした総合テストで使用したドキュメントです。
ドキュメントはすべてExcelのワークシートを使用しています。最近のビジネスホンシステムは新しい通信媒体や新しい通信端末の登場で機能が増加し、数百の機能を備えています。テスト用ドキュメントは機能ごとに１つのExcelのBook（ファイル）にまとめられています。全体として数百のExcelのBookが存在します。
テスト技法に「要因組み合わせテスト」を採用したテスト項目がある場合は、組み合わせ作成ツール MTG のBookを利用します。１つのBookはテスト設計仕様書として１つのワークシートがあり、続いてテスト小項目ごとに１つのテストケース仕様書のワークシートがあります。MTGのBookを利用したものには組み合わせテストを採用したテスト項目ごとにMTGのワークシートが存在することになります。
テスト項目の分類は、機能ごとに大項目・大項目のなかの中項目・中項目のなかの小項目、となっており、小項目はさらにいくつかのテストケースで構成されています。
それでは最初に一例として「個別保留・転送」機能に関するテスト設計仕様書を示します。
この例では、「Ｄ－０１ 個別保留・転送」が機能名称であり、大項目に相当します。これを単位として１つのＥｘｃｅｌのBookを構成します。この機能のテスト設計仕様書はワークシート名が「テスト仕様D-01」となっています。この機能についてのテストケースの件数が339件であることが左上の集計欄から分かります。
テスト設計仕様書のワークシートは、項目番号（中項目）と細目番号（小項目）とから成り立っています。このワークシートには、テスト小項目ごとにテスト操作欄、確認内容欄、参考欄、そして「機能説明書との関連」欄があります。
「機能説明書との関連」欄には、そのテスト小項目が機能説明書のどの記述項目の部分についてのテストなのかを記入します。この記述があるおかげで、そのテストで確認しようとする機能の詳細が分かり、テスト内容の意味を把握する上で参考になります。
「参考」欄には、そのテストを実施するために必要なテスト環境について記述します。具体的にはシステムのデータ設定項目とその設定値などです。ビジネスホンシステムは、このシステムデータの設定内容によって、さまざまな機能がどのように動作するかを指定するようにできています。システムデータの種類には膨大な数があり、テスト担当者がテスト実施時に独力で設定項目を把握することは困難な場合が多いため、テスト設計時に設定すべきデータ項目とその設定値を調査し、明記しておきます。
「テスト操作」欄には、そのテストで行なう操作を順番に箇条書きで記述します。「チェックシート」とあるのは、テストケース仕様書のワークシートのことです。
「確認内容」欄には、テスト操作欄の番号に対応する形で、その操作を行なったことでどのような結果となるかを箇条書きで記述します。確認内容欄の記述どおりの結果となればテストはOKとなります。
次にこのテスト仕様書の「テストケース仕様書」の一例を以下に示します。
このテストケース仕様書（チェックシート）には67件のテストケースのあることが左上の集計欄から分かります。この例ではテスト技法に「要因組み合わせテスト」を採用しており、このワークシート（1-1）のテストケースはMTGが生成したものです。そのMTGのワークシートは「要因1-1」というワークシート名のシートです。8行目には10個のパラメータ欄があり、列 L、M、N には、そのテストケースで使用した端末、回線など、リソースの具体的な番号を記入します。その右側に、合否欄、確認者名欄、日付欄、テストに使用したソフトウェアのバージョンを記入するバージョン欄、障害が検出された場合に、発行した障害票の発行番号を記入する障害票欄があります。
次にこのテストケースを生成したPictMsterのワークシートを以下に示します。
このワークシート（要因1-1）で、左上の「D-01 個別保留・転送」が大項目名であり、大項目No. が中項目の番号、小項目No. が小項目の番号に相当します。
以上のようにExcelベースでテスト仕様書を作成することにより、MTGのワークシートも含めてテスト設計仕様書とテストケース仕様書をまとめて１つのファイルで管理することが可能となります。
さらにはすべてのテスト仕様書についてExcelの関数を駆使することで、１つのテスト進捗状況管理用のファイルで大項目ごとの進捗状況を把握することが可能となります。あとは工夫次第で1日ごとのテストケース消化件数、テスト担当者別の消化件数など、さまざまな情報を収集し、グラフ化してビジュアルに表示することも可能です。
VBAが使える人ならさらに自由にカスタマイズが可能となります。テスト仕様書をExceｌで作成することでテストプロジェクトにカスタマイズした使いやすい管理ツールを比較的容易に作成することができます。
詳解 PICTのヒューリスティック・アルゴリズム
以下で示すPICTのアルゴリズムは、例によってPICTの開発者であるJacek Czerwonka氏が2006年に発表した論文「Pairwise Testing in Real World」からの引用です。そのアルゴリズムを図5に示します。図5で示されているアルゴリズムは最終的にはいくつかのテストケースの集まりとなる組み合わせのうち、1つのテストケースの1つの組み合わせを生成するアルゴリズムを示しています。このアルゴリズムの記述では、説明を簡単にするためにいくつかの仮定（前提条件）が用いられています。
注釈のために数字記号を追記したものを示します。
このアルゴリズムについて、注釈の数字順に従って説明していきます。
以上のアルゴリズムは、1つのテストケースの1つの組み合わせを生成する部分についてのものです。このアルゴリズムを繰り返し実行することで、組み合わせの集合P において除外組み合わせを除いた残りのすべての組み合わせが網羅とマーキングされ、かつテストケース ri のすべてのパラメータに値があるとき、必要とされるすべてのテストケースの生成は完了します。
⑧と⑮で「未網羅組み合わせを最も多く網羅する」スロットを選択していますが、この部分が「グリーディ」（どん欲な）と呼ばれる部分です。できるだけ少ないテストケース数ですべての可能な組み合わせを網羅しようとする、言い換えれば、うまく行けば最適解、最適解でなくともできるだけ最適解に近い結果を得ようとすることから、PICTが採用しているアルゴリズムは、正確には「グリーディ・ヒューリスティック・アルゴリズム」と呼ばれます。ヒューリステックとは自己発見的という意味です。いつも同じ結果となるアルゴリズムと異なり、シード値という初期条件によって異なる結果となります。おそらく組み合わせの制約をサポートするには、ヒューリステック・アルゴリズムが最適と考えられます。