支付功能怎么测试？
1、从功能方面考虑：
测试范围
支付金额
临界值测试 ：最大-最小
无实际意义金额，如0元
格式错误（负数、非数字）
余额小于实际需要支付的金额
超过第三方支付接口当日消费/单笔消费金额
银行卡或其他设置当日消费金额或者是单笔消费金额超限
支付接口
第三方接口，微信/支付宝/网银系统/post机终端服务
支付操作
指纹支付
免密支付
账号+密码支付
动态获取支付验证码支付
银行卡密支付
银行卡号+密码绑定支付
信用卡支付码
如今的支付方式多样化、快捷支付和银行卡支付之间的差异性。信用卡和普通储蓄卡之间的差异处。等都是需要考虑的，银行卡网银支付、支付宝支付、微信支付等；
异常处理
支付中断后继续支付的流程；（断电、断网、弱网）
支付中断后结束支付的流程；
单订单支付的流程；
多订单合并支付的流程；
余额不足；
支付金额不足时，充值后可否继续支付
第三方支付未登录时支付
未绑定银行卡；
密码错误；
密码错误次数过多；
找人代付；
弱网状态下，连续点击支付功能功能，会不会支付多次；
支付失败之后 如何补单和退单
退款处理
有优惠券、折扣、促销价进行结算是否正确；
不同的支付方式：
支付时间有效性
多端支付同一笔订单
2、从性能方面考虑：
多个用户并发支付能否成功；
支付的响应时间；
3、从安全性方面考虑
使用Fiddler拦截订单信息，并修改订单金额，或者修改订单号，(下两个订单A,B，付款时拦截订单B，并把订单B的订单号改为A订单的订单号)无法完成支付；
4、从用户体验方面考虑
是否支持快捷键功能；
点击付款按钮，是否有提示；
取消付款，是否有提示；
UI界面是否整洁；
输入框是否对齐，大小是否适中等。
5、兼容性
BS架构：不同浏览器测试。注重用户常用浏览器测试
APP：不同类型，不同分辨率，不同操作系统的手机上测试
PC/笔记本/平板
6、高级测试点
修改用户发过去的数据：
1）产品ID 与价值不对等---->检查点：篡改数据和key，检查商户系统报错：key值不对或者是用户数据有误。
2）取消充值流量
3）重复发起流量充值请求
商户系统-第三方之间：
1）密钥搞错-第三方报错，不接收密钥
2）提交商户系统里面不存在的订单/支付订单->第三方这里也是不能通过请求
3）篡改用户支付金额-->第三方也要检查
第三方--用户之间:
1）支付密码错误/余额不足
2）取消支付
3）重复支付[对账--->处理退款]
详细支付流程
1、支付正常流程
按照需求说明，进行常规支付操作。期望，支付成功，且无任何报错情况。
订单金额测试 --
用户发过去的信息测试--
本地数据会留存一份用户的订单信息，并且会根据每笔订单信息生成一笔支付信息
第三方有存支付订单信息
账户信息变更（余额，流量）
分别使用wifi和4G进行支付
2、支付异常流程
2.1 相关配置验证
（1）未开通对应渠道的支付开关
（2）未配置对应渠道的支付参数类
（3）未安装对应渠道APP（支付宝、微信等）
（4）未登陆对应渠道APP
2.2 支付基础验证
（1）订单支付金额小于目前账户余额
（2）拆分类交易：拆分金额与总金额不相等
（3）模拟用户进行付款后，使用fiddler等工具，将订单金额进行修改
（4）支付请求完成后，不输入密码（一般支付渠道需要输入密码才能支付成功，但对于扫码类的被扫支付接口，微信和支付宝都有免密支付，金额<=1000时不需要输入密码，因此输入密码需要输入大金额）
（5）支付输入密码时，直接关掉该页面（包含pc端支付、APP端支付）
（6）支付请求完成后，输入密码错误（一般这种情况由渠道方进行控制，会提示密码错误，重新输入密码）
（7）扫码类交易：生成二维码不扫，查看支付结果
（8）扫码类交易：使用错误付款码进行支付（比如：微信渠道使用支付宝付款码）
（9）超时测试：某些渠道会有支付超时时间，待过了超时时间进行支付
2.3 重复操作支付
（1）输入密码错误重新支付
（2）支付无响应时重复支付
（3）支付完成后重新返回支付页面，重新支付
（4）单笔订单多人支付
（5）单笔订单一人多设备支付（比如手机和pc都可登录微信/支付宝）
（6）单笔订单快速点击支付按钮支付
2.4 服务器类
（1）支付完成后，未接收到异步通知时，我方服务器故障
（2）支付完成后，未接收到异步通知，渠道方服务器故障
（3）支付完成后，未接收到前台通知，我方服务器故障
（4）支付完成后，未接收到前台通知，渠道方服务器故障
（3）支付过程中，已下单，未成功进行支付时，渠道方服务器故障
（4）发起支付时，我方服务器故障
（5）发起支付时，渠道方服务器故障
2.5 网络问题
（1）弱网环境下，支付请求超时，查看支付订单是否有生成，查看支付情况
（2）弱网环境下，输入密码支付成功后，返回相关页面或者APP时请求超时，查看订单支付情况
（3）支付过程中，切换设备网络情况，比如WiFi切换4G/4G切换WiFi，查看支付情况
（4）用户点击支付后，出现网络异常等影响支付流程问题，查看数据库是否有待支付订单生成
，验证页面是否进行刷新，用户是否继续进行支付
（5）用户输入密码支付后，还未接收到成功通知时，出现网络异常等影响支付流程问题，查看数据库该笔订单是否成功，查看用户是否收到前台支付结果通知页面
支付结果涉及到用户使用方面，所以在异常时相关提示需清楚明了，并且支付页面不可有明显错误出现，不能有显示乱码情况。
支付接口完成后，需要具备完善的查询机制，
在网络或者服务器问题导致订单支付成功后不能接收到成功的异步通知时，需要通过查询对账来修改系统的支付结果。
3、退款流程
正常的用例：
1.用户发起退款--->该用户的订单以及支付订单号都要存在。---检查点：商户系统/第三方检查数据没有问题，可以退款成功--->交易状态改成退款
异常用例：
1：无故发起退款：提交不存在的订单号或者支付订单号--->订单号不存在/支付订单号不存在
2：信息不匹配发起退款：提交订单号与支付订单号不匹配的数据--->订单号/支付订单号有误
3：退款大于实际金额：提交的退款金额大于实际支付订单的金额-->商户系统要报错
4：商户系统这里发过去的请求：退款金额大于实际支付金额-->第三方要报错
4、流程示意图
支付流程图
大致流程：
1.A用户在B商户平台选购商品并发起支付请求；
2.B商户将支付订单通过B2C网关收款接口传送至C支付平台；
3.用户选择网银支付及银行，支付平台将订单转送至指定银行网关界面；
4.用户支付完成，银行处理结果并向平台返回处理结果；
5.支付平台接收处理结果，落地处理并向商户返回结果；
6.商户平台接收到支付公司返回结果，落地处理（更改订单状态）并通知用户
合作渠道网关：指客户或商家将支付指bai令经由银行的支付网关传送到银行后台业务处理系统来完成支付的业务模式
退款流程：
如果出现用户发起退款情况，一般业务流程是这样的：
1.用户在商户平台发起退款申请，商户核实退款信息及申请；
2.商户登录支付平台账户/或者通过支付公司提供的退款接口向支付平台发起退款；
3.支付系统会对退款信息校验（退款订单对应的原订单是否支付成功？退款金额是否少于等于原订单金额？），校验商户账户余额是否充足等；校验不通过，则无法退款；
4.支付系统在商户可用余额账户扣除金额，并将退款订单发送至银行，银行完成退款操作。
注意：对于网关收款的订单退款，各银行要求不一，有些银行提供的退款接口要求原订单有效期在90或180天，有些银行不提供退款接口；针对超期或者不支持接口退款的订单，支付公司通过代付通道完成退款操作。对于收单金额未结算，还在“待结算”账户的订单，如果出现退款情况，业务流程和上述流程差不多，只是从待结算账户进行扣款。
接口
流程清楚之后，我们再来看看其中会涉及到哪些接口？这个支付流程图里面就涉及到了第三方支付接口：
下单接口：
商户提交下单请求到第三方支付接口，第三方支付收单成功后返回下单成功结果给到商户系统。（下单接口的最终处理结果分为下单成功和下单失败，若未收到明确结果可调用单笔订单查询接口查询结果。）
支付接口：
调用该接口时指定支付参数，完成买家账户向商户账户的支付，采用页面跳转交互模式和后台通知交互模式。（结果分为两路返回：一路为前台在return_url页面跳转显示支付结果；一路为后台在notify_url收到支付结果通知后进行响应。）
退款接口：
调用第三方支付的支付请求接口返回付款成功后，在需要做退款处理时调用退款请求接口发起退款处理。（退款接口的最终处理结果分为退款成功和退款失败，若未收到明确结果可调用退款查询接口查询结果。）
单笔订单查询接口：
根据订单号查询单笔订单信息和状态。
退款订单查询接口：
调用第三方支付的退款接口返回后，在需要查询退款请求状态可调用退款订单查询接口查询退款订单的状态和订单信息。
针对第三方的接口，测试过程中需要注意的主要测试点及异常场景：
· 首先要保证接口都能正常调用；
· 生成一笔订单，支付完成后，同步或异步重复回调，只有一次有效；
· 生成一笔订单，复制订单号和金额，再次生成一笔订单，用fiddler设置断点，用第一笔已完成的订单号和订单金额去替换现有的订单号和金额，无法完成支付；
· 生成一笔订单，跳转到第三方时修改金额，无法到账，
· 异步通知屏蔽，同步有效，进行支付，同步能够正常到账；
· 同步设置无效，异步有效，进行支付，异步能够正常到账；
· 同步异步都设置无效，在第三方支付完成后，在重发机制时间范围内，设置异步有效，到下次通知时间点时，能够正常通知到账（补单机制的验证，如果商户收到第三方支付成功的通知后，要告知第三方支付收到了成功的通知，如果第三方支付收到商户应答不是ok或超时，第三方支付就会认为通知失败，会在规定的时间内持续调用notify_url，一般有时间或次数的限制）；
· 针对支付订单在数据库中存储是否完整和正确进行校验（比如：第三方订单号--方便与第三方对账和问题排查、订单金额、订单状态等）；
· 如果是用户购买实物商品，用户发起退货，要保证退货流程正常，资金能正常返还，要考虑下并发情况的验证以确保安全性；
· 如果是用户购买虚拟商品，比如话费、油卡之类的商品，只有在发货失败的时候才能发起退货，注意验证；
遇到过的坑：
· 用户购买100元游戏币时，前往第三方支付跳转进行金额的篡改由100元改成0.01元，结果就拿了0.01元充值了100元的游戏币。对订单金额没有做校验导致这样的后果，损失比较大。大家在测试的过程中一定要注意对服务端进行校验，支付时数据的篡改一定要有校验。
· 当同步、异步通知都存在的情况的，异步通知（第三方支付成功后台通知），没有到账，导致部分用户充值不到账，引起客诉。当同步、异步并存的时候，一定要分别对同步和异步进行检验，确保都能正常到账。
我们所做的绝大多少的互联网产品都会涉及到第三方支付，所以支付功能必然是重要的，作为测试互联网产品的一员，我们必须要做好支付的安全性。
那么，如何规避支付风险？
为了进一步的加强支付功能的安全，也可以适当的增加一些监控机制，比如：订单与第三方订单进行对比，可以使用跑批完成，当我们完成支付的订单从数据库中查出来与通过第三方订单查询接口查询出来的同一个订单金额有异常时，进行报警通知能够及时发现处理，甚至当有异常情况进行创建订单的终止，从而把损失降到最低。
后台处理订单
1.成功订单财务处理
2.失败订单财务处理
3.退款订单财务处理
4.差错账单如何处理等
微信支付验收用例文档：https://pay.weixin.qq.com/wiki/doc/api/jsapi.php?chapter=23_1
支付宝：https://docs.open.alipay.com/270
测试方法
重点采用了场景法、边界值法进行系统功能测试，
采用负载压力测试工具实现性能测试。
下面结合具体关键点测试案例，来分析本系统的测试方法。
1. 转账流程测试
常规情况下，支付系统为客户提供正常转账流程，但本系统对客户进行了细分，包括个人会员、电子协议商户、纸质协议商户，对不同类型的客户间转账设置了不同的处理规则，如表1所示。
▲表1 转账对应关系表
此外，还存在转出账户处于异常状态、转出账户余额不足、转入账户处于异常状态、转账金额超过交易限额、转账支付撤销等异常情况，如图2所示。
▲图2该系统转账流程
综合以上情况，整个转账过程包含很多事件，
将登录作为起始事件，登录后的不同操作会进一步触发不同的事件，这些事件在被触发时形成了不同的场景，因此我们可以采用场景法，
将正常的转账过程作为基本流，
将特殊情况和异常情况的处理过程作为备份流
根据确定的基本流和备份流形成不同场景并设计相应的测试用例，最后通过执行测试用例完成测试。
2. 退款流程测试
退款业务属于异常交易处理范畴，本系统提供的退款方式较多包括单笔退款、批量退款、多次退款、人工退款等，此外由于退款还涉及手续费返还，分成结算、查询统计等业务，退款流程较复杂，对于边界值处理的准确性得要求较高。因此，对于测试来讲，设计好的测试用例对于退款业务测试尤为重要。本次测试采用等价类法、边界值法相结合的方法，按照退款计算设计方案将其分类，分为自动退款和人工退款，然后再细分为单笔退款和批量退款，同时考虑单次退款金额略小于原交易额、单次退款金额等于原交易额、单次退款金额略超过原交易额、多次退款金额略小于原交易额、多次退款金额等于原交易额、多次退款金额略超过原交易额，分别设计测试用例，执行时还需重点查看手续费返还、分成结算、状态查询统计等的正确性。
3. 风险监控测试
风险监控测试重点验证系统对账户及交易风险防范的能力及相关管理制度。鉴于本系统具有独立的风控系统，在测试时主要采用系统验证、文档审核与访谈相结合，考核相关管理制度是否完善，并模拟钓鱼、套现、欺诈、大额交易、洗钱、盗用等不同类型的账户管理风险和风险交易，考核系统的风险防范及预警能力。
4. 性能测试
本系统性能测试包括并发测试、大数据量测试及系统自恢复能力测试。测试点较多，数据量大，需求指标要求较高，因此在测试前被检测机构尽量构建与真实环境相同配置、数据规模满足检测规范要求的压力测试环境。测试时采用了自动化性能测试工具，创建压力测试程序、构建压力测试模型，对被测试系统实施自动化压力测试，并对测试过程中系统各关注点进行监控，最后形成压力测试结果分析报告。
4. 安全测评
系统安全性检测针对系统安全不同层面的不同内容，主要采用访谈、现场检查、自动化工具测试、文档审核相结合的方法进行考查。针对本项目服务器等相关设备较多的特点，测试前充分了解系统部署情况，熟悉网络设备、网络架构以及网络安全产品策略、服务器策略、审计及日志管理方式、应用安全保护设施、数据加密及存储方式等，要求被测方准备好相关制度和文档，并针对不同考查点，制定相应详细的访谈表、检查表及测试表。
网友评论