7. 重复消费和幂等性怎么测试
重复消费和幂等性，是 MQ、支付、订单、库存、优惠券、接口防重复提交中非常重要的测试点。很多系统使用消息队列后，消息并不一定只被消费一次。由于网络抖动、消费者异常、重试机制、支付回调重复、接口超时重发等原因，同一业务事件可能被处理多次。如果系统没有幂等设计，就可能出现重复扣库存、重复发优惠券、重复生成订单、重复退款、重复发送通知等严重问题。
面试中问“重复消费和幂等性怎么测试”，测试岗位要能讲清楚：什么是幂等，哪些业务必须幂等，重复消息怎么构造，怎么验证数据库和业务结果，如何判断重复处理是否造成副作用。这个问题非常能体现测试深度。
一、什么是幂等性
幂等性指同一个操作执行一次和执行多次，最终结果应该一致。
例如支付回调：同一笔订单支付成功消息可能重复到达，但订单只能从待支付变为已支付一次，支付流水不能重复生成，优惠券不能重复发放。
不是所有接口都天然幂等。查询接口通常是幂等的；创建订单、支付、扣库存、发券、退款等操作必须特别设计幂等。
二、为什么会重复消费
常见原因：
- MQ 消费失败后重试；
- 消费者处理成功但确认消息失败；
- 支付平台重复回调；
- 客户端超时后重试请求；
- 用户重复点击按钮；
- 定时任务重复执行；
- 服务重启导致消息重新投递；
- 网络抖动导致发送方不确定是否成功。
所以重复不是异常中的小概率事件，而是必须考虑的正常风险。
三、哪些业务要重点测幂等
1. 支付回调
同一支付成功回调多次到达，不能重复更新、重复发货、重复发券。
2. 创建订单
用户重复点击提交订单，不能生成多笔重复订单。
3. 扣库存
重复消费库存消息，不能重复扣减。
4. 发优惠券
同一活动奖励只能发一次。
5. 退款
重复退款请求不能导致多次退款。
6. 定时任务
同一批任务不能重复处理同一数据。
四、重复消费测试基本思路
可以按这个流程：
- 准备唯一业务 ID，例如订单号、支付流水号、消息 ID；
- 执行一次正常操作；
- 记录数据库状态和业务结果；
- 重复发送相同请求或消息；
- 再次查看数据库、流水、库存、优惠券等；
- 验证最终结果只生效一次；
- 查看日志是否识别重复处理。
核心不是看接口是否返回成功，而是看副作用是否重复发生。
五、项目场景：支付回调幂等
测试步骤：
- 创建待支付订单；
- 模拟支付成功回调；
- 验证订单变为已支付；
- 验证支付流水生成一条；
- 再发送同一支付回调；
- 验证订单状态仍为已支付；
- 支付流水没有新增重复记录；
- 优惠券、积分、通知不重复发放；
- 日志中记录重复回调已忽略。
这是最典型的幂等测试。
六、项目场景：重复提交订单
测试方法：
- 页面快速双击提交按钮；
- Postman 连续发送两次相同请求；
- 自动化并发请求；
- 模拟网络超时后重试。
验证点：
- 是否只生成一笔订单；
- 库存是否只扣一次；
- 优惠券是否只锁定一次；
- 支付单是否只创建一次；
- 第二次请求是否返回重复提交提示。
七、项目场景：MQ 重复消费
如果是 MQ 消息，可以使用相同 messageId 或业务 ID 重复投递。
验证：
- 消费者是否根据业务唯一键去重；
- 数据库是否有唯一约束；
- 是否记录消费状态；
- 重复消息是否直接跳过；
- 是否误报失败导致无限重试。
常见幂等方案包括业务唯一键、状态机判断、去重表、唯一索引、分布式锁等。测试不需要实现，但要知道验证点。
八、状态机和幂等
订单状态流转可以帮助防重复。例如订单已支付后，再收到支付成功消息，不应再次处理，只能识别为重复。
测试要验证：
- 待支付 -> 已支付，允许；
- 已支付 -> 已支付，重复忽略；
- 已取消 -> 已支付，是否拒绝；
- 已退款 -> 已支付，是否异常。
状态机测试能覆盖很多幂等问题。
九、幂等性常见 Bug
- 重复支付回调生成多条流水；
- 重复点击生成多笔订单；
- 重复消息导致库存扣两次；
- 重复发放优惠券；
- 重复退款；
- 第二次请求返回成功但实际重复处理；
- 幂等 key 过期太短导致重复生效；
- 只前端防重，后端未防重。
前端按钮置灰不是可靠幂等，后端必须防重复。
十、面试回答模板
如果面试官问“重复消费和幂等性怎么测试”，可以这样回答：
幂等性指同一个业务操作执行一次和多次，最终结果保持一致。测试时我会选择支付、下单、扣库存、发券、退款这类有副作用的场景，使用相同订单号、支付流水号或 messageId 重复发送请求或消息，然后验证数据库、流水、库存、优惠券和状态只变化一次。比如支付回调幂等测试中，我会重复发送同一支付成功回调，验证订单只从待支付变为已支付一次，支付流水不重复生成，优惠券和通知不重复发放。对于 MQ 重复消费，还会验证消费者是否有去重、唯一键、状态判断或重试机制。
十一、常见追问
追问：前端按钮防重复够不够？
不够。前端只能减少误操作，后端必须做幂等，因为接口可被重复调用，消息也可能重复投递。
追问：怎么构造重复消费？
重复发送同一请求、重复支付回调、重复投递相同消息、并发请求或模拟超时重试。
追问：幂等通过什么验证？
看业务最终结果和数据库副作用是否只发生一次，比如订单、流水、库存、优惠券记录。
追问：重复消息应该返回失败吗？
不一定。很多系统会返回成功但内部忽略重复处理，关键是不能重复产生副作用。
十二、练习清单
- 准备支付回调幂等案例；
- 准备订单重复提交案例；
- 准备库存重复扣减案例；
- 重复发送相同请求；
- 并发发送相同请求；
- 检查数据库唯一记录；
- 检查状态流转；
- 检查日志去重记录；
- 验证前端防重和后端幂等区别；
- 准备幂等性面试回答。
重复消费和幂等性测试的核心是验证副作用是否只发生一次。凡是涉及钱、库存、权益、状态流转的业务，都要重点测试幂等。
配套刷题：
