前提
- 全ての条件をテストすることはできない。 条件より要件を意識して、重要な機能に時間を割く。
- 単体テストとの違いは、結合テストではメソッドではなく、出口の値を検証する点にある。
- 実施は分岐網羅レベルで行。。
- ITaとITbがあり、 ITaはバッチ、画面、各機能別の検証、 ITbは各機能を統合した状態での検証を指す。
網羅性
すべての組み合わせを網羅しようとすると、ケース数がしばしば膨大になるため、 網羅性をどこまで考慮するか考えてテスト設計を行う必要がある。
特に全ての組み合わせを網羅するべき機能は、同じプロパティを複数回書き換えるケースや、たどりつく同じ解に、複数のルートが存在する場合などである。
組み合わせの除外
以下条件全てをテストする場合、15通りのテストを実施する必要がある。
- [a, b, c]のいずれか1つを取得する
- [1,2,3,4,5] のいずれか1つを取得する
- 処理1と2で取得した値を結合する
このとき、まず処理1でaを取得した場合に、 出力 a1,a2,3,4,5 が得られた場合、 処理2の値を結合するというロジックについては整合性が取れていることが確認できる。
そのため、残るは処理1のbとcについて、 値が結合されることを確認すればよく、b1と c1が出力される2ケースを追加した、 計7ケースに収めることができる。
処理が増えるほど、テストケースは指数関数的に増加するため、このように、どのテストでどのロジックが担保できるのか？を考慮してテストを設計することが重要となる。
条件別確認要件
AND条件
- 条件の1つを満たさない ※条件の数分実施
- 全ての条件を満たす
OR条件
- 条件の1つを満たす ※条件の数分実施
- 条件全てを満たさない
組み合わせにより、不規則に値が設定されるケース
- 全ての組み合わせの検証が必要
数値や、 日付による分岐
- 同値クラスを意識して、 境界値テストを実施する
同値クラスと境界値
例えば、値が 『1000』 と 『1500以上』 で特別な処理を行う場合、 同値クラスは以 下である。
- 1~999
- 1000
- 1001~1499
- 1500~
上記から、 境界値は、 1、999、1000、1001、1499、1500となる。
テストケースの作成手順
以下の分岐処理を網羅するMECEなテストケースを考える。
果物.種類 ="りんご" かつ、果物.産地="青森" かつ、
(
果物.色="赤""かつ、果物.サイズ="S" …条件B
または、
果物.色="青"または"黄" かつ、果物.サイズ="L" …条件C
) …条件A
の場合大分類からブレイクダウンして、すべての条件を書き出す
ROOT条件（種類／産地）：AND条件
| 果物.種類=”りんご” | 果物.産地=”青森” | 条件A | RETURN |
| F | T | T | F |
| T | F | T | F |
| T | T | F | F |
| T | T | T | T |
条件A（色／サイズ）：OR条件
| 条件B | 条件C | RETURN |
| T | F | T |
| F | T | T |
| F | F | F |
条件B（色／サイズ）：マトリクス条件 ※T/Fでも表現できるが、例としてマトリクスで表す
| 果物.色 | 果物.サイズ | RETRUN |
| 赤 | S | T |
| 赤 | ELSE | F |
条件C（色／サイズ）：マトリクス条件
| 果物.色 | 果物.サイズ | RETURN |
| 青 | L | T |
| 青 | ELSE | F |
| 黄 | L | T |
| 黄 | ELSE | F |
大分類からケース番号を割り振る
同じケース番号で対応できるものはまとめる。ただし、RETURNの値が変わると、親ケースのRETURNも変わるものしかまとめることはできない。
例えば、以下の条件Ａ票のケース4を見ると、RETURNはTであるため、本来、親のROOT条件表では4でなくても1、2にまとめることも考えられる。
しかし、1、2にまとめてしまうと、万一、処理に誤りがあり、条件AのRETRUNが実はFであった場合でも、ROOT条件表のRETURNはFのまま変わらず、検知することができない。
ROOT条件（種類／産地）：AND条件
| ケース番号 | 果物.種類=”りんご” | 果物.産地=”青森” | 条件A | RETURN |
| 1 | F | T | T | F |
| 2 | T | F | T | F |
| 3 | T | T | F | F |
| 4 | T | T | T | T |
条件A（色／サイズ）：OR条件
| ケース番号 | 条件B | 条件C | RETURN |
| 4 | T | F | T |
| 4-1 | F | T | T |
| 3 | F | F | F |
条件B（色／サイズ）：マトリクス条件
| ケース番号 | 果物.色 | 果物.サイズ | RETURN |
| 4 | 赤 | S | T |
| 3 | 赤 | ELSE | F |
条件C（色／サイズ）：マトリクス条件
| ケース番号 | 果物.色 | 果物.サイズ | RETURN |
| 4-1 | 青 | L | T |
| 3-1 | 青 | ELSE | F |
| 4-2 | 黄 | L | T |
| 3-2 | 黄 | ELSE | F |
※同じ値を返すものは枝番にしてまとめる
条件をまとめ、ケース番号順に並び変える
| ケース番号 | 果物.種類=”りんご” | 果物.産地=”青森” | 果物.色 | 果物.サイズ | RETURN |
| 1 | F | T | 任意 | 任意 | F |
| 2 | T | F | 任意 | 任意 | F |
| 3 | T | T | 赤 | ELSE | F |
| 3-1 | T | T | 青 | ELSE | F |
| 3-2 | T | T | 黄 | ELSE | F |
| 4 | T | T | 赤 | S | T |
| 4-1 | T | T | 青 | L | T |
| 4-2 | T | T | 黄 | L | T |
※赤字：枝番は親の値を引き継ぐ
Appendix
異常系のテスト
- 仕様 (要件) 外を異常系として、テストする
- 基本的にはシステムエラーとならなければ良い (正しく出力されるはずの情報が出力されない、誤った情報でDBが更新されない)
- 該当する条件（複数条件の組み合わせについても考慮する）のレコードがDBに存在する場合にテスト対象とする ※DBに存在しない異常系は時間の無駄
リグレッションテストの考え方
既存の実装に影響が無いかの確認。明確な対策ではないが、以下が考えられる。
- 命令網羅(1回はロジックを通る) の正常系を実施
- 修正前後で出力結果が同じであること
コメント