验证计划 Verification Plan
一句话回答
验证计划是在写测试前先定义清楚「要验证哪些功能、用什么激励、怎么自动判对错、覆盖到什么程度才算过」的文档/清单；它把规格拆成一条条可验证、可追踪的检查点，并挂上覆盖率目标，驱动后续整个回归与收敛，避免「先闷头写 testcase、最后才发现关键场景没测」。
一、为什么必须先有计划
没有计划，验证容易变成「能跑通几个例子就行」，边界、异常、组合场景全靠运气。计划把验证从「试」变成「有目标、可度量、可签核」的工程活动。
二、典型内容
- 特性提取：通读规格，列出所有 feature（功能、模式、配置、异常处理）；
- 场景分解：每条 feature 拆成正常、边界、错误、并发/组合场景；
- 激励策略：定向测试 vs 约束随机（CRV），各自覆盖什么；
- 检查机制：参考模型/scoreboard、SVA 断言如何判定对错；
- 覆盖率目标：每个功能点映射到 covergroup/bin 和代码覆盖；
- 通过准则：功能覆盖率 100%、代码覆盖率达标、无未处理 bug、断言无违例；
- 可追踪性：规格 → 功能点 → 场景 → 测试 → 覆盖率，双向可追溯。
三、计划驱动收敛
bash
规格 ─► 功能点 ─► coverpoint/bin ─► 回归 ─► 覆盖率空洞 ─► 补激励
▲ │
└──────────── 未覆盖/失败回填，迭代直到准则达成 ◄──────┘覆盖率空洞对应回计划里的功能点，缺哪补哪，而不是盲目加用例。
常见坑
- 计划流于形式、写完不更新：规格变了计划不跟，验证目标失真。
- 功能点粒度过粗：「验证 SPI」无法度量，要拆到可映射覆盖率的检查点。
- 只列激励、不列判据：没有 scoreboard/checker，跑了也不知道对不对。
- 通过准则不量化：「差不多就行」无法签核，要明确覆盖率和 bug 门槛。
- 可追踪性断裂：发现 bug 说不清对应哪个功能点，漏测难复盘。
- 计划和回归脱节：覆盖率结果不回灌计划，收敛无从谈起。
总结
验证计划在编码前把规格拆成可验证、可追踪的功能点和场景，规定激励、检查机制、覆盖率目标和量化通过准则，并用它驱动「回归—空洞—补激励」的收敛闭环；它是 coverage-driven 验证的起点，关键是持续维护、与回归和缺陷保持双向追踪。