现在有不少测试朋友做的项目中，可能也会涉及到支付相关的功能。比如：做商城的，做游戏的以及其他在线交易的网站、APP等。如果支付出了问题，或者用户拿少的钱通过篡改请求数据购买大金额的商品，如果是实物的话，发货前还有可能被发现。如果是虚拟商品话费、游戏币等就有可能造成损失。
所以，不管是实物也好，虚拟商品也好，对于互联网产品而言，支付是涉及到公司收入的一个重大环节，对于测试人员来说，支付测试是测试中的重要一环。失误或者轻视，可能会造成很大损失。之前可能大家也都看到过或者听过一个bug损失4.6亿美金的惨痛教训或者身边也有发生过其他因为支付功能的bug导致直接损失的案例。
那么，问题来了，对于支付模块的相关测试，我们应该如何进行呢？且听我细细道来！
一、测试方法
功能测试
通过将边界值分析、等价类划分、错误推测、因果图等各种测试方法进行结合，整理出尽可能全面的测试案例，对支付功能及其相关功能进行测试，以确保整个支付流程以及涉及到支付流程的其他流程在任何情况下都能正常进行。
接口测试
明确整个支付流程所需要调用的接口，分清楚商家和第三方支付平台的接口以及参数和请求方式。包括对接口特定参数的加密，使用异常订单号模拟支付，对服务端的校验等等。
功能测试
支付涉及到金额方面，所以要考虑安全测试方面。支付请求的伪造、金额的恶意篡改、恶意模拟第三方接口来调用商家接口等等。这都是我们需要考虑到的问题。
二、支付流程
常见的支付流程如下图所示：
主流：支付请求->第三方支付->第三方支付返回值->App根据返回值判断支付成功或失败。
之前：支付请求->第三方支付完成->返回到App前调用支付成功接口来判断支付是否成功或失败。
真实案例：
用12306买了一张火车票，支付宝支付的，支付完成后从支付宝返回到12306时，发现12306并未提示我支付完成，且在订单界面显示我的订单未支付，我就着急了（2011年，12306刚出来的时候，我有一次买票，票没买到，钱扣了的经历，后来经过客服把钱退回来了），刷新了好多次，还是未支付，正当我有点小焦虑的时候，短信通知我订票成功了。
三、支付分类
支付方式：充值支付、网银支付、银联支付、微信、支付宝，账户支付/扫码支付
资金流向：
1、网银支付：
流程：直接点击订单-》网银支付-》跳转到银行主页-》输入卡号，手机验证码，密码支付-》
支付完成跳转到return_url界面(同步回执)，支付状态一般为已支付-》银行打款成功，对方收到(异步回执)-》修改数据库里面订单状态为支付完成
虚资金变化：我的银行余额减少，对方余额增加
实资金变化：我的钱少了订单金额，对方增加了订单金额
资金流向：
假如你是在平台购买商品，然后钱最终是付给商家，采用的是网银支付：
你的银行卡账户->平台备付金账户->商户账户
如果平台商就是商家：
你的银行卡账户->平台备付金账户
2、充值支付：
把钱从你的银行卡充值到平台账户，支付时，使用平台账户上的余额进行支付
资金流向：
充值：你的银行卡->平台账户
支付：平台账户->商家账户
提现：平台账户->你的银行卡（通常收费）
转账：你的银行卡->对方银行卡
3、微信支付：
流程：购物平台生成订单->选择支付方式（微信支付）->跳转到微信界面->输入密码支付->生成收款二维码->扫码支付
这里分为两种：
1、微信余额支付
2、银行卡支付
资金流向：
1、微信备付金->平台备付金账户->商户账户
2、银行卡->微信备付金->平台备付金账户->商户账户
支付中涉及的对象有哪些？
我（用户）、卖家（商户）、平台、银行、第三方支付平台（如支付宝、微信等）
概念：
虚资金：虚拟货币或者虚拟的金额，比如网上查询银行卡余额
实资金：实实在在的钱
支付时会涉及到虚资金和实资金的转换。
四、支付接口
流程清楚之后，我们再来看看其中会涉及到哪些接口？这个支付流程图里面就涉及到了第三方支付接口：
· 下单接口：商户提交下单请求到第三方支付接口，第三方支付收单成功后返回下单成功结果给到商户系统。（下单接口的最终处理结果分为下单成功和下单失败，若未收到明确结果可调用单笔订单查询接口查询结果。）
· 支付接口：调用该接口时指定支付参数，完成买家账户向商户账户的支付，采用页面跳转交互模式和后台通知交互模式。（结果分为两路返回：一路为前台在return_url页面跳转显示支付结果；一路为后台在notify_url收到支付结果通知后进行响应。）
· 退款接口：调用第三方支付的支付请求接口返回付款成功后，在需要做退款处理时调用退款请求接口发起退款处理。（退款接口的最终处理结果分为退款成功和退款失败，若未收到明确结果可调用退款查询接口查询结果。）
· 单笔订单查询接口：根据订单号查询单笔订单信息和状态。
· 退款订单查询接口：调用第三方支付的退款接口返回后，在需要查询退款请求状态可调用退款订单查询接口查询退款订单的状态和订单信息。
五、测试点（侧重于App与第三方的交互）
1、检查请求接口（传参的方式）、特定参数（订单号、金额、数量等等）加密。
2、修改请求参数”订单号”，使用已重复订单号，支付未支付的订单。
3、修改请求参数”金额”（改小、改大、负数）。
4、修改请求参数”数量”（改小、改大、负数）。
5、检查订单提交请求、支付交易的按钮，要做阻断式操作，点击一次则要等待返回值，不能多次触发。
6、检查重要字段为空（不点击输入框的情况下），做提交的操作。
7、检查未安装第三方支付应用，走网页版测试流程。
8、检查通过限速，造成提交网络请求超时，确认该订单是否生成成功。
9、检查通过限速，造成提交请求成功但数据请求回传给App网络请求超时，刷新检查订单是否生成成功。
10、检查通过限速，造成支付网络请求超时，确认该订单是否支付成功。
11、检查通过限速，造成支持成功但数据请求回传给App网络请求超时，刷新检查订单是否支付成功。
12、支付测试过程中容易忽视的测试点，方便大家查缺补漏。
欢迎加入 51软件测试大家庭，在这里你将获得【最新行业资讯】，【免费测试工具安装包】，【软件测试技术干货】，【面试求职技巧】... 51与你共同学习，一起成长！期待你的加入： QQ 群： 755431660