Pairwise法（All-Pairs法）の定義
そこで今回は正確な定義を以下に示します。英文字の実際の形状が判別できるように画像データを用いています。
一読してなにがなんだか分からないかもしれませんが、注釈を加えると、「因子」とあるのは「パラメータ」のことです。「レベル」とはパラメータの「値」のことです。集合RがPairwise法によるテストケースの集まりを意味します。
なお、この定義はPICTの開発者であるJacek Czerwonka氏が2006年に発表した論文「Pairwise Testing in Real World」からの引用です。同論文によれば、この概念は、すべてのペアを網羅するPairwiseから、任意のt-wiseによる組み合わせ（1 ≦ t ≦ N）を網羅するまで簡単に拡張できるとしています。
制約を考慮しない場合は簡潔に定義できることが分かります。制約を考慮しなくてよいのならテストケース生成エンジンは比較的簡単に作成できそうですが、制約をサポートしようとするととたんに難しくなります。作成するからには極めて多数の制約を指定した場合でもテストケース生成にかかる時間を実用的な範囲内に納める必要があります。少なくともPICTの生成時間よりは、はるかに短時間で生成できなければ新しいエンジンを作成する意味がありません。かなりハードルが高そうです。
テストのほとんどが既存製品をベースにした新製品のテスト
本当の意味での新製品の場合は、すべてが新しいソフトウェアであり、当然そのテストにもかなりの工数がかかります。一方、大部分の新製品は、既存製品のソフトウェアのほとんどを流用し、その上に新規機能の新しいソフトウェアを組み込んでいくことになります。
こうした新製品のテストはそのソフトウェアの構成から、テスト戦略としてリスクベースドテストが採用されることが多いようです。つまり、新機能については徹底したテストを行なうが、既存機能についてはそれほど徹底したテストは行なわない、といったやり方になります。手を抜いてよいところは手を抜いてテスト期間を短縮できるようになります。
こうしたリスクベースドテストは既存製品をベースにした「新製品」のテスト方法として理にかなっており、実際に市場に出荷した後の市場障害からみても既存機能が原因の障害はかなりすくない傾向となっています。
新機能が絡む障害でよく見られるパターンとして、既存機能と新機能との間でのミスマッチがあります。これは総合テストで実際に見つかった例ですが、ビジネスホンの機能で、電話がかかってきたら、電話機のテンキーのバックライトが点灯する機能があります。これが新製品では、かけてきた相手に応じて異なる色でバックライトが点灯する新機能が追加になりました。総合テストでは異なる相手から着信があると相手に対応した色でバックライトが点灯することはでＯＫでした。しかし、複数の相手からかかってきた場合、最初にかけてきた相手の色でバックライトが点灯しますが、その最初にかけてきた相手が途中放棄（呼び出し中に電話を切ること）した場合、仕様では２番目にかけてきた相手の色に切り替わることになっていますが、実際の動作はそうならず、最初の相手の色のままであるという障害です。
この例では、機能仕様書では複数の着信があって、最初にかけてきた相手が電話を切った場合、２番目にかけてきた相手に対応した色に切り替わる、ということまでは書かれていません。なぜなら、こうしたことはビジネスホンの世界では常識であり、いわば「暗黙知」となっている事項だからです。このような暗黙知はたくさんあり、いちいちそれを機能仕様書に明記していたら仕様書の記述が冗長になり、逆に読みにくいものになってしまうでしょう。常識なので書かれていませんがそのことがソフトウェア開発者のうっかり考慮漏れにつながった例です。当人はそのことを指摘されて当然考慮すべきことを考慮していなかったことにはじめて気がつきます。ソフトウェア開発における暗黙知の扱いについてはそれだけでかなりの分量の記事が書けそうです。
このように新機能を組み込んだことによって、既存機能との連携がとれていないという障害が少なからず発生します。テスト仕様書を作成する側は、機能仕様書に書かれていることはもちろん、機能仕様書には書かれていないこと（暗黙知）も考慮してテスト仕様書を作成することになります。
話をリスクベースドテストに戻しますと、新機能については要因組み合わせテストも含めて徹底したテストを行ないます。これに対して、仕様に変更のない既存機能に関しては、要因の組み合わせテストは行なわず、単に各要因を列挙するだけの要因列挙テストにとどめることによってテストケースを大幅に省略します。
リスクベースドテストでテスト項目にメリハリをつけることによって合理的にテスト工数を抑えることができます。リスクベースドテストの考え方はこの記事で示した事項だけではなくより幅広い概念ですが、ひとつの適用対象として例に挙げました。
テスト実施時間に大きな影響を及ぼす「環境パラメータ」とサブモデルによる回避策
Pairwise法（All-Pairs法）で扱うパラメータには様々なものありますが、このパラメータには一般的な「入力パラメータ」と入力パラメータの組み合わせが実行される環境である「環境パラメータ」の２つに分けて考えることができます。ここで「環境パラメータ」とは例えばハードウェアの組み合わせなどを意味します。環境パラメータの考え方は富士通の辰巳敬三さんが提唱されたものです。
環境パラメータは、その構成の組み合わせを変更することにかなり時間がかかる例が少なくありません。コンピュータシステムのハードディスクを取り替えてテストを行なうなど、組み合わせのバリエーションを実現するのに時間がかかるという性質があると一般的には言えるでしょう。
組み合わせテストを実施する場合、環境パラメータの組み合わせがなるべく少なくなるようにすることができれば、テスト実施時間を短くすることができます。これをPICTの「サブモデル」を用いることで実現することができます。
では具体的な例をもとに説明します。
図１はコンピュータのハードディスクをテストする組み合わせモデルの例です。
このモデルで、黄色に塗りつぶした３つのパラメータが環境パラメータです。これらのパラメータは簡単に設定を変えれば済むという訳にはいきません。これらのパラメータの組み合わせ構成を実現するには時間がかかります。
まず通常の方法で生成したテストケースを表１に示します。
この例ではテストケースは32件となりました。表１の右端の欄は環境パラメータの種類番号を表します。全部で15種類あります。
次にサブモデルを用いた例を図２に示します。３つの環境パラメータのみサブモデルで２パラメータ間の組み合わせを定義します。
このモデルでは３つの環境パラメータがサブモデルによってペアの組み合わせとして生成され、それは9種類となります。その後に残りのパラメータと２パラメータ間の組み合わせが網羅されます。このことから、環境パラメータの組み合わせはサブモデルを使用しない場合の15種類に対して9種類と少なくなります。
このモデルで生成したテストケースを表２に示します。
この例ではテストケース数はサブモデルを使用しない場合の32件に比べて54件と増えますが、構成変更に時間のかかる環境パラメータの組み合わせ数が大幅に少なくなることによって結果的にテストケース全体のテスト実施時間が短くなることが期待できます。
このように組み合わせを変更する際に時間のかかるパラメータが複数存在する場合は、サブモデルを使用することで短時間でテストが実施できるようにすることができます。
※ この記事は、MicrosoftのJack Czerwonka氏のPICTに関する論文「Pairwise Testing in Real World」から引用した内容を基にしています。
組み合わせ生成エンジン開発の可能性
既存のフリーなソフトウェアで制約をサポートした生成エンジンは他には見当たらないようです。それなら新しい生成エンジンを自前で開発するという手があります。これまで検討してきた結果から、制約指定の機能を持たないPairwise法の生成エンジンであれば比較的容易に開発が可能との感触を得ています。この生成エンジンのアルゴリズムはPICTと同じヒューリスティック手法を用いたものです。
問題は、制約指定の機能を持たせた場合に、開発工数が一気に増大することです。どれぐらい増大するかは、制約指定の機能を持たない場合に比べて少なくとも４～５倍は工数がかかると見ています。それだけの工数をかけてまで開発するメリットがあるかどうかですが、PICTでは実用的に扱えない複雑で大規模なモデルでも短時間で生成が完了する点で大きなメリットがあると考えます。
今すぐは無理でも将来的には開発したいと考えています。
「命令網羅」の制御パステストケースを生成する
これまでの制御パステストのテストケース生成では、すべて条件網羅を扱ってきましたが、制約表の指定方法を変えることで命令網羅のテストケースも生成することができます。
例えば次のように条件がTrueの場合のみ命令文があるif文が３つ連続するプログラムがあるとします。
このプログラムの命令網羅のテストケースを生成するためのパラメータと値の並び、および制約表は次の通りとなります。
このモデルで組み合わせるパラメータ数に１を指定し、最少テストケース生成を行ないます。こうして生成されたテストケースの例を次に示します。
このテストケースで、ダミーの値だけで構成されているNo.1の組み合わせは、組み合わせる値の数は最低でも２つ必要というPICTの制限事項から生成されたものなので、テストケースからは削除します。そうすると、このプログラムの命令網羅のテストケースはNo.2のテストケース１つとなります。
命令網羅のテストケースを生成する際は、条件文で分岐先に命令文や条件文を含まない単なる迂回するパスの場合、その分岐先の値にはダミーの値「－」を組み合わせるように制約表で指定することがポイントとなります。
実際のプログラムでは、この３つのif文のTrueだけを通るパスは存在しないかもしれません。その場合は、通れるパスを制約表で定義することになります。