2.5 複合条件テスト (Multiple Condition Testing)

「複合条件テスト（Multiple Condition Testing）」 は、ソースコード内の判定文（if や while など）に含まれる「すべての単一条件（サブコンディション）の真（True）/偽（False）の組み合わせ」をすべて実行することを目的としたホワイトボックステスト技法です。

前節のMC/DCが「各条件が独立して影響を与える最小限の組み合わせ」を狙ったのに対し、複合条件テストは**「理論上可能なすべての組み合わせを力技で網羅する」**というアプローチをとります。

複合条件カバレッジの計算と「組み合わせ爆発」

複合条件テストの網羅率は 「複合条件カバレッジ」 として測定されます。単一の判定文の中に $N$ 個の独立した条件が含まれている場合、テストすべき組み合わせの総数は $2^N$ パターン になります。

計算式:

複合条件カバレッジ＝（実行された条件の組み合わせ数／実行可能な全組み合わせの数） × 100

具体例と爆発的増加リスク

例えば、if (A AND B AND C) という3つの条件を持つ判定文があったとします。

条件数 $N=3$ の場合: $2^3 = 8$ パターンのテストケースが必要です。
条件数 $N=5$ の場合: $2^5 = 32$ パターンのテストケースが必要です。
条件数 $N=10$ の場合: $2^10 = 1024$ パターンのテストケースが必要です。

このように、条件が少し増えただけでテストケースの数が指数関数的に膨れ上がる現象を 「組み合わせ爆発（Combinatorial Explosion）」 と呼びます。これが、複合条件テストの最大のデメリットです。

TTAが直面する「短絡評価」による到達不能な組み合わせ

前節のMC/DCでも触れた 「短絡評価（ショートサーキット）」 は、複合条件テストにおいてさらに大きな壁となります。

短絡評価を行うプログラミング言語（C、Java、Pythonなど）では、左側の条件だけで結果が確定した場合、右側の条件は評価されません。例えば、if (A AND B) の場合、理論上の組み合わせは4パターン（TT, TF, FT, FF）です。しかし、言語の仕様上、A が False の場合 B は評価されないため、実際のプログラムの実行においては (False, True) と (False, False) の違いは生まれず、後方の条件を強制的に評価させることができません。

テクニカルテストアナリスト（TTA）は、この言語仕様によって 「カバレッジツール上で100%を達成することが不可能な（到達不能な）組み合わせが存在する」 ことを理解し、コンパイラの最適化や言語仕様に基づいたカバレッジ結果の分析を行わなければなりません。

包含関係とTTAとしての適用ガイドライン

複合条件テストは、単一の判定文に対する論理カバレッジの中で最も強力（厳密）な基準です。

カバレッジの包含関係:

複合条件 100% ＞ MC/DC 100% ＞ブランチ 100% ＞ステートメント 100% （複合条件カバレッジを100%達成すれば、下位のすべてのカバレッジも自動的に100%達成されたことになります。）

いつ適用すべきか？

その厳密さの反面、組み合わせ爆発のリスクがあるため、TTAが複合条件テストを適用するケースは非常に限定的です。

条件数が少ない場合: 判定文の条件が $N=2$（4パターン）や $N=3$（8パターン）程度であれば、テスト設計の工数も少なく済むため、安全を期して複合条件テストを採用することがあります。
極めてクリティカルなソフトウェア: 万が一の論理バグが人命の喪失や環境破壊に直結するような、最高レベルの信頼性が求められるソフトウェアの特定のコアモジュールに対してのみ、局所的に適用されます。
MC/DCへの切り替え: 条件数が4以上になる場合、テストの費用対効果（ROI）が急激に悪化するため、TTAはテストマネージャや開発者と協議し、実質的な安全性を担保しつつテストケースを劇的に減らせる MC/DC（変更条件/デシジョンカバレッジ）への緩和 を提案するのがベストプラクティスです。