2. 需求捕获与测试计划
高速数字测试项目失败，往往不是失败在仪器带宽不够，而是失败在需求阶段：客户给了一份“支持 PCIe Gen5、眼图要好看”的规格书，测试团队按自己的理解搭了台子，测完交付时客户说“我要的是系统级链路眼图，不是芯片引脚眼图”。需求捕获的核心任务，就是把客户模糊的自然语言规格，翻译成一组可测量、可判定、可追溯的指标，并进一步组织成测试矩阵。
一、从客户规格中提取三类信息
拿到客户规格书后，先做一次结构化拆解，把信息分成三类：
- 接口与协议层：链路类型（PCIe / USB / Ethernet / DDR / MIPI）、速率等级（Gen5 32 GT/s、Gen6 64 GT/s）、通道数（x4 / x8 / x16）、参考时钟架构（Common Refclk / SRIS / SRNS）。这一层决定测试的“坐标系”——测什么信号、在哪个速率下测。
- 指标与限值：信号完整性（插入损耗、回波损耗、串扰）、抖动（Tj、Rj、Dj、SSC 调制）、眼图（眼高、眼宽、眼高裕量、眼宽裕量）、误码率（BER 目标，如 1E-12）。这一层决定“判据”。
- 测试条件与边界：温度、电压、通道损耗预算、夹具去嵌要求、测试点定义（TP1/TP2/TP3）、样本数量。这一层决定“在什么条件下判”。
以 PCIe Gen5 为例，客户规格常写“满足 PCIe Base Spec 5.0 电气规范”。这句话本身不可测，必须展开为：在 32 GT/s、BER ≤ 1E-12、参考时钟 SSC 开启（-5000 ppm 三角调制，30–33 kHz）条件下，发送端 TP1 处眼高 ≥ 30 mV、眼宽 ≥ 0.3 UI（示例值，实际以规范版本为准），接收端 TP2 处需满足通道损耗与串扰预算。只有展开到这一层，测试才有意义。
二、把指标翻译成可测参数
需求捕获的第二个动作，是建立“客户语言 → 仪器参数”的映射。客户说“抖动要小”，测试计划里必须写成：Tj@1E-12 ≤ 0.3 UI、Rj ≤ 1.5 ps RMS、Dj ≤ 0.1 UI，并明确测量方法（双狄拉克模型拟合、浴盆曲线外推）与去嵌方式。客户说“眼图要开”，必须写成眼高/眼宽在指定 BER 下的外推值，而不是示波器屏幕上肉眼看到的张开程度。
这里有一个常见陷阱：指标定义与测量点必须绑定。同一个“眼高”，在 TP1（芯片引脚）、TP2（接收端芯片引脚）、TP3（测试夹具输出）测出来差异巨大。测试计划中必须写明每个指标对应的测试点、去嵌参考面和夹具补偿方式，否则后续测试结果无法与客户规格对齐。
三、测试矩阵的组织方式
测试矩阵不是简单的指标清单，而是把测试项、测试点、条件、限值、仪器配置、判定规则组织成一张可执行的表。它的行是测试项，列是执行要素。下面给出一个 PCIe Gen5 发送端测试矩阵的示例结构（参数为教学示例，非实测结果）：
| 测试项 | 测试点 | 条件 | 限值（示例） | 仪器/方法 |
|---|---|---|---|---|
| 发送端眼图 | TP1 | 32 GT/s，SSC 开 | 眼高 ≥ 30 mV，眼宽 ≥ 0.3 UI | 示波器 + 时钟恢复 + 眼图模板 |
| 总抖动 Tj | TP1 | BER 1E-12 | ≤ 0.3 UI | 浴盆曲线外推 / 双狄拉克拟合 |
| 随机抖动 Rj | TP1 | 同上 | ≤ 1.5 ps RMS | 抖动分离软件 |
| 确定性抖动 Dj | TP1 | 同上 | ≤ 0.1 UI | 抖动分离软件 |
| 差分回波损耗 | TP1 | 50 MHz–16 GHz | ≤ -10 dB（示例） | VNA + 差分探头/夹具 |
| 通道插入损耗 | TP2–TP1 | 16 GHz | ≤ -28 dB（示例） | VNA 或 TDR |
矩阵的价值在于：它把“测什么、在哪测、什么条件、判多少、怎么测”一次性锁定。后续测试执行、数据记录、报告生成都直接引用矩阵行号，实现需求到结果的追溯。
四、测试计划中的关键约定
在矩阵之外，测试计划还需要明确几项容易引发争议的约定：
- 参考时钟与 SSC 状态：SSC 开启会显著改变抖动频谱，测试时必须与客户确认 SSC 配置，并在报告中记录调制频率与深度。
- 去嵌与夹具补偿：明确去嵌到哪个参考面，夹具的 S 参数是否已获取，补偿算法（如 AFR、去嵌滤波器）是否经过验证。
- 样本量与统计置信度：抖动和 BER 是统计量，样本量不足会导致外推不可靠。计划中应写明采集的 UI 数量（如 1E6 UI）与重复次数。
- 判定规则：明确是“单次通过”还是“多次取最差”，以及边界情况（如限值 ±5% 内）如何处理。
下面这张图展示了从客户规格到测试矩阵的转化关系：左侧是客户输入，中间是需求展开与指标翻译，右侧是测试矩阵的输出结构，底部标注了贯穿全程的追溯链。
五、需求捕获的常见遗漏与检查点
实际项目中，需求捕获阶段最容易遗漏的不是技术指标，而是边界条件与假设。以下检查点建议在测试计划评审时逐项确认：
- 客户规格中的“典型值”与“最大值”是否区分？测试判定用哪个？
- 参考时钟是 Common Refclk 还是 SRIS？SSC 是否开启？调制参数是否明确？
- 测试夹具的 S 参数是否已提供？去嵌参考面是否与客户一致？
- BER 目标与样本量的关系是否明确？外推方法是否被客户认可？
- 是否有客户指定的测试仪器品牌或型号？是否影响方法选择？
- 测试环境（温度、供电、屏蔽）是否有特殊要求？
把这些检查点固化到测试计划模板中，可以显著减少后期返工。需求捕获与测试计划的质量，直接决定了后续测试执行、数据分析和报告交付的效率。一份好的测试矩阵，本身就是项目交付的“合同附件”——它让客户和测试团队对“测什么、怎么判”达成一致，避免在交付阶段才暴露理解偏差。