制御パステストの制約表への記入自動化について
制約表を用いることで制御パステストのテストケースを容易に作成することができるようになりました。ただ、容易とはいってもプログラムの制御構造を制約表にマッピングするにはそれなりの時間がかかります。難しい作業ではありませんが機械的作業を間違いなく行なう必要があります。
機械的作業が中心になりますからこの作業を自動化できる可能性があります。制約表へのマッピングからテストケースの生成まで自動的に実行するソフトウェアの開発は想像するよりも簡単かもしれません。仮にそうしたテストケース生成ツールが誕生すれば、従来の制御パステストはもちろん、2つの要因の組み合わせを網羅したテストケースが生成できるこれまでになかったツールということになります。
今ある単体テスト用のツールで制御パステストをサポートしたものがいろいろありますが、それぞれに基本的な考え方が異なっているものが多いと感じます。よくあるツールでは、最初にユーザがプログラムを色々な条件で実行した後で、実行した命令網羅の網羅率（カバレッジ）を表示するものがあります。どのステートメントを実行し、どのステートメントが実行されていないか、ソースリスト上で色分けして表示するものです。これなどは命令網羅レベルをサポートしたものだと思います。
条件網羅をサポートしたツールもあることにはありますが、最初にプログラムの引数、スタブの返り値、グローバル変数の値、などなど非常にこまごました多くの値を定義ファイルとして作成する必要があり、その作業だけでもかなり工数がかかりそうです。それに価格が1ユーザあたり50万円～100万円と非常に高価です。
多くの単体ツールは、制御パステストについては実用上の制限事項が多いと感じました。ないよりはましといったレベルといったら言い過ぎでしょうか。
制約表を用いる方法は、最初に条件網羅の完全なテストケースを生成するという点が、従来のツールにはなかった考え方です。スタブの扱いが必要な点はありますが。また命令網羅についても制約表を用いることで、そのテストケースを生成することは可能と思われます。ただし組み合わせ生成エンジンは新しく作らなければなりません。PICTではパラメータが20個を超えるあたりから生成時間が急激に増加するため、ステップ数の多いプログラムには適用できないからです。
今は無理ですが、将来的には実現に向けてチャレンジするかもしれません。
機械的作業が中心になりますからこの作業を自動化できる可能性があります。制約表へのマッピングからテストケースの生成まで自動的に実行するソフトウェアの開発は想像するよりも簡単かもしれません。仮にそうしたテストケース生成ツールが誕生すれば、従来の制御パステストはもちろん、2つの要因の組み合わせを網羅したテストケースが生成できるこれまでになかったツールということになります。
今ある単体テスト用のツールで制御パステストをサポートしたものがいろいろありますが、それぞれに基本的な考え方が異なっているものが多いと感じます。よくあるツールでは、最初にユーザがプログラムを色々な条件で実行した後で、実行した命令網羅の網羅率（カバレッジ）を表示するものがあります。どのステートメントを実行し、どのステートメントが実行されていないか、ソースリスト上で色分けして表示するものです。これなどは命令網羅レベルをサポートしたものだと思います。
条件網羅をサポートしたツールもあることにはありますが、最初にプログラムの引数、スタブの返り値、グローバル変数の値、などなど非常にこまごました多くの値を定義ファイルとして作成する必要があり、その作業だけでもかなり工数がかかりそうです。それに価格が1ユーザあたり50万円～100万円と非常に高価です。
多くの単体ツールは、制御パステストについては実用上の制限事項が多いと感じました。ないよりはましといったレベルといったら言い過ぎでしょうか。
制約表を用いる方法は、最初に条件網羅の完全なテストケースを生成するという点が、従来のツールにはなかった考え方です。スタブの扱いが必要な点はありますが。また命令網羅についても制約表を用いることで、そのテストケースを生成することは可能と思われます。ただし組み合わせ生成エンジンは新しく作らなければなりません。PICTではパラメータが20個を超えるあたりから生成時間が急激に増加するため、ステップ数の多いプログラムには適用できないからです。
今は無理ですが、将来的には実現に向けてチャレンジするかもしれません。
ユーザーズマニュアルの訂正版をＵＰしました。
ＭＴＧ 3.1のユーザーズマニュアルの内容に記述ミスと記述漏れがありました。
内容を訂正したユーザーズマニュアル3.1.1版をＵＰしましたので旧版との差し替えをお願いします。 m(_ _)m
訂正事項は以下の通りです。
19ページ目、下から5行目の「５個以上の場合で」を「８個以上の場合で」に訂正。
55ページ目、下から4行目「例えばa2とb2の組み合わせ」を「例えばc2とd1の組み合わせ」に訂正。
3.5.2 特定のパラメータのみ３パラメータ間の組み合わせとするの章を記述内容訂正。
ダウンロードは以下のＵＲＩからできます。
http://sourceforge.jp/projects/pictmaster/docman/
このページに掲載されているドキュメントで、上から３つ目の
ＭＴＧユーザーズマニュアル 3.1.1版
です。
【重要】
マニュアルを開いたとき、Adobe Readerに「この文書はPDF/Aモードで表示されています。」とのメッセージが表示され、ＰＤＦ文書のハイパーリンクが無効となっている場合があります。原因は不明ですが、Adobe Readerの設定で、文書 → PDF/Aモードで文書を表示 の項目が「PDF/Aモード文書のみ」となっている場合は、「適用しない」に変更すると、ハイパーリンクが使えるようになります。
内容を訂正したユーザーズマニュアル3.1.1版をＵＰしましたので旧版との差し替えをお願いします。 m(_ _)m
訂正事項は以下の通りです。
19ページ目、下から5行目の「５個以上の場合で」を「８個以上の場合で」に訂正。
55ページ目、下から4行目「例えばa2とb2の組み合わせ」を「例えばc2とd1の組み合わせ」に訂正。
3.5.2 特定のパラメータのみ３パラメータ間の組み合わせとするの章を記述内容訂正。
ダウンロードは以下のＵＲＩからできます。
http://sourceforge.jp/projects/pictmaster/docman/
このページに掲載されているドキュメントで、上から３つ目の
ＭＴＧユーザーズマニュアル 3.1.1版
です。
【重要】
マニュアルを開いたとき、Adobe Readerに「この文書はPDF/Aモードで表示されています。」とのメッセージが表示され、ＰＤＦ文書のハイパーリンクが無効となっている場合があります。原因は不明ですが、Adobe Readerの設定で、文書 → PDF/Aモードで文書を表示 の項目が「PDF/Aモード文書のみ」となっている場合は、「適用しない」に変更すると、ハイパーリンクが使えるようになります。
MTG 3.1をリリースしました。
MTG 3.1をリリースしました。
今回のリリースでは、MTGの使い勝手の向上に焦点をあてたもので機能改善がメインです。
以下の機能改善により前バージョンよりより使いやすさを向上させました。
【機能改善】
1. 制約表などの編集専用のコンテキストメニューによる、行の挿入、削除、列の挿入、削除、元に戻す、操作で一呼吸待たされていたが、これを瞬時に完了するようにレスポンスを向上させた。
2. 環境設定の内容をワークシート右上に常時表示させておくことができるようにした。
3. ユーザが指定した制約指定をプログラム内部で最適化し、パラメータの値の個数が多いために組み合わせ生成に長時間かかるケースで生成時間を大幅に短縮化する「制約式最適化」の機能を追加した。
4. サブモデル記入欄で１行をセミコロン（;）で区切ることで複数のサブモデル指定を１行に記入できるようにした。
「制約式最適化」の機能は、制約指定したパラメータの値が多いときに、組み合わせ生成に長時間かかる制約指定をユーザが行なった場合に、MTG内部で組み合わせ生成時間が最も短くなるよう、ユーザが指定した制約指定と等価な別の形式の制約指定に変換する機能です。この機能が効果を発揮するケースはそれほど多くはないと思いますが、最も効果的なケースでは組み合わせ生成時間を数十分の１から数百分の１に短縮できます。
なお、ユーザーズマニュアルの制約式最適化の機能が有効となる条件の説明で、パラメータの値の個数が５個以上の場合、と記述した部分がありますが、正しくは８個以上の場合です。
MTGは以下のサイトからダウンロードすることができます。
http://sourceforge.jp/projects/pictmaster/
今回のリリースでは、MTGの使い勝手の向上に焦点をあてたもので機能改善がメインです。
以下の機能改善により前バージョンよりより使いやすさを向上させました。
【機能改善】
1. 制約表などの編集専用のコンテキストメニューによる、行の挿入、削除、列の挿入、削除、元に戻す、操作で一呼吸待たされていたが、これを瞬時に完了するようにレスポンスを向上させた。
2. 環境設定の内容をワークシート右上に常時表示させておくことができるようにした。
3. ユーザが指定した制約指定をプログラム内部で最適化し、パラメータの値の個数が多いために組み合わせ生成に長時間かかるケースで生成時間を大幅に短縮化する「制約式最適化」の機能を追加した。
4. サブモデル記入欄で１行をセミコロン（;）で区切ることで複数のサブモデル指定を１行に記入できるようにした。
「制約式最適化」の機能は、制約指定したパラメータの値が多いときに、組み合わせ生成に長時間かかる制約指定をユーザが行なった場合に、MTG内部で組み合わせ生成時間が最も短くなるよう、ユーザが指定した制約指定と等価な別の形式の制約指定に変換する機能です。この機能が効果を発揮するケースはそれほど多くはないと思いますが、最も効果的なケースでは組み合わせ生成時間を数十分の１から数百分の１に短縮できます。
なお、ユーザーズマニュアルの制約式最適化の機能が有効となる条件の説明で、パラメータの値の個数が５個以上の場合、と記述した部分がありますが、正しくは８個以上の場合です。
MTGは以下のサイトからダウンロードすることができます。
http://sourceforge.jp/projects/pictmaster/
まもなく新バージョン（MTG 3.1）をリリースします。
間もなくMTGの新バージョンをリリースします。今週末にはリリース予定です。
新バージョンでは機能改善がメインでより使いやすく機能改善したものになります。
おもな変更内容は以下の通りです。
【機能改善】
・制約表などの編集専用のコンテキストメニューによる、行の挿入、削除、列の挿入、削除、元に戻す、操作で一呼吸待たされていたが、瞬時に完了するようにレスポンスを向上させた。
・環境設定の内容をワークシート右上に常時表示させておくことができるようにした。
・ユーザが指定した制約指定をプログラム内部で最適化し、パラメータの値の個数が多いために組み合わせ生成に長時間かかるケースで生成時間を大幅に短縮化する機能を追加した。
・サブモデル記入欄で１行をセミコロン（;）で区切ることで複数のサブモデル指定を１行に記入できるようにした。
以上です。
新バージョンでは機能改善がメインでより使いやすく機能改善したものになります。
おもな変更内容は以下の通りです。
【機能改善】
・制約表などの編集専用のコンテキストメニューによる、行の挿入、削除、列の挿入、削除、元に戻す、操作で一呼吸待たされていたが、瞬時に完了するようにレスポンスを向上させた。
・環境設定の内容をワークシート右上に常時表示させておくことができるようにした。
・ユーザが指定した制約指定をプログラム内部で最適化し、パラメータの値の個数が多いために組み合わせ生成に長時間かかるケースで生成時間を大幅に短縮化する機能を追加した。
・サブモデル記入欄で１行をセミコロン（;）で区切ることで複数のサブモデル指定を１行に記入できるようにした。
以上です。
詳解 制御パステストの制約表への記入方法 【７月３１日追記】
制御パステストのテストケースを生成する制約表への記入の仕方を示すと以下の通りとなります。
。
(1) 制御パスを変える判定文（if, else, for, while, switch, break, continue, return, …）などをもれなくパラメータとする。
(2) パラメータの取りうる値（TRUE, FALSE,…）を決める。論理値以外に実際の判定文（a>10, a=<10など）を記入してもよい。この他に、このパラメータ（判定文など）を通らないパスを表すダミーの値、（－）なども必要となる場合が多い。
(3) プログラムによっては、代入文もパラメータに含めることで、生成されたテストケースが理解しやすくなる効果があり、代入文をシンボリックに表現したパラメータと値を定義してもよい。
(4) 制約表へは、制約条件としてパラメータの値を記入し、値ごとに次に通るパラメータを制約対象として記入する。
(5) 制約対象として記入されたパラメータの値は、右隣の制約欄の列で、制約条件としてそれぞれの値を記入する。その値のときに通るパラメータの欄に制約対象として次に通るパラメータを記入する。
制約表への記入は、要約して言えば、ある制約欄で制約条件と制約対象を記入し、次の制約欄で制約対象を制約条件として記入し、新しい制約対象を記入する、というサイクルを繰り返すことになります。その結果、制約表への記入は左上から始まって右下で終わる記入パターンを取ることになります。
それでは実際に具体例を取り上げてましょう。ExcelのVBAで書かれた CompCell というプログラムがあるとします。
このプログラムの仕様は以下の通りです。
① ExcelのA列１行目から、カンマ（,）で区切られた０以上の１つ以上の数字列がある。
② CompCellのプログラムを実行すると、A列１行目から、カンマで区切られた数値を１つずつ取り出し、最も小さい数をB列に、最も大きい数をC列に設定する。値が100以上の場合は99に変換して評価する。
③ A列に何も値が設定されていない行に差しかかったら、次にB列とC列の値を最初から調べ、B列で最も小さい値をその行のD列に設定する。またC列で最も大きい値をE列に設定して処理を終了する。
例えば、ワークシートに左側の値が設定されていた場合、プログラムCompCellの実行で右側の値が設定されることになります（図１）。
図１．プログラムCompCellの実行前と実行後
次にプログラムCompCellのソースリストを示します。
リスト１．プログラムCompCellのソースリスト
このソースリストで、12行目から31行目でA列の値を処理しています。16行目から27行目でA列の１つのセルに含まれるカンマで区切られた値を１つずつ処理して最小値をB列、最大値をC列に設定しています。35行目から47行目でB列の最小値、C列の最大値を求めています。最後に48行目と49行目でB列の最小値、C列の最大値をその値がある行のD列とE列に設定しています。
このプログラムの制御パステスト（条件網羅）のテストケースを生成するモデルと制約表を次に示します。
図２．制御パステストのテストケースを生成するモデルと制約表
リスト１と図３をもとに、ソースリストから制約表への記入の仕方を説明します。
最初にパラメータとその値を決めます。パラメータはソースリストとの対応がとりやすいように行番号と判定文を組み合わせた名称とします。パラメータの値は if, for, loop while, do whileなら TRUE, FALSE となります。その他に、この文を通らないパスがあるのでその場合に使用するダミーの（-）という値も定義します。if文以外の do, loop, nextの値は任意の名称でかまいません。この例ではキーワード名をそのまま用いています。
次に制約表へ記入を行ないます。
パラメータ7ifでは、制約条件としてTRUEとFALSEを記入します。TRUEの場合は、エラー終了なので制約１の列をすべてダミーの値を記入します。FALSEの場合は、16forでTRUEとFALSEを制約対象として記入します。そして同じ行で右隣の制約欄にTRUEとFALSEを制約条件として記入します。
16forがTRUEの場合は、ソースリストから３つのif文が連続しているので、制約対象として18if、21if、24ifの欄にTRUEとFALSEを記入し、27nextにnextと記入します。このパスは、forで繰り返すので、31loop whileから以降は通らないため、ダミーの値を記入します。
16forがFALSEの場合は、繰り返し処理が終了したことを意味するので31loop whileまでジャンプするため、そこまでのパラメータにはダミーの値を記入します。
31loop whileでは右隣の制約欄にTRUEとFALSEの制約条件を記入します。A列をすべて処理していない場合はTRUEとなり、12doから繰り返します。そのため、35do while以降はダミーの値を記入する。
A列をすべて処理した場合はFALSEとなり、35do whileの行に制約対象としてTRUEとFALSEを記入します。そしてその右隣の制約欄に制約条件としてTRUEとFALSEを記入します。
35do whileがTRUEの場合は、処理すべきB列の行が残っているので38if、40ifのTRUEとFALSEそして47loopにloopを記入して処理を繰り返すことを表します。
35do whileがFALSEの場合は、処理すべきすべてのB列の行を処理し終えたので、38if以降から47loopは実行しないので制約対象としてダミーの値を記入します。
以上で一通り必要な制約指定を記入し終えたことになります。しかし、ソースリストの18行目から24行目をよく見てみると、18ifがTRUEで21ifもTRUEの場合は、24ifは必ずTRUEを通るので、制約９でこの条件を指定しています。
これで制約表への記入が完了しました。ソースリストからそのまま制約表へ転記できることがお分かりいただけたと思います。この制約表を用いて組み合わせるパラメータに２を指定して組み合わせを生成すると、１１個の次のテストケースが得られます（最少テストケース生成の機能を使用しているので異なる結果となる場合もある）。
表１．Pairwise法と制約表で生成した制御パステストのテストケース
生成されたテストケースは、２パラメータ間の組み合わせを網羅しているため、２パラメータ間の組み合わせで発生する障害を検出することができます。ただし、テストケース数は通常の条件網羅に比べて若干増加するという負担があります。ちなみにこの例での通常の条件網羅のテストケースは７となります。
PICTでは組み合わせるパラメータ数を指定することができるので、１を指定すれば通常の条件網羅のテストケースが生成できます。プログラムの重要度に応じて使い分けることがよいでしょう。
テストケースができたら、各テストケースを通るテストデータのセットを決めます。この例の場合では、A列に何行か値が記入されたデータがテストデータのセットとなります。１つのテストデータのセットでは、テストケースをすべてカバーすることができないため、最低２つの異なるテストデータのセットが必要となる点が今までのプログラムと異なる点です。
テストデータを決める際に、テストケースには存在しないパスを通るテストデータが見つかることがあります。その理由は、このテストケースが条件網羅であるため、すべてのパスを網羅する経路網羅のテストケースとはことなり、可能な制御パスのうちの一部だけを生成しているためです。特にif文が連続している部分が多いプログラムにはその傾向が顕著に現れます。
それでは実際にテストデータのセットを決めてみましょう。このプログラムのテストケースをすべて通るテストデータのセットはワークシートのA列にいくつかの値を記入した行が何行か続く形になります。
A行１行目から順番に決めていきます。その行をプログラムが処理することで通過するテストケースの番号も併記することにします。
A列１行目
10, 1, 20 ・・・ 1がNo.8、20がNo.9、そしてNo.3を通ります。値が10はテストケースにないパスを通ります。
A列２行目
100, 99, 100 ・・・ 100がNo.10、99がNo.8、100がNo.7、No.3
A列３行目
50, 0 ・・・ 0がNo.8、No.3
A列４行目
10, 50 ・・・ 50がNo.9、No.3
A列５行目
（空白） ・・・ No.1、No.4、No.6、No.2、No.5
そしてエラーメッセージを表示する
A列１行目
（空白） ・・・ No.11
というテストデータになります。これは一例ですのでこれ以外にもいろいろ考えられます。このテストデータでのプログラムの実行結果を以下に示します。
図３．プログラムの実行結果
生成されたテストケースを通るようにテストデータを決定するステップは、慎重に決定する必要があります。
。
(1) 制御パスを変える判定文（if, else, for, while, switch, break, continue, return, …）などをもれなくパラメータとする。
(2) パラメータの取りうる値（TRUE, FALSE,…）を決める。論理値以外に実際の判定文（a>10, a=<10など）を記入してもよい。この他に、このパラメータ（判定文など）を通らないパスを表すダミーの値、（－）なども必要となる場合が多い。
(3) プログラムによっては、代入文もパラメータに含めることで、生成されたテストケースが理解しやすくなる効果があり、代入文をシンボリックに表現したパラメータと値を定義してもよい。
(4) 制約表へは、制約条件としてパラメータの値を記入し、値ごとに次に通るパラメータを制約対象として記入する。
(5) 制約対象として記入されたパラメータの値は、右隣の制約欄の列で、制約条件としてそれぞれの値を記入する。その値のときに通るパラメータの欄に制約対象として次に通るパラメータを記入する。
制約表への記入は、要約して言えば、ある制約欄で制約条件と制約対象を記入し、次の制約欄で制約対象を制約条件として記入し、新しい制約対象を記入する、というサイクルを繰り返すことになります。その結果、制約表への記入は左上から始まって右下で終わる記入パターンを取ることになります。
それでは実際に具体例を取り上げてましょう。ExcelのVBAで書かれた CompCell というプログラムがあるとします。
このプログラムの仕様は以下の通りです。
① ExcelのA列１行目から、カンマ（,）で区切られた０以上の１つ以上の数字列がある。
② CompCellのプログラムを実行すると、A列１行目から、カンマで区切られた数値を１つずつ取り出し、最も小さい数をB列に、最も大きい数をC列に設定する。値が100以上の場合は99に変換して評価する。
③ A列に何も値が設定されていない行に差しかかったら、次にB列とC列の値を最初から調べ、B列で最も小さい値をその行のD列に設定する。またC列で最も大きい値をE列に設定して処理を終了する。
例えば、ワークシートに左側の値が設定されていた場合、プログラムCompCellの実行で右側の値が設定されることになります（図１）。
次にプログラムCompCellのソースリストを示します。
このソースリストで、12行目から31行目でA列の値を処理しています。16行目から27行目でA列の１つのセルに含まれるカンマで区切られた値を１つずつ処理して最小値をB列、最大値をC列に設定しています。35行目から47行目でB列の最小値、C列の最大値を求めています。最後に48行目と49行目でB列の最小値、C列の最大値をその値がある行のD列とE列に設定しています。
このプログラムの制御パステスト（条件網羅）のテストケースを生成するモデルと制約表を次に示します。
最初にパラメータとその値を決めます。パラメータはソースリストとの対応がとりやすいように行番号と判定文を組み合わせた名称とします。パラメータの値は if, for, loop while, do whileなら TRUE, FALSE となります。その他に、この文を通らないパスがあるのでその場合に使用するダミーの（-）という値も定義します。if文以外の do, loop, nextの値は任意の名称でかまいません。この例ではキーワード名をそのまま用いています。
次に制約表へ記入を行ないます。
パラメータ7ifでは、制約条件としてTRUEとFALSEを記入します。TRUEの場合は、エラー終了なので制約１の列をすべてダミーの値を記入します。FALSEの場合は、16forでTRUEとFALSEを制約対象として記入します。そして同じ行で右隣の制約欄にTRUEとFALSEを制約条件として記入します。
16forがTRUEの場合は、ソースリストから３つのif文が連続しているので、制約対象として18if、21if、24ifの欄にTRUEとFALSEを記入し、27nextにnextと記入します。このパスは、forで繰り返すので、31loop whileから以降は通らないため、ダミーの値を記入します。
16forがFALSEの場合は、繰り返し処理が終了したことを意味するので31loop whileまでジャンプするため、そこまでのパラメータにはダミーの値を記入します。
31loop whileでは右隣の制約欄にTRUEとFALSEの制約条件を記入します。A列をすべて処理していない場合はTRUEとなり、12doから繰り返します。そのため、35do while以降はダミーの値を記入する。
A列をすべて処理した場合はFALSEとなり、35do whileの行に制約対象としてTRUEとFALSEを記入します。そしてその右隣の制約欄に制約条件としてTRUEとFALSEを記入します。
35do whileがTRUEの場合は、処理すべきB列の行が残っているので38if、40ifのTRUEとFALSEそして47loopにloopを記入して処理を繰り返すことを表します。
35do whileがFALSEの場合は、処理すべきすべてのB列の行を処理し終えたので、38if以降から47loopは実行しないので制約対象としてダミーの値を記入します。
以上で一通り必要な制約指定を記入し終えたことになります。しかし、ソースリストの18行目から24行目をよく見てみると、18ifがTRUEで21ifもTRUEの場合は、24ifは必ずTRUEを通るので、制約９でこの条件を指定しています。
これで制約表への記入が完了しました。ソースリストからそのまま制約表へ転記できることがお分かりいただけたと思います。この制約表を用いて組み合わせるパラメータに２を指定して組み合わせを生成すると、１１個の次のテストケースが得られます（最少テストケース生成の機能を使用しているので異なる結果となる場合もある）。
生成されたテストケースは、２パラメータ間の組み合わせを網羅しているため、２パラメータ間の組み合わせで発生する障害を検出することができます。ただし、テストケース数は通常の条件網羅に比べて若干増加するという負担があります。ちなみにこの例での通常の条件網羅のテストケースは７となります。
PICTでは組み合わせるパラメータ数を指定することができるので、１を指定すれば通常の条件網羅のテストケースが生成できます。プログラムの重要度に応じて使い分けることがよいでしょう。
テストケースができたら、各テストケースを通るテストデータのセットを決めます。この例の場合では、A列に何行か値が記入されたデータがテストデータのセットとなります。１つのテストデータのセットでは、テストケースをすべてカバーすることができないため、最低２つの異なるテストデータのセットが必要となる点が今までのプログラムと異なる点です。
テストデータを決める際に、テストケースには存在しないパスを通るテストデータが見つかることがあります。その理由は、このテストケースが条件網羅であるため、すべてのパスを網羅する経路網羅のテストケースとはことなり、可能な制御パスのうちの一部だけを生成しているためです。特にif文が連続している部分が多いプログラムにはその傾向が顕著に現れます。
それでは実際にテストデータのセットを決めてみましょう。このプログラムのテストケースをすべて通るテストデータのセットはワークシートのA列にいくつかの値を記入した行が何行か続く形になります。
A行１行目から順番に決めていきます。その行をプログラムが処理することで通過するテストケースの番号も併記することにします。
A列１行目
10, 1, 20 ・・・ 1がNo.8、20がNo.9、そしてNo.3を通ります。値が10はテストケースにないパスを通ります。
A列２行目
100, 99, 100 ・・・ 100がNo.10、99がNo.8、100がNo.7、No.3
A列３行目
50, 0 ・・・ 0がNo.8、No.3
A列４行目
10, 50 ・・・ 50がNo.9、No.3
A列５行目
（空白） ・・・ No.1、No.4、No.6、No.2、No.5
そしてエラーメッセージを表示する
A列１行目
（空白） ・・・ No.11
というテストデータになります。これは一例ですのでこれ以外にもいろいろ考えられます。このテストデータでのプログラムの実行結果を以下に示します。
生成されたテストケースを通るようにテストデータを決定するステップは、慎重に決定する必要があります。