大体上,我们可以从支付流程、退款流程、非功能测试点及支付测试的方法四个方向考虑。
支付的测试流程:点击支付-->选择支付方式-->确认金额-->输入密码-->成功支付。需要针对支付流程中的每个阶段和步骤分别测试。
1、支付:点击支付,然后取消订单,能否正常取消。
2、选择支付方式:可以从正常和异常角度考虑。
正常:可以支持的支付方式有:信用卡,储蓄卡,网银支付,余额,第三方支付(微信,支付宝,京东、百度、聚合支付、组合支付),找人代付,验证是否支持并且可以正常选择并支付;
异常:
支付时结合优惠券/折扣券/促销价抵扣进行相关的抵扣,验证规则正确,并且可以正常抵扣和支付。
手机上没有安装微信、支付宝等APP时,选择对应的支付方式,系统如何处理;
3、确认支付金额:
正常:正常金额里用黑盒测试中的边界值法去测试。
最大支付金额(单日最大,单笔最大,余额最大);
最小支付金额。
异常:同样也用边界值方法提取测试点。
超过支付方式单日最大消费金额/单笔最大/余额最大;
异常金额支付:非数字、负数、0,小数点超过2位、格式错误、余额小于实际需要支付的金额等。
4、支付密码:
正常:可以支持的支付密码类型有:指纹,人脸识别,账号密码,动态获取验证码,手势,信用卡和支付码,小额免密等,确认自己的产品所支持的密码类型,确认可以验证并支付成功;
异常:
输入错误的密码,检查有无提示信息且正确;
超过密码错误上限,检查是否冻结等。
5、其他场景测试点:
多笔订单合并支付,是否可以成功;
重复点击支付按钮,是否会出现多次购买,并同步检查数据库的数据账目是否正确;
支付失败之后,如何补单和退单。
支付中断:
主动中断:可以继续支付并成功;
被动中断:比如电话、低电量、闹钟,断网、切换后台、耳机插拔等,验证可以继续支付。
使用Fiddler等抓包篡改价格:不允许抓包或者数据加密,篡改不成功。
正常:验证正常的退款流程,也就是退款的冒烟测试。
点击退款可以退款成功,并且检查交易状态是退款,退款金额可以到账;
结合优惠券等抵扣,可以退款实际支付金额;
同步检查数据库的数据和账目是正确的;
异常:提交错误退款(退款订单号不对),或者退款金额错误,都能够退款失败(此处一般会借助工具进行测试,比如进行接口测试);
我们平时测试中,除了功能测试,还需要考虑其他方面的测试(非功能测试),主要包括以下几个方面:
(1)UI测试:
1、支付按钮是否足够明显;
2、支付的界面是否简洁、美观,符合大众审美;
3、支付页面的字体大小是否合理。
(2)兼容性测试:
BS:如果是BS架构的产品,需要测试浏览器的兼容性,所以就需要根据浏览器的内核,选择一些主流的浏览器进行测试;
APP:测试手机移动端的兼容性,比如手机型号,系统版本和屏幕大小及分辨率等。
(3)易用性测试:
1、是否支持快捷键功能;
2、点击付款按钮,是否有提示;
3、取消付款,是否有提示;
4、输入框是否对齐,大小是否适中等。
(4)性能测试:
1、多次点击支付按钮时,是否会出现多次扣款;
2、如果发生多次扣款,如何通过原支付渠道退回;
3、如果在双十一、双十二这种支付高峰的时候,支付时是否会排队;
4、是否会响应超时;
5、如果响应超时,是否会返回友好提示。
(5)安全测试:
验证敏感信息是否加密,是否可以篡改;
通过一些工具进行安全扫描,检查是否有安全漏洞或者采用一些其他的手段进行专门的安全测试;
支付请求的伪造,金额的恶意篡改,恶意模拟第三方接口来调用商家接口等,均是我们需要考虑清楚的问题。
(6)网络测试:
1、验证各种网络类型:2G、3G,4G,5G,wifi下都可以正常支付;
2、进行网络切换,支付功能正常;
3、弱网测试下支付功能正常:不会重复支付多次,APP不会闪退崩溃,而且页面提示友好;
经常有测试小伙伴问,支付功能我要如何测呢,要用真实的钱么?我们提供的思路有以下四种:
(1)小额支付:
让开发修改代码,不管支付多少钱,实际支付都是1分钱;不过这种方法只能测试小额支付,就有可能会出现产品小额支付没问题,但是大额支付就错误的漏测情况;
(2)申请测试金额,走报销流程:
这种方式一般会作为小额支付的一种补充,比如测试完小额支付后,再测试一些大额支付,这就需要跟公司申请测试基金,走报销流程;
(3)把收款方改成自己的收款账号:
这样就可以自己支付,自己收款,避免浪费自己的金钱做公司项目的支付测试。但是这也是有风险的。万一扣款成功,但是支付的金额没有到账可该怎么办?
(4)沙箱支付:
沙箱支付是一种虚拟的支付,不是真实的金额;这种方法可以验证小额和大额的支付流程;目前支付宝沙箱比较成熟,推荐使用。
作者:kexing
原文链接:https://blog.csdn.net/weixin_45131345/article/details/115346813