第二章 验证计划制定：从设计规格到验证计划、验证点的提取与分解、优先级划分

说实话，很多刚入行的朋友问我：“验证计划不就是列个清单吗？”
嗯，我当年也这么想。直到有一次，我负责一个AI加速器项目，规格文档300多页，我花了整整两周才把验证计划理清楚。那次之后我才明白——验证计划不是清单，是整个验证工程的蓝图。

这一章，我们就聊聊怎么从设计规格出发，一步步把验证计划做出来。我会结合我踩过的坑，给你一些实在的建议。

2.1 从设计规格到验证计划：三步走

我个人习惯把这个过程分成三步：读懂规格 → 提取验证点 → 组织成计划。听起来简单，但每一步都有门道。

2.1.1 读懂设计规格

设计规格（Design Specification）是验证的起点。但说实话，很多规格文档写得像天书。
我建议你拿到规格后，先做三件事：

• 画框图：把模块的输入输出、内部状态机画出来
• 找边界：哪些参数有最大值最小值？哪些场景是异常？
• 问问题：规格里没写清楚的地方，就是验证的盲区

2.1.2 提取验证点

验证点（Verification Point）说白了就是“你要测什么”。
我一般从三个维度提取：

1. 功能维度：每个功能特性是否正常工作？比如FIFO的读写、状态机的跳转
2. 时序维度：时序约束是否满足？比如建立时间、保持时间
3. 异常维度：输入非法数据时，模块会不会崩溃？

举个例子，我曾经验证一个DMA控制器。规格里写“支持最大64KB传输”。
我提取的验证点包括：

• 正常传输1字节、64字节、64KB
• 传输0字节（边界情况）
• 传输超过64KB（异常情况）
• 传输过程中打断再恢复

你看，一个简单的“64KB”就能拆出4个验证点。

2.1.3 组织成验证计划

验证计划不是验证点的简单罗列。我习惯用表格来组织：

2.2 验证点的提取与分解：从粗到细

提取验证点，我有个原则：先粗后细，层层分解。
你想想看，如果一开始就陷入细节，很容易漏掉大的功能场景。

2.2.1 功能分解法

我最常用的方法是功能分解法。把设计规格里的每个功能特性，拆成更小的子功能。
比如一个UART模块，可以这样分解：

• 发送功能
  • 发送单字节
  • 发送多字节（FIFO模式）
  • 发送中断
• 接收功能
  • 接收单字节
  • 接收多字节
  • 接收错误检测
• 配置功能
  • 波特率配置
  • 数据位/停止位配置
  • 校验位配置

这样一层层拆下去，每个叶子节点就是一个具体的验证点。

2.2.2 场景驱动法

有时候功能分解法不够用，尤其是验证复杂交互时。这时候我会用场景驱动法。
说白了，就是模拟真实的使用场景。

我记得有一次验证一个网络交换芯片。单纯测每个功能点都通过了，但联调时发现丢包。后来我改用场景驱动法，模拟了“高负载+突发流量+背压”的场景，一下子就复现了问题。

2.3 优先级划分：把好钢用在刀刃上

验证资源永远是有限的。你不可能把所有验证点都测到100%。
所以，优先级划分是验证计划里最关键的一步。

2.3.1 我的优先级划分标准

我一般把验证点分为三个优先级：

• P0（必须通过）：核心功能、安全相关、接口协议。这些不过，芯片没法用。
• P1（重要）：常见使用场景、性能指标。这些不过，芯片体验差。
• P2（可选）：边界情况、低概率场景。有时间就测，没时间可以放一放。

举个例子，一个USB控制器：

2.3.2 优先级不是一成不变的

这一点很重要。随着验证的推进，优先级可能会变化。
比如，你发现某个P2的验证点，其实和P0的验证点有依赖关系，那它的优先级就要提升。

我习惯在验证计划里加一列“状态”，用来跟踪每个验证点的进展和优先级变化。这样整个团队都能看到最新的情况。

2.4 本章知识体系图

下面我用一张SVG图，把这一章的核心逻辑串起来。你可以把它当作验证计划制定的“路线图”。

2.5 一些实在的建议

最后，分享几个我在项目中积累的经验：

• 验证计划要可执行：每个验证点都要有明确的通过标准。不要写“验证功能正常”这种模糊的描述。
• 留出缓冲时间：我一般会在计划里留20%的缓冲时间，用来处理意外发现的问题。
• 定期评审：每周和设计团队过一遍验证计划，确保没有遗漏。

好了，这一章就到这里。记住，好的验证计划是成功验证的一半。下一章我们聊聊怎么搭建验证环境，到时候我会分享一些实用的框架选择经验。