• 第三方支付功能测试点【杭州多测师_王sir】【杭州多测师】


    支付类异常测试点

    一、支付流程

    我们在测试一个功能时,需要先了解一下这个逻辑,而订单支付逻辑普遍都会有以下内容:

    1. 创建本地唯一订单号;

    2. 去调用支付,在支付平台生成一个支付订单;

      • 会返回一个支付凭证(payInfo)
      • 支付订单号在回调方法中会拿到
    3. 此时待支付状态下,支付平台回调通知接口;

      • 在本地保存待支付订单信息(此时有两个订单记录:一个本地订单,一个支付平台的订单,两个ID关联)
    4. 用户根据收到的支付凭证发起支付(只需要管支付成功的,不成功可以当成忽略)

    5. 支付平台回调通知接口(支付成功)

      • 更新支付订单
      • 更新本地订单
      • 后续操作
    6. 主动查询订单状态

      • 更新支付订单
      • 更新本地订单
      • 后续操作
    7. 退款或体现(不做具体阐述)

    二、实际遇到支付的异常测试点

    上面的内容了解即可,大部分内容项目熟了就知道了,很多时候具体项目具体分析。下面的异常测试点大多是我亲身经历过的容易出现异常的情况。

    具体测试场景:

    1. 连续访问2次(或以上)支付接口,在第一次访问未回调完成时,第二次访问需要做限制;
      • 可能出现的问题:直接返回第二次的结果,而第一次就可能是成功的,只是第一次请求返回的结果被第二次请求返回的失败结果所覆盖;
    2. 连续访问回调订单接口(向支付平台提交支付请求接口),生成的多个签名,需要校验订单返回的是否是最新的签名;
      • 可能出现的问题:使用前面生成的一个签名去支付,会报错;
    3. 一个订单反复提交支付再返回,退出支付再次调取支付只允许生成不同的签名,这个根据需求;
    4. 需要校验1个签名只能支付1次,这个根据需求;
    5. 支付签名的校验,这个看需求及个人。如:异常/特殊符号等;
    6. 支付0元/0.01元/0.001元;
    7. 支付负值;
    8. 支付回调超时情况后端处理:一个合理的文案。方法:加挡板/断点;
    9. 注意一下消息回调,如果是第三方支付系统,通常会有消息的异步回调。
      • 如:支付后,会在一定时间内无限循环查询接口,最后会回传成功或失败,但是订单不会直接知道这个结果,系统需要再次访问一个接口了解支付的最新状态才能知道订单是否支付成功;
  • 相关阅读:
    Dubbo初次使用(广播形式)
    【基于YOLOv8的森林烟雾火焰检测 附源码 数据集】
    Linux内核的基础设施:工作队列、等待队列
    [ 云原生之谜 ] 云原生背景 && 定义 && 相关技术详解?
    【Linux】应用层协议序列化和反序列化
    游戏AI——GOAP技术要点
    手写rollup
    再见 Excel,你好 Python Spreadsheets!⛵
    【数据结构】 单链表:无头+单向+非循环链表增删查改实现
    dpdk hw-offload flows i
  • 原文地址:https://blog.csdn.net/weixin_39362573/article/details/125541548