(1)テスト設計技術

テスト設計のポイントは少ないテストでモレなく網羅

 テスト設計には図4[拡大表示]のようなポイントがあります。テストはやろうと思えばきりがありませんから，最小限の労力で最大の効果が得られるように知恵を絞ろうというわけです。


図4●テスト設計の心得
[画像のクリックで拡大表示]

表1●漏れがないようにテスト対象を網羅するための三つの視点
[画像のクリックで拡大表示]

図5●表1の三つの視点とテスト実施工程との関係
[画像のクリックで拡大表示]

図6●コード・ベースの視点によるテスト設計の例
[画像のクリックで拡大表示]

図7●デシジョン・テーブルの例。TはTrue，FはFalseを表す。しかし，本当にこれでいいのか…
[画像のクリックで拡大表示]

図8●作成し直したデシジョン・テーブル
[画像のクリックで拡大表示]

表2●テストすべき値の検討結果。MAXの値は不明。( )の数値は，他と重複するのでテストする必要はない
[画像のクリックで拡大表示]

リスト2●Webアプリケーションのログイン・テストに使うWSH（VBScript）のプログラム例
[画像のクリックで拡大表示]

 「より少ないテスト・ケース」にするために必要な考え方として「同値クラス」があります。同値クラスは，テストに使う入力値が同じ結果をもたらす場合，その入力値を「同値」と呼ぶことからきています。例えば，判定の条件になる数値範囲が1～100の場合に，テストするときの値を100個全部入れていたら時間が足りませんよね。100個の値が全部同じ判定をするのならば，代表になる値を何個か選択してテストするほうが断然効率的です。そこでテストする際は，入力値，出力値，判定条件，時間的な範囲，仕様上の範囲などあらゆるものの「同値」を見つけることでテストの数を減らしていこうというわけです。

 「より多くのバグが見つかる」ための代表的な方法として「境界値分析」があります。同値クラスの中から代表を選ぶときに「境目」，つまり境界の値がどこかを分析してテストに使う値とするのです。なぜ，境目の値を狙ったテストで，多くのバグを見つけられるのかというと，境界値は要求分析でも実装でも，勘違いしたり間違えたりしやすいからです。例えばある数字「以下」と仕様書には記載してあるのに，開発者が「未満」だと思い込んで作り込むケースがあったとします。この場合，「境目」の値をテストすれば簡単にバグを見つけることができます。

 「漏れがないようにテスト対象を網羅」する視点としては，要件ベース，設計ベース，コード・ベースの三つの視点があります(表1)[拡大表示]。この三つの視点と各テスト工程の関係は図5[拡大表示]のようになります。このようにどのテスト工程でも三つの視点をもってテスト設計を行うことで，網羅したテスト設計が行えるようになるわけです。

コード・ベースと要件ベースの
テスト設計をしてみよう

 三つの視点のうち，要件ベースとコード・ベースの二つについて，具体的にテスト設計を行ってみましょう。まずは比較的考え方がシンプルなコード・ベースからです。

 コード・ベースの視点では，代表的なテスト設計方法である制御パス・テストでテスト設計を行います。制御パス・テストは関数やメソッドのロジックの処理経路(パス)を動かすテスト方法です。まず図6[拡大表示]のようにソースコードをフローチャートなどでモデル化します。その後にプログラムの処理経路を洗い出します。

 図6の例では，A，B，Cの処理経路を洗い出しました。この三つの処理経路を通るためのデータは，それぞれ，A(0～80)，B(81～99)，C(100)の三つになります。この三つのパスのどの値を使うかは，前述した境界値分析の考え方を使います。したがって
A：-1，0，80，(81)
B：(80)，81，99，(100)
C：100，101
 の値が挙げられるでしょう＊7。つまり，7個のテスト・ケースが考えられます。

 次は要件ベースのテスト設計です。あるイベントのチケット代金の支払いについて，仮に次のような要件仕様があったとします。

「年齢が6歳以上18歳以下，現住所が埼玉県，学生証の提示ありの場合に，チケット代金を学割金額とする」
  この記述には，たくさんの組み合わせ条件のうちの正常になる一つのパターンしか書かれていません。そこで，デシジョン・テーブルを使って全パターンを洗い出します。デシジョン・テーブルとは，図7[拡大表示]のように条件と動作の関係を表形式で表現したものです。このケースでは，年齢や住所の条件をT(真：True)とF(偽：False)で判断することで，8個のパターンがあることがわかります。

 ただ，ここでよ～く考えてみてください。図7には落とし穴があります。わかりますか？ それは，年齢が6歳以上18歳以下という条件だけで年齢を判断してしまっている点です。これでは，0歳から6歳の人と，19歳以上の人の金額はFalseということで同じチケット代金ということになってしまいます。それはどう考えてもおかしいですよね。つまり，これは“仕様の確定漏れ”なのです。こういう場合は勝手に判断せず，正しい仕様はどういうことなのかを確認し直すようにしなければなりません。そこで作り直したのが図8[拡大表示]のデシジョン・テーブルです。

 実際にこの組み合わせを全部テストするかどうかは，各条件の依存関係によって変わってきます。特に依存関係が無い場合は，No.1，No.2，No.4，No.5，No.9の五つのテストを行えば良いでしょう。

 確認用のデータは，年齢は三つの同値にしているので境界値分析の考え方を使います。表2[拡大表示]のようになるでしょう。このとき，MAX値がいくつであるかも，確認することを忘れないでください。