組み合わせテストケース生成ツール 「PictMaster」 とソフトウェアテストの話題 -50ページ目

生成結果のセル内容が数値であるとエラーマークが表示される場合の対処法

PictMaster 4.0 から、先頭が0で始まる値もゼロサプレスされることなくそのまま表示されるようになりました。この改善を行なったことにより、生成結果のセル内容が数値であると、セルにエラーマークが表示されるようになりました。これはExcelのオプション設定が、セルの形式が文字列であるときに内容が数値であるとエラーマークを表示するようになっているためです。


Excelで生成結果が数値のセルにエラーマークが表示されないようにするには、以下の設定を行なってください。


Excel2007の場合

Officeボタン → Excelのオプション → 「数式」 → エラー チェック ルール のカテゴリの 「文字列形式の数値、またはアポストロフィで始まる数値(H)」 のチェックを外す。


Excel2003の場合

ツール → オプション → エラーチェック のタブ → 「文字列として保存されている数値」のチェックを外す。


以上でエラーマークは表示されなくなります。


状態遷移図と有向グラフ

最も単純な状態遷移図は2つの状態を持ち相互に遷移可能な下図の状態遷移図でしょう。



組み合わせテストケース生成ツール 「PictMaster」 とソフトウェアテストの話題-単純な状態遷移図


さて、この状態遷移図の可能な状態遷移ルートはいくつあるでしょうか? s0からs1を往復する1つだけでしょうか。 じつはこの状態遷移図の可能な状態遷移ルートは無限にあります。


状態遷移の可能なルートを下図に示します。


組み合わせテストケース生成ツール 「PictMaster」 とソフトウェアテストの話題-状態遷移のルート

状態s0とs1との往復は無限に存在します。たとえばこの状態遷移で255回目の往復までは正常に動作するが、256回目の往復で不具合が発生するという可能性はゼロではありません。状態遷移のテストでは、何回か同じ動作を繰り返すとおかしくなるという現象はよく遭遇するものです。その意味で状態遷移テストで状態の往復を網羅することは不具合を発見する上で有効であるということができます。


PictMasterでは状態遷移テストのテストケースを作成することができますが、状態の往復を網羅するためには、最初の状態である始状態が最初と中間と最後にあり、その間に各状態を配置する形に状態遷移図を変形する必要があります。


例えば以下のような状態遷移図があるとします。


組み合わせテストケース生成ツール 「PictMaster」 とソフトウェアテストの話題-簡単な状態遷移図

状態遷移図は有向グラフの一種と考えることができます。状態がノードにあたり、矢印がアークにあたります。状態の往復を網羅した状態遷移図のテストケースを作成するためには、各ノードがアークの向きに並ぶように上から下に向かって配置します。状態遷移図と異なる点は、状態の遷移をノードの配置で表現する点です。これは有向グラフを時間軸上に沿って変形する操作にあたります。


変形した状態遷移図(有向グラフ)を以下に示します。


組み合わせテストケース生成ツール 「PictMaster」 とソフトウェアテストの話題-状態遷移図の変形

この有向グラフは始状態であるs0が最初と最後、そして中間の3箇所に配置されています。このように3箇所配置する目的には可能なすべての遷移ルートを網羅するという点もあります。もし最初と最後の2箇所にしかないと網羅できない遷移ルートが発生してしまいます。


変形した状態遷移図の各状態はPictMasterでのパラメータとなり、各イベントは値となります。ここで変形した状態遷移図を掲載しましたが、実際にPictMaster上にプロットする際は、わざわざ変形した状態遷移図を作成する必要はなく、それをイメージすることでPictMasterのモデルと制約表に転写することができます。

以下にこの状態遷移図のテストケースを生成するモデルと制約表、そして生成したテストケースを示します。


組み合わせテストケース生成ツール 「PictMaster」 とソフトウェアテストの話題-状態遷移図のモデル

組み合わせテストケース生成ツール 「PictMaster」 とソフトウェアテストの話題-状態遷移図の制約表


組み合わせテストケース生成ツール 「PictMaster」 とソフトウェアテストの話題-状態遷移図のテストケース


制約表の制約2は、PICTが1つのパラメータについて値が1だけの場合、その値を制約条件に指定するとエラーとなるため、ダミーの値として追加した「-」についてのものです。テストケースはこのダミーのテストケースを除いた5件となります。テストケース数は5件と少ないですが、1つのテストケースで複数の状態遷移を網羅しているため、状態遷移テストでよく用いられる状態遷移表によるテストケースよりも網羅度が高くなっています。Pairwise法(All-Pairs法)を用いているために任意の状態から他の2状態間のすべての状態遷移を網羅しています。実際のテストケースでは各状態間にその状態で確認すべき内容を記述した確認欄が挿入された形になります。


参考として従来の状態遷移表によるテストケースを示します。

組み合わせテストケース生成ツール 「PictMaster」 とソフトウェアテストの話題-状態遷移表のテストケース


今回示した例では最後の状態がs0で終わっていますが、続けてs1, s2を配置することでより網羅度の高いテストケースを生成することができます。

# と値の名称の間に空白があるとPICTでエラーとなる

この問題は最新バージョンだけに限ったことではありませんが、制約表で逆制約の演算子である # と値の名称の間に空白を設けるとPICTでエラーとなります。ただし、値のタイプが数字の場合はエラーとなりません。

次回のバージョンアップ時にこの問題を解決したバージョンをリリースする予定です。

この他に、パラメータ欄や制約表の行の一部を「表示しない」に設定していた場合、環境設定フォームを開いて閉じると、「表示しない」に設定していた行が強制的に「再表示」されてしまう問題も解決されます。

ソフトウェア開発工程とソフトウェアテスト工程の根本的な違いについて

狭義の「ソフトウェア開発」工程を要件定義からメイキングまでだとすると、「ソフトウェアテスト」工程は単体テストから受け入れテストまでを指すものとします。ソフトウェア開発とソフトウェアテストとの間には根本的な性質の違いがあります。その違いとはそれぞれに適用する「推論方法」が完全に分かれているからです。

もうお分かりだと思いますが、ソフトウェア開発工程において必要とされる推論方法は「演繹法」です。一方。ソフトウェアテスト工程において必要とされる推論方法は「帰納法」です。それぞれの工程での推論方法は完全といっていいほど分離しています。

狭義のソフトウェア開発工程においては、必ず演繹法にしたがった推論が用いられます。A=Bである。B=Cである。ゆえにA=Cである。という推論方法です。この推論は必ず正しいことが保障されています。正しい要件定義書から正しい基本設計書が作成され、正しい基本設計書から正しい詳細設計書が作成され、正しい詳細設計書から正しいコーディングが行なわれます。ただし人間がやることなので誤りが含まれる余地があります。そこでレビューが行なわれ、間違いがないかをチェックすることになります。この場合、レビュー対象の設計が正しいか誤っているかは自明の事柄です。ここで正しいか誤っているかの推論方法には演繹法を用いるほかにすべがありません。

ソフトウェアテスト工程においては、テスト対象のソフトウェアに欠陥が含まれたままとならないよう、できるだけ多くの欠陥を発見しようとします。このテスト工程では、できるだけ多くのパターンでテスト対象を動作させて見て欠陥を1つでも多く取り除くことに注力します。このときに用いられる推論方法は帰納法です。できるだけ多くのパターンでテストを繰り返すことによって、この場合も正常に動作した、あの場合も正常に動作した、といった事例を網羅し、その結果として欠陥が見つからないようになれば、欠陥はすべて取り除かれた(たぶん)と判断を下すことになります。したがってソフトウェアテストにおいては帰納法を用いることになります。というか帰納法しか使えないと言うべきでしょう。ここでどこまでテストするかが重要な問題となる場合があります。

ソフトウェアテストの方法は仕様に従った方法で実施しなければならないため、この点では演繹法の推論が用いられますが、それでも個々のテストケースに限ったことです。

単体テストなどのホワイトボックステストでは、直接ソースコードを見ながらテストするので演繹法を用いると考えがちですが、単体テストではテスト対象がテスト条件のもとにおいては正しく動作することを保障できますが、どのような条件のもとでも正しく動作することは保障できません(極端に単純なプログラムは除きます)。

デバッグ作業は演繹法の推論を用いて行ないますが、デバッグ作業はソフトウェアテストではありません。

ソフトウェアテストが帰納法の推論にもとづくものであるかぎり、「完全なテスト技法」というものは存在しません。ということは「多様な」テスト技法の中からテスト対象にふさわしいテスト技法を選択し、テストを行なうことが重要となってくる訳です。

組み合わせテストケース生成ツール PictMaster 4.0 をリリースしました。

Pairwise法(All-Pairs法)を採用した組み合わせテストケース生成ツール MTG 3.2 にいくつかの機能追加と軽微な不具合の修正を加えた PictMaster 4.0 をリリースしました。
諸般の事情からツールの名称を以前の「PictMaster」に戻しました。

MTG 3.2 からの主な変更点は以下の通りです。

2010.3.1 Ver. 4.0
【機能改善】
・制約表の制約指定と結果表の一致条件指定で値の名称に「*」、「?」のワイルドカードが使えるようにした。
・PictMasterの複数のワークシート間でセル範囲を指定してのコピー&ペーストを可能とした。
・先頭が0で始まる値でもゼロサプレスされることなくそのまま出力されるようにした。
・パラメータとパラメータの比較を行なう制約指定で、演算子とパラメータ名称の間にスペースがあってもエラーとしないようにした。
・結果表への記入処理を見直し、不必要だった処理をスキップすることで結果指定が多数でも瞬時に記入処理が完了するようにした。
・値の重み付けとエイリアス指定を同じ値に行なった場合にPictMasterでエラーメッセージを表示するようにした。
・環境設定のフォームのレイアウトを分かりやすいように変更した。

【バグ修正】
・ファイル a.xls が存在する状態で「生成」ボタンをクリックしたときにエラーメッセージのダイアログが表示されるが、このときに画面の再描画が行われないバグを修正した。
・その他、こまかい不具合の修正。

【その他】
・デフォルトのBook名称をPictMasterに変更した。
・マニュアルにパラメータの要因組み合わせと要因列挙とを合成することで合理的にテストケース数を削減する方法を追記した。その他、サブモデルに関する記述を分かりやすく整理した。
・変更履歴のファイルをPDF化した。

PictMaster 4.0 は以下のサイトからダウンロードすることができます。
http://sourceforge.jp/projects/pictmaster/

今回のリリースで機能追加は一段落し、保守モードに移行することになります。