4. 验证计划制定与需求追踪
Snapdragon平台的验证计划不是把测试项罗列成一张清单，而是把产品规格书和客户需求翻译成可执行、可判定、可追溯的验证活动。它的核心产物有两个：一份验证计划（Verification Plan），明确“验什么、怎么验、验到什么程度”；一份需求追踪矩阵（Requirement Traceability Matrix, RTM），把每条需求与测试用例、执行结果、缺陷记录一一对应。没有RTM，验证覆盖率只能靠口头承诺；有了RTM，任何一条需求是否被验证、验证结果如何，都能在几分钟内定位。
需求分解：把规格书拆成可验证条目
规格书通常以功能描述、性能指标、接口定义、环境条件等形式给出，颗粒度并不统一。制定验证计划的第一步是需求分解，把每条需求拆成“可观测、可判定”的验证条目。例如规格书写“支持LPDDR5X，最高速率8533 Mbps”，这条需求至少可拆为：链路训练是否成功、读写带宽是否达到目标、误码率是否在允许范围、低功耗状态下能否正确进入/退出。每条条目都要有唯一编号，如REQ-MEM-001，并标注来源（规格书章节号或客户需求编号）、优先级（P0/P1/P2）、验证维度（功能/性能/功耗/可靠性）。
需求分解时最容易出问题的是“隐含需求”。客户说“游戏场景下不卡顿”，背后隐含的是CPU/GPU调度、温控降频、内存带宽、显示帧率稳定性等多条可验证条目。验证计划必须把这些隐含需求显式化，否则后期出现争议时无法界定责任。
验证维度与测试用例设计
Snapdragon平台验证通常覆盖四个维度：功能、性能、功耗、可靠性。功能验证关注协议一致性、寄存器行为、中断响应、启动流程等；性能验证关注CPU/GPU算力、内存带宽、存储IOPS、显示刷新率等；功耗验证关注待机电流、典型场景功耗、温升曲线、充电策略等；可靠性验证关注高低温循环、电压拉偏、长时间老化、异常掉电恢复等。
每个验证条目至少对应一个测试用例，复杂条目可对应多个用例。用例编号建议与需求编号建立映射关系，如TC-MEM-001-01对应REQ-MEM-001。用例内容应包含：前置条件（如设备已烧录指定版本固件、环境温度25℃）、测试步骤、预期结果、判定阈值、所需工具（如功耗分析仪、协议分析仪、温箱）。判定阈值必须量化，例如“读写带宽≥7.5 GB/s”“待机电流≤2 mA”“连续运行72小时无重启”。
示例：一条需求的追踪链路
需求REQ-PWR-003：典型视频播放场景整机功耗≤1.8 W。对应测试用例TC-PWR-003-01：在25℃环境下，播放1080p/30fps视频30分钟，用功耗分析仪采样整机电流与电压，计算平均功耗。判定阈值：平均功耗≤1.8 W，且无异常峰值超过2.5 W。执行结果记录为实测值，若超标则关联缺陷编号BUG-xxxx，并回溯到需求确认是否阈值合理或设计需要优化。
需求追踪矩阵的结构与维护
RTM是一张动态表，不是一次性文档。它的最小字段集包括：需求编号、需求描述、来源、优先级、验证维度、测试用例编号、用例状态（未执行/通过/失败/阻塞）、实测结果、缺陷编号、备注。矩阵的价值在于双向追踪：从需求能查到用例和结果，从失败用例能回溯到受影响的需求，从缺陷能判断影响范围。
维护RTM的关键是“状态同步”。用例执行后必须当天更新状态，失败用例必须关联缺陷编号，阻塞用例必须注明阻塞原因（如缺少样机、工具未到位）。每周验证例会应基于RTM检查覆盖率：P0需求是否100%有用例、用例执行率是否达标、失败项是否有明确处理计划。覆盖率不是简单的“用例数/需求数”，而是“已通过用例覆盖的P0需求数/总P0需求数”。
覆盖率分析与验证收敛
验证计划执行到中后期，重点从“有没有用例”转向“覆盖率够不够”。覆盖率至少看三个层面：需求覆盖率（每条需求是否至少有一个用例）、用例执行率（已执行用例/总用例）、通过率（通过用例/已执行用例）。对于P0需求，需求覆盖率必须达到100%，任何未覆盖的P0需求都要在验证计划评审中给出明确理由和替代验证方案。
当出现失败用例时，处理路径是：确认失败现象可复现→关联缺陷→评估影响范围（是否影响其他需求）→修复后回归→更新RTM状态。如果失败原因是需求阈值本身不合理（例如规格书标称值与实际设计能力不匹配），则需要走需求变更流程，同步更新规格书、验证计划和RTM，而不是直接修改用例判定阈值来“凑通过”。
常见误区：把RTM做成“只增不改”的静态表格。需求变更后没有同步更新用例和矩阵，导致验证结果与最新需求脱节。正确做法是：需求变更必须触发RTM更新，并在变更记录中注明影响到的用例编号和执行状态。
验证计划的评审与基线
验证计划初稿完成后，需要组织跨团队评审，参与方至少包括：系统设计、软件、硬件、测试、项目管理。评审重点不是文档格式，而是：需求分解是否完整、判定阈值是否可测量、测试环境是否具备、时间排期是否合理、风险项是否有应对措施。评审通过后，验证计划和RTM进入基线管理，后续变更走变更控制流程。
基线后的RTM应作为项目周报和阶段评审的输入。在流片前评审、样机回片评审、量产评审等关键节点，RTM的覆盖率、通过率、未关闭缺陷数是判断能否进入下一阶段的核心依据。只有P0需求全部通过、P1需求通过率达标、无阻塞项，才具备进入量产交付验证的条件。
总结来说，验证计划制定与需求追踪的本质是“把需求变成可执行的验证活动，再把验证结果映射回需求”。Snapdragon平台涉及功能、性能、功耗、可靠性多个维度，只有通过结构化的需求分解、量化的用例设计、动态维护的RTM，才能在复杂的芯片验证中做到不漏项、不重复、可追溯、可收敛。