1. 航空软件适航与MC/DC的强制要求
在民用航空领域，机载软件能否装上飞机，并不取决于它“功能是否好用”，而首先取决于它能否证明“足够安全”。这套证明逻辑由适航规章与行业标准共同约束，其中 DO-178C 是机载软件适航符合性方法的核心标准，而 MC/DC（Modified Condition/Decision Coverage，修正条件/判定覆盖）则是该标准中针对最高安全等级软件提出的一项强制性结构覆盖目标。理解 MC/DC，必须先从它在适航体系中的位置讲起。
一、适航要求如何落到软件上
适航管理的顶层依据是各国的适航规章，例如美国联邦航空条例 FAR Part 25、欧洲的 CS-25，以及中国的 CCAR-25 部。这些规章规定的是飞机整机与系统的安全性要求，本身并不直接写“软件要做 MC/DC”。规章通过“可接受的符合性方法”把要求逐层传递：整机安全性目标 → 系统安全性评估 → 软硬件研制保证 → 具体标准。DO-178C《机载系统和设备合格审定中的软件考虑》就是被广泛接受的软件符合性方法，它把抽象的“安全”翻译成可执行、可审查的软件生命周期活动与目标。
DO-178C 的核心思想是：软件的安全等级决定研制过程的严格程度。等级越高，需要满足的目标越多、证据越强。因此，MC/DC 并不是孤立的技术指标，而是“高安全等级 → 更严格验证目标”这一逻辑链条的末端产物。
二、软件等级划分：A 到 E
DO-178C 依据“软件失效可能导致的飞机级后果严重性”，把软件分为五个等级：
| 等级 | 失效后果 | 典型含义 |
|---|---|---|
| A | 灾难性（Catastrophic） | 可能导致机毁人亡 |
| B | 危险性（Hazardous） | 严重降低安全裕度或机组处置能力 |
| C | 较大（Major） | 明显增加机组工作负荷或降低安全裕度 |
| D | 较小（Minor） | 轻微增加机组负担 |
| E | 无安全影响（No Effect） | 不影响飞机安全运行 |
等级由系统安全性评估（如 FHA、FTA、CCA 等）自上而下分配，而不是软件团队自行决定。例如，飞行控制律、发动机全权限数字控制（FADEC）、大气数据与惯导融合等通常被划为 A 级；而客舱娱乐系统往往为 D 级甚至 E 级。等级一旦确定，就决定了后续必须满足哪些目标。
三、MC/DC 作为 A 级目标的由来
DO-178C 为不同等级规定了不同的结构覆盖目标。对 C 级，通常要求语句覆盖；对 B 级，要求判定覆盖（Decision Coverage）；对 A 级，则要求修正条件/判定覆盖（MC/DC）。这一递进关系体现了“等级越高，越要证明测试充分”的原则。
为什么 A 级必须做到 MC/DC？因为语句覆盖和判定覆盖都存在明显盲区。判定覆盖只要求每个判定整体取到真和假，但一个由多个条件组成的复杂判定，可能因为某个条件被其他条件“掩盖”，导致该条件从未真正影响结果，缺陷因此被隐藏。MC/DC 要求：判定中的每一个条件，都必须至少有一次能够独立地影响该判定的结果。也就是说，在固定其他条件不变的前提下，改变该条件的取值，判定结果随之改变。这样，每个条件对判定结果的独立影响都被验证到，测试充分性显著提高。
从法规依据看，MC/DC 的强制力来自“DO-178C 被适航当局接受为符合性方法”这一事实。当某软件被定为 A 级，其验证目标表中就包含 MC/DC 目标；申请人若不能证明满足该目标，就难以获得适航批准。因此 MC/DC 不是可选项，而是 A 级软件的“准入条件”之一。
四、MC/DC 的判定逻辑与一个示例
设一个判定为 D = A and (B or C)，其中 A、B、C 为三个布尔条件。要满足 MC/DC，需要为每个条件找到一对测试用例，使该条件单独变化时 D 的结果发生变化。下面是一组可满足 MC/DC 的示例用例（示例数据，用于说明方法）：
用例1: A=1, B=0, C=0 → D=0
用例2: A=0, B=0, C=0 → D=0 （A 独立影响：用例1→2，D 由 0 变 0？需修正）
更严谨的一组：
用例1: A=1, B=1, C=0 → D=1
用例2: A=0, B=1, C=0 → D=0 （A 独立影响）
用例3: A=1, B=0, C=1 → D=1
用例4: A=1, B=0, C=0 → D=0 （C 独立影响）
用例5: A=1, B=1, C=0 → D=1
用例6: A=1, B=0, C=0 → D=0 （B 独立影响，与用例3配对）
实际工程中，测试用例由需求驱动设计，再用 MC/DC 准则检查覆盖是否完整。工具（如 LDRA、VectorCAST、RapiCover 等）可自动统计条件、判定的覆盖情况，并指出未满足独立影响的对。覆盖率报告是适航审查的重要证据之一。
五、从标准到实践的衔接
对航空软件团队而言，DO-178C 与 MC/DC 的要求会具体落到：需求可追溯性、测试用例设计、覆盖分析、工具鉴定、生命周期数据等方面。A 级软件不仅要满足 MC/DC，还要满足更严格的需求覆盖、结构覆盖与独立性要求。因此，MC/DC 测试通常与需求验证、代码审查、工具链鉴定协同进行，而不是单独的一项“跑覆盖率”任务。
下面这张图概括了从适航规章到 MC/DC 目标的传递关系，以及软件等级与覆盖目标的对应逻辑，帮助建立整体框架。
需要强调的是，MC/DC 只是 A 级软件众多目标中的一项。它解决的是“结构覆盖是否充分”的问题，但并不能替代需求验证、边界分析、鲁棒性测试等工作。真正通过适航审查的软件，是在完整生命周期活动与证据链支撑下，把 MC/DC 作为其中一块关键拼图。