偶发异常BUG,如何高效精准分析排查定位? 作为测试,经常会收到领导.同事.用户反馈过来各种各样BUG,令人措手不及 首选需要判断确认是不是BUG,不要急于给予回复,需有充分的条件给予说明回复 很多测试人员收到问题的反应: 需求没说这样? 不是BUG? 怎么可能是BUG? 这个我们测过的怎么会有问题? 肯定是环境问题? 肯定是程序偷偷改了东西的? 昨天还是好的呢?今天怎么这样了? 作为专业测试,我们应保持大度.精心的状态,正因为每次能遇到问题,我才能涨了更多的见识 收集BUG发生信息,拆分条件:…

Story background 回望2018年12月,这也许是程序员们日夜不得安宁的日子,皆因各种前线的系统使用者都需要冲业绩等原因,往往在这个时候会向系统同时写入海量的数据,当我们的应用或者数据库服务器反应不过来的时候,就会产生各种各样诡异的问题,诸如表现出来就是系统变得巨卡无比,无法使用,或者周期性卡顿,令人发指,用户轻则问候系统全家,重则心脏病发.总而言之每天都脑壳疼!归根到底是我们的应用服务器或数据库服务器因为扛不住流量造成的系统BUG问题暴露,诸如OOM等,呈现出机器的三高,这里说的…

原文链接:线上BUG:MySQL死锁分析实战 1 线上告警 我们不需要关注截图中得其他信息,只要能看到打印得org.springframework.dao.DeadlockLoserDataAccessException就足够了,就是MySQL发生死锁导致服务抛异常. 关于接口得逻辑,可以大概描述为:C端调用接口查询店铺得追踪事件列表,如果查询为空列表则顺便给初始化,这里的初始化是批量插入一批事件追踪列表,然后再返回,这里要给到一个关于表的信息点:这个表有主键索引和唯一索引. 1.1 云日志&死…

linux 阿里技术协会 摘要: Linux服务器上经常遇到一些系统和应用上的问题,如何分析排查,需要利器,下面总结列表了一些常用工具.trace tool:最后也列举了最近hadoop社区在开发发展的分布式系统的trace tool. 概览: 引用linux-performance-analysis-and-tools中图片, Linux服务器上经常遇到一些系统和应用上的问题,如何分析排查,需要利器,下面总结列表了一些常用工具.trace tool:最后也列举了最近hadoop社区在开发发展的…

Android BroadcastAnyWhere(Google Bug 17356824)漏洞具体分析 作者:简行(又名 低端码农) 继上次Android的LaunchAnyWhere组件安全漏洞后,近期Google在Android 5.0的源代码上又修复了一个高危漏洞.该漏洞简直是LaunchAnyWhere的姊妹版--BroadcastAnyWhere. 通过这个漏洞,攻击者能够以system用户的身份发送广播.这意味着攻击者能够无视一切的BroadcastReceiver组件訪问限制.并…

原文:Directx11教程(21) 修正程序最小化异常bug       很长时间竟然没有注意到,窗口最小化时候,程序会异常,今天调试水面程序时,随意间最小化了窗口,发现程序异常了.经过调试,原来程序最小化时候,屏幕的高度和宽度为0,此时创建深度缓冲会fail,所以在D3DClass.cpp的初始化函数中加入以下的代码,可以防止最小化时候程序异常. D3DClass.cpp增加代码: //Initialize函数包含完成D3D设置的所有代码. bool D3DClass::Initialize…

目录 引入 环境配置 编译体验 入口查找 代码分析 board_init_f pie 内存分布分析 SP设置 board_init_f 重定位 代码段重定位实现 变量地址修改 参考 title: uboot2012(一)分析重定位 date: 2019/02/23 21:53:21 toc: true --- 引入 关于移植,搜索关键英文词语portting 移植简单的介绍在readme中,手册是它的使用帮助 代码仓库地址 02-uboot重定位加入自己的代码 环境配置 这里使用编译工具arm-…

百篇博客系列篇.本篇为: v55.xx 鸿蒙内核源码分析(重定位篇) | 与国际接轨的对外部发言人 | 51.c.h.o 加载运行相关篇为: v51.xx 鸿蒙内核源码分析(ELF格式篇) | 应用程序入口并不是main | 51.c.h.o v53.xx 鸿蒙内核源码分析(ELF解析篇) | 你要忘了她姐俩你就不是银 | 51.c.h.o v54.xx 鸿蒙内核源码分析(静态链接篇) | 完整小项目看透静态链接过程 | 51.c.h.o v55.xx 鸿蒙内核源码分析(重定位篇) | 与国际接…

 排查流水账: 通过平台监控,发现很多偶发的查看推荐列表的接口时延大于0.5s 写单元测试,不能重现.在测试环境不能重现.只有在正式环境可以偶发重现. 通过日志埋点,等待重现 不断地加日志埋点后发现耗时在redis的hmget操作 这时猜想原因 hmget命令才会有,会不会是hmget命令的问题 查看redis的慢查询日志,发现没有慢查询.排除是Redis执行慢的原因 查看当时的负载情况,负载很低,并发也不多.所以排除是Redis的命令等待原因 多协程下,20条hmget,不会全部都卡,只会卡几…

1.严格按用例执行: 2.如果是作随机测试时,把测试步骤的点进行速记; 3.偶发BUG一般都是严重的,保留现场,让开发人员一起分析留下的现场(如数据的变化,界面窗口的变化等,找出问题的引子,那怕是千丝万缕,只要有一线希望,都要与开发人员一起分析,千万别关机(关机后再重启很多现场已破坏,不少数据是保存在闪存中的). 4.最好的做法:要求开发打开trace,测试版本在执行时能自动把测试的路径,或触发的消息等输出到文件,相当于软件的执行log,这个log对解决偶发问题将大有裨益. 5.即使一时没有重现…