一、DO-178C概述：软件级别划分、目标与产出物、结构覆盖在适航中的角色
各位工程师朋友，大家好。今天我们来聊聊DO-178C的开篇内容。说实话，我接触这个标准快十五年了，每次回头看都觉得有些新体会。咱们先从最基础的软件级别说起。
1.1 软件级别划分——说白了就是“出事后果有多严重”
DO-178C把软件分成五个级别，从A到E。这个分级不是拍脑袋定的，它完全取决于软件失效后对飞机安全的影响程度。我个人习惯用一个比喻来理解：
- Level A：软件失效会导致灾难性事故。比如飞控系统、发动机控制系统。说白了，这玩意儿坏了飞机就没了。
- Level B：失效会导致严重危险，但飞机还能勉强飞回来。比如部分导航系统。
- Level C：失效会造成较大影响，但机组还能处理。比如客舱压力控制系统。
- Level D：失效会引起轻微不便。比如机上娱乐系统。
- Level E：对安全没影响。比如一些维护用的地面软件。
关键点：级别越高，审查越严，需要的证据越多。Level A的代码覆盖率要求是100%的MC/DC覆盖，而Level D可能只需要语句覆盖就够了。
我在项目中遇到过一件事：有个团队把某个Level C的模块当成了Level D来做，结果到了适航审查阶段，发现缺少分支覆盖数据，硬生生补了三个月。嗯，这里要注意——级别划分必须在项目启动时就定清楚，不然后面全是坑。
1.2 目标与产出物——适航审查到底要看什么
DO-178C定义了66个目标（Objectives），这些目标分布在软件开发的不同阶段。你想想看，适航局方的人不可能把每一行代码都看一遍，他们看的是你有没有按照标准流程走，有没有留下足够的证据。
我整理了一下主要产出物，大家看看：
| 阶段 | 主要产出物 | 我个人的经验 |
|---|---|---|
| 计划阶段 | PSAC（软件适航计划）、SDP（软件开发计划）、SVP（软件验证计划） | PSAC是门面，写不好后面全白干 |
| 需求阶段 | 软件需求规格、需求评审记录 | 需求要可测试，不然覆盖分析没法做 |
| 设计阶段 | 软件设计说明、设计评审记录 | 架构设计直接影响结构覆盖的难度 |
| 编码阶段 | 源代码、编码标准检查记录 | 代码风格统一，工具分析才省心 |
| 测试阶段 | 测试用例、测试结果、覆盖分析报告 | 覆盖数据是适航审查的重头戏 |
| 集成阶段 | 集成测试报告、硬件/软件集成报告 | 别忘了做接口覆盖 |
小提示：产出物不是越多越好，关键是每个产出物都要能回答一个问题——“这个证据能证明软件是安全的吗？”
1.3 结构覆盖在适航中的角色——为什么它这么重要？
结构覆盖分析，说白了就是检查你的测试到底测了哪些代码路径。适航局方为什么盯着这个不放？因为光靠功能测试，你根本不知道有没有漏掉某些代码分支。
我曾经见过一个案例：某飞控系统功能测试全部通过，但结构覆盖分析发现有一段异常处理代码从来没被执行过。后来一查，那段代码里有个逻辑错误，如果真触发了异常，飞机会直接进入不可控状态。你想想看，如果没有结构覆盖分析，这个问题可能到飞机交付都发现不了。
DO-178C对结构覆盖的要求分三个层次：
- 语句覆盖：每行代码至少执行一次。这是最基础的，Level D就够用。
- 分支覆盖：每个判断的真假分支都要走到。Level C必须做。
- MC/DC覆盖：每个布尔条件的独立影响都要验证。Level A和B的硬性要求。
这里我画了一张图，帮大家理清结构覆盖在整个适航体系中的位置：
警告：结构覆盖分析不是万能的。它只能告诉你“测了哪些代码”，不能告诉你“测得对不对”。功能正确性还是要靠需求测试来保证。两者是互补关系，不是替代关系。
最后说一句，结构覆盖分析在适航审查中扮演的角色，就像安检在机场的角色——它不能保证绝对安全，但能大幅降低风险。我曾经参与过一个项目，就因为MC/DC覆盖差了一个条件，被局方打回来重新做测试。那感觉，嗯，挺难受的。所以大家从一开始就要把覆盖分析纳入测试计划，别等到最后才补。
好了，这一章就到这里。结构覆盖的具体方法，咱们后面慢慢聊。