接口测试思路-接口幂等

接口测试思路-接口幂等

什么是接口幂等

例如：

1.电商平台中的支付接口，针对同一个订单只能支付一次，且不能因为多次提交支付请求（因网络卡顿、延迟等）就多次扣款

2.电商平台中的订单创建接口，例如从购物车中勾选指定几个商品后，重复点击去结算，只会创建一个订单，而不会同时创建多个订单，同理，库存扣除逻辑也是如此。

3.微信中的抢红包，抢一次就不能再抢了，不会因为多次点击，而多次获取同一个红包里的金额

幂等原先是数学中的一个概念，指的是进行1次变换和N次变换产生的效果相同，在接口中可以理解为：以相同的请求调用同一个接口一次或者多次，其产生的效果是一致的。

接口幂等与防止重复提交的区别：

​ 区别在于针对的阶段不一样，防止重复提交是在客户端限制用户多次重复提交信息，例如：注册页面/发送验证码/提交订单按钮等。而幂等针对的是重复请求已经发生或者无法避免的情况下，采用技术手段来保障这些重复请求不会给系统带来负担。

实现接口幂等的几种方案

解决办法分为两个方向，一个方向是客户端防止重复调用，一个是服务端进行校验。当然，客户端防止重复提交并不是绝对可靠的，优点是实现起来比较简单。在我们设计幂等接口时重点关注新增接口和更新接口。因为查询和删除操作天生是幂等的（根据id查询和根据id删除多次对系统的影响是一致的），不需要我们提供额外的技术手段来保证幂等性。

1. 按钮只可操作一次

提交后把按钮置灰或者loding状态，消除用户因为重复点击而产生的重复记录。比如微信的抢红包，点击的过程中是loding状态，无法再点击，且抢过一次之后，抢红包的按钮就不会再出现

2. tooken机制

token机制的核心思想是为每一次操作生成一个唯一性的凭证。功能上允许重复提交,但要保证重复提交不产生副作用,比如点击n次只产生一条记录,具体实现就是进入页面时申请一个token,然后后面所有的请求都带上这个token,后端根据token来避免重复请求。

3. 使用Post/Redirect/Get模式

在提交后执行页面重定向,这就是所谓的Post-Redirect—Get(PRG)模式,简单来说就是当用户提交连表单后,跳转到一个重定向的信息页面,这样就避免用户按F5刷新导致的重复提交,而且也不会出现浏览器表单重复提交的警告,也能消除按浏览器前进和后退导致同样重复提交的问题。

4.唯一序列号

比如通过source来源 + 唯一序列号传入给后端，后端来判断请求是否重复,在并发时只能处理一个请求,其他相同并发请求要么返回请求重复,要么等待 前面请求执行完成后再执行。

当调用接口时，参数中必须传入source字段和seq字段（并不一定要传两个字段，传一个唯一的序列号uuid也能达到一样的效果）。服务端接收到请求，先判断自己是否是一个幂等接口，如果不是幂等接口就正常处理请求。

如果是一个幂等接口，就将source和seq组成联合主键去数据库表中或者是Redis中查询，如果没有查询到，说明没处理过这个请求，然后正常处理请求就行了。处理完之后将处理结果和source和seq信息一个存入数据库或Redis中。

如果根据source和seq能查询到，说明已经处理过这个请求了，直接将处理的结果返回即可。

5.唯一索引

这种方案适合用于执行新增操作的接口。

比如说新增用户接口。我们将用户表中的身份证字段加上唯一索引。当同一个请求调用两次时，我们可以先根据身份证字段查询下用户是否存在，不存在的话再新增。存在的话就返回新增失败。
或者直接新增也行，数据库会抛异常，我们对异常处理返回前台就行了。

6.乐观锁

这种方案适用于执行更新操作的接口。

乐观锁只是在更新数据那一刻锁表，其他时间不锁表，所以相对于悲观锁，效率更高。 我们一般通过数据库来实现乐观锁，比较通用的做法是增加一个时间戳字段。

7.缓冲队列

将请求都快速地接收下来后放入缓冲队列中,后续使用异步任务处理队列中的数据,过滤掉重复的请求,该解决方案优点是同步处理改成异步处理、高吞吐量,缺点则是不能及时地返回请求结果,需要后续轮询得处理结果。

还有很多解决接口幂等的方案，就不一一列举了，想要了解更多的可以点下方链接，查看原文。
参考文章：

https://www.cnblogs.com/54chensongxia/p/12598944.html
https://bbs.huaweicloud.com/blogs/261667