4. 验证需求分析与可验证性设计

星载异构计算平台的验证工作，最容易出问题的地方不是“测不出来”，而是“不知道该测什么、测到什么程度算通过”。任务书里写的是“图像预处理时延不大于 200 ms”“平台在单粒子翻转下可恢复”，这些是任务级需求，无法直接变成一条测试用例。验证需求分析要做的，就是把任务级需求逐层分解为可观测、可激励、可判定的验证需求，并建立从任务需求到验证用例的双向追踪关系。

从任务需求到验证需求的三层分解

建议按“任务需求 → 功能/性能需求 → 验证需求”三层展开。以“图像预处理时延不大于 200 ms”为例：第一层是任务需求，描述用户可见的能力；第二层拆为功能需求（完成辐射校正、几何校正、滤波三级流水）和性能需求（端到端时延、吞吐率、资源占用）；第三层才落到验证需求，必须明确激励条件、观测点、判定准则三要素。例如：“在 CPU+FPGA 异构模式下，向图像输入接口注入 4096×4096×16 bit 的测试图，在预处理输出接口打时间戳，端到端时延 ≤ 200 ms，连续 100 帧无丢帧”。这条验证需求已经可以直接映射为一条测试用例。

分解过程中要特别警惕两类不可验证需求：一类是缺少量化边界的，如“系统应具有高可靠性”；另一类是缺少观测手段的，如“内部调度应公平”。前者需要与任务方确认量化口径（如“连续工作 72 h 无不可恢复故障”），后者需要先设计可观测点（如导出调度器每周期分配的队列深度日志），否则验证需求无法闭环。

可测性指标：让“测得到”成为设计约束

可测性不是验证阶段才考虑的事，而应在架构设计阶段就作为指标约束。对星载异构平台，常用的可测性指标包括：

• 观测覆盖率：关键内部信号（如 FPGA 流水线各级 valid、CPU 核间中断计数、DDR 带宽占用）可被探针或计数器捕获的比例，建议关键路径 ≥ 90%。
• 激励可控性：能否在不改动硬件的前提下注入故障、边界数据和异常时序，例如通过 JTAG、寄存器回写或故障注入模块。
• 状态可复位性：任意测试用例结束后，平台能否在限定时间内回到确定初态，避免用例间相互污染。
• 时间可分辨性：时间戳分辨率应优于被测时延指标的 1/10，例如判定 200 ms 时延，时间戳分辨率应 ≤ 20 ms，实际工程中通常取 μs 级。

这些指标应写入验证需求，而不是停留在“设计时注意”。例如可写成：“平台应提供不少于 32 个可配置性能计数器，覆盖 CPU、FPGA、DDR、总线四类对象，计数器可通过遥测接口读取，读取不影响被测路径时延超过 1%”。

验证用例设计原则

验证用例不是测试步骤的堆砌，而应满足四条原则：单一判定（一条用例对应一个明确的通过/失败准则）、可重复（相同激励在相同配置下结果一致）、可追溯（能反查到它覆盖的验证需求编号）、边界优先（优先覆盖参数边界、异常注入和并发冲突，而非只测正常路径）。

以异构任务调度为例，一条合格的用例应包含：用例编号、覆盖需求、前置配置（如 CPU 主频、FPGA 位流版本、任务优先级表）、激励序列（注入 3 个高优先级任务与 1 个低优先级长任务）、观测点（调度日志、各任务起止时间戳）、判定准则（高优先级任务响应延迟 ≤ 5 ms，且低优先级任务不被饿死超过 500 ms）。

需求覆盖与追踪方法

追踪的核心是建立双向映射：正向从任务需求查到验证用例，反向从用例执行结果回填需求覆盖状态。工程上通常用需求追踪矩阵（RTM）承载，字段至少包括：任务需求编号、验证需求编号、用例编号、执行状态、通过/失败、缺陷编号、覆盖类型（正常/边界/异常）。

覆盖分析要区分三种口径：需求覆盖率（已映射用例的验证需求数 / 验证需求总数）、用例执行率（已执行用例数 / 计划用例数）、通过率（通过用例数 / 已执行用例数）。三者不能混为一谈——覆盖率 100% 但执行率 60%，说明验证尚未完成；执行率 100% 但通过率 70%，说明设计存在缺陷。建议在每轮验证结束后同时输出这三个数字，并对未覆盖需求逐条给出原因（如“缺少故障注入手段，需补充可测性设计”）。

最后要强调：验证需求分析不是一次性文档工作，而是贯穿设计、集成、测试的持续活动。当发现某条验证需求无法设计出可执行用例时，正确的做法往往不是降低判定标准，而是回到架构补充可测性设计——增加观测点、开放激励接口、预留故障注入通道。可验证性本身就是星载异构平台的一项设计质量属性。