2. 航空软件测试需求分析与平台功能定义

DO-178C 并不直接规定“测试平台应该有哪些按钮”，它规定的是机载软件必须满足的目标（Objectives），以及为证明这些目标已达成所需的证据（Evidence）。测试平台的价值，在于把“目标—证据—活动”这条链条自动化、可追溯化。因此本章的第一件事，是把 DO-178C 的目标翻译成可执行的测试需求，再据此定义平台的角色与功能模块。

一、从 DO-178C 目标推导测试需求

DO-178C 按软件等级（A~E）确定目标集合，等级越高，目标越多、独立性要求越强。以常见的 Level B 软件为例，与测试直接相关的目标包括：验证软件需求被正确实现、验证软件满足系统需求、验证软件对异常与边界条件的响应、确认测试覆盖达到结构覆盖率要求等。这些目标本身是“结论性”的，必须被拆解为可操作的测试需求。

推导的基本方法是“目标 → 证据 → 测试活动 → 测试需求”。例如目标“验证软件需求被正确实现”，其证据是需求覆盖分析报告与测试用例执行记录；对应的测试活动是基于需求的正向测试；由此产生的测试需求是“每条高层需求至少有一条测试用例覆盖，且用例包含预期结果与判定准则”。再如目标“结构覆盖率达成”，Level B 通常要求语句覆盖 100%、判定覆盖 100%，Level A 还要求 MC/DC。对应的测试需求就是“覆盖率分析工具能对目标代码插桩并输出未覆盖项清单”。

把目标逐条展开后，会得到一组测试需求条目。它们应具备可验证性：有明确的输入、预期输出、判定准则和追溯标识。下面是一份简化的测试需求条目示例（示例数据，用于说明格式）：

这一步的产出是平台的“输入规格”：平台必须能管理需求条目、关联用例、记录执行结果并生成追溯矩阵。若缺少这一步，平台很容易退化为一个“跑脚本的工具”，无法支撑适航审查。

二、平台用户角色分析

测试平台不是单人工具，它服务于多个角色，每个角色的关注点不同，直接决定功能优先级。

• 测试工程师：编写用例、配置测试环境、执行测试、查看失败详情。最关心用例编辑效率、执行反馈速度和日志可读性。
• 验证工程师（独立验证）：审查用例是否覆盖需求、复核执行结果。关心追溯完整性和结果不可篡改性。
• 软件开发者：根据失败用例定位缺陷。关心失败时的输入快照、变量值和调用栈。
• 适航/质量人员：关注证据链是否完整、工具是否经过鉴定（DO-330 工具鉴定）。关心报告导出与审计日志。
• 平台管理员：维护环境、账号、工具链版本。关心配置一致性与权限控制。

角色分析的关键结论是：平台需要“同一份数据、不同视图”。测试工程师看到的是用例编辑器，验证工程师看到的是追溯矩阵，质量人员看到的是符合性报告。权限与数据模型必须从一开始就设计好，否则后期补追溯会非常痛苦。

三、功能模块划分

综合测试需求与角色诉求，平台可划分为六个核心模块，它们之间的数据流关系如下图所示。

数据流方向是：需求管理提供追溯基准，用例管理基于需求生成用例，执行引擎驱动目标机或仿真环境运行用例，覆盖率分析从执行中采集结构覆盖数据，结果与追溯模块汇总执行记录并生成追溯矩阵，报告与审计模块输出符合性证据。六个模块共享同一数据模型，避免“需求在 Excel、用例在脚本、结果在日志”的碎片化。

四、用例设计示例

以某飞控软件的高度保持功能为例，其高层需求为“当高度偏差超过 ±30 ft 时，俯仰指令应在 200 ms 内响应”。据此可设计如下用例（示例参数，用于说明结构）：

用例ID: TC-ALT-005
关联需求: HLR-ALT-012
前置条件: 仿真大气数据源，初始高度 10000 ft
输入序列:
  t=0ms    高度阶跃至 10035 ft (偏差 +35 ft)
  t=50ms   记录俯仰指令
  t=250ms  记录俯仰指令
预期结果:
  t=50ms   俯仰指令开始变化
  t=250ms  俯仰指令变化量 ≥ 2.0 deg
判定准则: 响应时间 ≤ 200ms 且指令方向正确

该用例体现了三个关键点：输入是带时间戳的激励序列，中间观察点是响应起始时刻，判定准则是可量化的阈值。平台在执行时需自动记录时间戳、变量值和判定结果，并把这些数据回写到追溯矩阵中。

五、从需求到平台功能的映射

最后需要检查：每条测试需求是否都有平台功能承接。例如 TR-003 要求覆盖率 100%，平台就必须具备插桩、覆盖率采集和未覆盖项定位能力；TR-004 要求双向追溯，平台就必须在用例与需求之间建立可查询的关联字段。若某条测试需求没有对应功能，说明平台定义存在缺口，应在开发前补齐，而不是等到审查时才发现证据链断裂。