接口测试 资金的 bug 怎么测?怎么防资损?

chen_sen · 2018年01月04日 · 最后由 andrew-qiu 回复于 2018年03月04日 · 3626 次阅读
本帖已被设为精华帖!

上次介绍了一些常见的影响资金的bug,由于篇幅原因,没有全部写完,这次接着来介绍资金相关还有可能出现bug的地方,当然,操作方式跟之前介绍的也略微不同。

前文:接口测试除了功能,还有安全

1、欺骗充值

充值指的是向应用程序充钱到自己的账号,欺骗充值指的就是欺骗应用程序说自己已经充值成功了,让自己的账号没有经过实际支付就增加余额。下面以小程序为例,来讲下怎么做到欺骗。

首先,看下小程序支付交互的流程:

小程序支付交互图
↑↑小程序官方交互图↑↑

从上图可以看出,支付状态是由微信后台通知商户系统后,再由商户系统更新状态的。根据官方推荐的做法一般不会出什么幺蛾子,但是有些初学者不按套路来,直接在小程序收到支付结果中的回调函数中调用后端接口进行更新状态(小程序回调没有上图中画出),这就留下了祸根了。

我们可以尝试在发起支付接口后,不进行真实支付,通过模拟回调函数中调用的接口直接调用,看看订单的状态是否改变,如果真的改变了,余额新增了,那么恭喜你,找到一个大bug了。这种系统不是新手就是临时工开发的,毕竟这类bug现在已经少而又少,比较常见的案例是0.01元充100话费。

2、超领红包

什么是超领?正常的话,一个拼手气红包每个人只可以领取一次,超领就是一个拼手气红包被一个人领了多次。这类bug分为两种,下面来说说怎么找:

第一种是比较低级的:用户能不能领取全由前端控制,后端不做校验,交互图如下:

从UI上看,找不出不出什么bug来,但是从接口上就很容易绕过,每次直接调用领取红包接口,就能实现不断的领取红包了。

这么来说,是不是后端加上校验就行了?话是这么说,但是也要看是怎么个校验法,如果是单纯在领取结果前的查下数据库是否领取就算校验的话,那就要留个心眼了。交互如下:

现在开始介绍第二种稍微高级一丢丢的超领方法:那就是并发请求。同时发起10个甚至100个请求,领取同一个红包,所有并发请求同一时间到达数据库判断的时刻,判断结果都是没有领取过,这样有概率再一次实现超领了。(怎么发起并发就不用做过多介绍了吧?)

这里,我推荐的是在数据库中的红包领取表中添加唯一约束,将红包id与领取人id设置为为唯一约束,这样插入领取信息的时候,数据库就会报错拉。当然我只是测试,没有实战过,有经验的开发者可以留言推荐更好的解决方法。

3、超额提现&并发提现

其实超额提现&并发提醒这两类bug是跟上面介绍的红包超领如出一辙的,只是场景不同而已。

超额提现的问题是出在:只由前端限制可提现金额,后端没有做任何校验,导致调用提现接口就能直接超额提现。

并发提现就是后端做了校验的前提下,通过并发同时调用提现接口100次,校验做的不好,公司的实际金额就这样被盗走了。

关于异常提现,我建议的是追加两种方案来应对:

  • 加至少24小时的审核机制:这样就可以在审核期间检查是否有异常提现数据了。
  • 自动对账机制:通过人工来审核是不合理的事,系统应该是要每天自动检查出入账金额是否正确,有异常及时告警,避免造成资金损失。

看到这,各位可以去试一试自家的产品是否有被并发超领的情况咯,场景不限于:领红包、抽奖、提现等。

如果你有其他奇招,欢迎一起交流。

共收到 13 条回复 时间 点赞

这些问题都是接口测试层面能发现的

jacexh 回复

是的,专从接口入手,寻找一些常见设计缺陷的bug

Lihuazhang 将本帖设为了精华贴 01月05日 07:31

希望多多介绍这方面的知识,非常好。

pacerron 回复

一起交流学习学习

多个并发的时候,我这边测试主要是看代码有没有加锁,是否锁定该红包的状态;性能要求高一些是使用队列,将并发消息缓存后一条一条处理。
PS:新手开发还应该关注线程安全,我隔壁项目组一开发在处理并发的时候,全局变量被重写,导致订单数据严重错误,直接被开除了……

记得之前开发用了一个github上开源的支付模块,信用卡支付的状态逻辑上测出来一个漏洞,然后开发解了还发了pr~有惊无险

Innocence 回复

我个人认为,责任并不在开发其本身,个人见解仅限参考:

1.这样的人,基础知识不足,怎么被招进来的
2.开发团队没有代码review直接上线?
3.测试为什么没有测出来
4.测试不对核心计算方法做代码检查吗?

直接开除这种粗暴的做法,既害了这个小伙子,公司也有损失。

siwen 回复

你这样的就是牛逼,嗯,牛逼

虽然不符合设计原则和编码规范……但是我还是以切身经历告诉大家:
对涉及资金的事物的测试,一定要关注catch exception之后的行为,尝试各种断网、down库的操作,对数据一致性和事物完整性做一切可能的检查测试……几千万重复支付的教训,虽然不是我亲手测的😂

这帖子很及时啊,前几天腾讯视频刚刚出了个0.2元开通VIP的bug,我猜可能的原因是在测试环境为了测试方便,把钱改成了0.2,上生产环境的时候忘记改了。

感谢分享

防御性编程和原子化事务;互联网全局的容忍失败重试又不包括扣钱的功能。。。

个人觉得,测试应该把后端接口、前端逻辑进行分层开来,一般来说前端校验为了用户体验、后端校验为强行校验。这样,对照产品需求来看,你说的那些逻辑漏洞其实很容易发现

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册