你能说说“支付功能”怎么测试么?

本贴最后更新于 1147 天前,其中的信息可能已经时移世改

前言

年底了,大家都在欢欢喜喜的盼过年;但是也有很多人在蓄势待发,全面武装准备好年后复工的找工作黄金期--俗称”金三银四“。那么,作为测试,不管是面试还是笔试,必然要被考验到的就是”测试思维“。在面试中就是体现在如下面试题中:

“说说你项目中的xx模块你是如何测试的?”

“给你一个购物车,你要怎么测试?”

"你说一下这个产品的登录功能有哪些测试点?"

“支付功能怎么测试?”

......

所有的这些问题其实都是在考察你的测试思维。我们再回答这类问题的时候有方法可依循的。

今天这篇文章,我就很多同学都觉得难的一个问题“支付功能”作为案例,一起来分析一下如何回答这类的面试题。

测试思维

要分析测试点之前,我们先来梳理一下测试思维。总结来说,任何事物的测试思路都可以总结如下:

第一步:梳理产品的核心业务流程:明白这是个什么项目,实现了什么业务,以及是怎么实现的?

这个步骤一般是参考公司的需求文档来的,如果产品提供需求文档的同时提供了业务流程图,可以遵循流程图来梳理;如果产品没有提供流程图,就需要测试人员根据需求的理解自己画出流程图,达到梳理业务的目的。

第二步:根据流程进行模块细分,然后针对每个功能模块进行详细的测试点设计和提取。

这个单个功能的测试点提取要覆盖一下几个方面:

正常功能验证:优先覆盖正常的业务流程和功能验证,这其实也是单个功能的冒烟测试。冒烟测试先行,如果不通过,可以直接停止测试等开发修复后继续测试。
异常功能验证:为了更加贴近用户的使用产经,我们也要验证各种异常的场景,故意操作导致出错,检查系统的反馈和提示,保证用户操作失误的情况能够得到系统的友好指示。

因为有很多地方的操作都有可能会导致系统异常和抛错,所以为了不漏测,我们需要找出所有可能导致异常的输入项和选项。所以就到了第三步:

第三步:针对具体功能,寻找每个输入项和步骤,从以下三个角度来分析测试点 。
  1. 长度,数据类型,必填项,重复
  2. 需求的约束条件+隐形需求
  3. 功能之间的交互

这其中就需要用到一些用例的具体设计方法了,比如场景法,等价类法,边界值法,错误推测法等等

第四步:考虑非功能测试点,包括界面、易用性、兼容性、安全性、性能压力

支付功能的测试点

基于上面的测试思路,我们可以分析得出“支付功能”测试点如下:

一、梳理支付的业务流程如下:

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

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

1)点击支付,提交订单但是取消了,检查可以取消成功
2)选择支付方式:

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

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

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

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

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

最大支付金额(单日最大,单笔最大,余额最大)

最小支付金额

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

超过支付方式单日最大消费金额/单笔最大/余额最大

异常金额支付:非数字、负数、0,小数点超过2位等

4)支付密码:

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

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

5)其他场景测试点:

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

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

c、支付中断:

主动中断:可以继续支付并成功

被动中断:比如电话、低电量、闹钟,断网、切换后台、耳机插拔等,验证可以继续支付;

d、网络测试:

验证各种网络类型:2G、3G, 4G,5G,wifi 下都可以正常支付;

进行网络切换,支付功能正常;

弱网测试下支付功能正常:不会重复支付多次,APP不会闪退 崩溃,而且页面提示友好;

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

二、退款流程

**正常:**验证正常的退款流程,也就是退款的冒烟测试:

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

异常:提交错误退款(退款订单号不对),或者退款金额错误,都能够退款失败(此处一般会借助工具进行测试,比如进行接口测试);

三、测试方法

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

1) 小额支付:

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

  1. 申请测试金额

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

3)沙箱支付:

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

四、非功能测试点

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

1)界面

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

2)兼容性

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

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

3)易用性

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

4)性能

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

5)安全

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

回帖
请输入回帖内容 ...