3. 测试需求分析与验证矩阵建立

整星功能测试不是“把能测的都测一遍”，而是围绕任务书和设计文件所定义的功能需求，逐条回答三个问题：这条需求要不要测、用什么测试项测、测到什么程度才算通过。测试需求分析就是把任务书中的功能指标“翻译”成可执行的测试项，再用验证矩阵把需求与测试项一一锁定，最后用覆盖性分析确认没有漏项、没有重复、没有无法验证的悬空需求。

一、从任务书和设计文件提取功能需求

需求提取的输入通常包括：研制任务书、整星功能基线文件、分系统设计说明、接口控制文件（ICD）、遥测遥控参数表、工作模式与飞行程序文件。提取时不要直接抄写整段文字，而要拆成“单一、可判定”的需求条目。一条合格的功能需求应包含对象、动作、条件和判据四要素。例如任务书写“星上应能在入轨后按地面指令完成太阳翼展开并保持锁定状态”，可拆为：

• REQ-F-001：星上在收到太阳翼展开指令后，应执行展开动作；
• REQ-F-002：太阳翼展开到位后，应输出锁定到位遥测；
• REQ-F-003：锁定后太阳翼应保持在位，遥测状态持续有效。

拆分后每条需求都有明确的观测点（遥测参数、总线报文、供电电流等）和判据（到位信号由0变1、锁定电流回落至保持值等），后续才能映射到具体测试项。提取过程中要同步记录需求来源文件与条款号，便于追溯和变更管理。

二、建立需求-测试追踪矩阵

需求-测试追踪矩阵（Requirement Traceability Matrix, RTM）是本节的核心交付物。矩阵的行是需求条目，列是测试项，交叉格填写覆盖关系与验证方式。一个可用的矩阵至少包含以下字段：需求编号、需求描述、验证方式（测试/分析/演示/检查）、对应测试项编号、测试条件、判据、覆盖状态、备注。

矩阵的价值在于双向追踪：正向从需求找到测试项，确认每条需求都有测试手段；反向从测试项找到需求，确认每个测试项都有存在理由，避免“为测而测”。当设计变更导致需求条目修改时，矩阵能快速定位受影响的测试项和已执行的测试记录。

三、确定测试项与测试条件

由需求到测试项的映射不是一对一的。一条需求可能由一个测试项覆盖，也可能需要多个测试项组合覆盖；一个测试项也可能同时覆盖多条需求。确定测试项时要明确测试条件，包括：测试状态（整星加电、单机独立、模拟飞行模式）、输入激励（指令序列、模拟遥测源、供电电压）、环境条件（常温常压、真空罐、EMC暗室）、观测手段（遥测采集、总线监听、示波器、电流表）以及通过判据。

例如针对上述太阳翼展开需求，可设计测试项 TC-F-012“太阳翼展开与锁定功能测试”，测试条件为：整星处于发射前待发模式，太阳翼模拟负载接入，地面发出展开指令，采集展开到位遥测与锁定电流。判据为：指令发出后规定时间内到位遥测由0变1，锁定电流在展开峰值后回落至保持区间并稳定。若测试条件不具备（如无法在整星状态下展开），则需在矩阵中标注替代验证方式，如分系统级测试加分析。

四、覆盖性分析方法

覆盖性分析通常从三个维度展开：需求覆盖率、测试项冗余度、验证方式充分性。需求覆盖率统计已覆盖需求数占总需求数的比例，未覆盖项必须给出原因和处置措施。测试项冗余度检查是否存在多个测试项重复验证同一需求且无新增信息，避免测试资源浪费。验证方式充分性则判断所选验证方式是否足以证明需求满足，例如关键功能仅用“分析”而无“测试”支撑时，应评估风险并补充测试。

覆盖性分析的结果应反馈到矩阵中，形成闭环。对于无法在当前阶段验证的需求，要明确推迟到哪个阶段、由哪个测试项承接，不能留下无归属的悬空需求。

五、矩阵与覆盖性分析的联动

矩阵建立后，覆盖性分析不是一次性动作，而是随设计迭代持续进行的。建议在每次需求变更或测试项调整后，重新运行覆盖性检查：先看新增需求是否已分配测试项，再看被修改的测试项是否仍覆盖原需求，最后看是否有测试项因需求删除而失去存在意义。对于覆盖率为100%但验证方式仅为“分析”的关键需求，应标记为高风险项，优先安排测试验证。

六、示例：某太阳翼展开需求的完整追踪链

以REQ-F-001为例，其追踪链为：任务书第4.2.3条 → 需求条目REQ-F-001 → 测试项TC-F-012 → 测试条件（待发模式、模拟负载、展开指令）→ 判据（到位遥测0→1，锁定电流回落至保持区间）→ 覆盖状态“已覆盖”。若该测试项因整星状态限制无法执行，则需在矩阵中标注替代验证方式，如“分系统级测试+分析”，并说明分析所依据的模型或数据来源。这样，一条需求从提出到验证的完整路径就清晰可查，测试需求分析与验证矩阵建立的工作才算真正闭环。