常见幂等测试方法

一、什么是幂等

一个幂等操作的特点是其任意多次执行所产生的影响与一次执行的影响相同。幂等性，通俗的说就是一个接口，多次发起同一个请求，必须保持操作只执行一次。

二、为什么要做幂等测试

2.1 影响用户体验

某种业务场景下，弱网/接口返回失败时，多次触发请求，会消耗多次特权，导致用户投诉

2.2 支付相关测试的严谨性

涉及金额、金融类相关的业务，必须考虑幂等严谨性，思之毫厘，差之千里，当用户量放大时，会给公司或者项目方带来的损失不可估量。

三、什么时候需要考虑幂等测试

3.1 同样的请求需要重试（或可能被重复调用）

例子1：
ERP、OA系统，在删除提交单据上传的附件，但因网络抖动等原因，响应延迟，用户反复点击删除按钮，导致一个请求把数据删除了，另一个请求去删除时没有数据导致报错。

例子2：
ERP、OA等业务系统在关闭单据时，重复两次点击关闭，进而在请求系统流程关闭接口时，并发请求两次导致生产环境产生脏数据

以上例子都可以在方案设计初期避免的，但因为忽略幂等的重要性，从而导致，在产品使用的过程中，投入时间和人力去排查此类问题同时也升级了用户的投诉情绪

3.2 支付/特权的消耗

要处理一次电商网站收款或者付款的交易。当你给微信支付发送这个付款请求后，一个顺利的场景不会有任何错误发送的，微信支付收到你的付款请求，处理所有转账，然后返回一个HTTP200消息表示交易完成。那如果发出请求后，有个请求超时，你再也没收到关于这个请求是否成功还是失败的回执，又该如何呢?

这里有很多种情况。
1）这个请求在到达微信支付前端就已经发生超时，微信支付从来没有收到这样的请求。
2）这个请求到达微信支付端，但支付交易失败，这时发生超时，微信支付收到这样的请求，但没有处理成功。
3）这个请求到达微信支付端，并且支付交易成功，这时发生超时，微信支付收到这样的请求，处理成功，但没有回执。
4）这个请求到达微信支付端，并且支付交易成功，并且发回绘制，然后因为网络原因回执丢失，客户端超时，微信支付收到这样的请求，处理成功，发出回执，但客户没有收到。

人们很直观的想法，也是实现中开发最常见的做法就是：重新提交一次支付请求。但是这样做有一个潜在的问题：请求超时是上面的哪一种情况，会不会引发多次支付的问题性？

四、幂等如何实现

4.1 幂等令牌

客户端和服务器通过什么方式来识别，这实际上是同一个请求或者同一个请求的多次尝试。这往往需要双方有一个既定的协议，比如账号单号或交易令牌，这种在同一个请求上具备唯一标识的元素，这种元素通常由客户端生成。

4.2 确保唯一性

服务器端用什么机制去确保同一个请求一定不会被处理两次，也是微信支付如何确保，同一笔交易不会因为客户端发送两次请求就被处理多次。

4.3 数据库的竞争条件

最常用的做法是利用数据库，比如把幂等令牌所在的数据库表的列作为唯一索引。这样，当你试图存储两个含有同样令牌的请求时，必定有一个会报错。注意，简单的读检查并不一定成功，因为读与读之间会有竞争条件（Race Condition），因此还是有可能出错。

五、常见测试方式

5.1 前端重复快速点击，可能会重复提交单据（用UI自动化容易复现）

以电商系统为例，通过前端”下单“按钮，反复请求接口，在接口没做校验时，可以生成两个相同的单据

复现方式：手动鼠标快速点击多次/通过UI自动化脚本实现

解决措施：
在点击单据”下单“按钮后，页面新增loading效果，防止再次点击按钮

5.2 网络重试，比如：在扫码支付时，商户在扫码时，先断网扫码一次在重连扫码

5.3 对同一笔业务并发请求，比如接口并发请求

通过postman或者其他接口调用工具，对接口实现并发请求，查询数据库或者接口响应是否生成多条数据