需求评审与测试方案设计教程

你要让需求变得可实现、可验证、可验收

产品提出“用户支付后可以退款”，还不能直接写用例。你需要继续确认谁能退、何时能退、退多少、失败后怎么办，以及订单、支付记录和库存如何变化。

可执行步骤

1. 通读一遍，只标出角色、动作和结果。
2. 第二遍圈出金额、数量、时间、状态和权限词。
3. 画出登录→下单→支付→退款主流程。
4. 为每个节点补充失败、取消、超时和重复操作。
5. 把不能唯一判断结果的句子加入问题清单。

商城评审问题示例

把模糊描述改成验收标准

模糊：退款成功后更新订单。明确：当支付成功的订单发起整单退款且支付渠道受理时，退款单进入“处理中”；收到成功回调后，订单进入“已退款”，退款金额等于实付金额，库存按约定恢复。

商城风险排序

• P0：重复支付或超额退款，直接造成资金损失。
• P0：支付成功但订单仍待支付，造成履约和投诉。
• P1：优惠券边界计算错误，影响部分订单金额。
• P1：登录过期后提交未给出可恢复提示。
• P2：退款列表文案换行，功能仍可完成。

风险驱动用例

• 当用户连续点击支付时，只生成一次有效支付并只扣款一次。
• 当退款回调重复到达时，退款状态和金额只更新一次。
• 当支付金额与订单应付金额不一致时，系统拒绝入账并告警。

本次退款需求的范围示例

接口结果的统一判断

下面的创建订单和退款申请示例统一使用 HTTP 200。HTTP 200 只表示请求已被服务正常处理；仍要检查业务码是否成功，以及订单、支付和退款状态是否符合规则。

按工作拆分估算

1. 列出评审、用例设计、数据准备、执行、缺陷回归和报告。
2. 按 P0/P1/P2 风险估算用例与轮次，不按页面数拍脑袋。
3. 标出支付沙箱、测试账号、Mock、日志权限等依赖。
4. 预留联调变化和高风险缺陷回归时间。
5. 若时间被压缩，明确减少哪些范围以及残余风险。

小型迭代资源表

练习

1. 为“支付成功订单支持整单退款”列出 10 个评审问题。
2. 画出登录、下单、支付、退款的主流程和三条异常分支。
3. 列出 6 个风险并给出优先级与理由。
4. 分别写出本次测试、关联回归和不测范围。
5. 按单元、接口、集成和端到端设计测试策略。
6. 定义准入、准出和阻断发布条件。