テスト設計技法の紹介(3)：網羅型のブラックボックス型技法
今回はブラックボックステスト技法の続きとして、網羅型の技法を解説します。
紹介する技法
今回紹介する技法の名前と分類、概要を以下に挙げます。
| デシジョンテーブルテスト | ユースケーステスト | 状態遷移テスト | |
|---|---|---|---|
| 概要 | テスト対象の仕様をデシジョンテーブルで整理し、作成された入出力の組み合わせパターンをテストケースとして考える技法 | テスト対象の仕様をユースケース記述で整理し、発生しうるフローをテストケースとして考える技法 | テスト対象の仕様を状態遷移モデルで整理し、発生しうる遷移列をテストケースとして考える技法 |
デシジョンテーブルテスト
考え方
デシジョンテーブルは「決定表」と呼ばれることもあり、入力・条件に対する出力・動作を決定するために用いられる整理方法です。
デシジョンテーブルの書き方は文献によりさまざまですが、基本的にはどの様式も数の通り、4つの記述エリアにわかれます。
- 条件
- 条件記述部（左上）：起こりえる入力や条件のバリエーションを列挙する
- 条件指定部（右上）：条件記述部に列挙した各条件の組み合わせパターンを作成する
- 動作
- 動作記述部（左下）：起こりえる出力や動作のバリエーションを列挙する
- 動作指定部（右下）：条件指定部で作成した各パターンに対して、動作記述部に列挙した各動作の振る舞いを決定する
条件指定部と動作指定部を記述する際に用いる記号もさまざまですが、代表的なものとして「成り立つ」場合は「T(rue)」、「成り立たない」場合は「F(alse)」を用いる記法があります。
また条件指定部では「成り立つ／成り立たないのどちらでもよい」を「-」で表現します。
このような形でシステムの仕様を整理し、洗い出された振る舞いの各パターンを1件ずつテストケースとして用いるのがデシジョンテーブルテストの考え方です。
具体例
簡単な具体例を考えてみましょう。以下のような仕様の映画割引システムを考えます。
- 水曜日は女性は割引
- レイトショーは割引
このシステムの入力パラメータは、1つめの仕様から「曜日」「性別」、2つめの仕様から「時間帯」があることが読み取れます。
また結果としては今回は具体的な値段についての言及はないため、割引があるかないかだけを考えます。
すると、デシジョンテーブルを用いて以下のように仕様を整理することができます。
デシジョンテーブルの例
入力パラメータは独立しているため、単純に考えると2 × 2 × 2 ＝ 8通りのパターンができますが、「-（どちらでもない）」をうまく活用することで5パターンに整理できます。
注意点
デシジョンテーブルは強力な仕様整理法ですが、もちろん制限もあります。一番大きな制限としては、「順序」を考慮できないことです。
デシジョンテーブルは、ある入力に対する出力、というシステムへの問い合わせが1回の仕様を整理することには向いています。
一方、問い合わせが連続し、前の結果を受けて結果が変わるといった、順序が仕様に影響を与える場合には向いていません。（条件指定部を記述する際に工夫すれば表現は可能ですが、デシジョンテーブルの記法の恩恵はうけられず、したがって考慮漏れなどが発生する可能性があります。）
そういった仕様を整理しテストケースを設計するには、次に紹介するユースケーステストの考え方が有効です。
ユースケーステスト
考え方
ユースケースは、UMLにも記法が定義されている、ユーザがシステムを利用して達成したい・できる目的と、その目的を達成するための具体的なシステムとのインタラクションを表現したものです。
インタラクションには以下の2種類があります。
| 種類 | 説明 |
|---|---|
| 基本系列 | ユーザとシステム間の最も典型的で正常なインタラクションの流れ |
| 代替系列 | 基本系列には含まれない例外的なインタラクションの流れ |
（上記の2種類に加えて「例外系列」を扱う考え方もありますが、ここでは例外系列は代替系列に含むとします。）
ユースケーステストは、基本系列とそこから派生する代替系列で構成されたユースケースに対して、フローのパターンを網羅するようにテストケースを設計する技法です。
網羅基準は書籍や文献によって様々な考え方がありますが、シンプルなものであれば例として以下のような網羅の仕方が考えられます。
- 基本系列のフローが正しく振る舞うかどうかを確認する。
- 全ての代替系列について、1回代替系列を通るようなフローが正しく振る舞うかどうかを確認する。
ここではこの考え方で、具体例を見ていきましょう。
具体例
例として、以下のような映画予約システムを考えます。（スペースの都合上、基本／代替系列のみを掲載します。）
| 系列 | 内容 |
|---|---|
| 基本系列 | 1. ユーザは見たい映画を選択する |
| 2. システムは選択された映画の予約可能な上映回を表示する | |
| 3. ユーザは希望の上映回を選択する | |
| 4. システムは選択された上映回の予約を実施する | |
| 5. ユーザは予約番号を確認する | |
| 代替系列1 | 2a. シスタムは選択された映画に予約可能な上映回がなければエラーメッセージを表示し、基本系列1に戻る |
| 代替系列2 | 4a. システムはエラーによって選択された予約回を予約できなければエラーメッセージを表示し、異常終了する |
このユースケースに対して先ほど挙げた基準でフローのパターンを抽出します。 まず、1つめのテストケースとして、基本系列のフローを以下のように抽出します。
| テストケースID | フロー | 概要 |
|---|---|---|
| 1 | 1 ⇒ 2 ⇒ 3 ⇒ 4 ⇒ 5 | 基本系列のフロー |
次に、2つある代替フローについて、それぞれを含むようなフローをテストケースとして追加します。
| テストケースID | フロー | 概要 |
|---|---|---|
| 1 | 1 ⇒ 2 ⇒ 3 ⇒ 4 ⇒ 5 | 基本系列のフロー |
| 2 | 1 ⇒ 2a ⇒ 1 ⇒ 2 ⇒ 3 ⇒ 4 ⇒ 5 | 代替系列1を含むフロー |
| 3 | 1 ⇒ 2 ⇒ 3 ⇒ 4a | 代替系列2を含むフロー |
したがって、この例では3つのテストケースが作成できます。
注意点
ユースケーステストを利用する際に気をつけるべきことは、事前にしっかりと系列の網羅基準を決定することです。今回の例ではシンプルに2つの網羅したルールを設けましたが、実際に活用するには、例えば「代替系列を可能な限り全て同時に含ませたフロー」などを追加することで、より多くバグを発見できることがあります。
このようにプロジェクトの品質目標などに合わせて、適切な網羅基準を設定することで、効果的なユースケーステストの実践が可能になります。
状態遷移テスト
考え方
先ほどはユーザとシステムのインタラクションを扱いましたが、最後にシステムやシステム内部のデータの状態を扱う状態遷移テストについて解説をします。
状態遷移テストは、状態遷移モデルで表現された設計情報を読み解き、遷移のパターンを網羅するようにテストケースを設計する技法です。状態遷移モデルにはさまざまな表現方法がありますが、ここでは簡単のため、以下の4つの要素で構成されたものを扱います。
| 構成要素 | 説明 |
|---|---|
| 初期状態 | どの状態からも遷移してこない状態。扱われる状態のライフサイクルはここからはじまる。 |
| 状態 | ある特定のシステム、もしくはシステムで扱われるデータの状態。 |
| 遷移 | システムに対する作用によって発生する状態の遷移。遷移が発生する条件となる作用を自然言語で記述する。 |
| 終了状態 | どの状態にも遷移しない状態。扱われる状態のライフサイクルはここで終わる。 |
ユースケーステストと同様、状態遷移テストも網羅基準にはさまざまな考え方が存在します。ここでは一番シンプルな以下の網羅基準を用いて、この後の例題を考えていきましょう。
- 全ての2状態間遷移について、正しく振る舞うかどうかを確認する。
なおここでは、初期状態からの遷移、および終了状態への遷移は含まないものとします。
具体例
例として、映画システムにおいて各上映回は以下のように状態が遷移するとします。
デシジョンテーブルの構成”
この状態遷移モデルに対して先ほど挙げた基準で遷移のパターンを抽出します。
2状態間遷移の網羅は非常に簡単で、モデル内に存在する全ての遷移をそのままテストケースとして抽出するだけです。
この例では遷移は4つあるため、テストケースも以下の4つとなります。
| 項番 | 説明 |
|---|---|
| 1 | 予約可能状態のときに満員となった場合、予約不可能状態となることを確認する。 |
| 2 | 予約不可能状態のときにキャンセル等が発生して満員でなくなった場合、予約可能状態となることを確認する。 |
| 3 | 予約可能状態のときに上映が完了した場合、上映完了状態となることを確認する。 |
| 4 | 予約不可能状態のときに上映が完了した場合、上映完了状態となることを確認する。 |
注意点
先述の通り、状態遷移テストもユースケーステストと同様、モデルに対する網羅基準をどのように設定するかが、テスト設計の品質を左右します。
例では2状態間遷移を扱いましたが、より念入りにテストをするためには、例えば3状態間遷移を網羅するようなテストケースを追加することが考えられます。
先ほどの例では3状態間遷移は4つ存在するため、2状態間遷移と合わせて8つのテストケースが作成されることになります。
今回は網羅型のブラックボックス型技法としてデシジョンテーブルテスト、ユースケーステスト、状態遷移テストの3つのテスト設計技法を紹介しました。
どれも活用シーンの多い重要な技法ですので、日頃の業務で活用できるものがあればぜひトライしてみてください。
次回はホワイトボックス型技法について解説を行います。
参考文献：
テスト技術者資格制度 Foundation Level シラバス 日本語版
© International Software Testing Qualifications Board VER2011
© 日本語翻訳版Japan Software Testing Qualifications Board Version 2011.J02
執筆者：プロフィール みけねこ
某IT企業勤務。入社以来B2B、B2C系のWebシステムの開発やテストに従事。現在は社内の開発支援ツールの開発や、テスト工程も含めた標準開発プロセスの整備を担当。興味のある分野は振る舞い駆動開発とテストコードの自動生成。
