zoukankan      html  css  js  c++  java
  • 作为一名测试员“支付功能”你是怎么测试?

     
    前言
    作为测试,不管是面试还是笔试,必然要被考验到的就是”测试思维“。在面试中就是体现在如下面试题中:
    “说说你项目中的 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)安全
    验证敏感信息是否加密,是否可以篡改;通过一些工具进行安全扫描,检查是否有安全漏洞;或者采用一些其他的手段进行专门的安全测试。
     
     
    ============================================ Attention ============================================
  • 请大家尊重原创,如要转载,请注明出处:转载自:https://www.cnblogs.com/tricy-nmb/谢谢!!

  • 有任何疑问,欢迎加V:ningmengpyn(请备注:博客园-Tricy)
查看全文
  • 相关阅读:
    Linux-命令-seq
    怎样打开U盘最安全
    SQL Anywhere .NET
    技巧:低版本VS打开高版本VS创建的工程
    数据库插入数据返回当前主键ID值方法
    Nvelocity模板引擎
    .ashx文件与.ashx.cs
    该站点安全证书的吊销信息不可用。是否继续?
    IE8“开发人员工具”(下)
    IE8“开发人员工具”(上)
  • 原文地址:https://www.cnblogs.com/tricy-nmb/p/14822137.html
  • Copyright © 2011-2022 走看看