• bug特殊情况总结


    • 登陆按钮,如果有验证码的,需要拦截登陆按钮多次点击。否则多次点击的时候,如果输入一次正确的验证码,点击登陆,调了2次登陆接口,就会出现先登陆成功,再提示验证码失效。因为这个验证码已经用过了,肯定会失效。

      • 消息需要做幂等,否则会容易重复生成待扣款记录。比如发2次消息。可能会生成2条记录。
      • PHP进程负载过高最多导致请求超时,报503,接口就挂了。这种线上情况要考虑到。问题现象是:app用线上接口访问绑定还款方式,接口返回报错,前端提示取消订单。
      • h5.js 60s超时了之后。就不会等待
      • 敏感信息,比如身份证证件号码。身份证正反面照片。查询接口访问的时候应该加登陆验证。图片也是的。需要加安全防护。
      • 代扣的时候,输入密码情况,弹起支付宝后,不进行支付。过半小时后,支付宝会生成一条记录。这时候返回app去查看回调的结果。线上bug是回调的结果 虽然未支付成功,但是判断逻辑错误。导致判断这个订单的支付结果是支付成功。实际上没有支付。只是弹起了支付页面。这个支付bug很严重。
      • 同一个订单,不同设备,用同一个支付担保方式,同时支付一个订单,查看是否能支付成功2次。期望不能支付成功2次。只能支付成功一次。
      • 同一个订单,不同设备,切换不同担保方式,然后,选择其中一个支付,查看是否可以支付成功。
      • 缓存逻辑,导致代扣到其他账号了。2个账号串了。
      • 下完订单。不支付。订单详情页面也要看下。避免出现未支付。下单详情页面传支付单号,导致报错。
      • 支付金额,一定要考虑2位小数点。额度有小数点。会导致付款的金额是小数点。如果开发没有精确小数点,就会导致支付报错。
      • 前端的逻辑支付完,除了看前端展示和数据库展示。后台也要看数据展示。同时上线后,监控数据库。
      • 确认订单页面,减了优惠券。要看下服务条款的金额是否减掉了。如果不用优惠券。看下是否服务条款协议的优惠没有用。这点很重要。
      • 退款时,去查支付宝有没有成功,由于网络问题(可能是超时,可能是丢包导致)。退款失败的情况。
      • 如果有数据变更,状态和数据都要刷新。订单下单后,如果有变更下单的信用卡的时候,一定要注意前端和后台之前显示信用卡信息的数据的变更。
      • 订单支付后,取消后没有退款。原因是支付宝回调超时
      • 前端创建订单的时候,如果操作多次点击并发会导致创建多个支付单号,导致退款的时候,退款失败。不知道用哪个单号。
      • 检验银行卡4要素的时候,前段格式化了,有空格,如果传给后端不进行去掉格式化,就很有可能导致错误。因为接口要的是不要格式化的,这样接口就会判断不一致。
      • 测试的时候,需求闭环需要做好。比如数据统计部门和新上线的需求,都要及时同步。否则容易导致更改的需求,统计的逻辑还是按照以前的方式统计。出现的bug是:产品新增了乐百分续租,冻结的押金是花呗的钱,跟乐百分无关,买断的时候,也是转支付花呗的钱。但是数据部门统计乐百分转现的逻辑还是按照只要这个订单是乐百分那么所有转支付的钱都是乐百分的。其实续租之后乐百分订单买断后转现的金额是之前续租冻结的花呗的钱。问题是数据部分统计的时候把这个转现的钱记录成乐百分的转现的钱了。其实乐百分转现的钱是0元。乐百分订单 到期后转续租,冻结金额转到花呗,如果此时买断 扣除的是花呗的钱,跟乐百分没有关系;问题表述:数据统计部门对此类数据的统计 还是归类到乐百分,导致一些账目对不上。避免措施:这类产品需求评审的时候需要带上数据部门,并告知影响
      • 优惠券小程序兼容问题,小程序优惠券没有上。老版本的小程序没有做兼容,导致没有限制不可用的优惠券,很多用户使用了不可用的优惠券。用户量下单多,损失大。
      订单上线流程要求:
      1. 订单取消入口是否有多个。app取消。后台退货取消。后台退货
      2. 有dbrt的需要提前一天通知开发上。
      3. 在stage和beta环境测试的,遇到问题的订单数据,需要修改完,或者删除完,才能进行上线,不要在上线之前留下脏数据。
      4. 一个项目一个项目独立开来。不要存在上个项目的脚本部署是需要在下个项目进行部署的。需要独立开来。
      5. 上线后。需要确保线上的脚本都部署完毕。
      6. 代码都确认ok后才能上线。
      7. beta环境一定要真实数据进行测试。
      8. 注意点:测试一个项目的时候,如果有上线的东西,就需要时刻rebase下。涉及到支付中心,新建表或者数据库的时候,就需要看下兼容老版本。
               老版本下的订单,在新代码上看支付是否是会有问题。 这个是重点。
               新代码下单,支付是否正常,这个肯定会过下。
      1. 如果请求,超时失败后,再次发一笔请求,就又会创建一笔支付单,就说支付成2笔订单。同步没有结果,异步有结果。
       
      下单负责的日常点:
      1. 平时的时候测试环境切master环境,进行下单流程的日常回归。线上订单需要做到日常回归。
      2. 发包之前进行日常下单流程回归。
       
      支付的测试注意点:
       
      信用卡预授权bug 这个是3个担保方式的bug。信用免押和花呗这样组合也会有这个问题。
      1、安卓先点击花呗,进入授权确认页面。
      2、ios点击信用卡预授权,进入授权确认页面。
      3、安卓点击花呗授权确认页面的下一步,页面一直加载。
      4、ios点击信用卡预授权的下一步,进入了租金代扣方式页面。
      service_pay`.`e_pay_trans_online` pay_no 支付单,只会有一笔支付单有效,有多笔的,都是以最后一笔生成的支付单有效,其他都会变成已关闭状态。关闭的支付单,支付的话,会提示订单已经关闭,支付请求无效 
    •  
      如果支付单被关闭,即使调起了收银台,输入完了密码,微信也会提示:订单已经关闭,支付请求无效“这个时候,微信是不会扣钱的。这个原因就是,支付单被关闭,平台会通知微信这个支付单被关闭了,不需要扣款了,所以,弹出的这个提示是微信提示的:订单已经关闭,支付请求无效
       
       
       
       
       

  • 相关阅读:
    go---weichart个人对Golang中并发理解
    go语言值得学习的开源项目推荐
    mysql17---增量备份
    mysql16---读写分离
    mysql15--垂直分表水平分表
    mysql14---手动备份
    mysql13---索引使用注意
    mysql12----explain
    mysql11---主键普通全文索引
    OpenOffice的简单安装
  • 原文地址:https://www.cnblogs.com/swiftycc/p/12468942.html
Copyright © 2020-2023  润新知