3.3 ルールベースのテスト技法 (Rule-Based Test Techniques)

「ルールベースのテスト技法（Rule-Based Test Techniques）」 は、テスト対象アイテムの状態に関係なく有効なルール（例えば、ビジネスルールなど）によって仕様化された、ステートレス（状態を持たない）な振る舞いの実装を検証するための技法です。

前節の「振る舞いベースのテスト技法」が状態遷移やユーザーの操作フローに焦点を当てていたのに対し、このカテゴリでは複雑な論理条件の組み合わせや、データ入力と出力の間に存在する特定の「関係性（ルール）」に着目します。

本シラバス（v4.0）では、以下の2つのルールベースのテスト技法について詳しく論じています。

デシジョンテーブルテスト
メタモルフィックテスト

1. デシジョンテーブルテスト (Decision Table Testing)

デシジョンテーブルテストの基本はFoundation Levelで扱われていますが、Advanced Levelのテストアナリスト（TA）は、より高度な最適化（最小化）手法や、品質基準のレビュー方法を適用する必要があります。本シラバスの用語と表記法は、標準規格（OMG DMN）に従っています。

デシジョンテーブルの最小化 (Minimization)

TAは通常、すべての条件の組み合わせを網羅した「完全な（フル）デシジョンテーブル」を作成するか、テストベースから既存のテーブルを分析することから始めます。完全なデシジョンテーブルのルール数は、各条件が取り得る値の数の積となり、条件が増えると指数関数的に増加してしまいます。そのため、テーブルの「最小化」が必要になります。

「Don’t care (-)」の活用: アクション（結果）に影響を与えない条件の値を「Don’t care（気にしない：-）」演算子で置き換えることで、複数のルールを統合（マージ）します。
実現不可能なルールの除外: 現実には決して起こり得ない条件の組み合わせ（実現不可能なルール）は、ルールの統合時に無視することが推奨されます（多くの場合、統合前にテーブルから削除されます）。
アルゴリズム: 1つの条件のみが異なり、かつその条件の取り得るすべての値を網羅していて、結果（アクション）が同じである複数のルールを探し出します。それらを統合し、異なっていた条件の値を「-」に置き換えます。

最小化の結果は処理する列の順序に依存するため、常に最適な結果が得られるとは限りません。TAは、さらなる最小化が可能かどうかを確認する必要があります。

デシジョンテーブルのレビュー基準

TAは、他のステークホルダーと共に、以下の基準でデシジョンテーブルをレビューするタスクを担います。

整合性 (Consistency): 同じ条件の組み合わせに対して異なるルールが適用される場合、それらのアクションは等しくなければなりません。
実現可能性 (Feasibility): 実現不可能なルールが含まれていないかを確認します。
完全性 (Completeness): 実現可能な条件の組み合わせに、漏れがないかを確認します。
正確性 (Correctness): ルールがシステムの意図された振る舞いを正しくモデル化しているかを確認します。

また、ルール同士が「重複（オーバーラップ）」していないこと（任意の条件の組み合わせに対して、適用されるルールが最大で1つであること）も推奨されます。

チェックサム手順 (Checksum procedure)

テーブルが正しく最小化され、ルールに重複や漏れがないかを確認するために 「チェックサム手順」 を使用します。

最小化されたテーブル内の各ルールについて、それが元のテーブルでいくつのルールを代表しているかを計算します。
条件に「-」がないルールのスコアは1とします。
条件に「-」がある場合、その条件が取り得る値の数をスコアに掛け合わせます。
すべてのルールのスコアの合計が、最小化されたデシジョンテーブルの「チェックサム」となります。

判定: 最小化後のチェックサムが元のテーブルのチェックサムより小さい場合、テーブルは不完全（漏れがある）です。逆に大きい場合は、ルールが重複しているか、不要なルール（実現不可能な組み合わせなど）が存在しています。完全に等しければ計算上は合っていますが、それだけで元のテーブルとの等価性が完全に保証されるわけではない点に注意が必要です。

カバレッジと適用時の注意

デシジョンテーブルカバレッジは、「実行された列（ルール）の数」を「実現可能な列の総数」で割ることで測定されます。 TAがルールからテストケースを実装する際、「- (Don’t care)」をどのように具体的なデータに落とし込むかを決定しなければなりません（「-」は少なくとも2つ以上の値のいずれかを意味するため）。ただし、そのデシジョンテーブルに関連するリスクレベルが高い場合、TAはあえてテーブルを最小化せず、完全なデシジョンテーブル内の実現可能なすべての列をテストすべきです。

2. メタモルフィックテスト (Metamorphic Testing)

メタモルフィックテスト（MT）は、既存の「ソーステストケース（元となるテストケース）」をベースにして、新たなテストケースを自動的・論理的に生成するための技法です。

この技法では、 「メタモルフィック関係（Metamorphic Relation: MR）」 という概念を用います。MRとは、テスト対象アイテムの特定の特性を定義したもので、「入力データをこのように変更させたら、出力（期待結果）はこう変化するはずだ」という論理的な関係性を記述したものです。

具体例での理解

例えば、一連の数値の「平均値」を計算する関数があるとします。

ソーステストケース: ある数値のセット（例: [2, 4, 6]）を入力し、期待される平均値（4）が得られることを確認します。
メタモルフィック関係 (MR) 1: 「入力する数値の順番（順列）をどのように入れ替えても、平均値は同じになるはずだ」と定義します。
フォローアップテストケース: MR1に基づき、[6, 2, 4] や [4, 6, 2] など、順番を変えた複数のテストケースを生成します。期待結果はソースと同じ 4 のままです。
メタモルフィック関係 (MR) 2: 「入力するすべての数値を $x$ 倍したら、結果（平均値）も $x$ 倍になるはずだ」と定義します。これにより、$x$に異なる値を選ぶことで、無限に新しいテストケースを導出できます。

TAはこれらのテストケースをまとめて評価し、MRが満たされていれば「パス」、満たされていなければ「フェイル（失敗）」と判定します。

テストオラクル問題の解決とAIへの適用

メタモルフィックテストは、事前に明確な期待結果を用意することが難しい、またはコストがかかりすぎるという 「テストオラクル問題」 の解決に非常に役立ちます。

典型的な例が、機械学習を用いたAIベースのシステムです。例えば、膨大なデータから「死亡年齢」を予測するAIプログラムがあるとします。ある人物のデータを入力した際、AIが弾き出した年齢が正確かどうかを人間が事前に知ることは不可能です（テストオラクルがない）。
しかし、「他の条件がすべて同じで、喫煙するタバコの本数だけを増やした場合、予測される死亡年齢は下がるか、または同じになるはずだ」というメタモルフィック関係（MR）を定義することは可能です。これにより、AIの出力結果の妥当性を検証することができます。

適用時のポイント

現在、メタモルフィックテストには確立されたカバレッジ基準や明確な終了基準は存在しません。定義した各MRを1回ずつカバーするだけでは、検証としては不十分です。
そのため、自動テストを用いたランダムテストと組み合わせることが推奨されます。ランダムな入力を大量に生成し、それにMRを適用して膨大なフォローアップテストケースを自動生成して評価します。
機能テストだけでなく、負荷テストやインストールテストなど、非機能テストにも広く応用できる強力な技法です。