4. 从需求到布尔表达式
在航空软件适航审定中，DO-178C 对 MC/DC 的要求并不是直接针对源代码，而是针对需求中可判定的逻辑条件。这意味着测试工程师必须先把自然语言书写的需求规格，翻译成结构清晰、可独立取真取假的布尔表达式，才能进一步设计 MC/DC 测试用例。这一转化过程是 MC/DC 覆盖率测试的起点，也是最容易埋下隐患的环节——如果表达式与需求语义不一致，后续再精确的覆盖率统计都失去意义。
一、为什么不能直接对需求文字做 MC/DC
航空软件需求通常以自然语言加表格的形式给出，例如“当自动驾驶接通且无线电高度低于 1500 英尺，或飞行员按下复飞按钮时，复飞模式应激活”。这句话里包含“且”“或”“低于”等逻辑词，但自然语言存在歧义：“且”与“或”的优先级如何？“低于 1500 英尺”是否包含 1500？多个条件之间是否存在隐含的时序依赖？MC/DC 要求每个原子条件都能独立影响判定结果，因此必须先把需求拆解为原子条件，再用明确的布尔运算符组合，形成无歧义的判定表达式。
二、转化的四个关键动作
从需求到布尔表达式，通常需要完成以下动作，它们不是简单的线性步骤，而是需要反复对照需求确认的迭代过程。
- 识别原子条件：把复合描述拆成不可再分、可直接判真假的命题。例如“高度低于 1500 英尺”是一个原子条件，而“高度低于 1500 英尺且自动驾驶接通”是两个原子条件的合取。
- 确定逻辑连接词：明确“且”“或”“非”“异或”等关系，并处理自然语言中的省略与隐含。例如“A 和 B 均满足”对应 AND，“A 或 B 至少一个满足”对应 OR。
- 处理比较与边界：把“低于”“不大于”“等于”等转化为带明确边界的不等式或等式，并标注是否含端点。航空软件中高度、速度、温度等参数常涉及边界值，边界定义错误会直接导致 MC/DC 用例遗漏。
- 消除时序与状态隐含：若需求隐含“先满足 A 再满足 B”，则不能简单写成 A AND B，而应引入状态变量或时序条件，否则布尔表达式无法表达真实逻辑。
三、一个可对照的转化示例
假设某飞控软件需求为：“当迎角大于 12 度且空速大于 180 节，或迎角大于 15 度时，触发失速告警。”我们按上述动作转化。
首先识别原子条件：A = 迎角 > 12°，B = 空速 > 180 节，C = 迎角 > 15°。注意 A 与 C 都涉及迎角，但阈值不同，不能合并。然后确定逻辑关系：需求中“A 且 B”构成一个合取项，“或 C”构成析取，因此判定表达式为：
StallWarning = (A AND B) OR C
其中：
A: AngleOfAttack > 12.0
B: Airspeed > 180.0
C: AngleOfAttack > 15.0这个表达式共有 3 个原子条件。按 MC/DC 要求，需要设计用例使每个原子条件都能独立影响判定结果。例如，固定 B=true、C=false，改变 A 的真假，观察 StallWarning 是否随之变化；固定 A=true、C=false，改变 B；固定 A=false、B=false，改变 C。这样就能覆盖每个条件的独立影响对。
四、转化结果的结构化表达
为了便于评审和测试用例追溯，建议把转化结果整理成“条件—表达式—边界—来源”的结构。下面给出一个可直接使用的示例表格，字段均围绕 MC/DC 测试设计所需信息设置。
| 条件编号 | 原子条件 | 布尔变量 | 边界/取值 | 需求来源 |
|---|---|---|---|---|
| C1 | 迎角 > 12.0° | A | 12.0 不含，12.1 为真 | REQ-FCS-021 |
| C2 | 空速 > 180.0 kt | B | 180.0 不含，180.1 为真 | REQ-FCS-021 |
| C3 | 迎角 > 15.0° | C | 15.0 不含，15.1 为真 | REQ-FCS-022 |
判定表达式为 (A AND B) OR C。基于该表达式，MC/DC 最小用例集可设计如下（示例，非实测）：
| 用例 | A | B | C | StallWarning | 独立影响条件 |
|---|---|---|---|---|---|
| T1 | 真 | 真 | 假 | 真 | — |
| T2 | 假 | 真 | 假 | 假 | A 独立影响 |
| T3 | 真 | 假 | 假 | 假 | B 独立影响 |
| T4 | 假 | 假 | 真 | 真 | C 独立影响 |
可以看到，T1 与 T2 构成 A 的独立影响对，T1 与 T3 构成 B 的独立影响对，T2 与 T4 构成 C 的独立影响对。四个用例即可满足该表达式的 MC/DC 覆盖要求。若表达式更复杂，用例数会相应增加，但设计方法一致。
五、转化过程中常见的陷阱
第一，把物理相关条件误当逻辑冗余。例如 A 与 C 在物理上相关，但布尔表达式层面不能省略，否则 MC/DC 会漏掉 C 的独立影响。第二，边界方向写反。航空软件中“低于”与“不大于”在边界点上的真假不同，必须与需求逐字核对。第三，忽略“非”条件。需求中“未接通”“无效”等否定描述应显式写成 NOT 形式，不能默认取反。第四，把时序条件写成纯组合逻辑。若需求要求“先 A 后 B”，应引入状态变量或时序算子，否则布尔表达式无法表达真实行为。
六、从表达式到测试设计的衔接
完成布尔表达式转化后，下一步才是 MC/DC 用例设计。表达式中的每个原子条件对应一个可独立取真取假的输入，每个逻辑运算符对应一个需要覆盖的判定节点。测试工程师应把表达式、条件表、用例表三者建立追溯关系，确保每个原子条件至少有一对用例证明其独立影响。这样，MC/DC 覆盖率就不再是事后统计的数字，而是从需求转化阶段就已被设计好的证据链。