4. 下单支付功能怎么测才能体现项目经验？
下单支付是业务测试里最能体现能力的场景之一。
因为它不只是页面点击，还涉及库存、优惠、订单、支付、状态流转、数据一致性和异常补偿。
一、先讲清楚业务链路
面试官问下单支付怎么测，不要直接罗列用例。
可以先说明完整链路：
- 用户选择商品；
- 确认规格和数量；
- 提交订单；
- 使用优惠券或积分；
- 选择支付方式；
- 支付成功；
- 订单状态更新；
- 库存扣减；
- 生成支付流水。
先把链路讲出来，说明你理解业务。
二、商品和库存是前置条件
下单前要关注商品状态：
- 商品正常上架；
- 商品已下架；
- 商品库存不足；
- 商品限购；
- 商品价格变化；
- 商品规格失效；
- 购物车商品失效。
库存相关要特别注意：
- 下单时扣库存还是支付时扣库存；
- 取消订单是否恢复库存；
- 支付超时是否释放库存；
- 多人同时购买最后一件商品如何处理。
这些是电商类系统常见高风险点。
三、订单金额要重点验证
金额计算是下单支付的核心。
需要验证：
- 商品单价；
- 商品数量；
- 优惠券金额；
- 满减规则；
- 积分抵扣；
- 运费；
- 实付金额；
- 小数精度；
- 退款金额。
比如满 100 减 20，要测试 99.99、100、100.01，还要看优惠后是否影响运费或积分抵扣。
四、提交订单要测重复和异常
提交订单时常见问题包括：
- 重复点击生成多个订单；
- 网络超时后前端提示失败但后台已生成订单；
- 库存不足仍然下单成功；
- 地址为空仍可提交；
- 优惠券过期仍可使用；
- 登录失效后仍可提交；
- 订单生成后金额和页面确认金额不一致。
这里要结合接口幂等、数据落库和状态一致性来测。
五、支付场景要覆盖成功、失败和超时
支付不能只测成功。
至少要覆盖：
- 支付成功；
- 支付失败；
- 用户取消支付；
- 支付超时；
- 支付中页面关闭；
- 支付成功但回调延迟；
- 支付成功但订单状态未更新；
- 重复支付；
- 支付金额被篡改。
真实项目中，支付回调和订单状态同步非常容易出问题。
六、订单状态流转要单独验证
订单状态一般包括：
- 待支付；
- 已支付；
- 已取消；
- 已发货；
- 已完成；
- 退款中；
- 已退款。
测试时要确认：
- 每个操作能否触发正确状态；
- 非法状态能否被拦截；
- 页面状态、接口返回、数据库状态是否一致；
- 支付流水和订单状态是否一致；
- 取消、退款、售后是否影响订单主状态。
七、数据库和接口要验证哪些点
下单支付建议重点看：
- 订单表是否生成订单；
- 订单明细表是否正确；
- 库存表是否扣减；
- 支付流水表是否生成记录；
- 优惠券使用状态是否更新；
- 用户积分是否扣减；
- 日志是否记录关键节点。
如果只是看页面显示“支付成功”，测试深度是不够的。
八、面试回答模板
可以这样回答：
测下单支付时，我会先梳理从选择商品、确认订单、使用优惠、提交订单、发起支付到订单状态更新的完整链路。用例上先保证主流程可用，再重点覆盖库存不足、商品下架、地址为空、优惠券失效、金额边界、重复提交、支付失败、支付超时、回调延迟和重复支付等异常场景。同时会通过接口返回、订单表、库存表、支付流水表和日志验证数据一致性，尤其关注订单状态、库存扣减和支付结果是否一致。
这个答案能明显体现项目经验。
九、下一步建议
下单支付建议重点准备三个追问：
- 如何防止重复下单？
- 支付成功但订单状态没更新怎么办？
- 库存什么时候扣减更合理？
配套刷题：