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

MC/DCと判定条件網羅の違いと実務での使い分け

✨ はじめに

前回の記事では「判定条件網羅（Decision Condition Coverage, DCC）」を取り上げました。今回はその発展形である MC/DC（Modified Condition/Decision Coverage, 修正条件判定網羅） を取り上げ、DCCとの違いや歴史的背景、実務における使い分け方を整理します。

📜 歴史的背景と登場の理由

  • 1970年代〜1980年代:
    ソフトウェアテストは命令網羅や判定網羅を中心に体系化。

  • 1980年代後半〜1990年代:
    航空機や医療機器など、人命に直結するシステムで「DCCでは不十分」という議論が強まる。

  • DO-178B（1992年）:
    航空機ソフトウェア規格でMC/DCが義務化。特にレベルA（最も高い安全性が必要）で必須に。

  • 以降: 自動車（ISO 26262）や医療機器（IEC 62304）でも参照されるようになり、セーフティクリティカル領域の標準に。

MC/DCは、単に網羅性を高めるだけでなく「各条件が判定にどう影響するか」を確認することを目的に誕生した。

🧩 MC/DCの定義

MC/DCでは、以下を満たすことが求められます：

  1. 判定網羅: 判定結果のTrue/Falseを少なくとも1回。

  2. 条件網羅: 各条件がTrue/Falseを少なくとも1回。

  3. 独立性の確認:
    各単純条件が、他の条件の値が固定された状態で判定結果を変えることがあると示す。

例: if (A && B)

  • 判定条件網羅では、以下の3ケースで十分：

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

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

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

  • MC/DCでは、AとBそれぞれが独立に判定に影響することを示さねばならない：

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

    • (A=false, B=true) → 判定=False（Aの影響を確認）

    • (A=true, B=false) → 判定=False（Bの影響を確認）

結果的にテストケース数は同じ3つになるが、**「意図してAやBが判定に効いているかを確認する」**のがポイント。

🔍 さらに複雑な例

if (A || (B && C))

  • 判定条件網羅: A, B, C の各True/Falseと判定結果のTrue/Falseが1回ずつ出ればよい。

  • MC/DC:

    • Aの変化が判定に影響することを確認

    • Bの変化が判定に影響することを確認

    • Cの変化が判定に影響することを確認
      → 5〜6ケース必要になる

MC/DCを満たすと、「どの条件がバグを引き起こしているのか」切り分けが容易になる。

✅ DCCとMC/DCの違いまとめ

項目 判定条件網羅（DCC） MC/DC
網羅範囲 判定結果と条件結果をそれぞれ網羅 さらに各条件の独立した影響を確認
必要テスト数 少ない 多め
検出力 条件不足や偏りを検出可能 条件の独立性まで検証でき、欠陥検出力が高い
主な利用領域 一般的なソフトウェア、Webシステム 航空機、自動車、医療など安全規格必須領域
歴史的位置づけ 判定網羅＋条件網羅の改良版 DCCの限界を克服した厳格基準

🚀 実務での使い分け

  • Webアプリや業務システム
    → 判定条件網羅で十分なことが多い。コストとリスクのバランス重視。

  • 金融システムや社会インフラ
    → 重要部分ではMC/DCを取り入れると安心。障害コストが高いため。

  • 航空・自動車・医療機器
    → 規格でMC/DCが必須。網羅基準を満たさないと認証不可。

MC/DCは強力だが、テストケース爆発が起きやすいため、自動生成ツールやカバレッジ解析ツールの利用が前提。

🌟 まとめ

  • DCCは「漏れを減らす」ための実用的な基準。

  • MC/DCは「条件の独立性を保証」するための厳格な基準。

  • 歴史的にはDCC → MC/DCと発展してきた。

  • 実務では システムの重要度とリスク に応じて基準を使い分けるのがポイント。


上に戻る