1. 航空软件测试平台开发导论
航空软件与普通商业软件最大的区别，不在于代码规模，而在于它一旦失效可能直接威胁飞行安全。因此，航空软件从需求、设计、编码到验证，都处在适航审定体系的约束之下。理解自动化测试平台为什么必须存在、应该具备哪些能力，需要先看清三个前提：软件在机载系统中的分类、DO-178C 对测试活动的硬性要求，以及人工测试在满足这些要求时的现实瓶颈。
一、航空软件的分类：等级决定测试强度
在机载系统中，软件并不是按“功能重要不重要”笼统划分，而是按失效后果的严重程度分级。DO-178C 沿用 DO-178B 的软件等级（Software Level）体系，从 A 到 E 共五级：
- A 级：软件失效会导致飞机灾难性失效，例如电传飞控律计算、主飞行显示的关键姿态解算。
- B 级：失效会导致危险性失效，例如部分告警与保护功能。
- C 级：失效会导致较严重的失效，例如客舱压力控制的非关键环节。
- D 级：失效仅导致轻微影响，例如部分维护信息显示。
- E 级：失效不影响飞机安全，也不增加机组工作负荷，通常不参与适航审定目标。
等级直接决定测试的“证据强度”。A 级软件要求满足 DO-178C 表 A-7 中全部目标，包括语句覆盖（SC）、判定覆盖（DC）和修正条件/判定覆盖（MC/DC）；B 级要求 SC 与 DC；C 级只要求 SC。这意味着同一段代码，若从 C 级升到 A 级，测试用例数量可能增加数倍，且每个判定中的每个条件都必须独立影响判定结果。测试平台若不能自动统计覆盖率并定位未覆盖的条件，A 级软件的验证几乎无法收敛。
二、DO-178C 对测试的核心要求
DO-178C 并不规定“必须用什么工具”，但它规定了必须产生的验证证据。与测试直接相关的目标集中在验证过程（Verification Process）中，可归纳为四条主线：
- 需求覆盖：每个高层需求与低层需求都必须有测试用例对应，且能双向追溯。
- 结构覆盖：按软件等级达到 SC、DC 或 MC/DC，并分析未覆盖代码的原因。
- 独立性：验证活动应由非开发者执行，或至少由独立于开发过程的人员确认。
- 可重复与可追溯：测试用例、测试结果、工具版本、配置项必须形成可审计的记录链。
这些要求落到工程上，就是大量重复的用例执行、结果比对、覆盖率采集和证据归档。以 MC/DC 为例，一个含 4 个条件的判定，理论上需要构造满足“每个条件独立影响判定”的用例组合，人工设计容易遗漏，执行后还需逐条核对真值表。这正是自动化测试平台的价值入口。
三、自动化测试平台的价值与核心能力
航空软件自动化测试平台不是简单的“脚本批量跑用例”，而是围绕适航证据链构建的工程系统。它的价值体现在三方面：把重复执行交给机器，把覆盖率与追溯关系自动关联，把测试结果固化为可审计的证据包。一个可用的平台通常需要具备以下核心能力：
- 测试用例管理：用例与需求 ID、软件等级、配置项绑定，支持版本冻结。
- 测试执行引擎：驱动目标机或仿真环境，按序执行用例并采集输出。
- 结果判定与比对：支持期望值比对、容差判定、超时与异常捕获。
- 覆盖率采集：与插桩工具或目标机调试接口配合，统计 SC/DC/MC/DC。
- 追溯与报告：自动生成需求—用例—结果—覆盖率的追溯矩阵和审定报告。
- 配置与版本管理：记录被测软件版本、工具版本、测试环境配置，保证可重复。
下面用一张结构图说明平台各能力模块与适航证据之间的对应关系。图中左侧是 DO-178C 的验证目标，右侧是平台模块，中间通过数据流连接，体现“目标驱动模块、模块产出证据”的关系。
四、从人工到自动：一个可感知的对比
假设某 A 级飞控软件有 1200 条低层需求，人工执行一轮回归测试约需 3 人周，覆盖率统计靠插桩工具导出后手工整理，追溯矩阵用电子表格维护。当需求变更 5% 时，人工需要重新识别受影响用例、重跑、重新统计，周期长且容易漏项。引入自动化平台后，用例与需求 ID 绑定，需求变更可自动标记受影响用例；执行引擎在夜间批量跑完，覆盖率与追溯矩阵自动刷新。测试人员的工作从“执行与抄录”转向“分析未覆盖原因与判定异常”，这才是平台真正的价值所在。