一、验证策略与计划制定

各位同学，今天我们来聊聊验证策略和计划制定。说实话，这是整个验证流程中最容易被忽视，但也是最关键的一步。我见过太多项目，一上来就写代码、跑仿真，结果到后期发现验证目标不明确，覆盖率凑不齐，最后只能延期。

为什么会这样？说白了，就是前期没想清楚「我们要验证什么」和「怎么验证」。今天我就把我在多个车规项目中的经验，掰开揉碎了讲给你听。

1.1 验证策略（Test Strategy）的制定

验证策略，说白了就是回答三个问题：

• 我们要验证哪些功能？
• 用什么方法验证？
• 验证到什么程度算够？

我个人习惯，先画一张图把整个验证策略串起来。你看下面这张图，就是我在一个车规SoC项目中用的策略框架：

这张图我每次做新项目都会拿出来改一改。你想想看，车规芯片和消费芯片最大的区别在哪？就是安全验证。消费芯片功能跑通就行，车规芯片不行，你得证明它在各种故障下还能安全地工作。

1.2 验证计划（Verification Plan）的撰写要点

验证计划，就是把策略落地成可执行的文档。我见过很多新人写的验证计划，要么太粗（就几行字），要么太细（连每个测试用例都写进去）。

我个人认为，一份好的验证计划应该包含以下内容：

章节	内容	要点
1. 验证范围	明确要验证的功能模块	哪些测，哪些不测，为什么
2. 验证环境	UVM环境结构、组件列表	要画出环境框图
3. 测试用例清单	每个功能的测试场景	优先级、依赖关系
4. 覆盖率定义	功能覆盖点、交叉覆盖	要可量化、可追踪
5. 回归策略	回归频率、种子管理	每天回归还是每周回归
6. 交付物清单	报告、日志、覆盖率数据	格式、存储位置

嗯，这里要注意一点。验证计划不是写一次就完事的。我习惯用版本控制来管理验证计划，每次迭代都更新。你想想看，项目进行到一半，需求变了，验证计划不变，那后面肯定出问题。

1.3 验证指标的定义

验证指标，说白了就是「怎么算验证完了」。车规芯片的验证指标，我一般分三类：

1.3.1 覆盖率指标

• 代码覆盖率：行覆盖、条件覆盖、状态机覆盖。目标≥90%。
• 功能覆盖率：根据验证计划定义的功能覆盖点。目标≥95%。
• 交叉覆盖率：多个功能点的组合。这个最难凑，但最有用。

1.3.2 安全指标（KPI）

• 故障注入覆盖率：所有安全机制都要被故障注入验证过。目标≥99%。
• 诊断覆盖率：ISO 26262要求的诊断覆盖率，根据ASIL等级不同，要求不同。
• 安全机制响应时间：从故障发生到安全机制响应的时间，必须在规定范围内。

1.3.3 项目指标

• 测试用例通过率：回归测试通过率≥99.5%。
• Bug发现率：每周新发现的Bug数量趋势，应该是下降的。
• 验证进度：已完成的功能点占比。

1.4 资源与时间估算

这个环节，说实话，是最容易出问题的。我见过太多项目，资源估算少了，时间估算乐观了，最后加班加到崩溃。

我个人习惯用这个公式来估算验证时间：

验证总时间 = (功能点数 × 每个功能点验证时间) × 1.5（缓冲系数）

其中：
- 功能点数：从验证计划中统计
- 每个功能点验证时间：包括环境搭建、测试用例开发、调试、回归
- 缓冲系数：1.5 是保守估计，我一般用 2.0

举个例子，一个车规SoC有100个功能点，每个功能点平均需要2周验证时间：

总时间 = 100 × 2 × 1.5 = 300 人周
如果团队有5个人，需要 60 周 ≈ 15 个月

你想想看，15个月是不是很夸张？但车规芯片就是这样，验证时间往往比设计时间还长。我做过一个ASIL-D级别的芯片，验证花了18个月，设计只用了12个月。

1.5 总结

好了，今天的内容就到这里。验证策略和计划制定，说白了就是「想清楚再动手」。我见过太多项目，上来就写代码，结果验证环境搭了三次才稳定，测试用例写了又删，覆盖率永远差一点。

记住三句话：

• 策略先行，计划跟上
• 指标要量化，不要模糊
• 资源估算要保守，时间估算要留余量

嗯，这些经验都是我用加班和流片失败换来的。希望你能少走弯路。

---

公众号:蓝海资料掘金营，微信deep3321