仿真跑了几百个case覆盖率也看着不错结果流片回来还是踩了坑。复盘的时候才发现当时的测试用例集中在一类场景其他维度根本没想到去测。这是绝大多数验证工程师在入行前几年都会遇到的问题。根源在哪测试用例的构造视角太单一。大部分人写用例脑子里只有一个维度功能对不对。但芯片要验证的东西远不止功能是否正确还有性能、容量、安全、可靠性、可恢复性……这些维度每一个都能单独找出一堆问题。这篇文章要做的事情是把构造测试用例的完整视角梳理清楚——从哪些方向想每个方向怎么落地新手在哪里容易踩坑。文章分两部分。第一部分是通用框架不管验证什么模块这套思路都适用。第二部分是领域特定的按模块类型展开给出更具体的测试要点。一、通用框架12种测试用例类型怎么用在芯片验证里从功能对不对开始但不能止步于此1.能力测试Capability Testing是所有测试用例里最基本的一类目标就是确认芯片的目标功能是否实现。很多新手的测试用例集其实大部分都属于这一类给一个合法输入期望一个正确输出验证功能是否符合spec描述。这一类用例是基础但有几个细节新手容易做得不够扎实。第一个问题用例覆盖的功能点是否完整。实操建议是拿出模块spec把所有shall、must、应该这类表述提取出来每一条对应构造至少一个测试用例。这个过程机械但有效很多遗漏的功能点就是在这里被找回来的。第二个问题功能的边界是否测到。等价类划分和边界值分析是软件测试里的经典方法在芯片验证里同样适用而且往往比功能本身更重要。举个例子某个加密引擎支持128/192/256-bit三种密钥长度很多人写用例只测128-bit认为其他长度应该也没问题。但这三种密钥长度在内部调度逻辑上的round数量是不同的192-bit和256-bit的实现路径和128-bit完全不一样不单独测就是漏测。新手必记每一个配置选项、每一种工作模式都要有对应的测试用例不能靠应该没问题来代替。2.文档测试Documentation Testing