4. 测试用例建模与数据管理

在航空软件自动化测试平台中，测试用例不是一段随手写下的脚本，而是对“需求—激励—预期—判定”这一完整闭环的结构化描述。如果用例只以自然语言散落在文档里，自动化平台就无法稳定地生成激励、比对结果、追溯需求。因此本节的核心任务，是把需求转化为机器可解析的用例模型，并围绕航空参数的特点设计测试数据生成与边界值分析策略。

一、基于需求的结构化用例描述

结构化用例描述的目标，是让一条用例同时具备“可读、可执行、可追溯”三种属性。可读是给测试工程师和适航审查人员看的，可执行是给自动化执行引擎用的，可追溯是给需求覆盖分析用的。实现这一点的常见做法是把用例拆成固定语义字段，而不是把全部信息塞进一段描述文本。

一条航空软件用例通常包含以下字段：用例标识、关联需求标识、被测对象（如某型飞控软件的迎角限制模块）、前置条件（如系统处于地面维护模式、大气数据有效）、激励参数（信号名、量纲、取值范围、注入方式）、预期结果（输出信号、容差、判定条件）、后置处理与清理动作。其中激励参数与预期结果是自动化平台真正消费的部分，必须用结构化形式表达，例如以参数名、单位、标称值、上下限、容差、采样率来描述，而不是写成“给一个较大的迎角”。

下面给出一个可参考的用例描述片段，采用类 YAML 的结构化形式，便于平台解析：

case_id: TC_AOA_LIMIT_007
requirement: REQ_FCS_AOA_012
dut: FCC_AOA_Limiter
precondition:
  mode: GROUND_MAINT
  adc_valid: true
stimulus:
  - signal: AOA
    unit: deg
    nominal: 14.0
    range: [12.0, 18.0]
    tolerance: 0.05
    rate_hz: 50
expected:
  - signal: AOA_WARN
    value: true
    delay_ms: 120
    tolerance_ms: 20
  - signal: PITCH_CMD_LIMIT
    unit: deg
    max: 10.0
cleanup: reset_mode

这种描述方式的价值在于：平台可以直接读取 stimulus 生成激励序列，读取 expected 生成判定规则，读取 requirement 完成需求覆盖统计。用例模型一旦结构化，后续的数据生成、边界分析、回归筛选都可以在同一套字段上自动化展开。

二、测试数据生成策略

航空软件的测试数据不能只靠人工枚举，也不能盲目随机。合理的策略是分层组合：等价类划分负责压缩无效组合，边界值分析负责覆盖风险最高的临界点，正交或组合覆盖负责处理多参数耦合，随机与故障注入负责补充非预期场景。

以迎角限制模块为例，输入参数包括迎角、空速、俯仰角速率、大气数据有效性等。若每个参数取 5 个水平，全组合是 5⁴=625 组，成本过高。采用等价类划分后，可把迎角分为正常区、接近限制区、超限区；空速分为低速、巡航、高速；俯仰角速率分为平稳、机动；大气数据分为有效、无效。再用两两组合覆盖，通常几十组即可覆盖绝大多数参数交互缺陷。

数据生成还需要考虑物理约束。例如迎角与空速并非独立，某些组合在真实飞行中不可能同时出现，平台应支持约束表达式，如 AOA < 20 && IAS > 80，在生成阶段过滤非法组合，避免产生无意义的测试数据。对于时序相关参数，还要定义变化率与保持时间，例如迎角以 2°/s 从 12° 爬升到 18°，并在 18° 保持 500 ms，这样才能触发限制逻辑中的时间判定分支。

三、航空参数边界值分析方法

边界值分析是航空软件测试中性价比最高的方法之一，因为大量缺陷集中在参数临界点附近。对每个关键参数，应至少取五类点：下界外侧、下界、标称值、上界、上界外侧。若参数存在容差或迟滞，还需增加容差边缘点与迟滞回环点。

以迎角限制为例，假设限制阈值为 15.0°，告警触发容差为 ±0.2°，迟滞为 0.5°。则边界点可设计为：14.3°（下界外侧，不应告警）、14.8°（下界）、15.0°（阈值）、15.2°（上界）、15.7°（上界外侧，应告警）。同时还要测试从 15.7° 回落到 15.2° 时告警是否保持，以验证迟滞逻辑。这类“上升沿”和“下降沿”分别取点的方式，是航空参数边界分析区别于普通软件边界分析的关键。

下表给出一个边界值分析示例，明确每个点的设计意图与预期判定：

需要强调的是，边界值不是孤立取点，而应与数据生成策略联动。平台在解析用例模型时，应能根据参数定义自动推导出上述边界点，并生成对应的激励序列与判定规则。这样，测试工程师只需维护参数定义与阈值，边界点由平台自动展开，既减少人工遗漏，也保证回归测试的一致性。

四、用例模型与数据管理的协同

用例模型、数据生成与边界分析三者不是独立环节，而是同一条数据链上的不同阶段。用例模型定义“测什么”，数据生成策略决定“用哪些数据测”，边界值分析决定“重点测哪些点”。平台应把这三者统一到同一份参数元数据上：参数名、单位、量纲、标称值、上下限、容差、迟滞、变化率、采样率。只要元数据完整，用例展开、数据生成和边界推导都可以自动完成。

下图展示了从需求到用例模型、再到数据生成与边界分析，最终进入执行与判定的数据流关系。图中左侧是需求与参数元数据，中部是结构化用例模型，右侧是生成的数据集与边界点，底部是执行引擎与判定结果，形成一条可追溯的测试数据链。

从图中可以看出，需求与参数元数据是整个数据链的源头，结构化用例模型是中间枢纽，数据生成与边界分析是展开结果，执行引擎负责消费并回写覆盖状态。只要这条链保持完整，测试用例就不再是一次性的脚本，而是可追溯、可复用、可自动扩展的工程资产。对于航空软件而言，这种可追溯性不仅是效率问题，更是适航审查中证明“需求已被充分验证”的基础。