一、梳理支付业务流程：

点击支付---> 选择支付方式 ---> 确认金额---> 输入密码 ---> 成功支付

完成这个流程测试，也就完成了项目的冒烟测试，然后需要测试针对流程中的每个阶段和步骤，具体分析可能导致异常的测试点，所以我们按阶段和输入项来进行划分，如下：

（一）下单支付

1）点击支付，提交订单但是取消了，检查可以取消成功

2）选择支付方式：

正常：可以支持的支付方式有：信用卡，储蓄卡，网银支付，余额，第三方支付（微信，支付宝，京东、百度、聚合支付、组合支付），找人代付，验证是否支持并且可以正常选择并支付；

异常: 没有绑定任何的支付方式时，支付报错。

**功能交互：**支付时结合优惠券/折扣券/促销价抵扣进行相关的抵扣，验证规则正确，并且可以正常抵扣和支付。

3）确认支付金额：这个步骤可以用到等价类和边界值的用例设计方法

正常：正常金额里用边界值法去测试点：

最大支付金额（单日最大，单笔最大，余额最大）
最小支付金额

异常：同样也用边界值方法提取测试点：

超过支付方式单日最大消费金额/单笔最大/余额最大 异常金额支付：非数字、负数、0，小数点超过 2 位等

4）支付密码：

正常：可以支持的支付密码类型有：指纹，人脸识别，账号密码，动态获取验证码，手势，信用卡和支付码，小额免密等，确认自己的产品所支持的密码类型，确认可以验证并支付成功；

异常：输入错误的密码，检查有无提示信息且正确；超过密码错误上限，检查是否冻结等。

5）其他场景测试点：

a、多笔订单合并支付，是否可以成功；

b、重复点击支付按钮，是否会出现多次购买，并同步检查数据库的数据帐账目正确；

c、支付中断：

主动中断：可以继续支付并成功 被动中断：比如电话、低电量、闹钟，断网、切换后台、耳机插拔等，验证可以继续支付；

d、网络测试：

验证各种网络类型：2G、3G, 4G，5G，wifi 下都可以正常支付； 进行网络切换，支付功能正常； 弱网测试下支付功能正常：不会重复支付多次，APP 不会闪退 崩溃，而且页面提示友好；

e、使用 fiddler 等抓包篡改价格：不允许抓包或者数据加密，篡改不成功

（二）退款流程

验证正常的退款流程，也就是退款的冒烟测试：

1. 点击退款可以退款成功，并且检查交易状态是退款，退款金额可以到账；
2. 结合优惠券等抵扣，可以退款实际支付金额；
3. 同步检查数据库的数据和账目是正确的；

异常：提交错误退款（退款订单号不对），或者退款金额错误，都能够退款失败（此处一般会借助工具进行测试，比如进行接口测试）；

（三）测试方法

那么以上的测试点在具体公司项目中要怎么进行测试呢？我们有不同的一些测试方法：

1） 小额支付：

需要让开发修改代码，不管支付多少钱，实际支付都是 1 分钱；不顾这种方法只能测试小额支付，就有可能会出现产品小额支付没问题，但是大额支付就错误的漏测情况；

这种方式一般会作为小额支付的一种补充，比如测试完小额支付后，再测试一些大额支付，这就需要跟公司申请测试基金，走报销流程；

2）沙箱支付：

沙箱支付是一种虚拟的支付，不是真实的金额；这种方法可以验证小额和大额的支付流程；不过目前只有支付宝沙箱比较成熟可用，其他的支付方法不可用。

（四）非功能测试点

测试完以上的功能测试点之后，我们还需要验证一些非功能测试点，主要包括以下几个方面：

1）界面

验证界面的美观，排版和错别字等。

2）兼容性

**BS：**如果是 BS 架构的产品，需要测试跟浏览器的兼容性；所以就需要根据浏览器的内核，选择一些主流的浏览器进行测试；

CS：如果 CS 架构的产品，测试手机移动端的兼容，比如手机型号，系统版本和屏幕大小及分辨率等。

3）易用性

测试站在用户的角度考虑用户体验，使用是否方便等。

4）性能

比如考虑多用户支付，长时间运行等，关注产品的响应时间等，一般需要借助工具或者代码进行测试。

5）安全

验证敏感信息是否加密，是否可以篡改；通过一些工具进行安全扫描，检查是否有安全漏洞；或者采用一些其他的手段进行专门的安全测试。

（五）安全性

涉及到资金安全方面，我一般都是从接口层面介入验证，之前在个人公众号有介绍过其他接口设计上有安全隐患的查找方式，有兴趣可以前往了解： 接口这样设计，资金没了都不知道为啥。

接下来介绍下稍微使用高级一点的手段介绍下如何测试资金是否安全。

1、欺骗充值

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

首先，看下小程序支付交互的流程：

                                                                 小程序官方交互图

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

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

2、超领红包

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

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

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

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

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

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

3、超额提现&并发提现

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

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

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

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

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

场景不限于：领红包、抽奖、提现等。

最后

以上就是机灵小蜜蜂为你收集整理的测试岗位面试题库---支付功能测试思路有哪些？一、梳理支付业务流程：的全部内容，希望文章能够帮你解决测试岗位面试题库---支付功能测试思路有哪些？一、梳理支付业务流程：所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。