代码改变世界

线上问题的一些记录与总结-2022年2月

2022-03-06 12:14  第二个卿老师  阅读(156)  评论(0编辑  收藏  举报

作为第一篇记录线上bug的文章,起因是部门本想搞一次bug品鉴会,但由于时间等原因,最终不了了之。

背景

虽然我们坚持质量来源于内建,但对我们测试人员来说,如何提高质量也是我们的事。

目标

预防我们已经知道有一定可能性产生的Bug

思考

bug为什么会产生?(5W原则)如何去预防它?下一次我们如何更容易地发现它?

维度分类

测试人员对bug是最熟悉的,究其本质主要的对编程习惯、开发逻辑、思维局限等有披露,根据对象来源与场景维度分

  • 流程规范
  • 配置相关
  • 编码习惯
  • 开发设计局限
  • 技术瓶颈
  • 无法测试重现(海森堡bug)
  • 需求遗漏
  • 产品设计局限
  • 需求二义性
  • 第三方依赖问题
  • 改动影响
  • 兼容性问题(包括软硬件,版本兼容性)

以上基本囊括了所有bug的来源。

实例剖析

-- 原因(直接原因)、分析(为什么会出现这种原因)、解决(怎么解决的,后续如何预防)

2020年10月27日

问题:3.6.4—>3.7.2版本,安卓覆盖安装崩溃,部分机型且第一次授权的时候

测试:测试环境提了bug也修复了,但没考虑线上版本的更新是否会出问题。
 
语录:涉及更新的问题,要特别注意线上版本!
 

问题:3.7.2版本,商城品尝券支付时需要付邮费(新需求),没有支付就下单成功了

测试:接口层面问题,未做效验,接口测试未测试到
 
语录:接口测试需要设计异常场景,避免非法流程漏洞。

2020年11月4日

问题:AB两个微信,手机号绑定A微信,并绑定B微信的小程序,会生成同手机号的两个账号(此问题测试环境已发现)
测试:应该是历史遗留问题,微信绑定手机号时未判断该手机号是否存在,微信小程序绑定手机号也存在这个问题
 
语录:账号生成机制不够深入,多个复杂情况需要考虑(重复绑定)。
 
附:修改手机号就行

2020年11月14日

 问题:砍价活动,新用户定义当天12点之后注册的用户,每个用户存在助力上限,如果后台配置大于1次,那么第二次助力也算新用户。
测试:测试点遗漏,新用户定义的漏洞。
 
语录:如果存在配置上限这种,需要看是否与设定冲突,比如新用户。

2020年11月16日

 问题:历史遗留的问题数据,如同一手机号生成多个memberID,历史数据没有处理,导致砍价活动,小程序与APP的账号砍价数据不能正常同步
测试:问题已经修复了,但历史数据未处理,怎么处理没有结论,导致后面填坑。
 
语录:如果修复了一个Bug,考虑是否有产生了脏数据,如果存在脏数据得商量一个好的办法处理掉,避免后面坑越来越大。

2021年1月29日

 问题:购物车服务发布上线后,ERP拆单推单无法正常进行。
测试:测试环境是可以的,线上环境不行,golang的日志查询是SQL查询的is_spilt字段为0,本来的值为1,后面深入排查发现是连接mysql时配置参数少了(&parseTime=True&loc=Local&timeout=10s),其中parseTime是查询结果是否自动解析为时间。loc是MySQL的时区设置
 
语录:如果在测试环境没问题,那么极大可能是配置出了问题,日志中可以从数据流排查,再看对应线上配置。

2021年3月18日

问题:安卓的首页发现刷不出来,关注和精选模块没问题

测试:没有重现,怀疑账号问题,结果发现是推荐导致的接口响应慢,而安卓的响应时间超过5s后会报网络异常,所以导致首页加载不出来,而推荐接口响应慢是因为Hbase挂了。
 
语录:线上推荐系统的对应服务组件缺少监控,安卓的超时时间改长一点,这样体验也好点。

2021年3月24日

 问题:关注列表最新的内容没有更新,显示昨天的信息
测试:nacos日志文件太多,导致ES磁盘满了,最新数据没有保存
 
语录:磁盘文件的容量也会导致一些问题,测试可把这个考虑进去,系统读写异常测试

2021年4月20日

问题:商城新增商品提示服务器内部错误
测试:商品名称存在特殊符号“+”,erp创建库存后没有添加库存
 
语录:如果对接第三方服务组件,记得试试特殊符号之类的

2021年4月26日

 问题:线上部分服务挂了,社区接口正常,但未返回数据
测试:获取粉丝列表的sql锁表了,导致不能访问表,服务挂掉
 
语录:sql需要优化,主要是慢查询导致,特别是粉丝关注数这种场景

2021年5月25日

 问题:秒杀出现订单数超过秒杀库存的情况
测试:秒杀开始后,锁库存时存在小概率被下订单成功,此时会取原库存而不是秒杀库存
 
语录:锁的时间太短,主要是多种售卖场景用同一个商品库存的方案导致

2021年5月26日

 问题:推送众测消息异常
测试:推送了同日但属于去年众测活动的酒款消息
 
语录:消息推送要加上年份的判断,测试时如果有定时推送场景,看看跨年的会不会有影响

2021年6月4日

 问题:动态人工上架,话题标签缺失
测试:机审下架后再次手动上架,话题缺失,人工下架后上架不会缺失
 
语录:测试用例设计遗漏,测试时长链路的流程需要考虑

2021年9月7日

问题:每周五 10 点之后几分钟内偶现进入任何 H5 页面报服务器错误的问题
原因:抽奖码页面在服务端渲染时开启了定时器(严禁这么做),作用是在活动结束后刷新页面。定时器是脱离于页面渲染异步工作的,这会造成即使页面请求已经到达客户端甚至客户端与服务端已经断开了连接,定时器依旧会继续工作在服务端,与之相关的页面内存也无法得到释放,因此每次请求抽奖码页面都会在服务端生成一个定时器,项目持续运行时间越长,内存中定时器的数量就越多。在 8 月 20 日那天,单台服务器中的项目已连续运行 7 天,单台服务器中累计了约 9 万个定时器。由于抽奖码活动运营设置的都是每周五早上 10 点开奖,因此每周五早上 10 点那些在服务端内存中的定时器都会到达预定时间执行相同的刷新页面逻辑,而这个逻辑会调用只有在客户端才有的 API,因此会一下子产生定时器数量的错误,20 号那天在 4 秒内就产生了 400 MB 大小的日志文件。这个错误的发生会被框架的全局错误捕捉器捕捉到,捕捉之后的处理方式为重定向页面至统一的渲染失败页面。而发生在抽奖码页面的错误会影响到其他页面渲染的原因是全局错误捕捉器重定向指令的发送是针对于两端连接会话的,当用户访问其他页面时会话并没有断开,此时重定向指令虽然由抽奖码页面发出,但是实际生效页面就可能是任何其他页面
 
解决:去除定时器在服务端开启的逻辑并继续跟踪错误的发生
 
语录:最终是开发定位的原因,牛皮的开发合作起来最nice了

2021年11月17日

问题:商城订单订单关闭后还能支付成功,但订单还是关闭状态

原因:支付宝支付超时写死了30分钟(支付宝支持分钟级以上的超时设置),商城存在定时任务,订单会15分钟自动关闭,用户如果停留在支付宝就会出现该情况,支付成功后没有判断订单状态,且没有自动退款的机制(账号原因),微信则是支付后更改订单状态为已付款。
 
解决:商城订单支付目前有2个延迟消息来触发订单自动关闭,一个是下单时发送的延迟队列,一个就是拉起支付时的延迟队列,目前这两个延迟队列的时间都是取得后台配置时间,不是一致的,后一个基本没用。现在要用起这个没用的延迟消息,当下单时的消息过来的时候,判断订单是否付款中的状态,如果是付款中状态,就不关闭订单,只有支付的消息过来的时候才能关闭付款中状态的订单
 
语录:涉及钱的东西需要多投入测试资源,需要深入理解数据流转链路。

2022年1月5日

问题:闲置支付偶尔能支付成功,偶尔支付成功后,会直接退款,订单会处于付款中
原因:支付后,支付宝会回调服务端,由于服务端的服务有时没有注册上。导致支付宝回调失败,而服务端就以为没有支付,然后就显示未支付,然后超时订单关闭后,支付宝那边再回调就会退款了
 
解决:因为该问题属于偶发性的,当时查了很久,最后才排除是服务偶尔注册不上的问题
 
语录:涉及第三方对接,则需要清楚互相调用的链路,重要的业务线上日志最好详细点,方便后续跟踪
附一张支付宝调用流程图:

2022年1月10日

 问题:盲盒问题,活动进行中有用户反馈下不了单,并且领取的盲盒变成了寄存已过期状态
原因:多个盲盒批量领取时,存在部分盲盒领取失败(盲盒商品下架了),导致下单报错,整个盲盒的状态被改为寄存已过期
 
解决:出现上述情况时,盲盒领取失败,不修改状态,整个盲盒可重新领取
 
语录:批量操作时,需要考虑部分异常情况,是否有回退机制,以及考虑操作记录的个数上限

2022年2月9日

 问题:钱包提现数据异常,存在特定用户充值300元,多次提现约9千多元
原因:钱包提现的接口由于多服务部署,没有分布式锁
 
解决:行政方面,首先收集证据,进行报警处理;技术方面,加上分布式锁(替换单机锁)
 
语录:涉及金额的需要做下并发测试,开发可能不会深入思考分布式问题。