ツール MTGとテスト仕様書を一体化し、テストドキュメントの管理を容易にする
テスト仕様書をExcelで作成している場合は、MTGのBookとテスト仕様書を一体化することができます。こうすることで、テストケースの作成にMTGを使用して組み合わせテスト、デシジョンテーブルテストなどで作成した元となるMTGのワークシートとそれから作成されたテストケースのワークシートを１つのBookとすることができます。
MGTの組み合わせテストのモデルが記述されたワークシートとそれから生成されたテストケースを１つのBookとして統合することにより、ドキュメントの管理がとても容易になります。これはテストケースと、そのモデルのBookが別々に分かれている場合にテストドキュメントを管理することを想像してみればそのメリットが分かるでしょう。
例としてある架空のテスト仕様書を取り上げてみます。これは私のテストチームが採用している方法です。このテスト仕様書はExcelの１つのBookであり、ワークシートとして、テスト設計仕様書、テストケース仕様書、およびテスト技法に組み合わせテストを採用したテスト項目についてのモデルから成り立っています。
テスト用ドキュメントは IEEE 829標準規格の分類を採用しています。ただし、IEEE 829 で規定されている「テスト手順書」については、その内容をテスト設計仕様書とテストケース仕様書に包含しているため、そのドキュメントは省略しています。
図１の例では、ワークシート名が「テスト仕様C-12」のワークシートがテスト設計仕様書にあたります。このワークシートでは、ワークシート名が 1-1～6-1 のテストケース仕様書について、適用するテスト技法、テストの手順と確認内容、そのテストの実行に必要なテスト条件（データ設定の内容、使用する機材、など）、およびそのテストケースが機能仕様書上のどの仕様項目のテストなのかを明記します。
テスト項目の分類は、この例では C-12 が大項目であり、ワークシート名の左側の数字が中項目、右側の数字が小項目です。テスト設計仕様書には、そのBookのすべてのテストケース仕様書についての説明が記述されています。テストケース仕様書には、テストケースごとに具体的なテスト対象を記述し、OK/NGなどのテスト結果を記入するの欄と、どのような機器を使用したのか、使用した機器の論理番号を記入する欄があります。テスト設計仕様書とテストケース仕様書の例を次に示します。
図２のテスト設計仕様書は、大きく５つの列に分かれており、左側から、中項目名称欄、小項目名称＋採用するテスト技法＋試験操作欄、確認内容欄、そしてこのテスト項目が機能仕様書のどの部分のテストであるかを示す、機能仕様書との関連欄、とからなっています。試験操作欄は、①、②、③、･･･、のようにテストの手順を具体的に記述します。確認内容欄は試験操作欄の①、②、③、･･･、ごとに対応する確認内容を記述します。ただし、必ずしもすべての確認内容が記述されるわけではなく、確認が必要な項目のみ記入されています。
図３のテストケース仕様書は、各テストケースごとに具体的なテスト対象機器、データ設定内容、テストに使用した機器の論理番号を記入する欄、OK/NG を記入する合否欄、確認者名欄、確認日、テスト対象のソフトウェアのバージョン欄、などで構成されています。
Excelの関数機能を駆使して、テストケース仕様書ごとの OK/NG の数、テスト設計仕様書には、この大項目全体の OK/NG が自動的に集計されます。さらに別のBookですべてのテスト項目についての OK/NG を集計します。同様にテストの進捗管理もExcelの自作のBookで行なっています。Excelを使用することで、テストプロジェクトの構成に応じて自由にテストの進捗管理ツールがカスタマイズできるのでテストドキュメントをExcelで記述するメリットには計り知れないものがあります。
図1で要因1-1と要因2-1はMTGのワークシートであり、テストケース仕様書1-1と2-1の組み合わせテストのモデルが記述されています。このBookは、MTGのBookにワークシートを追加して、テスト設計仕様書とテストケース仕様書を一体化したものです。
要因2-1のタイトルの例を次に示します。この例では「C-12 ダイヤルイン着信」が大項目の名称となっています。中項目名称が「名称表示」、小項目名称が「着番号対応名称」です。
こうしてMTGのBookにワークシートを追加することで、ツールのドキュメントとテスト仕様書のドキュメントを一体化することができます。そうすることでテストドキュメントの管理が容易となります。このメリットは非常に大きなものがあります。
多種類テストケース生成ツール MTG 3.0 をリリースしました。
ソフトウェアのテストケース生成ツール MTG 3.0は、PictMaster 2.8.1からいくつかのバグ修正を行ない、ユーザーズマニュアルに各種テスト技法のテストケース生成方法を追記したものです。
MTGは、次のテストケースを生成することができます。
・組み合わせテスト
・デシジョンテーブルテスト
・状態遷移テスト
・制御パステスト
MTG 3.0 での変更点は次の通りです。
【機能改善】
・最少テストケース実行時、従来は指定された生成回数＋３回生成を行なっていたが、処理を見直して不必要な生成処理を削除し、指定された生成回数＋２回の生成とした。
【バグ修正】
・複数のBookが開かれた状態でウインドウ分割のショートカットキーを押すとウインドウ分割が正しく行われなかったバグを修正した。（既存バグ 制限事項：最初に開いたBookでのみ有効）
・制約表、結果表などの編集専用のコンテキストメニューが、表示対象外の部分でも表示されるバグを修正した。
・Ａ列１行目などを右クリックすると、VBAのエラーが表示されるバグを修正した。
・起動ディスクがドライブC 以外の環境で生成するとVBAのエラーとなるバグを修正した。（既存バグ）
・値が小数の場合、制約表で指定するとPICTのエラーとなるバグを修正した。（既存バグ）
・最少テストケース生成でテストケース数の最少値と初期値が等しい場合、生成条件として初期値の0が表示されるように修正した。（既存バグ）
【その他】
・デフォルトのBook名称をMTG（Multi type Test case Generation tool）に変更した。
・ユーザーズマニュアルに制御パステスト、状態遷移テスト、デシジョンテーブルテストの各テストケースを生成する方法の説明を追記した。
MTG 3.0 は次のURIからダウンロードすることができます。
http://sourceforge.jp/projects/pictmaster/
今後のサポートはMTGに対するものとなり、PictMasterは対象外となります。
制御パステストのテストデータの決め方
Pairwise法（All-Pairs法）と制約表を併用することで制御パステストのテストケースを生成することができますが、生成された各テストケースで示されたルートを通るテストデータを決める必要があります。この値の決め方が不十分であると制御パステストとして不十分なテストとなってしまいます。
例として文字列 aStrings をもう１つの文字列 aText でサーチし、一致した最初の文字の桁位置を返す関数を取り上げてみます。一致しなかった場合は -1 が返されます。ソースリストは以下の通りです。VBAで書かれています。
この関数の制御パステストのテストケースを生成するモデルを以下に示します。
このモデルの生成結果を以下に示します。
右端の Data# は、関数の入力パラメータ（テストデータ）の識別番号であり、その内容は以下の通りです。
表１と表２から、すべての制御パスを網羅していることが分かります。ここでわかることは、１つのテストデータで２つ以上の制御パスを通る場合があるということです。プログラムがループを含む場合、生成されたテストケースは、ループの途中までの制御パスを含みます。そのため、１つのテストデータで２つ以上の制御パスを通ることになります。
もう１つ注意が必要なのは、Data # の *4 です。このテストデータは他のテストデータも通る制御パスを通っていますが、No.4の制御パスしか通りません。こうしたテストデータをもれなくテストする必要があります。
今回のプログラムでは、組み合わせるパラメータ数が１、２、すべて、のいずれの場合でも制御パスは５で同じ数です。条件網羅、経路網羅で制御パスの数が違ってくるのは、条件文が直列に２つ以上接続されている場合です。それも条件文の真と偽の双方で１つのルートに戻る場合です。どちらかが Return 文でパスから外れる場合は除かれます。その意味で今回のプログラムには２つ以上の条件文が完全に直列になっている箇所がないため、条件網羅と経路網羅で同じ制御パスとなります。
Pairwise法（All-Pair法）による制御パステストのテストケースを生成するやり方には、こうしなければならないという重要な決まりごとはほとんどありません。それだけ記述の自由度が高い訳ですが、どのように記述するかのよって制御パステストの質が決まると言えます。そしてこれは生成エンジンの処理能力の問題ですが、パラメータの数はむやみに多くすることはできません。
Pairwise法（All-Pair法）による制御パステストについては、語るべきことが多いのですが、それを分かりやすく全体像を説明することの難しさを感じています。
テスト仕様書こそ財産
ということは、旧機種用に作成したテスト仕様書であっても、新機種のテスト仕様書としても使えるケースが多いということになります。一度テスト仕様書を作成すれば、新機種用のテスト仕様書として大部分が流用でき、一部の新機能に関する部分だけ新たにテスト仕様書を作成すればよいことになります。具体的な用途は従来機能に何らかのレベルダウンがないかを確認するために用いることになります。
この意味でテスト仕様書は「財産」と言えるでしょう。作成したテスト仕様書は随時内容をチェックし、誤りがあれば修正を加え、常に最新の状態にしておくことによって、数世代に渡って新機種のテスト仕様書として活用することができます。わずかなコストをかけるだけで何度でも活用できるテスト仕様書はまさにソフトウェアテストにおける「財産」と呼ぶにふさわし いものです。
状態遷移テストのNスイッチテストとPairwise法（All-Pairs法）によるテスト
状態遷移テストの一形式として、Nスイッチテストという手法のあることを最近知りました。
Nスイッチテストを知らない人のために説明しますと、最初に遷移前の状態を列方向に、遷移後の状態を行方向にならべた状態遷移表を作成します。表中の各欄には、遷移前の状態で有効なイベントを、そのイベントによる遷移先の状態の行と列がクロスする欄に記入します。
例を用いると分かりやすいので図１の状態遷移図をもとに説明します。この状態遷移図に特に意味はありません。
この状態遷移図を表す状態遷移表を表１に示します。
状態遷移表には、このほかに、左の列に状態欄、その右にイベント欄、つづいてそのイベントで実行する処理内容を記述した欄、最後に次に遷移する状態欄、という形式の状態遷移表もあります。今回説明に使用する状態遷移表はそれとは異なる形式です
表１の状態遷移表では、遷移前の状態で、表中のあるイベントにより遷移後の状態が指定されています。この表はある状態から次の遷移先の状態を表しており、2つの状態間の遷移をカバーしています。この表をもとに行うテストをNスイッチテストでは0スイッチテストと言います。
これに対して1スイッチテストという方法があります。この方法はある状態から次の状態、そしてさらに次の状態という具合に3つの状態間の遷移をカバーする方法です。この方法では、状態遷移表を行列式とみなし、行列の2乗を行なうことで得られる新しい行列式の内容が3つの状態間の遷移を表しています。
表１の状態遷移表の内容を行列式とみなし、それを2乗した結果を表２に示します。
この表中の欄に記述されている内容は2つのイベントを表し、そのイベントの連続で遷移前の状態から遷移後の状態に遷移することを意味しています。表中で「+」がある欄は、イベントの組み合わせが2つあることを表しています。表中の各欄のイベントを調べると、3つの状態間の遷移がすべて網羅されていることが分かります。
Nスイッチテストというように2スイッチテスト以上も考えられます。これは行列式の積で得ることができます。
Nスイッチテストは、単純な状態間の遷移を確認するだけのテストに比べて網羅度の高いテストを行なうことができます。ただし、最初の状態がどの状態から遷移してきたものであるかが不定であるため、状態遷移の網羅度は低いと思います。また各状態の遷移の過程での確認事項をテストケースとしてまとめるのにかなり手間がかかるはずです。
一方、Pairwise法によるテストケースでは、すべての状態の遷移が網羅されるため、Nスイッチテストより網羅度の高いテストを行なうことができます。図１の状態遷移図を例にとると、少なくとも4つの状態間の遷移をすべて網羅するテストケースを14件で作成することができました。個々のテストケースは状態s0から始まっています。このテストケースを表３に示します。
それでは、また。