4. 测试覆盖率基础
各位搞测试的同事，咱们聊个基础但特别容易被误解的话题——测试覆盖率。说白了，你辛辛苦苦把 ATE 程序写完了，跑了一堆向量，最终拿什么衡量“测够了没”？就是覆盖率。
但我见过太多人只盯着一个数字看，比如 95% 的 stuck-at 覆盖率就以为万事大吉。结果呢？DPPM 高得吓人。今天我把这块的底层逻辑掰开了讲。
四大主流故障模型
先说说常见的故障模型。ATE 测试里，我们模拟的是芯片内部可能出现的物理缺陷。不同的缺陷要用不同的故障模型去“套”。我个人习惯把最常用的四个模型记在脑子里：
- 固定故障（Stuck-at Fault）——最经典。某个节点 stuck-at 0 或 stuck-at 1。简单，但覆盖不了时序问题。
- 过渡故障（Transition Fault）——测的是信号从 0→1 或 1→0 时变慢了。说白了，就是检查门能不能在规定时间内翻转。
- 桥接故障（Bridging Fault）——两根线意外短路了。我早期做过一个案子，成品率一直上不去，后来发现是相邻金属线桥接，而 stuck-at 覆盖率 99% 都查不出来。
- 延迟故障（Delay Fault）——路径上的累积延迟超了。对高速芯片特别重要，比如 28nm 以下的工艺，一个小电阻都能让路径延迟增加。
| 故障模型 | 模拟的物理缺陷 | 典型覆盖率目标 | 我的经验 |
|---|---|---|---|
| Stuck-at | 金属线开路/对电源短路 | ≥ 95% | 基础门槛，但不够 |
| Transition | 晶体管开关变慢 | ≥ 85% | 必须和 at-speed 测试配合 |
| Bridging | 相邻线短路 | ≥ 90% | layout 版图决定哪些桥接要测 |
| Path Delay | 关键路径延迟超标 | ≥ 80% | 时序收敛后的最后检查 |
你想想看，如果一个芯片只跑了 stuck-at 测试，过渡故障留着不管，流片回来低频跑没问题，一到高频就挂——这种坑我至少见过三次。
缺陷覆盖率 vs 故障覆盖率
很多人把这两个词混着用，其实差别大了去了。
- 故障覆盖率：你的向量能测到多少个故障模型中的故障点。比如 1000 个 stuck-at 故障，你测到了 950 个，覆盖率 95%。这是工具算出来的。
- 缺陷覆盖率：芯片上真实的物理缺陷，你的测试能抓住多少。这是流片后才能统计的，和工艺良率有关。
关键区别：故障覆盖率是“理论覆盖”，缺陷覆盖率是“实际覆盖”。理论 95% 不代表真缺陷能抓到 95%。
我记得有一次，某个项目故障覆盖率 97%，但客户 DPPM 要求 500。结果量产出来 DPPM 飙到 2000。追查原因——很多桥接故障没建模，虽然 stuck-at 覆盖率很高，但真实缺陷根本没测到。从那以后，我在制定策略时一定把缺陷覆盖率作为最终指标，故障覆盖率只是中间参考。
DPPM 与良率的数学关系
DPPM（Defective Parts Per Million）和良率是同一个硬币的两面。良率是好的芯片占比，DPPM 是有缺陷芯片在百万颗中的数量。
最基础的公式：
良率 = 合格芯片数 / 总投料数
DPPM = (不合格芯片数 / 总出货数) × 1,000,000但和覆盖率挂钩时，需要引入 测试逃逸 的概念。假设一个芯片有 n 个缺陷，你的测试对每个缺陷的检测概率是 C（缺陷覆盖率），那么所有缺陷都没被测到的概率就是 (1 - C)^n。实际逃逸率 ≈ 1 - Cn（近似），不过更常用的模型是：
DPPM = (1 - Y) × (1 - Coverage) × 1,000,000其中 Y 是工艺良率。举个例子：工艺良率 95%（即 50,000 DPPM 的原始缺陷），测试故障覆盖率 98%，那么出货 DPPM ≈ 50,000 × 2% = 1000。嗯，这里要注意——这个公式假设缺陷随机分布且独立，实际工艺会有 clustering 效应，所以 DPPM 往往比计算值高一些。
避坑指南：我曾经用这个公式估算 DPPM，结果实际 DPPM 比算出来高 3 倍。后来发现是覆盖率没考虑“等效故障”和“检测质量”——有些故障虽然被向量触发了，但输出观察窗口不够，导致漏检。所以算出来的 DPPM 最好留 2~3 倍余量。
如何设定覆盖率目标
这个问题没有标准答案，但我有一套自己的做法：
- 先看产品要求的 DPPM。比如通信芯片要求 ≤ 100 DPPM。
- 再拿工艺良率数据（foundry 会给 defect density）。算出需要的最低缺陷覆盖率。
- 然后分配故障模型：stuck-at 做到 > 95%，transition > 85%，再加上一部分桥接和 path delay。
- 最后用少量量产数据校准，如果实际 DPPM 偏高，就补向量或加测试项。
这么做的好处是，你心里有底，不会盲目追高覆盖率。我见过有人把 stuck-at 做到 99.9%，结果 0.1% 的未覆盖故障恰好是致命缺陷，DPPM 依然不达标——这就是典型的“方向错了”。
小技巧：用 TetraMAX 或 FastScan 跑完覆盖率后，不妨看看 未覆盖故障列表。那些统计上出现次数少的故障，往往对应着 rare defect，但一旦出现就是大问题。我习惯手动分析 top 10 未覆盖故障的物理位置，确认是否在敏感区域。
下面这张图把今天讲的核心脉络串起来了，你保存一下，做测试方案时对照着看：
最后说一句，覆盖率的本质是风险管控。不要为了数字好看把向量量级翻倍，花几周时间把 stuck-at 从 98% 抬到 99%，结果 DPPM 只降了 0.2%。把精力花在短板模型和物理敏感区上，这才是实战经验告诉我的正道。