2. 星载数据处理系统需求分析与测试可追溯性

星载数据处理系统的集成测试，如果只从“把设备接起来、跑一遍数据”开始，往往会在测试后期暴露出大量返工：某个功能测了但没测全，某个性能指标没有对应的测试项，某个接口的异常分支从未被触发，某个环境约束在测试台上根本没有复现。这些问题的根源通常不在测试执行阶段，而在需求分析阶段——需求没有被拆解到可验证的粒度，也没有建立需求到测试项的显式映射。本节围绕功能需求、性能需求、接口需求、环境约束四类需求，说明如何把它们转化为可追溯的测试项，并给出需求覆盖矩阵的实战做法。

一、四类需求的拆解方式

功能需求描述系统“做什么”，例如“完成遥感载荷数据的格式化打包”“支持在轨重构后重新加载处理参数”。功能需求拆解时，要落到“输入—处理—输出—异常”四个要素上。以“格式化打包”为例，输入是载荷原始数据帧，处理是按 CCSDS 分包规则添加主辅包头，输出是标准数据包流，异常包括帧同步丢失、包计数溢出、长度字段越界。只有把异常分支也写清楚，测试项才不会漏掉负向用例。

性能需求描述“做到什么程度”，典型指标包括吞吐率、处理时延、存储容量、功耗、资源占用率。性能需求必须带明确的度量条件和判据，例如“在 100 Mbps 输入码率下，端到端处理时延不大于 200 ms，CPU 占用率不超过 70%”。缺少度量条件的性能需求无法设计测试，也无法判定通过与否。

接口需求描述系统边界上的交互，包括电气接口、协议接口、数据接口、时序接口。接口需求要区分正常交互与异常交互：正常交互如“通过 SpaceWire 以 200 Mbps 接收载荷数据”，异常交互如“链路中断后 500 ms 内上报链路异常状态”。接口的异常行为往往是集成测试中最容易遗漏、也最容易在轨出问题的地方。

环境约束描述系统工作的外部条件与限制，包括温度、辐照、真空、供电波动、振动等。环境约束在集成测试阶段通常不能全真复现，但可以通过等效手段验证：用温箱模拟温度边界，用电源拉偏模拟供电波动，用故障注入模拟单粒子翻转导致的内存位翻转。环境约束必须转化为可执行的测试条件，否则它只是设计说明，不是测试依据。

二、需求到测试项的映射方法

映射的核心原则是“一条需求至少对应一个测试项，一个测试项至少追溯回一条需求”。实际操作中，先把每条需求拆成若干“可验证断言”，每个断言对应一个测试项。可验证断言应当包含：前置条件、激励、预期响应、判据。例如需求“支持在轨重构后重新加载处理参数”，可拆为三个断言：重构指令接收后返回确认；参数区写入后校验和正确；重新加载后处理结果与预期一致。三个断言对应三个测试项，分别验证指令通路、存储正确性、功能恢复。

映射时还要处理两类特殊情况。一是一条需求对应多个测试项，例如性能需求通常需要在不同码率、不同数据模式下分别测试。二是一个测试项覆盖多条需求，例如一次端到端数据流测试可以同时验证接口需求、功能需求和部分性能需求。覆盖矩阵中要如实记录这种多对多关系，不能为了矩阵好看而强行一对一。

三、需求覆盖矩阵实战

需求覆盖矩阵是一张二维表，行是需求，列是测试项，交叉格标记覆盖关系。实战中建议在矩阵中同时记录覆盖类型和验证状态，而不仅仅是打勾。下面给出一个可参考的矩阵片段，数据为教学示例，非实测结果。

矩阵填完后要做三项检查。第一，需求覆盖率：统计有多少条需求至少被一个测试项覆盖，未覆盖项必须给出理由或补充测试项。第二，测试项反向覆盖率：统计有多少个测试项能追溯到需求，无法追溯的测试项可能是冗余测试，也可能是需求遗漏，需要回查。第三，异常与边界覆盖：检查每条需求是否至少有一个异常或边界测试项，尤其是接口需求和性能需求。

下面这张图给出需求分析到覆盖矩阵的追溯链路，以及四类需求各自的验证落点。

四、从矩阵到测试执行的闭环

覆盖矩阵不是一次性文档，它要随测试执行持续更新。每执行一个测试项，把验证状态从“待测”改为“通过”“失败”或“阻塞”，失败项要关联缺陷编号。当所有需求状态为“通过”时，才能认为需求覆盖闭环完成。如果某条需求因环境条件无法在集成测试阶段验证，应在矩阵中标记“未覆盖”并注明替代验证手段，例如通过单机环境试验数据或仿真结果佐证，而不是简单留空。

实际项目中，建议把覆盖矩阵与测试用例管理工具联动，需求编号和测试项编号作为唯一键。这样在需求变更时，可以快速定位受影响的测试项；在测试失败时，可以快速判断影响哪些需求。对于星载数据处理系统这类需求密集、接口复杂的系统，可追溯性不是文档负担，而是控制集成风险的基本手段。