2. 航天器测试需求体系
航天器测试需求不是凭空写出来的，它必须能回答三个问题：这条需求从哪来、它在体系里处于哪一层、它被谁引用和验证。测试需求体系的作用，就是把分散在任务书、接口文件、故障预案和标准规范中的约束，整理成可追踪、可评审、可冻结的结构化条目。没有体系，测试就会出现"该测的没测、测了的说不清为什么测"的情况。
需求来源：四条主渠道
航天器测试需求的来源可以归纳为四类，每类对应不同的输入文件和提取方式。
- 任务与系统级要求：来自任务书、研制总要求、系统设计报告。例如"整器在发射前需完成一次全系统电性能测试"，这类需求通常以功能、性能指标形式出现，需要转化为可执行的测试项目。
- 接口控制文件（ICD）：来自星上各分系统之间、星地之间的接口定义。例如某遥测参数为28V离散量、更新周期1s，测试需求就要覆盖该参数的采集、传输和显示链路。
- 标准与规范：来自GJB、QJ、ESA/NASA相关标准以及型号测试规范。例如电磁兼容性测试的限值、接地电阻要求，直接构成测试通过判据。
- 故障模式与预案：来自FMEA、故障树和飞控预案。例如"若某陀螺失效，需验证冗余切换逻辑"，这类需求往往在常规功能测试之外，属于专项测试需求。
实际工作中，需求提取不是简单抄录。以某型号太阳翼展开测试为例，任务书只写"验证展开功能正常"，而测试需求需要细化为：展开指令发送后，展开到位信号应在规定时间内有效；展开电流峰值不超过限定值；展开后锁定状态遥测正确。这些细化条目才是可验证的测试需求。
层级划分：从任务级到用例级
测试需求按层级划分，通常分为四层，层级之间是"分解—追溯"关系，而不是简单分类。
| 层级 | 典型内容 | 示例 |
|---|---|---|
| 任务级需求 | 任务成功准则、飞行阶段目标 | 发射前完成全器综合测试并确认状态 |
| 系统级需求 | 分系统功能、性能、接口约束 | 姿轨控分系统在轨自主运行模式验证 |
| 分系统级需求 | 设备级功能、时序、参数范围 | 陀螺冗余切换时间≤200ms |
| 测试用例级需求 | 具体激励、观测点、判据 | 注入陀螺A故障，观测切换标志和切换时间 |
层级划分的关键是"每层可独立评审"。任务级需求由总体评审，系统级由分系统负责人评审，用例级由测试工程师评审。层级越往下，需求越具体、越接近可执行操作。需要注意的是，层级不等于测试阶段，同一层级需求可能在不同测试阶段被多次验证。
需求标识：唯一、稳定、可追溯
需求标识是需求体系的"身份证"。没有唯一标识，追踪矩阵就无法建立。推荐采用结构化编码，例如：
TR-SYS-AOCS-0012
│ │ │ │
│ │ │ └── 序号（4位，从0001起）
│ │ └─────── 分系统代码（AOCS=姿轨控）
│ └─────────── 层级代码（SYS=系统级）
└─────────────── 固定前缀（TR=Test Requirement）标识一旦分配，在需求生命周期内不应变更。如果需求内容发生重大修改，应通过版本号区分，而不是重新编号。例如 TR-SYS-AOCS-0012 V1.2 表示该需求第1.2版。这样做的目的是保证追踪矩阵中的引用关系不会因为编号变化而断裂。
标识还应携带"来源引用"字段，记录该需求来自哪份文件的哪一条。例如来源填写 ICD-AOCS-003 Rev.C §4.2.1，这样当上游文件改版时，可以快速定位受影响的需求条目。
需求基线管理：冻结、变更与追溯
需求基线是经过评审并正式冻结的需求集合。基线管理的核心动作有三个：建立基线、变更控制、追溯维护。
建立基线：在测试大纲评审通过后，将当前版本的全部测试需求纳入基线，分配基线号，例如 BL-TR-2024-03。基线建立后，需求条目进入受控状态，任何修改都需要走变更流程。
变更控制：当上游输入文件改版、测试方法调整或发现需求遗漏时，提出变更申请。变更申请应说明变更原因、影响范围、涉及的需求标识和追踪关系。变更评审通过后，基线版本递增，例如从 BL-TR-2024-03 升至 BL-TR-2024-04，并保留历史版本以便回溯。
追溯维护：基线变更后，必须同步更新追踪矩阵。追踪矩阵至少应包含：需求标识、需求描述、来源引用、验证方法、测试用例编号、验证状态。当某条需求变更时，通过矩阵可以快速找到受影响的测试用例和验证记录。
需求体系的实际运转：一个简化示例
假设某型号需要验证"星务计算机在收到遥控指令后，应在500ms内完成指令解析并回传执行状态"。这条需求的处理过程如下：
- 来源标注：任务书 §5.3.2 和 ICD-CDH-007 §3.1。
- 层级归属：系统级需求，标识
TR-SYS-CDH-0007。 - 分解为用例级需求：
TR-CASE-CDH-0007-01（正常指令解析时间测试）、TR-CASE-CDH-0007-02（异常指令拒绝与状态回传测试）。 - 验证方法：地面测试设备发送遥控指令，星务计算机通过遥测回传时间戳，测试系统计算时间差。
- 判据：时间差≤500ms为通过，否则记录超时并触发问题报告。
- 基线管理：该需求纳入
BL-TR-2024-03，若后续ICD改版导致时间要求变为300ms，则发起变更，基线升至BL-TR-2024-04，并更新追踪矩阵中关联的测试用例。
这个示例说明，需求体系不是静态文档，而是一条从来源到验证的链路。标识保证链路可引用，层级保证链路可分解，基线保证链路可控制。
从图中可以看出，需求体系是一条从来源到基线的完整链路：左侧输入决定需求内容，中间层级决定需求粒度，右侧标识决定需求引用方式，底部基线决定需求受控状态。四个环节缺一不可，任何一环断裂都会导致测试覆盖分析失去依据。
在实际型号中，建议将需求标识、层级、来源引用和基线版本作为需求管理系统的必填字段，并在测试大纲评审时逐条核对。只有当每条测试需求都能回答"从哪来、在哪层、叫什么、属于哪个基线"时，后续的覆盖分析和追踪验证才有可靠基础。