3. 健壮性测试基础与标准框架

星载计算机的资源耗尽问题，往往不是“功能没写对”，而是“异常条件下系统没有按预期收敛”。健壮性测试要回答的核心问题是：当输入越界、时序抖动、内存紧张、通信中断或单粒子翻转发生时，软件是否仍能保持可控状态，而不是崩溃、死锁或输出错误控制量。要系统化地回答这个问题，必须依托成熟的航天软件测试标准框架，并明确健壮性定义、故障模型与测试充分性准则三者的关系。

一、健壮性在航天标准中的定义

在 ECSS（欧洲空间标准化合作组织）体系中，健壮性通常与“容错”“故障容忍”并列讨论。ECSS-E-ST-40C 与 ECSS-Q-ST-80C 将软件健壮性理解为：软件在遭遇无效输入、异常时序、资源不足或内部故障时，仍能维持规定功能或安全降级的能力。NASA 的 NPR 7150.2 与 NASA-STD-8739.8 则更强调“软件保证”视角，把健壮性纳入安全性、可靠性与风险管理的整体框架，要求对关键软件进行故障注入与边界条件验证。GJB 体系（如 GJB 2786A、GJB 438B、GJB 5000A 相关软件测试要求）则从军用软件角度强调：健壮性测试应覆盖接口异常、资源极限、时序异常和故障恢复四类场景，并保留可追溯的测试证据。

三者表述不同，但共同指向一个可操作的定义：健壮性 = 在正常输入域之外，系统仍能保持安全状态、可恢复状态或可预测降级状态的能力。这一定义直接决定了测试用例不能只覆盖“合法输入”，而必须主动构造“非法但可能发生”的输入与故障。

二、故障模型：把“可能出错”结构化

健壮性测试不能靠随机尝试，必须建立故障模型。对星载计算机而言，常用故障模型可分为四层：

• 输入层故障：参数越界、类型错误、空指针、数据包长度异常、校验和错误、协议字段非法。
• 资源层故障：堆内存耗尽、栈溢出、文件描述符耗尽、消息队列满、CPU 占用率饱和、看门狗超时。
• 时序层故障：任务超时、中断延迟、时钟漂移、通信抖动、采样周期抖动、优先级反转。
• 硬件与空间环境故障：单粒子翻转导致寄存器位翻转、存储器位错误、总线错误、电源瞬降、传感器失效。

每一层故障都应映射到具体的注入方式与观测点。例如，资源层故障可通过内存分配钩子强制返回失败，观察软件是否进入安全模式；时序层故障可通过延迟任务调度或注入中断抖动，观察是否触发看门狗复位。故障模型的价值在于：它把“健壮性”从抽象要求转化为可枚举、可注入、可观测的测试对象。

三、测试充分性准则：什么时候算“测够了”

测试充分性准则回答的是“健壮性测试做到什么程度可以停止”。在航天标准框架下，常用准则包括：

• 故障模型覆盖率：已识别的故障类型中，被测试用例覆盖的比例。例如四层故障模型共 40 类，覆盖 36 类，则覆盖率为 90%。
• 边界与越界覆盖率：对每个输入参数，至少覆盖最小值、最大值、最小值减一、最大值加一、非法类型五类取值。
• 资源极限覆盖率：对每个动态资源，至少覆盖正常、80% 占用、100% 占用、分配失败四种状态。
• 恢复路径覆盖率：对每个可恢复故障，验证是否进入降级模式、是否记录日志、是否能在规定时间内恢复。
• 安全状态可达性：所有故障注入后，系统最终必须到达安全状态或可恢复状态，不允许出现不可控死循环或错误输出。

这些准则不是互相替代，而是分层叠加。实际项目中，通常先满足边界与越界覆盖，再逐步提升故障模型覆盖率与恢复路径覆盖率。

四、标准框架下的测试流程与证据链

ECSS、NASA、GJB 在流程上高度一致：先做健壮性需求分析，再设计故障注入用例，然后执行测试并记录证据，最后进行充分性评估与回归。区别在于证据形式与评审要求。ECSS 强调验证报告与可追溯矩阵；NASA 强调独立验证与确认（IV&V）和风险记录；GJB 强调测试记录、问题报告与归零闭环。

下面给出一个可直接参考的健壮性测试用例设计表，用于星载计算机资源耗尽场景。表中参数为教学示例，实际项目应按任务书与接口控制文件替换。

五、标准框架的落地要点

把 ECSS、NASA、GJB 的要求落到星载计算机项目，关键不是照搬条款，而是建立三条链路：需求链路（健壮性需求 → 故障模型 → 测试用例）、证据链路（用例 → 执行记录 → 充分性评估）、闭环链路（问题 → 归零 → 回归）。三条链路完整，健壮性测试才具备可审计性和可重复性。

此外，资源耗尽类故障具有累积性，单次注入可能不触发问题，需要设计“渐进式耗尽”用例：例如每周期泄漏 1 KB，持续 500 个周期，观察内存曲线与安全模式触发点。这类用例更能暴露真实星载环境中的慢速资源耗尽缺陷。

从标准框架到故障模型，再到测试执行与结果判定，健壮性测试的实质是把“异常”变成可管理、可度量、可追溯的工程对象。ECSS、NASA、GJB 提供的是框架与证据要求，而故障模型与充分性准则提供的是可操作的技术路径。只有两者结合，星载计算机的资源耗尽与健壮性问题才能真正从“事后救火”转向“事前可控”。