2. 星务软件测试标准与规范

星务软件（星载综合电子/姿轨控/OBDH 等）一旦在轨失效，几乎无法像地面软件那样热修复，因此测试标准与规范的核心作用，是把“测试什么、测到什么程度、用什么文档证明测过了”固化为可审查、可追溯的工程约束。国际上最常被引用的三套体系是欧空局的 ECSS、美国 NASA 的软件工程与安全标准体系，以及中国的 GJB 系列军标。它们并非互相替代，而是常在同一项目中分层引用：ECSS 提供航天软件全生命周期的过程框架，NASA 提供安全关键软件的严谨度分级与独立验证思路，GJB 则给出国内型号必须满足的强制条款与文档格式。

三套标准体系的定位与引用关系

ECSS 中与星务软件测试最直接相关的是 ECSS-E-ST-40C（航天软件）与 ECSS-Q-ST-80C（软件产品保证）。前者规定软件生命周期过程、验证与确认活动，后者规定保证活动与产品保证要求。ECSS 的显著特点是“按关键等级裁剪”：软件按关键性分为 A、B、C、D 四级，A 级（可能危及飞行或人员安全）要求最完整的验证、独立验证与确认（IV&V）和覆盖率证据，D 级可大幅裁剪。NASA 方面，NPR 7150.2 规定软件安全关键等级（Class A–E），NASA-STD-8739.8 规定软件保证与 IV&V 要求，其核心思想是“风险越高，独立验证与形式化证据越强”。GJB 方面，GJB 2786A《军用软件开发通用要求》、GJB 438B《军用软件开发文档通用要求》、GJB 5000A/B（软件研制能力成熟度）以及 GJB 8114 等，构成国内型号软件研制与测试的强制基线，其中 GJB 438B 直接规定了测试计划、测试说明、测试报告等文档的格式与内容。

实际项目中常见的引用方式是：型号总体依据 GJB 5000A 建立过程体系，软件研制任务书引用 GJB 2786A 与 GJB 438B 规定文档，若型号有国际合作或出口背景，则补充 ECSS-E-ST-40C 的验证活动与关键等级裁剪表，安全关键部分再参考 NASA-STD-8739.8 的 IV&V 要求。理解这一点，才能避免“标准堆砌”而不知道每条要求落在哪个测试活动上。

测试文档要求：从“测过”到“可证明测过”

标准体系对文档的要求，本质是让测试过程可追溯、可复现、可审查。GJB 438B 规定的核心测试文档包括《软件测试计划》《软件测试说明》《软件测试报告》，ECSS 对应的是验证计划、验证规范与验证报告，NASA 则强调测试计划、测试规程与测试结果的可追溯矩阵。无论名称如何，一份合格的测试文档必须回答四个问题：测什么（需求/接口/场景）、怎么测（用例、输入、预期输出、判据）、测的结果是什么（实际输出、偏差、结论）、以及需求是否被覆盖（追溯矩阵）。

以星务软件中“太阳敏感器数据采集与有效性判断”这一配置项为例，测试说明中一条用例应至少包含：用例编号、对应需求标识、前置条件（模拟器注入太阳敏感器数据帧）、输入数据（例如 0x1A2B 有效标志置 1、角度值 12.5°）、预期输出（采集值 12.5°、有效标志置位、无异常计数）、判据（误差 ≤ 0.1°）、以及测试方法（半实物仿真注入）。测试报告中则记录实际输出、是否通过、偏差说明与回归结论。这样的字段结构，正是 GJB 438B 与 ECSS 验证规范共同要求的“可追溯、可判定”。

测试级别划分与关键等级裁剪

测试级别通常划分为单元测试、部件/集成测试、配置项测试和系统测试四级。单元测试针对函数或模块，关注语句覆盖率、分支覆盖率与边界值；集成测试关注模块间接口、时序与数据流；配置项测试验证软件配置项是否满足软件需求规格说明；系统测试则把星务软件放入星务计算机、敏感器、执行机构等构成的闭环中，验证在轨场景下的功能与性能。ECSS 与 NASA 的关键等级裁剪，正是作用在这四级测试的深度与独立性上：A 级软件通常要求单元级覆盖率证据、独立验证与确认、以及系统级故障注入；D 级软件可减少独立验证，但仍需保留需求追溯与配置项测试。

实际裁剪时，建议先确定软件关键等级，再逐级确定测试深度。例如某星务软件被定为 B 级，则单元测试要求分支覆盖率 ≥ 90%，集成测试要求接口全覆盖，配置项测试要求需求全覆盖，系统测试要求典型在轨场景与至少一项故障注入；若定为 D 级，单元测试可只做功能覆盖，系统测试可只做正常场景。裁剪结论必须写入测试计划并经评审，不能由测试人员自行决定。

落地建议

在项目启动阶段，先建立“标准—文档—测试级别”三者的映射表：每条标准条款对应到具体文档章节与测试活动，每个测试级别对应到具体的覆盖率指标与评审节点。测试用例编号与需求标识必须双向可追溯，测试报告中的偏差必须闭环。这样，ECSS、NASA、GJB 就不再是纸面条款，而是贯穿星务软件测试与回归的可执行约束。