3. 测试用例设计：功能测试用例、性能测试用例、压力测试用例、边界测试用例、用例评审与维护
测试用例设计，说白了就是给量产测试画「作战地图」。
我见过太多团队，一上来就闷头写代码，结果产线一跑就崩。为什么？因为用例设计没想清楚。你想想看，量产测试和研发测试完全是两码事——研发测的是「能不能用」，量产测的是「每一片能不能用」。
核心观点：量产测试用例的设计原则是「覆盖全面、执行高效、结果可判」。少一个用例，可能漏掉一批坏品；多一个冗余用例，产线节拍就慢几秒。
3.1 功能测试用例
功能测试，就是验证「该有的功能有没有」。但量产的功能测试和研发不一样——研发测一次，量产测几万次。
我个人习惯把功能测试用例分成三类：
- 基本功能用例：上电、通信、寄存器读写、IO 电平。这些是「活着」的证明。
- 模式切换用例：工作模式、休眠模式、待机模式。我遇到过一款芯片，休眠模式下的电流正常，但唤醒后通信就丢包——这种问题不测模式切换根本发现不了。
- 异常处理用例：比如通信超时、CRC 校验失败、看门狗复位。嗯，这里要注意，量产测试里异常处理往往比正常流程更重要。
实战技巧：写功能测试用例时，我建议用「输入-操作-预期输出」的模板。举个例子：
用例ID: FT-001
描述: 验证UART通信正常
输入: 发送0x55 0xAA
操作: 等待100ms
预期: 收到0x55 0xAA回显
实际: ________ (Pass/Fail)别小看这个模板。产线操作员文化水平参差不齐，用例写得越傻瓜，执行越靠谱。
3.2 性能测试用例
性能测试，测的是「好不好」。量产中的性能测试，核心是规格符合性。
举个例子：某款电源芯片，规格书上写输出纹波 < 50mV。研发阶段测出来是 30mV，很漂亮。但量产时，同一批晶圆、同一套封装，纹波可能跑到 45mV 甚至 55mV。为什么？因为工艺角、温度、负载都在变。
我一般把性能测试用例分为：
- 电气参数测试：电压、电流、频率、功耗。这些是硬指标，一个都不能少。
- 时序参数测试：建立时间、保持时间、上升沿、下降沿。我曾经因为一个保持时间余量不足，导致整批产品在高温下通信失败——那批货返工花了整整两周。
- 精度/误差测试：ADC 精度、DAC 输出误差、时钟频率偏差。这类用例通常需要统计多个样本。
| 测试项 | 规格下限 | 规格上限 | 测试条件 |
|---|---|---|---|
| 工作电压 | 3.0V | 3.6V | 常温，满载 |
| 工作电流 | — | 100mA | 3.3V，25°C |
| UART波特率误差 | -2% | +2% | 115200bps |
避坑指南：性能测试用例一定要注明「测试条件」。同样的芯片，25°C 和 85°C 测出来的结果可能差 30%。我曾经见过一个团队，常温下所有性能都 pass，一到高温老化就全军覆没——就是因为用例里没写温度条件。
3.3 压力测试用例
压力测试，说白了就是「往死里测」。量产的压力测试不是为了找 bug，而是为了筛选出早期失效。
我常用的压力测试手段：
- 连续读写测试：比如对 Flash 连续写入 10000 次，再读出校验。有些芯片写几次没问题，写几百次就开始丢数据。
- 频繁上下电：模拟用户反复插拔电源。我记得有一次，某款芯片在连续上下电 500 次后，内部 LDO 启动失败——这种问题正常功能测试根本测不出来。
- 通信压力测试：比如连续发送 10000 个数据包，统计丢包率。量产标准通常要求 0 丢包。
关键点：压力测试的「压力值」怎么定？我个人的经验是：规格书标称值的 1.2~1.5 倍。比如标称工作温度 85°C，压力测试就跑到 105°C。标称通信速率 1Mbps，压力测试就跑到 1.5Mbps。留出余量，才能筛出边缘品。
3.4 边界测试用例
边界测试，测的是「临界点」。很多量产失效都发生在边界附近。
常见的边界测试场景：
- 电压边界：最低工作电压、最高工作电压。我遇到过一款芯片，3.0V 时正常工作，2.9V 时突然死机——但规格书上写的是 3.0~3.6V。这种芯片在电池供电设备里就是定时炸弹。
- 温度边界：最低温、最高温。量产测试通常只做常温，但边界测试一定要覆盖高低温。
- 时序边界：最小建立时间、最大保持时间。这类用例往往需要配合 ATE 测试机台来做。
小技巧：边界测试用例不要只测「刚好在边界上」的点。我习惯在边界内外各取一个点。比如电压下限是 3.0V，我就测 3.05V（pass 区）和 2.95V（fail 区）。这样能看出芯片的「安全余量」有多大。
3.5 用例评审与维护
用例写完了，不是终点，是起点。
用例评审，我建议至少过三关：
- 自审：写用例的人自己先跑一遍。很多低级错误在这一步就能发现。
- 互审：同组同事交叉检查。不同的人看问题的角度不一样，我经常在互审时发现「这个用例的预期结果写错了」或者「这个测试条件没写全」。
- 专家评审：请资深工程师或架构师把关。重点看用例的覆盖率和优先级。
用例维护，说白了就是「持续迭代」。量产不是一成不变的：
- 晶圆厂换了，工艺变了，用例要不要调？要。
- 产线上发现新问题，用例要不要加？要。
- 某个用例跑了一万次从来没 fail 过，能不能删？可以降级，但别删。我吃过这个亏——删了一个「从来没用过」的用例，结果下一批货就出了同样的问题。
血的教训：我曾经负责一款芯片的量产，初期用例只有 50 条。跑了半年，产线上陆续发现了 12 种新失效模式。每次发现新问题，我就加一条对应的用例。一年后，用例库扩充到了 200 条。但产线良率从 95% 提升到了 99.5%。你想想看，这 5% 的良率提升，背后就是一条条用例堆出来的。
最后说一句：用例设计没有「完美」这回事。你永远不可能覆盖所有失效模式。但你可以做到——每发现一个问题，就补一条用例，让同样的问题不再出现第二次。这就是量产测试用例设计的终极心法。