验证计划制定：从零到一搭建你的验证蓝图

说实话，我刚入行那会儿，觉得验证计划就是个形式。领导催着交，我就随便写写。结果呢？项目做到一半，发现遗漏了关键场景，回头补用例，整个进度全乱了。那次教训太深刻了。

后来我慢慢明白，验证计划不是写给领导看的文档，而是你整个验证工作的作战地图。今天我就跟你聊聊，一份靠谱的验证计划到底该包含什么，怎么把它写出来。

验证计划到底包含哪些内容？

我习惯把验证计划分成三大块：测什么、怎么测、怎么算过。你想想看，这三个问题搞清楚了，计划就立住了。

1. 功能分解与测试点

这是最核心的部分。说白了，就是把芯片规格书里的每一条功能，拆成可验证的测试点。

• 功能列表：从设计规格中提取所有功能特性
• 测试点矩阵：每个功能对应哪些测试场景
• 边界条件：正常情况、异常情况、极限情况

2. 验证策略与方法

这里要回答的是：用什么手段来验证？

• 仿真验证：定向测试 vs 随机测试的比例
• 形式化验证：哪些关键属性需要形式化证明
• 覆盖率驱动：功能覆盖率、代码覆盖率的收集方案

3. 验证环境架构

环境怎么搭？组件怎么划分？

• 验证组件列表：driver、monitor、scoreboard、coverage
• 接口协议：使用哪些VIP，是否需要自研
• 数据流：激励怎么产生，结果怎么比对

4. 验证进度与里程碑

阶段	交付物	时间节点
计划阶段	验证计划文档	RTL冻结前2周
环境搭建	验证环境跑通	RTL第一版交付后1周
冒烟测试	基本功能通过	环境搭建后1周
全面验证	所有测试点覆盖	项目冻结前2周
回归与签收	覆盖率达标	项目冻结前

如何制定一份靠谱的验证计划？

嗯，这里要注意，制定计划不是一蹴而就的。我一般分四步走：

第一步：吃透规格

把设计规格书从头到尾读三遍。第一遍通读，第二遍标注功能点，第三遍跟设计工程师逐条确认。我曾经遇到过规格书写得模棱两可的情况，比如「支持多种模式切换」，但没写清楚切换时的时序要求。这种坑，一定要在计划阶段就填上。

第二步：分解测试点

每个功能点拆成3-5个测试场景。举个例子：

功能：FIFO读写操作
测试点1：正常写入，正常读出
测试点2：FIFO满时写入（溢出保护）
测试点3：FIFO空时读出（下溢保护）
测试点4：同时读写（半满状态）
测试点5：复位后FIFO状态检查

第三步：确定验证优先级

不是所有测试点都同等重要。我习惯用P0/P1/P2来分级：

• P0：核心功能，不通过芯片没法用（比如上电复位、时钟）
• P1：重要功能，影响主要应用场景
• P2：边缘场景，可以后期覆盖

第四步：编写验证计划文档

把以上内容整理成文档。我习惯用模板，这样不会遗漏关键项。

验证计划模板（我常用的版本）

下面这个模板，是我在三个项目里迭代出来的。你直接拿去用，根据项目调整就行。

# 验证计划模板

## 1. 概述
- 项目名称：
- 模块名称：
- 版本号：
- 作者/日期：

## 2. 设计规格摘要
- 主要功能列表
- 接口协议
- 关键性能指标

## 3. 验证范围
- 包含的功能（明确列出）
- 不包含的功能（明确排除）

## 4. 测试点矩阵
| 功能ID | 功能描述 | 测试点ID | 测试场景 | 优先级 | 验证方法 |
|--------|----------|----------|----------|--------|----------|
| F1     | 数据写入 | T1.1     | 正常写入 | P0     | 定向测试 |
| F1     | 数据写入 | T1.2     | 满时写入 | P1     | 随机测试 |

## 5. 验证环境
- 环境架构图（见附件）
- 组件列表
- VIP清单

## 6. 覆盖率计划
- 功能覆盖率：需要覆盖的cross和coverpoint
- 代码覆盖率：行覆盖、条件覆盖、翻转覆盖

## 7. 验证进度
- 各阶段时间节点
- 交付物清单

## 8. 风险与缓解措施
- 已知风险
- 备选方案

验证计划的核心逻辑

说了这么多，其实验证计划的核心逻辑可以用一张图来概括。我画了个SVG，你看看就明白了：

你看，说白了就是四个问题：测什么、怎么测、怎么算过、什么时候做完。把这四个问题回答清楚，你的验证计划就立住了。

最后说一句，验证计划不是写完了就扔一边的。我每个星期都会拿出来看一眼，对照进度，看看有没有遗漏。项目中期如果发现新需求，也要及时更新计划。记住，计划是活的，不是死的。

可可精品资料库