一、验证方法论概述：为什么需要随机验证？
1.1 定向测试的局限性
先聊聊定向测试。说白了，就是你想好一个场景，写一段代码，跑一下，看结果对不对。
我刚入行那会儿，公司里全是定向测试。每个工程师手里攥着一份 Excel 表格，里面列了几百个测试用例。每个用例都写得清清楚楚：给什么输入，期望什么输出。
听起来很靠谱，对吧？
但问题来了——你永远不知道你漏掉了什么。
举个例子。你测了一个加法器，写了 10 个定向用例：1+1、2+3、0+0、最大数+1……你觉得覆盖全了。结果流片回来，发现 0x80000000 + 0x80000000 这个边界情况没测到。嗯，芯片挂了。
为什么会这样？
因为定向测试有一个根本缺陷：测试用例是由人的想象力决定的。而人的想象力，在复杂芯片面前，真的不够用。
定向测试的三大痛点：
- 覆盖率盲区：你只能测到你想到的，测不到你没想到的
- 维护成本高：每加一个功能，就要手动写几十上百个新用例
- 重复劳动：同样的场景，换个参数组合，又得重新写一个用例
我记得有一次，一个项目 deadline 前两周，我们发现了三个 bug。修完之后，又手动补了十几个定向用例。结果呢？又冒出来两个新 bug。那感觉，就像打地鼠——永远打不完。
1.2 随机验证的核心思想
随机验证的思路其实很简单：让机器帮你生成测试用例。
你想想看，一个 32 位的加法器，可能的输入组合有多少？2^64 种。你用手写，写到退休也写不完。但如果你写一个随机生成器，让它在约束范围内自动产生输入，那情况就完全不一样了。
核心思想就三个字：约束化随机。
不是瞎随机。是在合理的约束范围内随机。
比如你要测一个 FIFO，你可以约束：
- 写操作和读操作的比例在 3:1 到 1:3 之间
- 数据宽度固定为 32 位
- 复位后至少等待 10 个时钟周期再开始操作
这样随机出来的场景，既覆盖了各种组合，又不会跑到不合理的状态去。
我个人习惯的做法：
先写一个最宽松的约束，跑一轮看看覆盖率。然后根据覆盖率反馈，逐步收紧约束，把随机空间往那些没覆盖到的方向引导。说白了，就是让随机验证变得「有方向」。
1.3 随机验证 vs 定向测试：一张表说清楚
| 对比维度 | 定向测试 | 随机验证 |
|---|---|---|
| 用例生成方式 | 手动编写 | 自动生成 |
| 覆盖率 | 依赖工程师经验 | 可量化、可追踪 |
| 发现意外 bug 的能力 | 弱 | 强 |
| 维护成本 | 高（每加功能都要加用例） | 低（改约束即可） |
| 调试难度 | 低（场景可复现） | 中（需要种子复现） |
| 适用场景 | 边界值、关键路径 | 大规模、复杂交互 |
你看，随机验证并不是要完全取代定向测试。两者是互补的。定向测试用来打「点」，随机验证用来覆盖「面」。
1.4 随机验证的常见误区
我曾经踩过的坑，分享给你：
- 误区一：随机 = 完全随机 —— 结果跑了一亿个周期，全是同一个场景。约束没写好，等于白跑。
- 误区二：随机验证不需要定向测试 —— 边界值还是要手动测的。随机验证擅长的是「组合爆炸」的场景，不是「精确命中」的场景。
- 误区三：随机验证跑得越多越好 —— 不是的。关键是覆盖率。跑 100 万次和跑 1000 万次，如果覆盖率没提升，那就是在浪费仿真资源。
1.5 本章知识体系
下面这张图，是我自己总结的随机验证知识框架。你可以把它当作一张地图，后面几章的内容都会围绕它展开。
1.6 小结
这一章我们聊了为什么需要随机验证。说白了，就是定向测试的「想象力天花板」太低了。而随机验证通过约束化随机的方式，让机器帮我们生成海量测试用例，从而覆盖那些我们根本想不到的场景。
嗯，这里要注意：随机验证不是银弹。它和定向测试是搭档，不是对手。后面几章，我会带你一步步深入约束编写、覆盖率分析和仿真加速这些实战技术。
可可精品资料库