最少テストケース生成では指定回数+3回生成を行なっている
PictMasterの最少テストケース生成で「生成回数」を指定できますが、PictMaster内部では指定された回数より3回多く生成を行なっています。
3回のうち、1回目はエラーチェックのためにPICTのオプションを付けずに実行します。PICTは生成テストケース数のみを出力する /s オプションを指定すると、モデルファイルのエラーを検出しないことがあります。これを防ぐために行なっています。2回目はエラーがないことが確認できた上で、/s オプションをつけて実行し、デフォルトの条件でのテストケース数を記憶します。
その後、ランダムな生成条件値で /s オプションをつけて指定回数分PICTを実行します。この段階で進行状況を表示するプログレスバーが表示されます。3回目は、最も少ないテストケース数だったときの生成条件値で、オプションを付けずに実行を行ないます。そのため「生成回数」に2を指定して最少テストケース生成を行なうと、プログレスバーには3回分の進行状況が表示されます。
3回のうち、1回目はエラーチェックのためにPICTのオプションを付けずに実行します。PICTは生成テストケース数のみを出力する /s オプションを指定すると、モデルファイルのエラーを検出しないことがあります。これを防ぐために行なっています。2回目はエラーがないことが確認できた上で、/s オプションをつけて実行し、デフォルトの条件でのテストケース数を記憶します。
その後、ランダムな生成条件値で /s オプションをつけて指定回数分PICTを実行します。この段階で進行状況を表示するプログレスバーが表示されます。3回目は、最も少ないテストケース数だったときの生成条件値で、オプションを付けずに実行を行ないます。そのため「生成回数」に2を指定して最少テストケース生成を行なうと、プログレスバーには3回分の進行状況が表示されます。
オールペア法ツール「TConfig」の魅力
オールペア法ツールの１つに「TConfig」があります。例によってPairwise Testingのサイトから入手できます。
http://www.pairwise.org/tools. asp
TConfigはJavaアプリケーションのため、その実行にはJava Runtime Environment(JRE)が必要です。
TConfigの魅力には、Javaアプリケーションのため洗練されたGUIベースで入力できること、異なる2つのアルゴリズムを使用できること、などがあります。
TConfigを実際のテスト業務に使用するには無理がありますが、オールペア法を実験的に試してみたいという場合は最適だと思います。TConfigのもう１つの魅力には、生成されるテストケース数の少なさがあります。パラメータ数を10とした場合に各パラメータが同じ数の値を有するものとして、値の数を10、20、30と変化させてテストケース生成を行なった場合のテストケース数をTConfigとPictMaster(PICT)について以下に示します。PictMasterでは最少テストケース生成で100回を指定して生成した結果です、
TConfig
値 テストケース数
10 120
20 526
30 960
PictMaster(PICT)
値 テストケース数
10 165
20 613
30 1325
この結果から、TConfigが生成するテストケース数がかなり少ないことが明らかです。この違いの理由として考えられるのは、TConfigが数学的な手法でテストケースを生成しているのに対し、PICTはすべてのペアに分解してから組み合わせを作成するという帰納法的な手法でテストケースを生成している、という点があげられます。ただし、各パラメータの値の個数が10個未満ではPICTとの違いはあまりなくなります。また、この少ないテストケースで収まるのは組み合わせるパラメータ数が2個の場合に限られます。
TConfigは数学的な手法を用いることで大きなモデルの場合のテストケース数を少なくできましたが、それと引換えに制約の指定はできません。
http://www.pairwise.org/tools. asp
TConfigはJavaアプリケーションのため、その実行にはJava Runtime Environment(JRE)が必要です。
TConfigの魅力には、Javaアプリケーションのため洗練されたGUIベースで入力できること、異なる2つのアルゴリズムを使用できること、などがあります。
TConfigを実際のテスト業務に使用するには無理がありますが、オールペア法を実験的に試してみたいという場合は最適だと思います。TConfigのもう１つの魅力には、生成されるテストケース数の少なさがあります。パラメータ数を10とした場合に各パラメータが同じ数の値を有するものとして、値の数を10、20、30と変化させてテストケース生成を行なった場合のテストケース数をTConfigとPictMaster(PICT)について以下に示します。PictMasterでは最少テストケース生成で100回を指定して生成した結果です、
TConfig
値 テストケース数
10 120
20 526
30 960
PictMaster(PICT)
値 テストケース数
10 165
20 613
30 1325
この結果から、TConfigが生成するテストケース数がかなり少ないことが明らかです。この違いの理由として考えられるのは、TConfigが数学的な手法でテストケースを生成しているのに対し、PICTはすべてのペアに分解してから組み合わせを作成するという帰納法的な手法でテストケースを生成している、という点があげられます。ただし、各パラメータの値の個数が10個未満ではPICTとの違いはあまりなくなります。また、この少ないテストケースで収まるのは組み合わせるパラメータ数が2個の場合に限られます。
TConfigは数学的な手法を用いることで大きなモデルの場合のテストケース数を少なくできましたが、それと引換えに制約の指定はできません。
組み合わせテストのコスト
一般的には直交表やオールペア法の組み合わせテスト技法のメリットとして「少ないコストと高い品質の両立が可能」というスローガンが言われていると思いますが、果たしてそうでしょうか。
組み合わせテスト技法で生成されたテストケースは、１つ１つのテストケースが異なるパラメータの異なる値であるため、１つのテストケースをテスト実施するには、組み合わせテスト以外の場合のテストより比較的長い時間なコストがかかります。また、異なるパラメータを多く集めてテストケースが作成されているため、テスト実施にはテスト対象に対する充分な知識が必要とされます。
私のチームでは、組み合わせテストを適用するのは全体の20%ほどしかありません。何故かというと、従来、勘に頼ってきた組み合わせテストのテストケース抽出を、組み合わせテスト技法で置き換えただけだからです。これまでに組み合わせテストを行なってこなかった対象については、これまで同様に組み合わせテスト技法を適用することはありません。
様々な対象に組み合わせテストを適用しようとすると、テストケース数が倍増することになり、コスト的に無理だからです。
私の経験からすれば、組み合わせテスト技法を採用したからといって、テストにかかるトータルのコストが少なくなることはありません。直交表やオールペア法のメリットだけが主張されているように感じます。
ここで冒頭のスローガンは、「従来と変わらないコストで高い品質が可能」と訂正するべきでしょう。
組み合わせテスト技法で生成されたテストケースは、１つ１つのテストケースが異なるパラメータの異なる値であるため、１つのテストケースをテスト実施するには、組み合わせテスト以外の場合のテストより比較的長い時間なコストがかかります。また、異なるパラメータを多く集めてテストケースが作成されているため、テスト実施にはテスト対象に対する充分な知識が必要とされます。
私のチームでは、組み合わせテストを適用するのは全体の20%ほどしかありません。何故かというと、従来、勘に頼ってきた組み合わせテストのテストケース抽出を、組み合わせテスト技法で置き換えただけだからです。これまでに組み合わせテストを行なってこなかった対象については、これまで同様に組み合わせテスト技法を適用することはありません。
様々な対象に組み合わせテストを適用しようとすると、テストケース数が倍増することになり、コスト的に無理だからです。
私の経験からすれば、組み合わせテスト技法を採用したからといって、テストにかかるトータルのコストが少なくなることはありません。直交表やオールペア法のメリットだけが主張されているように感じます。
ここで冒頭のスローガンは、「従来と変わらないコストで高い品質が可能」と訂正するべきでしょう。
エラー推測テストの効用 (2009年9月6日訂正）
ほとんどのテスト技法は、何らかの形でテストの手順が書かれた文書をもとにして行なうスクリプトテストと呼ばれるカテゴリに分類されます。スクリプトテストに分類されないテストにエラー推測テストがあります。
エラー推測テストは、テスト仕様書などの文書を用いずにテスト担当者の勘を頼りに実施するテストです。
一般的に、テストを繰り返すと検出されるバグは減少し、最終的にはいくらテストしても１件もバグが検出されなくなります。しかし、テスト期間がまだ残っている場合にバグを検出できないと、テスト部隊はなにをやっているんだ、まじめにテストをやっているのか、という圧力が開発部隊からかかる困った事態になりかねません。テストが行き詰まった状態です。
このような場合に有効な方法としてエラー推測テストがあります。エラー推測テストはテスト担当者の勘を頼りにするといっても、テストの観点を明確にしておかなければ無駄なテストに終わる可能性が高いでしょう。
エラー推測テストを無駄なテストに終わらせないために、私たちのチームでは以下の「障害の発生しやすい事項」という表を目安にテストを行なうことにしています。この表は技術評論社のムック雑誌「ソフトウェアTEST･PRRESS」に掲載された記事に、私の経験をもとに追加・変更を行なったものです。
【障害が発生しやすい事項】
分類 内容
中止後の再操作 途中で操作をやめる。その後すぐに再操作を行なう。
エラー後の再操作 わざとエラーを起こして最初からやり直す。
繰り返し 同じ手順を繰り返し行なう。
最大最小 使用する値を大きくしたり小さくしたりする。
同時 同じ操作を同時に行なう。
境界 値の境目前後／時間的なタイミングの直前直後。
順序入れ替え 同一結果になる処理の手順を入れ替えて行なう。
省略 途中の操作を省略し別の操作を行なう。
操作中に別操作 ある操作中に別の操作を同時に行なう。
無効入力 性質の異なる無効な入力を行なう。
素早い操作 いろいろな操作を素早く行なう。
実際にバグが検出できず、行き詰まったテストチームに、この表の観点からのエラー推測テストを提案し、実施してもらったところ、多くのバグを検出することができました。この例は、エラー推測テストが有効だった場合です。
エラー推測テストは、いつでも有効なテスト技法というわけではありませんが、ふさわしい状況であるなら実施してみる価値のあるテスト技法です。
なお、エラー推測テストに似たテスト技法に探索的テストがあります。エラー推測テストがバグの発見を目的として使用する技法であるのに対して、探索的テストは、バグのあることが分かっている状態でバグの原因を見つけ出すデバッグで使用するテスト技法であるという違いがあります。
エラー推測テストは、テスト仕様書などの文書を用いずにテスト担当者の勘を頼りに実施するテストです。
一般的に、テストを繰り返すと検出されるバグは減少し、最終的にはいくらテストしても１件もバグが検出されなくなります。しかし、テスト期間がまだ残っている場合にバグを検出できないと、テスト部隊はなにをやっているんだ、まじめにテストをやっているのか、という圧力が開発部隊からかかる困った事態になりかねません。テストが行き詰まった状態です。
このような場合に有効な方法としてエラー推測テストがあります。エラー推測テストはテスト担当者の勘を頼りにするといっても、テストの観点を明確にしておかなければ無駄なテストに終わる可能性が高いでしょう。
エラー推測テストを無駄なテストに終わらせないために、私たちのチームでは以下の「障害の発生しやすい事項」という表を目安にテストを行なうことにしています。この表は技術評論社のムック雑誌「ソフトウェアTEST･PRRESS」に掲載された記事に、私の経験をもとに追加・変更を行なったものです。
【障害が発生しやすい事項】
分類 内容
中止後の再操作 途中で操作をやめる。その後すぐに再操作を行なう。
エラー後の再操作 わざとエラーを起こして最初からやり直す。
繰り返し 同じ手順を繰り返し行なう。
最大最小 使用する値を大きくしたり小さくしたりする。
同時 同じ操作を同時に行なう。
境界 値の境目前後／時間的なタイミングの直前直後。
順序入れ替え 同一結果になる処理の手順を入れ替えて行なう。
省略 途中の操作を省略し別の操作を行なう。
操作中に別操作 ある操作中に別の操作を同時に行なう。
無効入力 性質の異なる無効な入力を行なう。
素早い操作 いろいろな操作を素早く行なう。
実際にバグが検出できず、行き詰まったテストチームに、この表の観点からのエラー推測テストを提案し、実施してもらったところ、多くのバグを検出することができました。この例は、エラー推測テストが有効だった場合です。
エラー推測テストは、いつでも有効なテスト技法というわけではありませんが、ふさわしい状況であるなら実施してみる価値のあるテスト技法です。
なお、エラー推測テストに似たテスト技法に探索的テストがあります。エラー推測テストがバグの発見を目的として使用する技法であるのに対して、探索的テストは、バグのあることが分かっている状態でバグの原因を見つけ出すデバッグで使用するテスト技法であるという違いがあります。
もう1つのオールペア法ソフト「Jenny」
Pairwise Testingのサイトには数多くのオールペア法のソフトへのリンクが集められています。
http://www.pairwise.org/tools.asp
それらの中で、PICTと同じように制約の指定ができる数少ないフリーのソフトに「Jenny」があります。JennyはPICTほど多機能ではありませんが、制約の指定のほかに任意の組み合わせ数の指定が可能、PICTの原型ファイルに相当する機能を持っている、などの特徴があります。
制約の指定が可能なソフトの特徴として、Jennyでも任意の生成条件値を指定することにより、異なるテストケース数で組み合わせが生成されます。わたしがPICTを使う前はJennyを使っていました。ただし、固有名詞が使えず、a～zの文字と数字で組み合わせが出力されるため、それを固有名詞に変換する作業が必要でした。
試しに、パラメータ数が10、パラメータごとの値の数が30、合計300の値を持つモデルで生成時間を計って見たところ、Jennyは10秒、PICTは5秒でした（Pentium 4 3GHz）。あとは制約がある場合の生成時間がどうなるか興味のあるところです。
PictMasterはPICTを利用していますが、これをJennyに取り替えることは不可能ではないと思います。PICTにあってJennyにない機能はPictMaster側で実現できそうです。
Jennyは著作権を主張しないパブリックドメインとのことですので、Jennyを組み込んだツールを有償で販売することも可能だと思います。ただそれで採算がとれるかどうかは別の話になりますが...。
http://www.pairwise.org/tools.asp
それらの中で、PICTと同じように制約の指定ができる数少ないフリーのソフトに「Jenny」があります。JennyはPICTほど多機能ではありませんが、制約の指定のほかに任意の組み合わせ数の指定が可能、PICTの原型ファイルに相当する機能を持っている、などの特徴があります。
制約の指定が可能なソフトの特徴として、Jennyでも任意の生成条件値を指定することにより、異なるテストケース数で組み合わせが生成されます。わたしがPICTを使う前はJennyを使っていました。ただし、固有名詞が使えず、a～zの文字と数字で組み合わせが出力されるため、それを固有名詞に変換する作業が必要でした。
試しに、パラメータ数が10、パラメータごとの値の数が30、合計300の値を持つモデルで生成時間を計って見たところ、Jennyは10秒、PICTは5秒でした（Pentium 4 3GHz）。あとは制約がある場合の生成時間がどうなるか興味のあるところです。
PictMasterはPICTを利用していますが、これをJennyに取り替えることは不可能ではないと思います。PICTにあってJennyにない機能はPictMaster側で実現できそうです。
Jennyは著作権を主張しないパブリックドメインとのことですので、Jennyを組み込んだツールを有償で販売することも可能だと思います。ただそれで採算がとれるかどうかは別の話になりますが...。