3. 产品化测试计划制定

产品化测试计划不是把研发阶段的测试用例重新跑一遍，而是围绕“可制造、可交付、可追溯”三个目标重新组织测试活动。对 Zynq 这类 PS+PL 异构器件而言，测试计划的核心矛盾在于：PL 逻辑没有固定指令集，测试向量必须由设计者自己构造；PS 侧又涉及 DDR、QSPI、SD、以太网、USB 等大量外设，接口组合爆炸。因此计划制定必须从需求分析出发，先确定“测什么”，再决定“怎么测、测到什么程度、用什么文档固化”。

一、测试需求分析：从产品规格反推测试项

测试需求分析的第一步是把产品需求文档（PRD）和硬件规格书中的功能、性能、接口、环境、寿命条目逐条映射为可验证的测试需求。建议采用“需求—风险—测试项”三列映射表，每条需求至少对应一个测试项，高风险项对应多个。例如某工业网关产品要求“-40℃~+85℃ 工业级工作”，则测试需求应拆为：低温启动、高温持续运行、温度循环、结温余量四项，而不是笼统写“高低温测试”。

对 Zynq 平台，需求分析要特别关注三类条目：一是 PS 侧启动链路（BootROM→FSBL→PL 配置→U-Boot→Linux），任何一环失败都导致整机不启动；二是 PL 侧自定义 IP 的功能正确性与时序收敛；三是 PS-PL 之间的 AXI 互联带宽与中断响应。建议用风险优先数（RPN = 严重度 × 发生度 × 检出度）排序，RPN 高的项优先分配测试资源和覆盖率预算。

二、DFT 策略：把可测性设计进硬件与逻辑

DFT（Design for Test）策略决定测试能否高效执行。Zynq 产品化中常用的 DFT 手段包括：

• JTAG 边界扫描：用于 PCB 互连测试，检查 BGA 焊球、DDR 走线、连接器引脚的开短路。需在原理图阶段就规划 TAP 链，把 Zynq、DDR、PHY、CPLD 串入同一链，并预留 TCK/TMS/TDI/TDO 测试点。
• PL 内建自测试（BIST）：对 BRAM、DSP48、LUT 等资源插入扫描链或 March 算法，通过 JTAG 或 AXI-Lite 触发，快速定位逻辑阵列故障。
• PS 侧测试访问：利用 Zynq 的 DAP（Debug Access Port）和 CoreSight 组件，在不停机情况下读取 CPU 寄存器、性能计数器和总线事务。
• 测试点与环回：对以太网、USB、SATA 等高速接口，在 PCB 上预留 SMA 或测试焊盘，并设计 PHY 环回、MAC 环回路径，便于分层定位。

DFT 策略必须在 PCB 投板前冻结，否则后期补测试点会引入阻抗不连续和信号完整性问题。一个实用的做法是：在原理图评审时同步输出《DFT 检查表》，逐项确认 TAP 链、测试点、环回路径、电源监测点是否齐备。

三、测试覆盖率目标：分层设定，可量化

覆盖率目标不能只写“尽量高”，而要分层量化。对 Zynq 产品，建议按以下层次设定：

覆盖率目标要与测试成本平衡。例如对出货量大的型号，可把 PL 故障覆盖率从 95% 提到 99%，代价是测试时间增加；对小批量工业定制板，则优先保证启动链路和关键接口覆盖，结构覆盖可适当放宽。目标一旦确定，应写入测试计划并作为退出准则。

四、测试用例设计与文档规范

测试用例设计推荐采用“等价类 + 边界值 + 场景法”组合。以 DDR 测试为例：等价类划分为正常读写、不同 burst 长度、不同数据模式；边界值取最小/最大地址、最小/最大频率；场景法则模拟 Linux 启动时 DDR 初始化、压力测试、掉电恢复。每个用例必须包含唯一 ID、对应需求编号、前置条件、测试步骤、预期结果、实际结果、判定和备注。

文档规范方面，建议统一使用以下字段结构，便于评审和追溯：

用例ID: TC-DDR-012
需求追溯: REQ-MEM-003
测试目的: 验证 DDR3 在 533MHz 下连续读写 24h 无错误
前置条件: 板卡上电，FSBL 加载完成，DDR 初始化通过
测试步骤:
  1. 通过 U-Boot 加载 memtester 镜像
  2. 执行 memtester 512M 10
  3. 记录每轮结果与温度
预期结果: 10 轮全部 PASS，无 ECC 纠正计数增长
实际结果: (执行后填写)
判定: PASS / FAIL
备注: 环境温度 25℃，结温 62℃

文档还应包含测试环境拓扑、仪器清单、校准有效期、版本控制规则。所有用例在评审通过后冻结基线，变更需走变更记录，确保测试结果可复现、可审计。

把上述四块内容串起来，测试计划就形成闭环：需求分析确定测试项，DFT 策略提供可测性基础，覆盖率目标给出量化退出准则，用例与文档规范保证执行可追溯。计划评审通过后，任何变更都应记录在案，避免“测了但说不清测了什么”。