测试用例设计实战教程
不要从“我要写多少条用例”开始，而要先回答“这个业务可能在哪里出错”。
先看懂这次要测试的下单规则
需求不是用例你要测试的业务
用户购买 1～5 件商品，填写收货地址，可以使用“满 100 元减 20 元”优惠券，然后提交订单。系统只有在库存足够、地址有效时才能创建订单，同一次提交不能产生重复订单。
把一句需求拆成可以追问的规则
| 对象 | 已知规则 | 还要问清楚 |
|---|---|---|
| 商品数量 | 每次下单 1～5 件 | 0、1、5、6 件时系统如何处理？ |
| 库存 | 库存不少于购买数量才可下单 | 校验时库存变化怎么办？ |
| 优惠券 | 订单满 100 元减 20 元 | 正好 100 元是否可以使用？ |
| 收货地址 | 姓名、手机号和详细地址必填 | 格式错误后已填内容是否保留？ |
| 重复提交 | 同一次确认只能创建一笔订单 | 连续点击和请求重试是否幂等？ |
从业务流程中提取测试点
先覆盖风险先沿着用户操作向后追踪：页面收到了什么输入，系统执行了哪些规则，哪些数据发生了变化，失败后又要恢复什么。
输入
数量、地址、优惠券
规则
库存、金额、资格
数据
订单、库存、券状态
异常
超时、重试、重复提交
从输入找测试点
- 商品数量是否合法。
- 地址必填项和格式是否正确。
- 优惠券状态和使用门槛是否满足。
- 重复点击是否被识别为同一次提交。
从结果找测试点
- 页面提示和订单金额是否正确。
- 订单是否只创建一次。
- 库存是否按购买数量扣减。
- 失败时订单、库存和优惠券是否保持原状。
用等价类减少重复测试
同类选代表什么时候使用等价类
当一组输入会触发相同的处理规则时，不需要把每个值都测一遍。可以把它们分成有效类和无效类，再从每一类选择有代表性的数据。
为商品数量划分等价类
| 类别 | 范围 | 候选数据 | 选择方式 |
|---|---|---|---|
| 有效类 | 1～5 件 | 1、3、5 | 选择 3 件作为普通有效数据 |
| 无效类 | 小于 1 件 | 0、-1 | 选择 0 验证最常见非法输入 |
| 无效类 | 大于 5 件 | 6、20 | 选择 6 验证刚刚超限 |
| 无效类 | 非整数 | 1.5、文本、空值 | 分别验证类型和必填校验 |
用边界值盯住最容易出错的位置
边界前后都要测程序常在“大于还是大于等于”“从 0 还是从 1 开始”这些位置出错。找到规则的分界线，再检查边界值本身和它前后的值。
下单业务中的边界数据
| 边界 | 测试数据 | 预期判断 |
|---|---|---|
| 最小值附近 | 0、1、2 | 0 被拒绝；1、2 可以进入库存校验 |
| 最大值附近 | 4、5、6 | 4、5 可以购买；6 被拒绝 |
| 优惠门槛附近 | 99.99、100.00、100.01 | 门槛前不可用，达到门槛后可用 |
| 库存临界点 | 购买数 = 库存 - 1、库存、库存 + 1 | 足量成功，超量失败且不扣库存 |
用判定表覆盖规则组合
条件组合不遗漏库存和地址会共同决定下单结果
只看单个条件，很容易漏掉“库存不足并且地址也错误”这样的组合。判定表把条件写在上半部分，把每种组合对应的动作写在下半部分。
库存与地址判定表
| 条件或动作 | 规则 1 | 规则 2 | 规则 3 | 规则 4 |
|---|---|---|---|---|
| 库存足够 | 是 | 是 | 否 | 否 |
| 地址有效 | 是 | 否 | 是 | 否 |
| 创建订单 | 是 | 否 | 否 | 否 |
| 提示地址错误 | 否 | 是 | 否 | 是 |
| 提示库存不足 | 否 | 否 | 是 | 是 |
用状态迁移检查订单流转
不仅看当前结果订单不是一个静止的数据记录。创建、支付、取消和完成都会改变状态，而且不是任意两个状态之间都能直接跳转。
合法迁移
- 待支付 → 已支付：支付成功。
- 待支付 → 已取消：用户主动取消或超时关闭。
- 已支付 → 已完成：履约完成并确认收货。
非法迁移
- 已取消订单不能再次支付。
- 已完成订单不能回到待支付。
- 同一支付通知重复到达不能重复改变状态。
把正常流程和异常流程连起来
按真实路径执行成功创建订单
修改后继续提交
安全失败并恢复
基本流
选择商品 → 填写地址 → 使用优惠券 → 提交订单 → 创建成功。
备选流
不使用优惠券、修改购买数量、切换地址后仍能正确提交。
异常流
库存不足、优惠券失效、接口超时或重复提交时，系统安全失败并给出下一步。
异常之后还要继续检查
- 用户能否修改数据后重新提交。
- 请求超时后再次提交会不会产生重复订单。
- 失败操作有没有错误扣减库存或占用优惠券。
- 页面提示是否告诉用户问题和处理方式。
把测试点写成别人能执行的用例
条件、动作、结果用例标题统一使用“当……时，……”
“当”后面写清触发条件，“时”后面写操作或系统应该表现出的结果。例如：当库存少于购买数量时，提交订单失败。
一组可以直接执行的商城下单用例
| 优先级 | 用例标题 | 前置条件 | 关键预期 |
|---|---|---|---|
| P0 | 当库存等于购买数量且地址有效时，订单创建成功 | 库存 3；购买 3 件；地址有效 | 只创建一笔订单，库存变为 0，金额正确 |
| P0 | 当库存少于购买数量时，提交订单失败 | 库存 2；购买 3 件 | 提示库存不足，不创建订单、不扣库存 |
| P0 | 当连续点击两次提交时，仅创建一笔订单 | 库存充足；地址有效 | 两个请求对应同一业务结果，只扣减一次库存 |
| P1 | 当订单金额正好为 100 元时，满减券生效 | 100 元订单；满 100 减 20 券 | 实付 80 元，优惠明细正确 |
| P1 | 当订单金额为 99.99 元时，满减券不可用 | 99.99 元订单；满 100 减 20 券 | 提示未达到门槛，实付金额不变 |
| P1 | 当手机号少于 11 位时，订单无法提交 | 手机号 10 位 | 定位手机号错误，其他地址内容保留 |
| P1 | 当创建订单接口超时后重试时，不会生成重复订单 | 首次请求结果未知 | 查询或重试后仍只有一笔订单 |
| P1 | 当优惠券已过期时，订单按原价创建 | 库存和地址有效；券已过期 | 明确提示不可用，金额按原价计算 |
| P2 | 当备注为空时，订单可以正常创建 | 未填写备注 | 订单成功，备注保存为空 |
| P2 | 当备注达到最大长度时，内容完整保存 | 备注达到允许上限 | 不截断、不溢出，订单成功 |
检查优先级、覆盖和可执行性
写完不是结束立即阻断发布
本轮应完成
结合时间安排
优先级是否准确
- P0：交易中断、资金错误、重复订单和核心数据损坏。
- P1：主要业务规则、常见异常和重要边界。
- P2：低频输入、非核心体验和弱影响场景。
- 不要为了满足固定比例而调整真实风险等级。
是否覆盖所有测试点
- 每条需求规则至少有一条对应验证。
- 有效、无效和边界数据都有覆盖。
- 关键条件组合没有遗漏。
- 合法与非法状态迁移都有覆盖。
- 异常后数据一致性和恢复路径已检查。
这组 10 条用例的分布
比例用于观察用例结构，不是必须达到的配额。业务风险变化后，用例比例也应该跟着变化。
都映射到用例
有效、无效、边界
关键条件不遗漏
合法与非法流转
别人可以直接执行
独立完成一轮用例设计
交付可执行结果练习：新增“会员积分抵扣”规则
- 补充规则：100 积分抵扣 1 元，每单最多抵扣订单金额的 20%。
- 列出需要向产品确认的问题和可能的业务风险。
- 分别使用等价类、边界值和判定表提取测试数据。
- 补充积分冻结、扣减、退回涉及的状态变化。
- 按“当……时，……”格式编写不少于 12 条用例。
- 标记优先级，并说明每条 P0 用例阻断发布的理由。
- 建立测试点与用例的对应关系，确认没有遗漏。
需求已拆清
- 对象和规则明确
- 边界和异常明确
- 状态变化明确
- 数据影响明确
方法选得对
- 输入用等价类
- 数值用边界值
- 组合用判定表
- 流转用状态迁移
用例可交付
- 标题通俗可执行
- 前置数据明确
- 预期结果可验证
- 优先级有依据
下一步：测试设计方法地图
掌握常见业务用例设计后，你可以继续把更多方法放进同一张地图，根据问题类型选择工具，而不是机械套用固定模板。
掌握基础方法后，继续使用测试设计方法地图，根据不同业务风险选择更合适的设计技术。
继续学习测试设计方法地图