3. 验证计划：如何制定验证计划、验证范围定义、功能点分解、验证矩阵

验证计划，说白了就是整个验证工作的「作战地图」。没有它，你就像在迷宫里乱撞。我见过太多项目，验证做到一半才发现漏了关键功能，最后不得不紧急补测，那叫一个狼狈。

今天我们就聊聊，怎么把这份地图画好。

3.1 验证计划的核心要素

一份好的验证计划，至少得回答三个问题：

• 测什么？——验证范围
• 怎么测？——功能点分解
• 怎么才算测完？——验证矩阵

我个人习惯，在项目启动的第一周就把这三件事定下来。哪怕后面会调整，也得先有个框架。

3.2 验证范围定义

验证范围，就是明确「哪些归我管，哪些不归我管」。很多团队在这里栽跟头。

举个例子，我曾经负责一个AI加速器项目。设计文档里写了个「数据预取模块」，但没写清楚预取策略的边界条件。结果验证团队默认只测了正常情况，漏掉了地址越界和缓存冲突的场景。嗯，后来花了整整两周补测试用例。

定义验证范围时，我建议从这几个维度入手：

1. 功能边界：模块的输入输出是什么？异常情况怎么处理？
2. 性能边界：最大吞吐量、最小延迟、最差情况下的表现。
3. 接口协议：握手信号、时序约束、错误响应。
4. 配置空间：寄存器默认值、可配置范围、保留位处理。
5. 安全与容错：非法操作、数据完整性、复位行为。

3.3 功能点分解

功能点分解，就是把大功能拆成小颗粒度的验证项。你想想看，一个复杂的DMA控制器，如果直接写「验证DMA功能」，那根本没法下手。

我习惯用「功能树」的方式来做分解。根节点是模块名，子节点是主要功能，叶子节点是具体的验证场景。

比如一个简单的FIFO模块：

FIFO验证功能树
├── 基本读写
│   ├── 写一个数据，读一个数据
│   ├── 连续写满，再连续读空
│   └── 写指针回绕
├── 满空标志
│   ├── 满标志置位条件
│   ├── 空标志置位条件
│   └── 几乎满/几乎空阈值
├── 异常场景
│   ├── 写满后继续写（溢出）
│   ├── 读空后继续读（下溢）
│   └── 同时读写竞争
└── 复位行为
    ├── 复位后指针归零
    └── 复位后标志状态

分解时要注意颗粒度。太粗了漏场景，太细了文档比代码还长。我个人觉得，每个叶子节点对应一个独立的测试用例，这样最合适。

3.4 验证矩阵

验证矩阵，就是把功能点和验证方法对应起来。说白了，就是一张「谁负责测什么、用什么测、测到什么程度」的对照表。

一个标准的验证矩阵包含这几列：

功能点ID	功能描述	验证方法	覆盖率目标	责任人	状态
FIFO-001	基本读写操作	定向测试	100%	张三	已完成
FIFO-002	满标志置位	随机测试 + 断言	100%	李四	进行中
FIFO-003	写溢出场景	错误注入测试	90%	王五	待评审
FIFO-004	复位行为	形式化验证	100%	赵六	未开始

验证方法我一般分三类：

• 定向测试：针对特定场景，手动构造激励。适合边界条件和异常情况。
• 随机测试：用约束随机生成激励，配合覆盖率驱动。适合常规功能和大规模回归。
• 形式化验证：用数学方法证明属性成立。适合关键控制逻辑和安全性要求高的场景。

3.5 知识体系总览

下面这张图，把验证计划的整体流程串起来了。你可以把它当作一个检查清单，每做完一步就打个勾。

这张图里有个关键点：反馈迭代。覆盖率没达标？那就回到功能点分解，看看是不是漏了场景。验证矩阵状态卡住了？那就调整方法或资源。验证计划不是死板的，它应该随着项目推进不断优化。

可可精品资料库