制約があるとテストケース数が増えるのはなぜ？
組み合わせることのできない制約があると、生成されるテストケース数は制約がない場合に比べて若干ですが多くなります。直感的に考えると、組み合わせることができない組み合わせがあるなら、生成されるテストケース数は少なくなるように思えます。
実際に制約のない場合と、ある場合の生成結果を比べてみましょう。
例として、パラメータが３つで、それぞれ３つの値を持つ場合をあげてみます。
制約のない場合の生成結果
No. A B C
1 1 1 2
2 1 2 1
3 1 3 3
4 2 1 1
5 2 2 3
6 2 3 2
7 3 1 3
8 3 2 2
9 3 3 1
この場合は9個のテストケースです。
次に、パラメータAの値1はパラメータBの値1とのみ組み合わせ可能という制約がある場合の例をあげます。
制約のある場合の生成結果
No. A B C
1 1 1 1
2 1 1 2
3 1 1 3
4 2 1 2
5 2 2 1
6 2 2 3
7 2 3 3
8 3 1 3
9 3 2 2
10 3 3 1
11 3 3 2
制約がある場合は11個のテストケースとなりました。
制約がない場合に比べて2個テストケースが増えています。制約のある場合の生成結果をよく見てみると、Aが1とBが1の組み合わせで3個のテストケースを要しています。これに対して、制約がない場合は、同じ組み合わせは1個で済んでいます。制約がある場合は、この時点でテストケースが2個多くなっています。そのことで、各ペアの組み合わせをすべて満たすために、パラメータAの値が2と3の場合のテストケース数がそれぞれ4個づつ必要となり、全体としては3+4+4=11という結果になります。
制約があるために、他の値がすべてのペアを網羅するという条件を満たす上でより多くの組み合わせが必要となる、という訳です。
※ PictMasterを使ってみて、これはバグじゃないの？ とか こうしたことができればもっと便利になる！ などありましたらコメントしてください。可能な範囲で対応させていただきます。
実際に制約のない場合と、ある場合の生成結果を比べてみましょう。
例として、パラメータが３つで、それぞれ３つの値を持つ場合をあげてみます。
制約のない場合の生成結果
No. A B C
1 1 1 2
2 1 2 1
3 1 3 3
4 2 1 1
5 2 2 3
6 2 3 2
7 3 1 3
8 3 2 2
9 3 3 1
この場合は9個のテストケースです。
次に、パラメータAの値1はパラメータBの値1とのみ組み合わせ可能という制約がある場合の例をあげます。
制約のある場合の生成結果
No. A B C
1 1 1 1
2 1 1 2
3 1 1 3
4 2 1 2
5 2 2 1
6 2 2 3
7 2 3 3
8 3 1 3
9 3 2 2
10 3 3 1
11 3 3 2
制約がある場合は11個のテストケースとなりました。
制約がない場合に比べて2個テストケースが増えています。制約のある場合の生成結果をよく見てみると、Aが1とBが1の組み合わせで3個のテストケースを要しています。これに対して、制約がない場合は、同じ組み合わせは1個で済んでいます。制約がある場合は、この時点でテストケースが2個多くなっています。そのことで、各ペアの組み合わせをすべて満たすために、パラメータAの値が2と3の場合のテストケース数がそれぞれ4個づつ必要となり、全体としては3+4+4=11という結果になります。
制約があるために、他の値がすべてのペアを網羅するという条件を満たす上でより多くの組み合わせが必要となる、という訳です。
※ PictMasterを使ってみて、これはバグじゃないの？ とか こうしたことができればもっと便利になる！ などありましたらコメントしてください。可能な範囲で対応させていただきます。
制約表のメリットとデメリット
PictMasterでは制約の指定に「制約表」を用いていることが特徴の１つとなっています。
PICT自体は、プログラミング言語によく似た if ～ then ～ のスクリプト（制約式）を用いて制約を指定します。
制約式ではなく、制約表を用いることのメリットとデメリットにはどのようなものがあるでしょうか。以下に整理したものをあげてみます。
制約表のメリット
(1) 制約が表形式とセルの色の違いでモデル化されるため、複雑な制約の関係が視覚的に把握しやすい。
(2) これは(1)とも関係するが、複雑な制約の記述や修正を行なう場合、制約式で記述するよりも容易に行なうことができる。
(3) 制約式の記述と異なり、原理的に式の構文に関する記述ミスが起きない。
(4) 制約の記述に誤りがある場合、具体的に誤りのある個所を指摘できる。
(5) 制約の記述がカラフルなモザイク模様となり、記述していて楽しい。
メリットのうち、(5)は人によるかもしれません(^^)。少なくとも(1)～(4)は、実際に使用してみて妥当なものと感じています。
制約表のデメリット
(1) 制約表での記述に慣れるまで少し時間がかかる。
(2) これは(2)とも関係するが、制約表に関する知識がない人が見ても理解できない。
(3) セル内に記述する文字数が多い場合、セル内での文字列の折り返しとなり、読み取りにくい。
(4) 制約が多いと画面右側のセット欄に記入することになり、記入しづらいし読みにくい。
デメリットで(3)については、セルの列幅を広げることである程度対処できるでしょう。(4)については、PictMasterの機能であるウインドウの分割を使って記述のしづらさはかなり軽減されます。全体が見渡せない場合は、Excelの表示倍率を変えて見てはどうでしょうか。
制約表にはデメリットもありますが、長い間使ってきてメリットがそれを上回っていると感じています。
PICT自体は、プログラミング言語によく似た if ～ then ～ のスクリプト（制約式）を用いて制約を指定します。
制約式ではなく、制約表を用いることのメリットとデメリットにはどのようなものがあるでしょうか。以下に整理したものをあげてみます。
制約表のメリット
(1) 制約が表形式とセルの色の違いでモデル化されるため、複雑な制約の関係が視覚的に把握しやすい。
(2) これは(1)とも関係するが、複雑な制約の記述や修正を行なう場合、制約式で記述するよりも容易に行なうことができる。
(3) 制約式の記述と異なり、原理的に式の構文に関する記述ミスが起きない。
(4) 制約の記述に誤りがある場合、具体的に誤りのある個所を指摘できる。
(5) 制約の記述がカラフルなモザイク模様となり、記述していて楽しい。
メリットのうち、(5)は人によるかもしれません(^^)。少なくとも(1)～(4)は、実際に使用してみて妥当なものと感じています。
制約表のデメリット
(1) 制約表での記述に慣れるまで少し時間がかかる。
(2) これは(2)とも関係するが、制約表に関する知識がない人が見ても理解できない。
(3) セル内に記述する文字数が多い場合、セル内での文字列の折り返しとなり、読み取りにくい。
(4) 制約が多いと画面右側のセット欄に記入することになり、記入しづらいし読みにくい。
デメリットで(3)については、セルの列幅を広げることである程度対処できるでしょう。(4)については、PictMasterの機能であるウインドウの分割を使って記述のしづらさはかなり軽減されます。全体が見渡せない場合は、Excelの表示倍率を変えて見てはどうでしょうか。
制約表にはデメリットもありますが、長い間使ってきてメリットがそれを上回っていると感じています。
PictMasterがハングアップ？
PictMasterで多くの値と制約を指定すると、PictMasterがハングアップ状態になることがあります。例えば、値の総数が100個、制約を 10以上指定するとハングアップ状態になるかもしれません。これは、PICTで処理に時間がかかっているためです。１回の処理が完了するまでに数時間以上かかる場合があります。
PictMasterで「生成」ボタンをクリックした後、数秒たっても何も変化がないときは、PICTで時間がかかっているためです。このような場合は、PCのCTL、ALT、DELの各キーを同時に押してタスクマネージャを立ち上げ、リストのイメージ名から「pict.exe」を選択し、プロセスの終了ボタンをクリックすることで、pict.exeを強制終了させることができます。このときExcelのエラーメッセージが表示されるので、「終了」ボタンをクリックしてください。
PICTで処理に長時間かかるのはバグではありません。処理するモデルと制約が多すぎるために時間がかかっているのです。１回の処理完了までに数時間以上かかるのは、通常のテストではありえないほど大きなモデルと制約を記入した場合です。したがって、通常のテスト業務でこのような状態となることはまずないでしょう。
PictMasterがハングアップしたからといって使えないソフトと決め付けないでください（笑）。
PICTのテストケース生成時間に影響をあたえるパラメータ数、値の総数、制約の数、などについて測定を行なった結果が以下のサイトに掲載されています。筆者は私です。
「PICT と PictMaster のための活用情報集」
http://www.ne.jp/asahi/test/pictmaster/index.html
このサイトでは、図表を多用し、ブログでは説明しきれない、PICTとPictMasterに関するコアな情報を掲載していく予定です。
PictMasterで「生成」ボタンをクリックした後、数秒たっても何も変化がないときは、PICTで時間がかかっているためです。このような場合は、PCのCTL、ALT、DELの各キーを同時に押してタスクマネージャを立ち上げ、リストのイメージ名から「pict.exe」を選択し、プロセスの終了ボタンをクリックすることで、pict.exeを強制終了させることができます。このときExcelのエラーメッセージが表示されるので、「終了」ボタンをクリックしてください。
PICTで処理に長時間かかるのはバグではありません。処理するモデルと制約が多すぎるために時間がかかっているのです。１回の処理完了までに数時間以上かかるのは、通常のテストではありえないほど大きなモデルと制約を記入した場合です。したがって、通常のテスト業務でこのような状態となることはまずないでしょう。
PictMasterがハングアップしたからといって使えないソフトと決め付けないでください（笑）。
PICTのテストケース生成時間に影響をあたえるパラメータ数、値の総数、制約の数、などについて測定を行なった結果が以下のサイトに掲載されています。筆者は私です。
「PICT と PictMaster のための活用情報集」
http://www.ne.jp/asahi/test/pictmaster/index.html
このサイトでは、図表を多用し、ブログでは説明しきれない、PICTとPictMasterに関するコアな情報を掲載していく予定です。
テスト対象の性質と適用するテスト技法
テスト対象の仕様を分析し、どのテスト技法を適用するかを決めることはとても重要なことです。
ブラックボックステストの場合についてお話します。
私のチームでは、以下のテスト技法をテスト対象に合わせて使い分けています。
(1) 要因組み合わせテスト
(2) 要因列挙テスト
(3) 要因限定テスト
(4) デシジョンテーブルテスト
(5) 状態遷移表テスト
(6) 探索的テスト
要因列挙テストとは、要因の組み合わせを行なわず、各要因の種別を列挙します。したがって基本的にテストケース数は最も種別の数が多い要因の種別の数と同じになります。
要因限定テストとは、各要因のすべての種別ではなく、限定した種別（１つの場合もあり）に絞って行なうテストです。
例えば、ビジネスホンシステムでは。代表的な要因には、回線種別と端末種別があります。それぞれの要因の種別には、回線種別ではアナログ回線、ISDN回 線、IP回線、NGN回線など、端末種別ではKT、IP-KT、DC-PS、DC-KT、SLTなどがあります。この２つの要因だけで、それぞれ10種類 近くのあります。これをそのまま手を加えずに、要因組み合わせテストでテストケースを作成すると必ず10×10=100以上のテストケースとなってしまいま す。このあたりは、PICTのエイリアス機能を使ってテストケース数を減らすことになります。
おおざっぱにいって、各テスト技法の適用割合をテスト項目数で表すと、
要因組み合わせテスト： 20%
要因列挙テスト： 50%
要因限定テスト：10%
デシジョンテーブルテスト：10%
状態遷移テスト：10%
探索的テスト：？%
くらいです。同値分割や境界値分析はどのテスト技法でも同時に使っています。ただし、同値分割では不十分で、全数のテストが必要なテスト対象も一部ですが存在します。
要因組み合わせテストは、大まかに言って正常系の基本ルートなど特に重要な部分の確認に適用します。
要因列挙テストは、要因組み合わせテストではカバーされない部分の確認に適用します。
要因限定テストは、要因組み合わせテストと要因列挙テストでカバーされている部分で、限定した要因の種別のみで確認すればよい場合に適用します。
デシジョンテーブルテストは、複雑な論理を含むテスト対象や優先順位を含むテスト対象に適用します。
状態遷移表テストは、電話帳登録など、ユーザから見て多くの状態の遷移を伴うテスト対象に適用します。
探索的テストは、既存のテスト仕様書で障害が見つからなくなったときに行なう場合があります。
要因組み合わせテストが適用されるテスト項目の割合は、20%程度しかありません。思ったより少ないと思われた方がいるかもしれません。その理由には、テストケース数とテスト実施時間が関係します。要因組み合わせテストは、他のテスト技法より、テストケース数が多くなる傾向があります。また生成されたテストケースは、各要因の種別の組み合わせとなるため、そのテスト実施には実施条件を満たすための前準備により時間がかる傾向があります。仮に要因組み合わせテストをテスト項目全体の50%に適用したとしたら、全体のテストケース数は倍増するでしょう。さらに試験実施のための前準備に多くの工数が必要となります。
ということで、意外と思われるかもしれませんが要因組み合わせテストはメインのテスト技法とはしていません。ですが組み合わせテストは欠かせないテストです。その意味でオールペア法や直交表は重要なテスト技法といえます。
ブラックボックステストの場合についてお話します。
私のチームでは、以下のテスト技法をテスト対象に合わせて使い分けています。
(1) 要因組み合わせテスト
(2) 要因列挙テスト
(3) 要因限定テスト
(4) デシジョンテーブルテスト
(5) 状態遷移表テスト
(6) 探索的テスト
要因列挙テストとは、要因の組み合わせを行なわず、各要因の種別を列挙します。したがって基本的にテストケース数は最も種別の数が多い要因の種別の数と同じになります。
要因限定テストとは、各要因のすべての種別ではなく、限定した種別（１つの場合もあり）に絞って行なうテストです。
例えば、ビジネスホンシステムでは。代表的な要因には、回線種別と端末種別があります。それぞれの要因の種別には、回線種別ではアナログ回線、ISDN回 線、IP回線、NGN回線など、端末種別ではKT、IP-KT、DC-PS、DC-KT、SLTなどがあります。この２つの要因だけで、それぞれ10種類 近くのあります。これをそのまま手を加えずに、要因組み合わせテストでテストケースを作成すると必ず10×10=100以上のテストケースとなってしまいま す。このあたりは、PICTのエイリアス機能を使ってテストケース数を減らすことになります。
おおざっぱにいって、各テスト技法の適用割合をテスト項目数で表すと、
要因組み合わせテスト： 20%
要因列挙テスト： 50%
要因限定テスト：10%
デシジョンテーブルテスト：10%
状態遷移テスト：10%
探索的テスト：？%
くらいです。同値分割や境界値分析はどのテスト技法でも同時に使っています。ただし、同値分割では不十分で、全数のテストが必要なテスト対象も一部ですが存在します。
要因組み合わせテストは、大まかに言って正常系の基本ルートなど特に重要な部分の確認に適用します。
要因列挙テストは、要因組み合わせテストではカバーされない部分の確認に適用します。
要因限定テストは、要因組み合わせテストと要因列挙テストでカバーされている部分で、限定した要因の種別のみで確認すればよい場合に適用します。
デシジョンテーブルテストは、複雑な論理を含むテスト対象や優先順位を含むテスト対象に適用します。
状態遷移表テストは、電話帳登録など、ユーザから見て多くの状態の遷移を伴うテスト対象に適用します。
探索的テストは、既存のテスト仕様書で障害が見つからなくなったときに行なう場合があります。
要因組み合わせテストが適用されるテスト項目の割合は、20%程度しかありません。思ったより少ないと思われた方がいるかもしれません。その理由には、テストケース数とテスト実施時間が関係します。要因組み合わせテストは、他のテスト技法より、テストケース数が多くなる傾向があります。また生成されたテストケースは、各要因の種別の組み合わせとなるため、そのテスト実施には実施条件を満たすための前準備により時間がかる傾向があります。仮に要因組み合わせテストをテスト項目全体の50%に適用したとしたら、全体のテストケース数は倍増するでしょう。さらに試験実施のための前準備に多くの工数が必要となります。
ということで、意外と思われるかもしれませんが要因組み合わせテストはメインのテスト技法とはしていません。ですが組み合わせテストは欠かせないテストです。その意味でオールペア法や直交表は重要なテスト技法といえます。
PictMasterで最短経路を求める
PictMasterをテスト分野以外へ応用するという話題です。
ここでｎ×ｎのマス目がある格子状の道路網があるとします。ｎ×ｎの表のイメージです。
この道路網は交差点と他の交差点との距離がそれぞれランダムに異なっているものとします。また格子に斜線が入っていたり、格子の一部が存在しない場合もあってよいものとします。
目的は、この道路網でもっとも距離が短い最短経路を求めるというものです。
道路網の左上から出発して右下の終点までのルートは、ｎの値が多いと手計算では時間がかかりすぎます。
そこでPictMasterを使用すると、元に戻ったりするいたずらに時間がかかるルートを除外したすべての可能なルートを探し出し、それらのルートの所要時間を求めることができます。
PictMasterは最短経路を求めることを目的にしたツールではないので、可能なすべてのルートと、それらのルートでの各交差点間の距離を生成します。あとは、人手で各ルートでの交差点間の時間を集計することで、最短経路を求めることができます。
もっとも、PictMasterに交差点間の所要時間の合計をもとめ、もっとも所要時間が少ない最短経路を特定するコードを追加することは簡単にできるでしょう。
こうしたことができるのはPICTが柔軟な制約（来合わせることのできない組み合わせのこと）に関する機能を備えていることと、PictMasterで制約を表形式で表す「制約表」があることで、ほとんど機械的にPictMasterへの記入ができるようになっています。
近いうちに、実例をお見せできるでしょう。
ここでｎ×ｎのマス目がある格子状の道路網があるとします。ｎ×ｎの表のイメージです。
この道路網は交差点と他の交差点との距離がそれぞれランダムに異なっているものとします。また格子に斜線が入っていたり、格子の一部が存在しない場合もあってよいものとします。
目的は、この道路網でもっとも距離が短い最短経路を求めるというものです。
道路網の左上から出発して右下の終点までのルートは、ｎの値が多いと手計算では時間がかかりすぎます。
そこでPictMasterを使用すると、元に戻ったりするいたずらに時間がかかるルートを除外したすべての可能なルートを探し出し、それらのルートの所要時間を求めることができます。
PictMasterは最短経路を求めることを目的にしたツールではないので、可能なすべてのルートと、それらのルートでの各交差点間の距離を生成します。あとは、人手で各ルートでの交差点間の時間を集計することで、最短経路を求めることができます。
もっとも、PictMasterに交差点間の所要時間の合計をもとめ、もっとも所要時間が少ない最短経路を特定するコードを追加することは簡単にできるでしょう。
こうしたことができるのはPICTが柔軟な制約（来合わせることのできない組み合わせのこと）に関する機能を備えていることと、PictMasterで制約を表形式で表す「制約表」があることで、ほとんど機械的にPictMasterへの記入ができるようになっています。
近いうちに、実例をお見せできるでしょう。