2. 客户需求捕获与测试规格转化

高速接口项目失败，往往不是仪器带宽不够，而是需求在传递过程中被“翻译”错了。客户给的是接口文档和协议标准，测试团队要交付的是可执行的测试项，中间缺少一层结构化的转化。本节围绕这一层转化展开：如何从客户接口文档中捕获真实需求，如何把协议标准中的条款拆成可测条目，以及如何用 Tektronix 方案模板完成需求映射表，让每一条测试项都能追溯到来源、方法和判据。

一、需求捕获的三个来源与优先级

客户需求通常来自三个层面，捕获时必须区分优先级，否则容易在细节上过度投入而漏掉关键项。

• 客户接口文档：定义信号名称、速率、电平、连接器、引脚定义、上电时序等。这是最直接的需求来源，优先级最高，任何与协议标准冲突之处以客户文档为准，并需书面确认。
• 协议标准：如 PCIe、USB、DDR、以太网等规范，定义一致性测试项目、模板、眼图、抖动、均衡等要求。它决定“测什么”和“判据是什么”。
• 项目约束：测试时间、样机数量、夹具与探头资源、实验室环境。它决定测试项的取舍与执行顺序。

捕获阶段要产出的不是一份文档清单，而是一张“需求—来源—可测性”的初步对照。对每一条需求，先判断它是否可测：若客户只写“信号质量良好”，这不可测；需转化为“在 TP2 测试点，以 32 GT/s 速率、PRBS13Q 码型，眼高 ≥ 80 mV、眼宽 ≥ 0.3 UI”。这一步是后续所有工作的基础。

二、从协议条款到测试项的拆解方法

协议标准中的条款通常按“参数—条件—限值”组织，拆解时按四元组提取：测试对象、测试条件、测量参数、判据。以 PCIe 5.0 发送端为例，条款中“8 GT/s 下发送端眼图模板”可拆为：对象为发送端差分对，条件为 8 GT/s、参考时钟 SSC 开启、均衡预设 P4，参数为眼高/眼宽/抖动，判据为模板余量 ≥ 0。四元组齐全，才是一个可执行测试项。

拆解时常见三类问题需要处理：一是条款引用其他章节，需回溯到原始定义，避免断章取义；二是限值随速率或均衡档位变化，需建立参数表而非单一数值；三是测量点未明确，需结合客户文档确定 TP1、TP2 或 TP3 等测试点。测试点定义不清，后续所有测量都失去可比性。

三、用 Tektronix 方案模板完成需求映射表

映射表是本节的核心交付物。它的作用不是记录，而是暴露缺口：哪些需求没有对应测试项，哪些测试项没有明确判据，哪些判据缺少仪器或夹具支撑。建议字段如下，可直接作为模板使用。

填写时注意三点。第一，“来源”必须精确到章节或条款号，便于回溯和变更管理。第二，“判据”必须是可量化的数值或明确的通过/失败条件，出现“良好”“正常”等词即视为未完成转化。第三，“Tektronix 方案”列要落到具体仪器型号、软件选件和夹具，而不是笼统写“示波器”。状态列用于跟踪：已映射、待确认夹具、需澄清、资源不足等。

四、转化过程中的典型陷阱与处理

陷阱一：把标准条款直接当测试项。标准写“发送端应满足眼图模板”，这不是测试项，缺少速率、均衡档位、测试点和码型。处理方式是回到四元组逐项补齐，补齐不了的就标记为待澄清。

陷阱二：忽略测试点定义。同一信号在 TP1、TP2、TP3 测出的眼图差异很大。客户文档若只写“发送端”，需确认是芯片引脚还是连接器端。测试点不同，夹具和去嵌入要求也不同，Tektronix 方案中的夹具与电缆选型随之变化。

陷阱三：判据随条件变化未建表。PCIe 各速率、各均衡预设下的限值不同。若映射表只写一个数值，执行时必然出错。建议在映射表旁附一张参数表，按速率和预设列出对应限值，测试项引用参数表编号而非硬编码数值。

五、从映射表到执行清单

映射表确认后，按测试点、速率和均衡档位分组，生成执行清单。同一测试点、同一条件的项目合并到一次连接中完成，减少换线和重新校准。例如 TP2 在 32 GT/s、P4 条件下，眼图、抖动、模板余量可共用一次采集，由 TekScope 批量分析输出。执行清单中标注每项的预计耗时和依赖资源，便于排期。

最终交付给客户的不只是测试报告，还应包括映射表本身。它让客户看到每条需求如何被覆盖、哪些需求被澄清或调整、哪些判据来自标准而非项目自定义。这份映射表既是测试依据，也是需求变更时的追溯基线。当客户后续修改接口文档时，只需更新映射表中对应行，即可快速判断哪些测试项需要重测、哪些可以沿用，避免全量回归。