今天咱们聊聊测试用例设计。说实话，我见过太多测试工程师一上来就闷头写用例，结果漏测一堆。为什么？因为需求没吃透，测试点没理清。这一章，我就把压箱底的方法论掏出来，咱们一步步拆解。
19.1 测试需求分析：别急着动手，先看懂"题"
测试需求分析，说白了就是搞清楚"测什么"。我个人的习惯是，拿到一份需求文档，先问自己三个问题：
- 这个功能是干嘛的？（功能需求）
- 它要在什么环境下跑？（环境需求）
- 它必须满足什么标准？（性能/可靠性需求）
举个例子。有一次我负责一个USB充电口的测试。需求文档上只写了"支持5V/2A输出"。但实际分析时，我发现还需要考虑：
- 空载电压是否稳定？
- 满载2A时纹波多大？
- 短路保护是否触发？
- 长时间满载会不会过热？
你看，如果只看表面需求，这些点全漏了。所以我的建议是：把需求文档里的每一句话，都拆成"可验证的指标"。比如"支持5V/2A"可以拆成：电压精度±5%、纹波<50mV、过流保护阈值2.5A±0.2A。
**核心原则：**需求分析不是读文档，而是把文档翻译成测试语言。你翻译得越细，漏测就越少。
19.2 测试点提取：从需求到"可测点"的桥梁
测试点提取，就是把需求分析的结果，变成一个个具体的"检查项"。我习惯用思维导图来干这事。比如一个电源模块，我会从这几个维度展开：
| 维度 | 测试点示例 |
|---|---|
| 功能 | 输出电压、输出电流、使能控制、过流保护 |
| 性能 | 纹波噪声、负载调整率、线性调整率、效率 |
| 时序 | 上电时序、掉电时序、使能响应时间 |
| 可靠性 | 短路保护、过温保护、ESD、浪涌 |
| 兼容性 | 不同负载类型（阻性、容性、感性） |
嗯，这里要注意：测试点不是越多越好。我见过有人把"电源指示灯颜色"也列成测试点，结果浪费了大量时间。我的经验是：每个测试点必须能直接回答一个"是否满足需求"的问题。不能回答的，删掉。
**小技巧：**提取测试点时，可以试着用"如果...那么..."的句式。比如"如果输入电压降到4.5V，那么输出是否还能保持5V？"这样能帮你发现边界情况。
19.3 测试用例编写方法：等价类、边界值、场景法
测试点有了，接下来就是写用例。我主要用三种方法，咱们一个一个说。
19.3.1 等价类划分法：把无穷变成有限
等价类，说白了就是"把输入数据分成几类，每类只测一个代表"。比如一个电压输入范围是0~10V，那我可以分成：
- **有效等价类：**0V~10V（比如测5V）
- **无效等价类：**小于0V（比如测-1V）、大于10V（比如测12V）
我在项目中遇到过一个问题：一个温度传感器，规格书说工作范围是-40°C~85°C。测试员只测了25°C和85°C，结果-40°C下直接不工作。为什么？因为-40°C这个等价类被漏了。所以记住：每个等价类至少选一个代表值，尤其是边界附近的。
**避坑指南：**我曾经以为等价类很简单，结果在测一个多路选择器时翻了车。输入信号有8路，我每路只测了一个值，结果发现某路在特定频率下会串扰。后来我才明白：等价类不仅要考虑"值"，还要考虑"状态"和"时序"。
19.3.2 边界值分析法：bug最喜欢藏在边界上
边界值，是等价类的补充。经验告诉我，80%的bug都出在边界上。比如一个阈值是5V，那你要测：
- 4.9V（略低于边界）
- 5.0V（正好在边界）
- 5.1V（略高于边界）
你想想看，为什么边界容易出问题？因为硬件设计里，比较器、ADC、DAC这些器件，在边界附近往往有非线性区。我见过一个案例：一个过流保护电路，设计阈值是2A。测试时只测了1.9A和2.1A，结果2.0A时保护没触发，直接烧了板子。嗯，这就是边界没测全的代价。
我的习惯是：每个边界点，至少测"边界值-1"、"边界值"、"边界值+1"三个点。如果精度要求高，还要测"边界值-0.1"、"边界值+0.1"这种更细的粒度。
19.3.3 场景法：把用例串成故事
场景法，就是模拟用户真实的使用流程。比如测一个智能插座，你不能只测"开"和"关"，还要测：
- **正常场景：**手机APP连接 -> 打开插座 -> 关闭插座 -> 断开连接
- **异常场景：**打开插座时突然断电 -> 恢复供电后插座状态？
- **并发场景：**同时用APP和物理按键操作，谁优先？
- **压力场景：**连续开关1000次，会不会死机？
我个人习惯用"流程图"来设计场景。把每个操作步骤画成节点，把可能的分支画成箭头。这样能直观地看到哪些路径没覆盖到。比如一个充电宝的测试场景：
开始 -> 插入电源 -> 充电指示灯亮 -> 充满 -> 指示灯灭 -> 拔出电源
|-> 插入手机 -> 放电指示灯亮 -> 手机充满 -> 放电结束
|-> 同时插入电源和手机 -> 边充边放（看是否支持）
|-> 插入非标准设备 -> 看是否保护你看，一个简单的充电宝，场景法能帮你发现"边充边放"这种容易被忽略的测试点。我建议：每个功能模块，至少设计3~5个核心场景，包括正常、异常、边界三种类型。
总结一下： 等价类帮你覆盖"值"，边界值帮你覆盖"临界点"，场景法帮你覆盖"流程"。三者结合，才能写出高质量的测试用例。我见过太多人只用一种方法，结果漏测率居高不下。记住：方法没有好坏，只有合不合适。
19.4 实战案例：一个电源模块的测试用例设计
光说不练假把式。咱们拿一个5V/2A的DC-DC电源模块来练手。
第一步：需求分析
- 输入：12V±10%
- 输出：5V±5%，最大2A
- 纹波：<50mV
- 效率：>85%
- 保护：过流、过温、短路
第二步：提取测试点
- 功能：输出电压、输出电流、使能控制
- 性能：纹波、负载调整率、效率
- 保护：过流阈值、短路恢复、过温关断
- 时序：上电建立时间、掉电保持时间
第三步：编写测试用例（节选）
| 用例ID | 测试点 | 方法 | 输入条件 | 预期结果 |
|---|---|---|---|---|
| TC-01 | 输出电压精度 | 等价类 | 输入12V，负载0.5A | 4.75V~5.25V |
| TC-02 | 过流保护阈值 | 边界值 | 负载从2A缓慢增加 | 在2.2A~2.5A之间触发保护 |
| TC-03 | 短路恢复 | 场景法 | 输出短路后移除短路 | 自动恢复输出，无损坏 |
| TC-04 | 纹波噪声 | 等价类 | 满载2A，带宽20MHz | <50mVpp |
你看，每个用例都明确标注了"用什么方法"。这样后期评审时，别人一眼就能看出你的设计思路。我个人觉得，测试用例的"可读性"和"可追溯性"同样重要。
**我的习惯：**每个用例都加一个"设计理由"字段。比如TC-02的理由是"过流保护阈值是安全关键点，必须用边界值法覆盖"。这样即使几个月后回头看，也能明白当初为什么这么设计。
19.5 避坑指南：我踩过的那些坑
最后，分享几个我亲身经历的教训：
- 坑1：只测典型值，不测边界。 有一次测一个LDO，只测了3.3V输出，结果在输入电压接近dropout时，输出纹波飙升。后来补测了边界，才发现问题。
- 坑2：场景法只测"happy path"。 我见过一个团队测智能门锁，只测了"正常开锁"，结果没测"指纹识别失败后连续尝试5次"，导致锁死bug没被发现。
- 坑3：等价类划分太粗。 比如把"0~10V"只分成"有效"和"无效"两类，结果漏掉了"接近0V"这个特殊区域。我的建议是：每个等价类内部，再根据物理特性细分。
嗯，说了这么多，其实核心就一句话：测试用例设计不是写作文，而是搭积木。需求分析是图纸，测试点是积木块，等价类、边界值、场景法就是搭积木的方法。方法对了，积木才能搭得稳。