第二章：验证计划制定——如何编写验证计划、验证目标分解、功能点提取方法

说实话，很多刚入行的工程师觉得验证计划就是走个过场。写个文档，领导签字，然后扔到角落里吃灰。我以前也这么想，直到有一次项目延期三个月，原因就是验证计划没做好，漏掉了一个关键功能点。

那次教训让我明白：验证计划不是写给领导看的，是写给自己和团队用的。它是整个验证工作的作战地图，没有它，你就是在黑暗中乱撞。

2.1 验证计划的核心要素

一份好的验证计划，应该包含哪些东西？我个人习惯把它分成五个部分：

要素	说明	我的经验
验证范围	明确测什么、不测什么	边界一定要写清楚，否则后期扯皮
验证目标	功能覆盖率目标、代码覆盖率目标	我一般定90%以上，但有些模块必须100%
验证策略	定向测试还是随机测试？用UVM还是纯SV？	根据项目周期灵活选择
资源与时间	多少人、多少时间、多少机器	记得留20%的buffer，你永远不知道会出什么幺蛾子
交付物清单	测试用例、覆盖率报告、bug报告	每个交付物都要有明确的格式要求

2.2 验证目标分解——从需求到验证

验证目标怎么分解？说白了就是一句话：把芯片规格书里的每一句话，变成可验证的测试点。

举个例子，规格书上写了一句：「支持AXI4总线协议，支持突发传输长度1-256」。这句话看起来简单，但你要怎么验证？

我会这样分解：

1. 功能层面：突发长度1、2、4、8、16、32、64、128、256，每个长度都要测
2. 边界层面：突发长度=1（最小）、突发长度=256（最大）、突发长度=0（非法）
3. 交互层面：连续突发、中断后恢复突发、不同master同时发起突发
4. 时序层面：背压情况下的突发传输、等待状态下的突发传输

2.3 功能点提取方法——实战技巧

功能点提取，这是验证计划里最考验功力的部分。我见过太多人，要么提取得太粗（一个模块就写3个功能点），要么提取得太细（一个寄存器写了20个功能点）。

怎么把握这个度？我总结了一个「三问法」：

• 这个功能会不会出错？——如果不会，那就不用测
• 出错了影响大不大？——影响大的必须测
• 测起来成本高不高？——成本太高就考虑抽测

举个例子，我曾经负责一个DMA控制器的验证。规格书里有个功能：「支持链式传输」。我一开始只写了一个功能点：「验证链式传输功能正常」。

结果呢？第一次仿真就发现链式传输在跨页边界时数据会错乱。为什么？因为我没把「链式传输+跨页边界」这个组合场景提取出来。

2.4 功能点提取的层次结构

功能点不是平铺直叙的，它应该有层次。我习惯这样组织：

模块级功能点
├── 基本功能
│   ├── 配置寄存器读写
│   ├── 数据通路正常
│   └── 控制信号正确
├── 边界条件
│   ├── 最大/最小数据量
│   ├── 地址对齐/非对齐
│   └── 时钟域交叉
├── 异常处理
│   ├── 超时处理
│   ├── 错误响应
│   └── 非法操作
└── 性能指标
    ├── 吞吐率
    ├── 延迟
    └── 资源占用

你看，这样分层之后，每个功能点都有明确的归属。验证的时候也不会漏掉。

2.5 验证计划的评审与迭代

验证计划写完了，别急着开始写代码。先做一件事：评审。

我建议至少做两轮评审：

• 第一轮：设计团队评审——确认功能点是否覆盖了所有设计需求
• 第二轮：验证团队评审——确认验证方法是否可行、资源是否合理

评审的时候，我通常会问三个问题：

1. 「这个功能点，如果漏测了，后果是什么？」
2. 「这个测试用例，能不能真正覆盖到它想测的东西？」
3. 「如果时间不够，哪些功能点可以砍掉？」

嗯，第三个问题很现实。项目总是会压缩时间的，提前想好哪些可以砍，比到时候手忙脚乱要好得多。

2.6 本章知识体系

下面这张图，是我对验证计划制定流程的总结。你可以把它当作一个checklist：

这张图里，我特别想强调的是反馈迭代这个环节。很多团队做完计划就扔一边了，等到验证快结束了才发现计划有问题。我的习惯是：每完成一个功能点的验证，就回头看看计划，问问自己「这个功能点测到位了吗？还有没有遗漏？」

可可精品资料库