4. 验证需求分析与测试用例设计
长期运行稳定性验证的起点不是“跑多久”，而是“在什么任务条件下跑多久、跑哪些状态、跑多少次切换”。星载计算机在轨寿命通常以年计，但真正决定稳定性的，是任务剖面中反复出现的工况组合：长期稳态遥测、周期性载荷数据处理、轨道进出影时的温度与供电波动、姿态机动期间的高负载计算、以及故障恢复后的重构过程。验证需求分析的任务，就是把这些任务剖面要素映射为可观测、可判定、可复现的验证需求，再据此设计测试用例。
一、从任务剖面提取长期运行场景
任务剖面一般由轨道周期、工作模式、环境事件和任务事件四类信息构成。以某低轨遥感卫星为例，轨道周期约 95 min，其中光照约 62 min、地影约 33 min；工作模式包括安全模式、对地成像模式、数传模式和机动模式。长期运行场景的提取，应重点关注三类时间尺度：
- 连续稳态时长：如数传模式下连续 40 min 的载荷数据压缩与存储，考察内存泄漏、缓存溢出和看门狗误触发。
- 周期性切换次数：如每轨进出影各一次，一年约 5500 次，考察电源切换、时钟同步和任务调度的累积效应。
- 稀疏但关键事件：如单粒子翻转后的自主恢复、总线通信超时重试，考察故障恢复路径在长期运行后的可靠性。
提取时建议用“场景—触发条件—持续时间—频次—关键资源”五元组描述。例如：场景“成像后数传”，触发条件为“成像任务结束且测控可见”，持续时间 40 min，频次每轨 1 次，关键资源为 CPU、DDR 带宽、Flash 写入。这样得到的场景清单可直接作为验证需求的输入。
二、验证需求映射与测试用例设计
验证需求应写成“在什么条件下，系统应保持什么可观测属性，判定阈值是多少”。例如，不能只写“系统应长期稳定运行”，而应写“在连续 720 h 的稳态遥测场景下，CPU 占用率波动不超过 ±8%，堆内存剩余量下降不超过 2%，且无看门狗复位”。映射过程可参考下图：
测试用例设计方法上，长期运行验证不宜只依赖单一方法。常用组合包括：
- 等价类划分：把连续运行时长划分为短时（1 h）、中时（24 h）、长时（720 h）三类，分别验证瞬态、日周期和长期漂移。
- 边界值分析：针对内存余量、Flash 擦写次数、看门狗超时阈值等参数，取正常边界和极限边界各一组。
- 正交试验：当工作模式、环境温度、供电电压三个因素各有 3 个水平时，用 L9(3^4) 正交表安排 9 组用例，而不是 27 组全组合。
- 故障注入：对单粒子翻转、总线超时、任务超时等稀疏事件，用软件注入方式在加速环境中复现。
三、覆盖性与充分性评估
覆盖性评估要回答“任务剖面中的哪些场景已被用例覆盖”。建议建立一张覆盖矩阵，行是任务剖面场景，列是用例编号，单元格填写“覆盖/部分覆盖/未覆盖”。例如，若 TC-02 只覆盖了电源切换，未覆盖切换后的任务恢复，则标记为“部分覆盖”，并补充 TC-02A。充分性评估则进一步看三点：
- 时间覆盖：累计运行时长是否达到寿命的等效时间。若加速因子为 10，则 720 h 等效 7200 h，约 0.82 年，需说明外推依据。
- 事件覆盖：关键稀疏事件是否至少被注入或复现一次，如看门狗复位、总线重试、任务重构。
- 参数覆盖：CPU、内存、存储、总线、电源等关键资源的边界是否被触及。
四、一个可执行的用例设计示例
以 TC-01 为例，其设计要点如下：
用例编号：TC-01
验证需求：R1 连续稳态 720 h
前置条件：星载计算机处于遥测模式，供电 28 V，环境温度 20 ℃
输入：每 1 s 注入一帧遥测请求，每 10 min 记录一次资源快照
操作：连续运行 720 h，期间不主动复位、不切换模式
观测：CPU 占用率、堆内存剩余、看门狗计数、任务超时计数
判定：CPU 波动 ≤ ±8%，内存下降 ≤ 2%，看门狗计数 = 0
异常处理：若出现复位，记录复位原因并重新计时
该用例的“输入”是遥测请求流，“操作”是持续运行，“观测”是资源快照，“判定”是阈值比较。四者缺一不可，否则用例无法复现，也无法判定通过与否。
综上，从任务剖面到验证需求映射，核心是抓住“场景—需求—用例—判定”这条链。场景提取要覆盖连续、周期和稀疏三类时间尺度；需求要写成可观测、可判定的形式；用例设计要组合等价类、边界值、正交和故障注入；覆盖性与充分性评估则要回到任务剖面，检查时间、事件和参数三个维度是否闭合。只有这条链完整，长期运行稳定性验证才不是“跑得久”，而是“跑得准、判得清”。