测试用例设计实战：从入门到精通
“好的” 测试用例：从定义到设计的实用指南
一、什么是 “好的” 测试用例？—— 核心定义
很多人觉得 “能找到 bug 的测试用例才是好的”，但这个想法其实不对。就像你买了一把伞，不能说 “只有下雨时用得上的伞才是好伞”—— 好伞的核心是 “无论下不下雨，它都能随时提供防护”。
好的测试用例本质是一个 “完整的防护网”：
- 就像捕鱼时用的渔网，只要网眼均匀、覆盖整个池塘，就算这次没捕到鱼（没发现 bug），也是合格的渔网
- 它不需要 “专门找 bug”，但必须覆盖软件所有可能的使用场景（等价类）和临界情况（边界值）
- 比如你常用的打车 APP，好的测试用例不仅要测 “正常下单 - 接单”，还要包含 “网络突然中断”“手机突然关机” 等极端场景 —— 哪怕这些场景从没出过问题
二、“好的” 测试用例必须具备这 3 个特征
（一）整体完备性：一个都不能少
好的测试用例要像超市货架，该有的品类必须全。比如外卖 APP 的测试：
- 不仅要测 “选餐 - 支付” 的正常流程（基础功能）
- 还要测 “地址填错能否修改”“超时未接单能否取消”（用户高频操作）
- 甚至要测 “手机没电重启后订单状态是否保留”（极端场景）
如果漏掉 “支付失败后退款” 的测试用例，就像超市没卖饮用水 —— 虽然平时不觉得，但关键时刻会出大问题。
（二）等价类划分准确：测一个能顶一批
等价类就像 “同一款衣服的不同尺码”—— 只要中码能穿，小码和大码的版型问题可以类推。
比如测试 “手机号登录” 功能：
- 有效等价类：11 位正常手机号（如 13800138000）
- 无效等价类：10 位手机号（138001380）、12 位手机号（138001380000）、字母组合（abcdefghijk）
只要测过 “13800138000” 能正常登录，就不用再测其他 11 位正常手机号；同理，测过 “10 位手机号登录失败”，就知道所有短于 11 位的手机号都会失败。
（三）边界值覆盖完整：别忽略 “刚好差一点” 的情况
软件最容易在 “临界值” 出问题，就像电梯标着 “限载 10 人”，往往在第 11 人挤进去时容易出故障。
比如测试 “密码长度限制（6-20 位）”：
- 必须测 5 位（刚好不够）、6 位（刚好达标）、7 位（略多于达标）
- 还要测 19 位（接近上限）、20 位（刚好达标）、21 位（超出上限）
之前有个银行 APP 就是因为没测 “20 位密码”，导致部分用户设置最长密码后无法登录 —— 这种边界值问题，用户遇到一次就可能卸载 APP。
三、3 个常用设计方法（附生活例子）
（一）等价类划分法：把复杂场景归类
核心思路：把所有可能的输入分成 “有效” 和 “无效” 两类，每类选一个代表测试。
比如测试 “快递单号查询”（要求 12 位数字）：
| 等价类类型 |
具体例子 |
测试用例选例 |
| 有效等价类 |
12 位数字（123456789012） |
测 123456789012 即可 |
| 无效等价类 |
11 位数字（1234567890） |
测 1234567890 即可 |
| 无效等价类 |
含字母（123456abcdef） |
测 123456abcdef 即可 |
就像你买水果时，只要尝一个苹果甜，就知道这筐苹果大概率都甜 —— 不用每个都尝。
（二）边界值分析法：专盯 “差一点” 的情况
核心思路：重点测试 “刚好达标”“刚好不达标” 的临界值。
比如你用购物 APP 设置 “收货地址字数（最多 20 字）”：
- 必须测 19 字（差 1 字到上限）
- 必须测 20 字（刚好达标）
- 必须测 21 字（超 1 字）
这就像你坐火车赶时间：提前 1 分钟到（刚好赶上）、准时到（可能错过）、迟到 1 分钟（彻底错过）—— 这三个时间点最关键。
（三）错误推测法：凭经验预判坑点
核心思路：根据平时踩过的坑设计用例，就像老司机知道 “哪个路口容易堵车”。
比如测试视频 APP：
- 老测试会想到 “缓存满了能否播放”（基于 “手机存满照片会卡顿” 的经验）
- 会想到 “切换 WiFi 和流量时会不会断更”（基于 “追剧时切网络常出问题” 的经验）
为了避免依赖个人经验，团队可以建一个 “常见坑点清单”：比如 “支付相关功能必须测退款”“输入框必须测空格和特殊符号”—— 就像厨房贴的 “关火后必关煤气” 提醒。
四、设计 “好的” 测试用例，这 4 步最关键
以你常用的 “手机银行转账” 功能为例：
（一）先搞懂用户到底需要什么
测试前要先想：用户用转账功能时最在意什么？
- 普通人怕转错账（所以要测 “收款方信息错误能否提示”）
- 怕转丢了（所以要测 “网络中断后钱会不会消失”）
- 怕操作麻烦（所以要测 “常用收款人能否保存”）
如果没考虑这些，只测 “输入金额能转账”，就像给用户一把能开门但没锁的钥匙 —— 看似能用，实则有风险。
（二）把需求像剥洋葱一样拆清楚
从 “用户需求” 到 “测试用例” 需要层层拆解：
- 业务需求：用户能安全、便捷地转账
- 功能需求：支持输入金额、选择收款人、验证密码
- 测试需求：金额不能为负数、收款人姓名不能有特殊符号、密码错误 3 次锁定
- 测试用例：
-
- 输入 1000 元（正常金额）
-
- 输入 - 500 元（无效金额）
-
- 收款人姓名含 “*”（特殊符号）
可以用工具（如 JIRA）记录这种对应关系，就像快递单上的 “寄件人 - 中转站 - 收件人” 跟踪记录 —— 哪一步漏了能立刻发现。
（三）别放过任何一个细节需求
比如转账功能不能只测 “能转钱”，还要考虑：
- 安全性：连续输错 3 次密码会不会锁账户？
- 易用性：有没有 “转账备注” 功能？
- 兼容性：在老旧手机上会不会显示错乱？
就像你买电动车，不能只看 “能开”，还要看 “刹车灵不灵”“充电方不方便”—— 这些细节决定用户体验。
（四）3 种方法组合使用效果最好
以 “转账金额输入” 为例：
- 先用等价类：有效金额（0.01-50000）、无效金额（负数、0、超过 5 万）
- 再用边界值：测 49999 元、50000 元、50001 元（刚好到限额和超限额）
- 最后用错误推测：测 “输入 50000.01 元”（带小数的超限）、“输入字母 abc”（乱输）
就像做菜时 “盐 + 酱油 + 糖” 搭配 —— 单放一种不够味，组合起来才好吃。
五、老测试员的 3 个实战经验
（一）多了解软件 “内部构造”
比如知道手机银行用了 “缓存保存常用收款人”，就要测 “清除缓存后常用人会不会消失”；知道用了 “第三方支付接口”，就要测 “接口故障时能不能提示用户”。
这就像修自行车的师傅 —— 知道链条和齿轮怎么配合，才能发现别人看不出的小毛病。
（二）用 “覆盖率” 检查有没有漏
- 需求覆盖率：看看有没有没测的需求（比如漏测 “转账到账提醒”）
- 代码覆盖率：看看有没有没测的代码（比如某个异常处理逻辑从没执行过）
就像扫雪时用尺子量 —— 哪块没扫到一目了然。
（三）别照着代码设计用例
如果开发写的代码里 “忘记判断金额为 0 的情况”，你照着代码测也会漏 —— 要始终以 “用户需求” 为标准，就像老师判作业按参考答案，而不是按学生写的答案。
六、为什么一定要设计 “好的” 测试用例？
（一）能提前堵住漏洞，避免用户踩坑
之前有个理财 APP 因为没测 “到期自动赎回” 的边界值（刚好在节假日到期），导致部分用户资金延期到账 —— 如果测试用例覆盖了这个场景，就能提前发现问题。
（二）能少走弯路，节省时间和成本
好的测试用例能一次把问题测全，避免反复返工。比如测转账功能时一次测完所有异常场景，比上线后用户反馈一个问题再改一个，效率高 10 倍以上。
（三）能让用户更信任产品
当你用打车 APP 时，哪怕遇到 “暴雨天定位不准”，系统也能提示 “建议手动选择位置”—— 这种细节就是好的测试用例保障的。用户觉得 “这 APP 考虑真周到”，自然会一直用。
总结
好的测试用例就像雨伞的骨架 —— 平时看不见，但缺了一根就撑不起来。它不需要 “刻意找 bug”，但必须 “随时能防坑”。记住：设计测试用例时多想想 “如果是我用这个软件，会遇到什么情况”，就能离 “好的测试用例” 越来越近。