多種類テストケース生成ツール MTG （Multi type Test case Generation tool）

ソフトウェア開発ではまったくの新規開発は少なく、大部分は既存製品をベースにしたソフトウェアの再利用をともなうソフトウェア開発であることはよく知られた事項だと思います。

既存製品をベースにした新製品の開発では、新製品で新たに追加された「新規機能」と、既存製品の機能をそのまま流用した「既存機能」に分けられます。ソフトウェアの開発においては開発期間の短縮が至上命題である場合が少なくありません。こうした場合、ソフトウェア開発工程のほぼ半分を占めるテスト工程の効率化を図り、短いテスト工程で十分な品質に仕上げなければなりません。

こうした場合のテスト戦略として「リスクベースドテスト」を採用することが一般的だと思います。ソフトウェアテストを各テスト対象に対して均等に工数を割り当てるのではなく、市場でソフトウェアの欠陥が発生する可能性と重大性を考慮して、その可能性が低く、比較的重大でないと考えられるテスト対象についてはテスト工数を大きく減らし、テストにメリハリをつけるのがリスクベースドテストの考え方です。

具体的には、ソフトウェアの変更のない既存機能についてのテストは思い切って工数を減らし、新規機能のテストに工数を割り当てることになります。これを組み合わせテストに当てはめれば、新規機能については要因組み合わせテストを多めに行うが、既存機能についてはテストケース数が多くなりがちな要因組み合わせテストではなく、組み合わせを行わない要因列挙テストで済ますということになります。

要因列挙テストのテストケースを作成するには環境設定で「組み合わせるパラメータ数」に１を設定して生成を行なうだけです。

パラメータが５つ、各パラメータあたり５つの値を持つモデルでの要因列挙のテストケースの例を以下に示します。

表１．要因列挙のテストケース

テストケース数が５件となりました。要因列挙テストのテストケースは要因の組み合わせが行なわれないのでテストケース数は最も多くの値を持つパラメータの値の数となります。これが要因組み合わせではテストケース数が３２件とかなり多くの件数となります。

ソフトウェアに変更がない既存機能については徹底したテストは不要ですから、このように要因列挙テストで済ますことにより、テスト工数を大幅に削減することができます。

全てを要因列挙にする必要がない場合もあります。それは最も多くの数の値を持つパラメータとそれ以外のパラメータの持つ値の数に大きな開きがある場合です。

パラメータが５つ、８個の値を持つパラメータが２つ、残りは３個のパラメータを持つモデルを例として説明します。（図１）

図１．モデル

このモデルのテストケース数は要因列挙テストでは８件となります。この場合、３個の値をもつパラメータが３つありますが、このパラメータについては、要因組み合わせテストとしてもテストケース数は３×３＝９件となり、８件とほとんど変わりありません。

ここで１つのテストケースで要因組み合わせと要因列挙を合成する方法を説明します。
環境設定で「組み合わせるパラメータ数」に１を設定します。「サブモデルを使用する」にチェックを入れます。
サブモデルの記入欄に、要因組み合わせを行なうパラメータを記入し、組み合わせ数に２を記入します。（図２）

図２．サブモデルで要因組み合わせを行なうパラメータを指定する。

このモデルでの生成結果を以下に示します。このテストケースではパラメータAとBが要因列挙であり、パラメータC、DおよびEが要因組み合わせとなっています。

表２．要因組み合わせと要因列挙を合成したテストケース

このように多くの値を持つパラメータだけ選択して要因列挙とし、それ以外のパラメータを要因組合せとすることで、テストケース数をそれほど増加させることなく、要因組み合わせを混在させた要因列挙のテストケースを生成することができます。

この例では要因列挙テストとするパラメータが２つでしたが、３つ以上とした場合でも各パラメータの組み合わせはランダムとなり、組み合わせが１対１となるようなことはありません。

要因組み合わせと要因列挙を混在したテストケースはそれほど多くはないと思いますが、要因列挙のみのテストケースはよく使われることになると思います。要因列挙であればツールを使わなくてもいいではないかと考える方がいるかもしれませんが、制約がある場合はツールを使ったほうが間違いがなくてよいでしょう。

要因列挙テストは、要因の組み合わせによるソフトウェアの欠陥はないだろうということを前提としています。既存機能の流用であれば、要因を組み合わせてまでの徹底したテストは不要だとすることでテスト工数を大きく削減してよいと考えます。実際に市場に出荷した製品でのソフトウェアの欠陥は既存機能ではほとんど発生していないことから、リスクベースドテストのテスト戦略は有効であると言えます。

今回は少し複雑な状態遷移のテストケースを生成してみます。ここで使用する状態遷移は実際にサービス機能の１つの状態遷移です。この状態は９個あり、イベントは６種類あります。通常の状態遷移テストでは、状態遷移図をもとに状態遷移表を作成し、それをテストケースとする場合が多いと思われます。

Pawise法（All-Pairs法）では、状態をパラメータとし、イベントをその値とします。この方法で２つの状態間の遷移の組み合わせをすべて網羅することができます。これは単体テストで使われる制御パステストでの「条件網羅」のルートを網羅することに相当します。

状態遷移は、状態遷移の最初の状態である「始状態」と、最後の状態である「終状態」を持ちます。そしてほとんどの場合、始状態と終状態は同一です。せっかくPawise法（All-Pairs法）でテストケースを作成するのですから、より状態遷移の各ルートの網羅度をあげたテストケースを作成したいものです。そこで始状態／終状態を少なくとも２回通る状態遷移を網羅したテストケースを作成することにします。

以下に状態遷移図を示します。状態とイベントの名称はそのままでは差しさわりがありますので別名に置き換えています。

図１．状態遷移図

この状態遷移図から状態遷移表を作成すると、それはそのままテストケースとなりますが、その場合のテストケース数は２３となります。一方、Pawise法（All-Pairs法）により、同じ状態を２回以上通る状態遷移ではテストケース数は１４８となります。

以下のこの状態遷移図のモデルと制約表を示します。

表１．状態遷移図のモデル

表２．状態遷移図の制約表

このモデルと制約表から生成された状態遷移のテストケースを以下に示します。

表３．生成された状態遷移のテストケース

実際のテストケースは、このテストケースの各状態の間に当該状態で確認すべき事項を記述した確認欄の列を挿入したものになります。

このテストケースでは通常の状態遷移表に比べて網羅度の非常に高いテストを行うことができます。一般的に状態遷移テストはテストケースあたりにかかるテスト時間は短くて済むものです。その意味で、Pawise法（All-Pairs法）により、同じ状態を２回以上通る状態遷移のテストケースは有効だと考えられます。

なお、ツールが対応できる状態遷移は状態数がそれほど多くない場合に限られます。そうした制限があることに留意してください。

MTG 3.2 をリリースしました。 3.1のバグ修正バージョンです。

3.1からの変更点は以下の通りです。

【機能改善】

・日本語以外のOS環境、日本語バージョン以外のExcelでも動作可能とした。

【バグ修正】

・Bookのワークシートで77行目2列目に数値データがあるとVBAのエラーとなるバグを修正した。

【その他】

・「生成条件」という用語を「シード値」に訂正した。
・ユーザーズマニュアルに３つ以上の任意のパラメータのみ３パラメータの組み合わせとする方法を追記した。

・ユーザーズマニュアルでサブモデルの記述を修正した。

http://sourceforge.jp/projects/pictmaster/ からダウンロードすることができます。

最新版のMTG 3.1も含めてMTGのBookを開いたときに、

実行時エラー'1004':　Characters クラスの Text プロパティを取得できません。

というVBAのエラーが発生する場合があります。
このエラーは、MTGが他のワークシートを含み、そのワークシートの77行目2列目に数値データが存在する場合に発生します。

このエラーを回避するには、Excelのツール→マクロ→Visual Basic Editor でVBAのエディタを開き、左端のリストから ThisWorkBookを選択し、表示されるVBAのソースコードを以下のように修正します。

If Worksheets(i).Cells(77, 2).Characters.Text = " 結果表 " Then
ThisWorkbook.Worksheets(i).Cells(77, 2).Characters.Text = "結果表"
　　　　　　　　　　　　　　　　　↓
If Worksheets(i).Cells(77, 2) = " 結果表 " Then
ThisWorkbook.Worksheets(i).Cells(77, 2) = "結果表"

この障害は次のバージョンで修正する予定です。

これまで任意のパラメータのみ３パラメータの組み合わせとする方法については何度か取り上げてきましたが、何らかの制限があったり、方法が複雑だったりしました。今回は特に制限なしで簡単な方法を取り上げてみます。

すべてのパラメータについて３パラメータの組み合わせとした場合、テストケース数が多くなりすぎ現実的でなくなる場合がよくあります。こうした場合、特に重要だと考えられるパラメータに限定して３パラメータ間の組み合わせを網羅することができれば、むやみにテストケース数が多くなりすぎることを防ぎ、かつ網羅度の高いテストケースを実用的な範囲で生成することができます。

基本的な手順は以下の通りとなります。

１．３パラメータの組み合わせとしたい３つ以上のパラメータについてサブモデルで３パラメータの組み合わせを指定します。同時に環境設定で組み合わせるパラメータ数に１を指定します。

２．以上の条件でテストケースを生成します。このときのテストケース数を控えておきます。

３．生成されたテストケースを原型シートのワークシートに貼り付けます。

４．環境設定で組み合わせるパラメータ数に２を指定します。そして原型シートを使用する設定とします。同時にサブモデルを使用しない設定とします。

５．以上の条件でテストケースを生成します。このときのテストケース数が２項でのテストケース数より多いことを確認します。

ここで生成されたテストケースの集合は、指定した任意のパラメータのみが３パラメータの組み合わせとなり、残りのパラメータは２パラメータの組み合わせとなります。このときのテストケース数はすべてを３パラメータの組み合わせとした場合より顕著に少ない数となります。

モデルの構成によっては、この手順で最後の５項のテストケース数が２項でのテストケース数よりも少ない場合がありえます。この場合は必要な組み合わせが得られていないので、３パラメータの組み合わせとしたい３つ以上のパラメータ以外の任意のパラメータにダミーの値を１つだけ追加し、もう一度テストケースを生成します。そうすると生成されるテストケース数は、２項でのテストケース数よりも多くなるのでこの生成結果を最終的なテストケースとします。ダミーの値は任意の値に置き換えます。

具体的なモデルの例を図１に示します。このモデルではパラメータ A, B, C, D の４つのパラメータのみ３パラメータ間の組み合わせとし、残りのパラメータ E, F, G, H は２パラメータ間の組み合わせとします。

図１．サブモデルで３パラメータの組み合わせを指定する

このとき環境設定で組み合わせるパラメータ数を１とします。

図２．環境設定その１

以上の条件で生成されたテストケースを示します。このときのテストケース数は２８となります。（最少テストケース生成で生成しているため、必ずしも２８となるわけではありません）

図３．必要な３パラメータの組み合わせを生成する。

次にＭＴＧに新規ワークシートを作成し、それをＭＴＧのワークシートの右側に移動し、原型シートとします。そして先ほど生成した３パラメータの組み合わせ結果を原型シートに貼り付けます。

続いて環境設定でサブモデルを使用しないに設定し、原型シートを使用するに設定します。また組み合わせるパラメータ数に２を設定します。

図４．環境設定その２

この条件で生成されたテストケースを示します。

図５．任意のパラメータのみ３パラメータの組み合わせとしたテストケース

このときのテストケース数は３０となります。このテストケースはパラメータ A, B, C, D のみ３パラメータの組み合わせとなり、残りのパラメータは２パラメータの組み合わせとなっています。

こうした方法ではなく、単純に組み合わせるパラメータ数に３を指定した場合のテストケース数は５７となり、２倍近くのテストケース数となります。