下单支付测试案例¶

下单支付是电商系统中风险最高的流程之一。测试时要关注订单状态、库存、金额、支付回调、超时取消和重复支付。

需求背景¶

用户从购物车选择商品提交订单，订单创建后进入待支付状态。支付成功后订单变为已支付，库存扣减。超过 30 分钟未支付，订单自动取消。

测试点拆解¶

维度	测试点
订单创建	单商品、多商品、不同收货地址、备注
金额	商品金额、优惠券、运费、实付金额
库存	下单扣减、支付扣减、库存不足
支付	支付成功、支付失败、取消支付、重复支付
回调	回调成功、重复回调、回调延迟、回调验签失败
状态流转	待支付、已支付、已取消、退款中、已退款
超时	30 分钟未支付自动取消
异常	网络中断、页面关闭、第三方支付返回异常

用例示例¶

编号	测试点	步骤	预期结果
ORDER-001	正常下单	购物车选择商品，提交订单	订单创建成功，状态为待支付
ORDER-002	使用优惠券	选择可用优惠券后提交订单	实付金额正确，优惠券被锁定或使用
ORDER-003	库存不足	下单前将库存改为不足	下单失败，提示库存不足，不生成有效订单
ORDER-004	支付成功	待支付订单完成支付	订单状态变为已支付，支付流水生成
ORDER-005	重复支付	支付成功后再次发起支付	不允许重复支付或返回订单已支付
ORDER-006	回调重复	模拟支付平台重复回调	订单状态保持正确，不重复扣款、不重复发货
ORDER-007	超时取消	待支付订单超过 30 分钟未支付	订单自动取消，库存释放

数据校验¶

至少检查这些数据：

订单表金额是否正确。
订单状态是否按流程流转。
支付流水是否唯一。
库存是否扣减或释放。
优惠券状态是否正确。
重复回调是否没有产生重复数据。

测试数据准备¶

数据	用途
正常用户	验证创建订单和支付流程
库存充足商品	验证正常下单
库存不足商品	验证失败下单
可用优惠券	验证金额计算
待支付订单	验证支付成功、取消、超时
支付沙箱或 Mock 回调	验证支付结果和回调幂等

支付场景尽量使用沙箱或 Mock，不要在真实支付环境里反复试错。

执行步骤示例¶

下单前查询商品库存和用户优惠券状态。
从购物车提交订单，记录订单号和应付金额。
查询订单表、订单明细表、库存表，确认状态和金额正确。
使用沙箱完成支付或模拟支付成功回调。
再次查询订单状态、支付流水和库存。
重放同一支付回调，确认不会重复扣款或重复发货。
创建一笔待支付订单不支付，验证超时取消和库存释放。

接口与 SQL 校验示例¶

POST /api/orders
POST /api/pay
POST /api/pay/callback
GET  /api/orders/{orderId}

SELECT id, user_id, status, total_amount, pay_amount
FROM orders
WHERE id = 10001;

SELECT order_id, product_id, quantity, price
FROM order_items
WHERE order_id = 10001;

SELECT order_id, pay_status, transaction_no
FROM payment_records
WHERE order_id = 10001;

缺陷示例¶

字段	内容
标题	支付平台重复回调导致重复生成支付流水
前置条件	订单已支付成功，支付平台回调报文可重放
复现步骤	对同一订单连续发送两次支付成功回调
实际结果	系统生成两条成功支付流水
期望结果	第二次回调识别为重复通知，不改变订单和流水结果
影响	对账异常，存在重复发货或财务风险

容易漏测¶

支付成功但订单状态未更新。
订单取消后库存没有释放。
回调重复导致状态重复变更。
金额计算只看页面，不校验数据库。
优惠券使用失败但订单仍按优惠价生成。

复盘问题¶

库存应该在下单时扣，还是支付成功时扣？
支付回调为什么要做幂等？
如果支付成功但系统没有收到回调，应该怎么补偿？