2. 测试策略制定：基于风险的测试策略、测试覆盖度分析

好，咱们进入第二章。上一章我们聊了为什么要做电源网络可靠性验证，这一章我重点讲讲怎么测的问题。

说实话，我刚入行那会儿，做PI测试就是“把所有能测的都测一遍”。结果呢？项目周期拖得很长，该发现的问题反而没发现。后来我慢慢悟出一个道理——测试不是越多越好，而是越精准越好。

那怎么做到精准？核心就两件事：基于风险的测试策略和测试覆盖度分析。

你想想看，一颗复杂的SoC芯片，电源网络可能有几十个域、上千个节点。如果每个节点都做全参数测试，时间和成本根本扛不住。我见过一个团队，为了追求“100%覆盖”，测试项列了300多条，结果流片后最关键的VDD_CORE域出了问题，反而没测到。

所以，我的习惯是：先评估风险，再决定测什么、测多深。

核心原则： 把有限的测试资源，投入到风险最高的区域。

那风险怎么评估？我一般从三个维度看：

光靠感觉不行，得有个工具。我个人喜欢用风险矩阵来量化。下面这个表是我在项目中常用的模板：

风险等级	功能关键性	设计复杂度	历史失效概率	测试优先级
高 (H)	核心逻辑、PLL、高速IO	走线宽度 < 3um，层数 > 6	同类设计曾失效	必须全覆盖
中 (M)	普通数字逻辑、低速IO	走线宽度 3-10um，层数 4-6	偶有失效	抽样测试
低 (L)	辅助电路、测试模式	走线宽度 > 10um，层数 < 4	极少失效	目检或免测

有了这个矩阵，你就能快速把芯片上的电源节点分门别类。高风险的，投入70%的测试资源；中风险的，投入25%；低风险的，5%就够了。

我的经验： 别把低风险项完全忽略。我曾经在一个“低风险”的辅助供电网络上栽过跟头——因为走线太细，大电流时压降超标，导致芯片在高温下重启。所以低风险不是不测，而是用低成本的方式验证，比如目检或者简单的DC测量。

策略定好了，接下来要回答一个问题：我们的测试到底覆盖了多少？

覆盖度分析，说白了就是算一笔账。我常用的覆盖度指标有这几个：

嗯，这里要注意：覆盖度不是越高越好。我见过有人追求节点覆盖度100%，结果测了一堆冗余节点，真正关键的动态响应测试反而没时间做。我个人习惯，把覆盖度目标定在80%-90%之间，剩下的10%-20%留给风险分析和工程判断。

下面这张图是我在项目中常用的测试策略制定流程，你可以参考：

这个流程看起来是线性的，但实际上执行与反馈这一步会不断往回迭代。比如你测完发现某个高风险区域覆盖度不够，那就得回到“制定测试方案”那一步，补充测试项。

光说不练假把式。我拿一个实际项目举例：

假设芯片有5个电源域，总共200个测试节点。按照风险矩阵，我们识别出：

测试方案定的是：高风险全测，中风险抽30%，低风险抽10%。那实际测试节点数就是：

高风险：50 × 100% = 50个
中风险：100 × 30% = 30个
低风险：50 × 10% = 5个
总计：50 + 30 + 5 = 85个

节点覆盖度 = 85 / 200 = 42.5%

你看，节点覆盖度只有42.5%，但高风险区域是100%覆盖的。这就是基于风险的策略——用42.5%的测试量，覆盖了90%以上的失效风险。

注意： 覆盖度计算不能只看节点数。我遇到过一种情况：节点覆盖度很高，但所有测试都是在常温、低频下做的，高温、高频的工况一个都没测。结果芯片在高温下IR Drop超标，直接挂掉。所以工况覆盖度和参数覆盖度同样重要，甚至更重要。

最后，分享几个我亲身经历过的教训：

坑一：过度依赖仿真数据。仿真说某个节点压降只有1%，我就没把它列为高风险。结果实测出来是3.5%，因为仿真模型没考虑封装寄生。后来我学乖了：仿真结果只能作为参考，不能替代实测。
坑二：忽略动态测试。静态DC测试只能测稳态压降，但芯片工作时电流是动态变化的。我有个项目，静态测试全过，结果芯片在负载跳变时电压跌了15%，直接复位。从那以后，动态响应测试成了我必测的项目。
坑三：覆盖度报告造假。这个说起来有点尴尬。有次项目赶进度，测试团队为了凑覆盖度，把一些没测的节点也写进了报告。结果流片后出了问题，追责时才发现覆盖度是假的。所以我的原则是：宁可覆盖度低，也不能造假。低覆盖度可以补测，造假会毁掉整个团队的信任。