ソフトウェアテストでは、考えられるすべての入力値や操作パターンを確認することは現実的ではありません。
そこで重要になるのが、限られたテストケースで効率よく不具合を見つけるためのテスト設計技法です。
本記事では、代表的な以下4つの技法について、具体例を交えながら整理します。
- 同値分割法（Equivalence Partitioning）
- 境界値分析（Boundary Value Analysis）
- デシジョンテーブルテスト（Decision Table Testing）
- 状態遷移テスト（State Transition Testing）
テスト設計を学び始めた方や、それぞれの違いを整理したい方の参考になれば幸いです。
1. 同値分割法（Equivalence Partitioning）
概要
同値分割法とは、同じように処理される入力値をグループに分け、そのグループから代表値を選んでテストする技法です。
このグループを「同値クラス」と呼びます。
すべての値をテストするのではなく、同じ結果になると考えられる値をまとめることで、テストケース数を効率よく減らせます。
具体例
次の仕様を考えてみます。
年齢は18歳以上65歳以下の場合のみ入力可能とする。
この場合、入力値は次の3つの同値クラスに分けられます。
| 同値クラス | 入力範囲 | 代表値 | 期待結果 |
|---|---|---|---|
| 無効同値クラス | 17以下 | 10 | エラー |
| 有効同値クラス | 18～65 | 30 | 正常 |
| 無効同値クラス | 66以上 | 80 | エラー |
イメージすると、以下のようになります。
無効 有効 無効
───────────|─────────────────────|───────────
18 65
10 30 80
↑ ↑ ↑
代表値 代表値 代表値
18～65歳までのすべての値を確認する代わりに、たとえば「30歳」を代表値としてテストします。
ポイント
同値分割法は、ひと言で表すと、
同じ結果になるデータをグループ化する
という考え方です。
特に以下のような項目で活用しやすい技法です。
- 年齢
- 金額
- 数量
- 文字数
- 日付
- 選択肢
- 入力フォーマット
2. 境界値分析（Boundary Value Analysis）
概要
境界値分析とは、入力可能な範囲の境界と、その直前・直後の値を重点的にテストする技法です。
プログラムでは境界部分に不具合が発生しやすいため、正常値の中央付近よりも、境界付近を重点的に確認します。
たとえば実装時には、
<
と
<=
を間違えるといった不具合が起こる可能性があります。
具体例
先ほどと同じ仕様を使います。
年齢は18歳以上65歳以下の場合のみ入力可能とする。
境界値分析では、次のような値をテストします。
| テスト値 | 意味 | 期待結果 |
|---|---|---|
| 17 | 下限のすぐ外側 | エラー |
| 18 | 下限 | 正常 |
| 19 | 下限のすぐ内側 | 正常 |
| 64 | 上限のすぐ内側 | 正常 |
| 65 | 上限 | 正常 |
| 66 | 上限のすぐ外側 | エラー |
↓ 下限 ↓ 上限
──17──[18]──19────────64──[65]──66──
NG OK OK OK OK NG
同値分割法との違い
同値分割法と境界値分析は似ていますが、注目するポイントが異なります。
同値分割法
10 / 30 / 80
のように、それぞれのグループから代表値を選びます。
一方、境界値分析では、
17 / 18 / 19 / 64 / 65 / 66
のように、値が切り替わる境界付近を重点的に確認します。
実務では、
同値分割法でグループを整理し、境界値分析で境界を確認する
という形で、セットで使われることが多いです。
3. デシジョンテーブルテスト（Decision Table Testing）
概要
デシジョンテーブルテストとは、複数の条件と、それによって決まる処理結果の組み合わせを表形式で整理するテスト技法です。
条件が増えてくると、文章だけで仕様を確認するのは難しくなります。
そこで条件と結果をマトリクス化することで、
- 条件の組み合わせ漏れ
- 矛盾
- 仕様の曖昧さ
などを発見しやすくします。
具体例
ECサイトに次の仕様があるとします。
会員であり、かつ購入金額が5,000円以上の場合は送料無料とする。
条件は以下の2つです。
- 会員であるか
- 購入金額が5,000円以上か
これをデシジョンテーブルにすると次のようになります。
| 条件・結果 | ケース1 | ケース2 | ケース3 | ケース4 |
|---|---|---|---|---|
| 会員である | ○ | ○ | × | × |
| 5,000円以上 | ○ | × | ○ | × |
| 送料無料 | ○ | × | × | × |
このように整理すると、
「非会員だけれど5,000円以上購入した場合はどうなるのか？」
といったケースも明確になります。
向いているケース
デシジョンテーブルは、次のように複数の条件によって結果が変化する機能に向いています。
- 割引判定
- キャンペーン適用条件
- ログイン権限
- 承認条件
- 保険料計算
- 審査処理
- 配送料判定
イメージとしては、
条件A
＋
条件B
＋
条件C
↓
結果
です。
ポイント
ひと言で表すと、
条件の組み合わせを整理して、テストの漏れを防ぐ
ための技法です。
条件が2つ、3つと増えるほど、デシジョンテーブルの効果が大きくなります。
4. 状態遷移テスト（State Transition Testing）
概要
状態遷移テストとは、システムの現在の状態と入力・イベントによって、次の状態へ正しく遷移するかを確認する技法です。
同じ操作でも、現在の状態によって結果が変わるシステムに適しています。
具体例
ログイン機能に以下の仕様があるとします。
パスワードを3回連続で間違えた場合、アカウントをロックする。
この場合、システムには複数の状態が存在します。
通常状態
│
│ 1回目の失敗
↓
失敗1回
│
│ 2回目の失敗
↓
失敗2回
│
│ 3回目の失敗
↓
ロック状態
ここで重要なのは、
「間違ったパスワードを入力するとどうなるか」
だけではありません。
何回失敗した状態なのかによって、同じ「パスワード入力」という操作でも結果が変わります。
状態遷移表
表にすると、次のように整理できます。
| 現在の状態 | 操作・イベント | 次の状態 |
|---|---|---|
| 通常 | ログイン成功 | ログイン済み |
| 通常 | パスワード失敗 | 失敗1回 |
| 失敗1回 | パスワード失敗 | 失敗2回 |
| 失敗2回 | パスワード失敗 | ロック |
| ロック | 正しいパスワード入力 | ロックのまま |
状態遷移テストでは、正常な遷移だけでなく、
本来許可されていない遷移が発生しないこと
も重要な確認ポイントです。
たとえば、アカウントがロックされているのに正しいパスワードを入力するだけで解除されてしまう場合、それが仕様と異なれば不具合です。
向いているケース
状態遷移テストは、特に次のような機能に向いています。
- ログイン／アカウントロック
- 注文ステータス
- チケット予約
- ATM
- ワークフロー
- 承認処理
- ゲーム
- セッション管理
ポイント
ひと言で表すと、
現在の状態と操作によって、正しい次の状態になるかを見る
技法です。
入力値そのものより、操作の順番や履歴が重要になる機能で有効です。
4つのテスト技法を比較
ここまでの内容をまとめると、次のようになります。
| テスト技法 | 注目するもの | 覚え方 | 代表例 |
|---|---|---|---|
| 同値分割法 | 入力値のグループ | グループ | 年齢18～65歳 |
| 境界値分析 | 範囲の境界 | 境目 | 17、18、19、64、65、66 |
| デシジョンテーブル | 条件の組み合わせ | 組み合わせ | 会員 × 購入金額 |
| 状態遷移テスト | 状態とイベント | 流れ・状態変化 | 3回失敗 → ロック |
迷った場合は、次のように考えると整理しやすくなります。
値をグループ分けしたい
↓
同値分割法
範囲の境目が気になる
↓
境界値分析
複数条件の組み合わせがある
↓
デシジョンテーブル
操作履歴や現在の状態で結果が変わる
↓
状態遷移テスト
実務では複数の技法を組み合わせる
実際のソフトウェアでは、1つの機能に対して1つのテスト技法だけを使うとは限りません。
たとえば、ECサイトの会員登録機能を考えてみます。
年齢
18～65歳
という条件なら、
- 同値分割法
- 境界値分析
を利用できます。
割引条件
会員 ＋ 購入金額 ＋ クーポン有無
によって割引率が変わる場合は、
- デシジョンテーブル
が適しています。
ログイン
3回連続失敗
↓
アカウントロック
という仕様なら、
- 状態遷移テスト
が適しています。
つまり、重要なのは、
どの技法が正解かを1つ選ぶことではなく、仕様の特徴に応じて適切な技法を組み合わせること
です。
まとめ
今回紹介した4つの技法は、ブラックボックステストにおける基本的なテスト設計技法です。
覚える際は、まず以下の4つのキーワードと結びつけると理解しやすくなります。
| 技法 | キーワード |
|---|---|
| 同値分割法 | グループ |
| 境界値分析 | 境目 |
| デシジョンテーブル | 組み合わせ |
| 状態遷移テスト | 状態・流れ |
仕様を読んだときに、
「この入力はどのグループに分けられるか？」
「境界はどこか？」
「条件の組み合わせは何通りあるか？」
「現在の状態によって動作は変わるか？」
という4つの視点を持つだけでも、テストケースを考えやすくなります。
テスト技法は単なる知識ではなく、仕様を構造的に捉え、テストケースの抜け漏れを減らすための考え方です。
まずは身近な画面や機能を題材に、「この機能ならどの技法を使えるか？」と考えてみると、実務でも使える感覚が身につきやすくなります。