メインコンテンツへスキップ

判定条件網羅（Decision Condition Coverage）の基礎と活用法

✨ はじめに

ソフトウェアテストにおいて、テストケースをどこまで作り込むべきかは大きなテーマです。特に条件分岐を含むプログラムでは、条件が複雑になるにつれて「テストが十分かどうか」を判断することが難しくなります。そこで役立つのが 網羅基準 であり、その一つが 判定条件網羅（Decision Condition Coverage, DCC） です。この記事では、その概要・歴史的背景・メリットと課題を整理します。

📜 歴史的背景と位置づけ

ソフトウェアテストにおける網羅基準

  • 初期のテストでは「すべての文を実行したか？」を確認する 命令網羅（Statement Coverage） が基本でした。

  • その後、「条件分岐がすべて実際に分かれるか？」という 判定網羅（Decision Coverage） が登場。

  • しかし、条件式が複雑化すると「if (A && B)」のように、判定全体がTrue/Falseになっても、内部の A や B が十分に検証されていない場合が出てきます。

  • これを補う形で 判定条件網羅 が考えられました。

🧩 判定条件網羅とは

定義

判定条件網羅（Decision Condition Coverage） は、以下を両立させる網羅基準です。

  1. 判定網羅（Decision Coverage）: 各判定結果（True / False）を少なくとも1回実行する。

  2. 条件網羅（Condition Coverage）: 判定式に含まれる各単純条件（A, B など）が True / False を少なくとも1回取る。

つまり、判定の結果 と 個別の条件の評価結果 の両方をテストで網羅する基準です。

🔍 具体例で理解

例: if (A && B) then ...

  • 判定網羅だけの場合

    • (A=true, B=true) → 判定=True

    • (A=false, B=true) → 判定=False
      → A=false, B=false や A=true, B=false を試さなくても判定結果は網羅される。

  • 条件網羅だけの場合

    • A=true, A=false を含むテスト

    • B=true, B=false を含むテスト
      → ただし、組み合わせ次第では判定の結果が同じだけに偏る可能性がある。

  • 判定条件網羅の場合

    • 判定（全体のTrue/False）と、A, B の個別のTrue/Falseをすべて1回以上カバー
      → 組み合わせ例:

      • (A=true, B=true) → 判定=True

      • (A=false, B=true) → 判定=False

      • (A=true, B=false) → 判定=False
        → この3ケースで判定網羅＋条件網羅を両立できる。

判定条件網羅は「全組み合わせ網羅（MC/DCや条件判定組合せ網羅）」ほどは厳しくないが、判定網羅や条件網羅の弱点を補えるちょうど良い基準。

✅ メリット

  • 判定網羅よりも 条件ごとのテスト漏れを防げる。

  • 条件網羅よりも 判定の動作を実際に確認できる。

  • テストケース数が増えすぎない（全組合せ網羅に比べて効率的）。

  • 規格（DO-178Cなどの安全規格）で求められることもある。

⚠️ 課題と限界

  • 各条件の影響が独立して検証されるわけではない。

    • 例: A, B, C の3条件がある場合、判定条件網羅ではAやBの値がCに依存していても検出できない。

  • 複雑な論理式では、依然として テストケース不足 のリスクあり。

  • 高信頼性が求められる分野では MC/DC（修正条件判定網羅） など、さらに厳格な基準が使われる。

判定条件網羅を満たしたからといって、バグがすべて潰せるわけではない。特にセーフティクリティカル領域ではMC/DC以上が必要。

🚀 まとめ

  • 判定条件網羅は、判定網羅＋条件網羅 を合わせたテスト基準。

  • 歴史的には、命令網羅 → 判定網羅 → 判定条件網羅 → MC/DC と発展してきた流れの中間地点にあたる。

  • 過不足の少ないテストを行うための現実的な選択肢であり、規模や重要度に応じて使い分けることが重要。

 

上に戻る