3. 故障注入测试基本原理

故障注入测试并不是“随便往软件里塞一个错误看它崩不崩”，它的理论根基是一条清晰的因果链：故障（Fault）→ 错误（Error）→ 失效（Failure）。理解这条链，才能理解为什么注入点、注入时机和判据设计决定了测试的有效性。

一、故障、错误、失效的传播链

在航空嵌入式软件语境下，这三个概念有严格区分：

• 故障：系统内部潜在的缺陷或异常条件。它可能是代码缺陷（如数组越界、除零、未初始化变量）、硬件位翻转、接口数据异常、时序偏差，也可能是需求遗漏。故障本身不一定立即表现为可观察的异常。
• 错误：故障被激活后，系统内部状态偏离了正确状态。例如某个传感器读数被注入偏移后，滤波器的内部状态量开始累积偏差，此时系统“已经错了”，但输出可能尚未越界。
• 失效：错误传播到系统边界，导致对外服务或输出不再满足规定要求。例如姿态解算输出超过允许误差、飞控指令超时未响应、告警未在规定周期内触发。

这条链的关键在于“传播”：故障被激活后，错误可能在多个模块、多个周期中传播和放大，最终才表现为失效。因此故障注入测试的核心不是“注入一个故障”，而是在受控条件下激活故障、观察错误传播路径、判定是否到达失效边界。

二、故障注入在 V 模型中的位置

V 模型左侧是需求分解与设计，右侧是集成与验证。故障注入测试并非只属于某一层，而是贯穿 V 模型右侧各验证层级，并在左侧设计阶段就需要预留注入接口和可观测性。

在单元测试层，故障注入主要针对函数级缺陷，例如注入非法参数、模拟返回值异常、强制分支跳转。在集成测试层，注入点转向接口和模块间交互，例如总线数据错误、消息丢失、时序抖动。在系统测试层，注入对象变为传感器、执行机构、供电和通信链路等真实或半实物接口。在验收测试层，则关注故障条件下系统是否满足安全需求，例如是否在规定时间内进入安全状态。

左侧设计阶段需要同步考虑：哪些故障需要被注入、注入接口放在哪里、注入后如何观测、失效判据如何定义。如果设计阶段没有预留可观测性和可控性，右侧测试阶段往往只能做“黑盒碰运气”，覆盖率和置信度都难以保证。

三、测试充分性与覆盖准则

故障注入测试的充分性不能靠“注入了多少个故障”来衡量，而要看注入是否覆盖了关键故障模式、传播路径和失效边界。常用的覆盖准则包括：

在实际工程中，通常先根据安全分析（如 FMEA、FTA）确定关键故障模式，再为每个故障模式设计注入用例，最后用覆盖准则检查是否遗漏。例如某飞控软件识别出 12 个安全相关故障模式，若只注入了 8 个，则故障模式覆盖率为 66.7%，未覆盖的 4 个必须补充用例或给出不注入的合理理由。

四、从原理到测试设计

把上述原理落到测试设计上，可以形成一条可操作的思路：先识别故障模式并确定注入点，再设计注入方式和激活条件，然后布置观察点以捕获错误传播，最后定义失效判据并判定结果。整个过程需要与 V 模型右侧的验证层级对应，并在左侧设计阶段就预留注入和观测能力。

例如针对“高度传感器偏置”这一故障模式，注入点选在传感器接口数据入口，注入方式为在指定周期后叠加一个缓慢漂移的偏置量，观察点包括滤波器内部状态、高度解算输出和控制指令，失效判据为实际高度偏离指令高度超过 ±30 m 且持续超过 2 s。测试执行后，若在 8 s 内触发失效判据，则记录传播时间、中间状态变化和最终失效形式；若未触发，则需分析是注入量不足、传播路径被抑制，还是判据设置不合理。

故障注入测试的价值，正在于它把“故障—错误—失效”这条链从理论变成了可观察、可度量、可重复的工程活动。只有理解传播链、明确 V 模型中的位置、并用覆盖准则约束测试充分性，注入测试才能真正支撑航空嵌入式软件的安全验证。