用例流是什么
用例流把一条业务功能拆成：前置条件、触发、主成功流、备选流、异常流、后置状态。测试设计按「一个主流程加多个分支」组织，保证不是只测顺利路径。它与场景法配合使用：场景定故事线，用例流定分支覆盖。
基本信息
| 结构六件套 | 前置、触发、主流程、备选流、异常流、后置状态 |
|---|---|
| 主流程 | 一切顺利的最短闭环，必测并作为冒烟核心 |
| 备选流 | 合法但非主线的分叉：换支付方式、改地址 |
| 异常流 | 错误处理路径：余额不足、超时、重复提交 |
| 与状态机的关系 | 每步动作改变业务状态，流转要对状态表核对 |
| 产出 | 用例标题即 对象_条件_预期，来自每条流 |
流程解剖示例
流程解剖示例
用例：提交订单
前置：已登录且购物车非空
主流程：结算 -> 选地址 -> 选支付 -> 提交 -> 订单创建成功
备选流：改用货到付款 -> 提交成功
异常流：余额不足 -> 提示并保留购物车；支付超时 -> 订单待支付可重试
后置：订单状态=待支付，库存扣减，生成支付流水典型使用场景
- 新功能用例设计：按流逐条展开防漏分支
- 需求评审：把「如果……会怎样」的问题问全
- 自动化分组：主流程做冒烟，备选与异常流进回归集
- 缺陷定位：先确定失败发生在哪条流，再缩小范围
- 新人理解业务：读流程文档比翻页面更快
流类型与覆盖要点
| 流类型 | 覆盖要点 | 断言什么 |
|---|---|---|
| 主流程 | 最短闭环必测 | 业务结果与状态 |
| 备选流 | 每个合法分叉 | 分支后结果一致性 |
| 异常流 | 每个错误码路径 | 提示、状态、数据回滚 |
| 后置状态 | 数据与下游联动 | 库存、流水、通知 |
每条异常流都要有可观察的结果：提示语、订单状态、日志三者至少占其一，否则无法断言。
备选流多的功能要防组合爆炸：挑高价值组合覆盖，不必做笛卡尔积全测。
流程文档要随需求更新：流程改了用例照旧，回归就是在验证过时需求。