前言
跳槽高峰期,作为测试,不管是面试还是笔试,必然要被考验到的就是”测试思维“。在面试中就是体现在如下面试题中:
“说说你项目中的 xx 模块你是如何测试的?”
“给你一个购物车,你要怎么测试?”
“你说一下这个产品的登录功能有哪些测试点?”
“支付功能怎么测试?”
…
所有的这些问题其实都是在考察你的测试思维。我们再回答这类问题的时候有方法可依循的。
今天这篇文章,我就很多同学都觉得难的一个问题“支付功能”作为案例,一起来分析一下如何回答这类的面试题。
测试思维
要分析测试点之前,我们先来梳理一下测试思维。总结来说,任何事物的测试思路都可以总结如下:
第一步:梳理产品的核心业务流程:明白这是个什么项目,实现了什么业务,以及是怎么实现的?
这个步骤一般是参考公司的需求文档来的,如果产品提供需求文档的同时提供了业务流程图,可以遵循流程图来梳理;如果产品没有提供流程图,就需要测试人员根据需求的理解自己画出流程图,达到梳理业务的目的。
第二步:根据流程进行模块细分,然后针对每个功能模块进行详细的测试点设计和提取。
这个单个功能的测试点提取要覆盖一下几个方面:
正常功能验证:优先覆盖正常的业务流程和功能验证,这其实也是单个功能的冒烟测试。冒烟测试先行,如果不通过,可以直接停止测试等开发修复后继续测试。
异常功能验证:为了更加贴近用户的使用产经,我们也要验证各种异常的场景,故意操作导致出错,检查系统的反馈和提示,保证用户操作失误的情况能够得到系统的友好指示。
因为有很多地方的操作都有可能会导致系统异常和抛错,所以为了不漏测,我们需要找出所有可能导致异常的输入项和选项。所以就到了第三步:
第三步:针对具体功能,寻找每个输入项和步骤,从以下三个角度来分析测试点 。
长度,数据类型,必填项,重复
需求的约束条件 + 隐形需求
功能之间的交互
这其中就需要用到一些用例的具体设计方法了,比如场景法,等价类法,边界值法,错误推测法等等
第四步:考虑非功能测试点,包括界面、易用性、兼容性、安全性、性能压力
支付功能的测试点
基于上面的测试思路,我们可以分析得出“支付功能”测试点如下:
一、梳理支付的业务流程如下:
点击支付—> 选择支付方式 —> 确认金额—> 输入密码 —> 成功支付
完成这个流程测试,也就是完成了项目的冒烟测试!然后需要测试针对流程中的每个阶段和步骤,具体分析可能导致异常的测试点,所以我们按阶段和输入项来进行划分如下:
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)申请测试金额:
这种方式一般会作为小额支付的一种补充,比如测试完小额支付后,再测试一些大额支付,这就需要跟公司申请测试基金,走报销流程;
3)沙箱支付:
沙箱支付是一种虚拟的支付,不是真实的金额;这种方法可以验证小额和大额的支付流程;不过目前只有支付宝沙箱比较成熟可用,其他的支付方法不可用。
四、非功能测试点
测试完以上的功能测试点之后,我们还需要验证一些非功能测试点,主要包括以下几个方面:
1)界面
验证界面的美观,排版和错别字等。
2)兼容性
**BS:**如果是 BS 架构的产品,需要测试跟浏览器的兼容性;所以就需要根据浏览器的内核,选择一些主流的浏览器进行测试;
CS:如果 CS 架构的产品,测试手机移动端的兼容,比如手机型号,系统版本和屏幕大小及分辨率等。
3)易用性
测试站在用户的角度考虑用户体验,使用是否方便等。
4)性能
比如考虑多用户支付,长时间运行等,关注产品的响应时间等,一般需要借助工具或者代码进行测试。
5)安全
验证敏感信息是否加密,是否可以篡改;通过一些工具进行安全扫描,检查是否有安全漏洞;或者采用一些其他的手段进行专门的安全测试。
总结:
感谢每一个认真阅读我文章的人!!!
作为一位过来人也是希望大家少走一些弯路,如果你不想再体验一次学习时找不到资料,没人解答问题,坚持几天便放弃的感受的话,在这里我给大家分享一些自动化测试的学习资源,希望能给你前进的路上带来帮助。
软件测试面试文档
我们学习必然是为了找到高薪的工作,下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料,并且有字节大佬给出了权威的解答,刷完这一套面试资料相信大家都能找到满意的工作。
视频文档获取方式:
这份文档和视频资料,对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴我走过了最艰难的路程,希望也能帮助到你!以上均可以分享,点下方小卡片即可自行领取。