很多新人测试拿到需求就开始"点点点"，点了半天自己都不知道测了什么、漏了什么。
老测试拿到需求，先想的是：这个功能有哪些输入维度？哪些边界？哪些组合？哪些异常路径？
这背后就是测试用例设计方法。这篇用登录、注册、下单三个真实场景，把六大方法一次讲透。
一、为什么不能"瞎点"？
没有方法的测试，靠的是运气和经验。结果就是：正常路径测了十遍，边界和异常一个没碰，上线就出 Bug。
用例设计方法的核心价值是用最少的用例覆盖最多的风险。六大方法各有适用场景：
| 方法 | 适用场景 | 核心思想 |
|---|---|---|
| 等价类划分 | 输入框、参数 | 同类数据视为等价，取一个代表 |
| 边界值分析 | 有范围的输入 | 错误最容易发生在边界 |
| 判定表 | 多条件组合 | 穷举所有条件组合 |
| 因果图 | 复杂逻辑关系 | 先画原因-结果图再转判定表 |
| 场景法 | 业务流程 | 基本流+备选流覆盖完整路径 |
| 错误推测法 | 经验补充 | 凭经验猜哪里容易出问题 |
二、等价类划分：把无限输入变有限
等价类的核心是：同一类数据，系统处理方式相同，测一个就够了。
分两类：
- 有效等价类：符合需求的合法输入
- 无效等价类：不符合需求的非法输入
以"登录用户名"为例，需求是"6-16位字母或数字"。
有效等价类：
1. 6-16位字母组合（如 zhangsan） 2. 6-16位数字组合（如 12345678） 3. 6-16位字母+数字组合（如 zhang123）无效等价类：
1. 少于6位（如 abc） 2. 超过16位（如 abcdefghijklmnopq） 3. 包含特殊字符（如 zhang@san） 4. 包含中文（如 张三123） 5. 包含空格（如 zhang san） 6. 空字符串每个等价类取一个代表值，就把"无数种输入"压缩成了 9 条用例。给新人的建议：拿到输入框先画等价类表，再写用例，别上来就填数据。
三、边界值分析：Bug 最爱藏在边界
经验表明，大量 Bug 发生在输入范围的边界上，而不是中间。所以等价类要配合边界值用。
边界值取三个点：
- 上点：边界上的值（刚好等于）
- 离点：离边界最近的无效值（刚好超出）
- 内点：范围内的任意有效值
以"密码长度 6-16 位"为例：
边界值用例：
1. 5位（离点，无效） 2. 6位（上点，有效，最小值） 3. 7位（内点，有效） 4. 15位（内点，有效） 5. 16位（上点，有效，最大值） 6. 17位（离点，无效）注意：6 位和 16 位是最容易出问题的——前端可能限制了 16 位但后端没限制，或者反过来。给老人的进阶点：边界值不仅测输入长度，还要测数值边界（金额 0、负数、超大值）、时间边界（月末、跨年、闰年 2 月 29 日）。
四、判定表：多条件组合不遗漏
当一个功能的输出取决于多个条件的组合时，用判定表。
以"会员折扣"为例：是否会员（是/否）+ 订单金额是否满 100（是/否），共 4 种组合。
判定表：
| 条件/规则 | 规则1 | 规则2 | 规则3 | 规则4 | |--------------|-------|-------|-------|-------| | 是否会员 | 是 | 是 | 否 | 否 | | 金额>=100 | 是 | 否 | 是 | 否 | |--------------|-------|-------|-------|-------| | 打8折 | 是 | 否 | 否 | 否 | | 满100减20 | 否 | 否 | 是 | 否 | | 无优惠 | 否 | 是 | 否 | 是 |4 条规则就是 4 条用例，所有组合全覆盖。如果有 3 个条件就是 8 种组合，4 个条件 16 种——条件多了可以合并不可能出现的规则（如"会员且非会员"）。
五、因果图：复杂逻辑先画图
因果图是判定表的前置工具。当条件之间有约束关系（比如"选了 A 就不能选 B"），先画因果图理清逻辑，再转判定表。
- 原因：输入条件（如"用户名正确"“密码正确”）
- 结果：输出动作（如"登录成功"“提示密码错误”）
- 关系：与（∧）、或（∨）、非（¬）
登录功能的因果关系：用户名正确与密码正确 → 登录成功；用户名错误或密码错误 → 提示对应错误。画清楚后，转成判定表就是完整用例。
六、场景法：跟着业务流程走
场景法适合测有完整流程的功能（如下单、支付、注册）。核心是：
- 基本流：最顺利的主路径（选商品→加购物车→下单→支付→成功）
- 备选流：主路径上的分支和异常（库存不足、支付失败、地址为空）
以电商下单为例：
场景用例：
基本流：选商品→加购物车→去结算→选地址→提交订单→支付成功 备选流1：加购物车时库存不足 备选流2：结算时地址为空 备选流3：提交订单时商品已下架 备选流4：支付时余额不足 备选流5：支付超时取消每条备选流就是一条测试场景。给新人的建议：画流程图，把每个判断节点的"否"分支都列出来，就是备选流。
七、错误推测法：经验的价值
前面五种是结构化方法，错误推测法靠经验。比如：
- 输入框粘贴超长文本会不会崩？
- 快速连续点击提交按钮会不会重复提交？
- 网络中断后重试会不会产生重复订单？
- 并发操作同一资源会不会数据错乱？
这是老测试的优势——踩过的坑多了，自然知道哪里容易出问题。建议把每次发现的 Bug 记录下来，形成自己的"错误推测清单"。
八、综合实战：注册功能怎么设计用例？
需求：手机号注册，手机号 11 位、验证码 6 位、密码 6-16 位字母数字组合、需勾选同意协议。
第一步：等价类+边界值覆盖输入：
手机号：11位有效 / 10位无效 / 12位无效 / 非数字无效 / 空 验证码：6位有效 / 5位无效 / 7位无效 / 错误验证码 / 过期验证码 密码：6位有效 / 16位有效 / 5位无效 / 17位无效 / 纯字母 / 纯数字 / 含特殊字符 协议：勾选 / 不勾选第二步：判定表覆盖组合：
手机号正确 + 验证码正确 + 密码合法 + 勾选协议 → 注册成功 手机号正确 + 验证码错误 + ... → 提示验证码错误 手机号正确 + 验证码正确 + 密码含特殊字符 → 提示密码格式 ...（关键组合全覆盖）第三步：场景法覆盖流程：
基本流：输入手机号→获取验证码→输入验证码→设置密码→勾选协议→注册成功 备选流：验证码倒计时未结束重复获取 备选流：验证码输入错误超过次数锁定 备选流：手机号已被注册第四步：错误推测补充：
快速连续点击"获取验证码"→是否限流 注册成功后返回上一页→是否重复提交 弱网下提交→是否超时友好提示这样一套下来，注册功能的用例就系统、完整、不遗漏了。
经验总结
给新人：
- 别上来就点，先花 10 分钟分析需求、画等价类和边界
- 用例要写清楚前置条件、步骤、预期结果，别人能看懂能执行
- 正常路径和异常路径比例大概 3:7，异常才是 Bug 高发区
给老人：
- 六大方法不是孤立的，实际工作中是组合使用（等价类+边界值打底，判定表/场景法补组合，错误推测补经验）
- 关注接口层和数据层的边界，前端限制了不代表后端限制了
- 建立自己的 Bug 库，每次复盘"这个 Bug 用哪种方法本可以提前发现"
口诀
等价分类省用例，边界值上找问题；
判定表穷举组合，因果图理清逻辑；
场景法走完流程，错误推测靠经验；
六法组合来使用，系统覆盖不遗漏。
觉得有用点个赞、关注一下，下一篇讲缺陷管理（Bug 生命周期、严重等级 vs 优先级、高质量缺陷报告怎么写）。
#软件测试 #测试工程师 #测试用例 #接口测试 #自动化测试 #测试实战 #测试入门
