验证计划与场景分解：从计划到执行的桥梁

说实话，很多验证工程师拿到一份验证计划后，第一反应就是「好，开始写测试用例吧」。

我以前也这么干过。结果呢？写了上百个用例，覆盖率还是上不去。后来我才明白——验证计划到场景分解，中间缺了一座桥。

今天我们就聊聊这座桥怎么搭。

一、从验证计划中提取场景：别被文档骗了

验证计划通常写得又长又全。功能点列了几百条，优先级标得清清楚楚。但问题来了——这些功能点不是场景。

举个例子。计划里写「支持AXI突发传输」，这是个功能点。但真正的场景是什么？是「主机连续发起16笔写操作，从机响应延迟不定，中间还插了个读请求」。

我个人习惯的做法是三步走：

1. 找「动词」——计划里描述「支持」「实现」「处理」的地方，往往藏着场景入口
2. 找「边界」——「最大」「最小」「超时」「溢出」这些词，是场景的天然分界线
3. 找「异常」——「错误处理」「恢复机制」「保护行为」，这些是验证价值的核心

我在项目中遇到过一份计划，写了「支持多通道DMA传输」。看起来很简单对吧？但当我用这个方法一拆，发现至少需要覆盖：通道抢占、优先级反转、带宽竞争、死锁恢复……最后拆出了47个场景。

二、场景分解的粒度控制：拆太细 vs 拆太粗

这是最让人头疼的问题。拆太细，场景列表长得像超市购物小票；拆太粗，一个场景里藏着十几个bug，你都不知道测没测透。

我自己的判断标准是：一个场景，应该能用一个「场景描述句」说清楚。

比如：

• ❌ 太粗：「测试FIFO读写」——这到底测什么？满？空？半满？同时读写？
• ❌ 太细：「FIFO写指针从0增加到1时，读指针不动，空标志保持为1」——这已经是一个测试用例了，不是场景
• ✅ 合适：「FIFO在写满后，读操作能否正确释放空间并恢复写操作」——一个场景，一个目标

你想想看，如果场景拆得太细，你最后会陷入「为了写用例而写用例」的怪圈。我以前带过一个项目，新人把「寄存器复位值检查」拆成了200个场景——每个寄存器一个。结果呢？覆盖率报告出来，全是重复劳动。

三、场景优先级划分：别把时间浪费在低价值场景上

项目时间永远不够用。这是铁律。所以场景优先级划分，说白了就是决定哪些场景值得先做，哪些可以砍掉。

我常用的方法是「三维打分法」：

每个场景按这三个维度打分（1~5分），加权求和。得分高的先做，得分低的……嗯，说实话，有些场景最后可能根本来不及做。

四、知识体系总览：一张图说清楚

下面这张图是我自己总结的「验证场景分解流程」。每次带新人，我都会先让他们看这张图。

五、避坑指南：我踩过的几个坑

做场景分解这么多年，有些坑是反复出现的。分享几个给你：

• 坑一：场景和用例混为一谈。我曾经让团队写场景，结果交上来的是「写寄存器0x00，读寄存器0x04，比对结果」——这明明是用例。场景应该是「验证寄存器读写功能在跨时钟域场景下的正确性」。
• 坑二：过度依赖工具。有些工具可以自动从验证计划生成场景。但说实话，工具生成的场景往往缺乏「人情味」——它不知道哪些场景在实际项目中容易出问题。我建议工具生成 + 人工review，缺一不可。
• 坑三：忽视负向场景。很多团队只关注「功能正常」的场景，对「异常处理」「错误恢复」视而不见。结果呢？芯片在实验室跑得好好的，一上客户板子就挂。为什么？因为客户不会按你的测试用例来操作。

好了，关于验证计划与场景分解，今天就聊这么多。记住一句话：场景分解的质量，决定了验证效率的上限。花时间把场景拆好，后面写用例、跑仿真都会顺畅很多。

可可精品资料库