反思了下,解决问题无外乎3w1h when where who how 就是查询出来的事情多了,现在不知道哪个地方出问题,应该根据日志一步一步梳理,查看每一步的输出结果是否与预期一致 顺藤摸瓜 觉得不清楚的地方,可以新增打印,或通过其它方法获取这些不可知的信息. 已经确认没有问题的代码,不能出异常情况时,就开始漫无目的的怀疑,张驰有度... 严格的讲这个Bug还没有彻底解决,因为没有找到真正的原因 重启下服务就好了!!!!!!!!!!!!!!!! 主要想梳理下操作流程: 当时的反应: bug出现

问题:QA突然发个截图说一个Dialog上展示的东西变形了 分析:不理解,什么也没做,怎么会变形,刚刚我用的时候还正常.看看代码,的确什么也没更改:在本地测一下,也没有问题:baidu,bing,stackoverflow下,没找到什么线索 突然看到一个ComboBox下面有一个item的值比较长, 布局使用的是GridBagLayout,也就是相对布局,如果设置Size是固定的,如果有一个控件变大,则整体的布局变形了 因此这个Combobox item的值比较长解决了,这个问题就解决了. 解决

摘要: 除了吃瓜,还是得吸取教训啊同学们! 这次,我从纯技术角度分析腾讯云与前沿数控的磁盘数据丢失事件,不站队. 硬盘门 这里说的硬盘门不是10年前陈老师的那一次,而聊的是最近"腾讯云"用户"前沿数控"的磁盘数据丢失. 关于这次事件,腾讯云是这样说的: 近日,腾讯云用户北京清博数控科技有限公司所属"前沿数控"平台一块操作系统云盘,因受所在物理硬盘固件版本bug导致的静默错误(写入数据和读取出来的不一致)影响,文件系统元数据损坏. 腾讯云多少有点打

前言 最近接收了一个老项目,突然甲方 QA 报了一个 bug,连续请求 60 次,成功 8 次,后面的 52 次全部失败,而且成功的 case 返回时间普遍较长.看了日志,并非业务上的异常.这让刚毕业没什么经验的我,顿时陷入了沉思.但回过神来考虑了一下,大胆才猜测,可能是网络问题或者是并发请求上的问题. 但其实业务异常相对容易排查,而网络或者并发的问题会相对难一些,刚好自己对于服务器服务器请求处理的流程也不太清楚,所以就花了时间看了下,最后基本断定是接口是实现方式出现了问题,重新改写成异步接口后

时间线 大约在2020年10月,内网测试服服务端更新,发现进程A重启后,与其他进程之间的心跳协议不通,不能正常的提供服务.重启后,就正常了. 这个情况持续了很长时间.只在重启时才会出现,且发生概率很低,一个月一次的概率.所以这个问题就被搁置了. 现网部署后,发现更新时,也出现了这个情况,但是由于重启就可以解决,这个问题被归属为:重要但不紧急的范畴. 大约2021年5月,花了一些时间尝试解决这个问题.由于没有找到重现的步骤,所以等待出现问题时观察现场.后面有一次出现了,进行排查: 看日志,没有异常

mybatis与数据库交互时,报了莫名其妙的错,日志中显示的Stack Trace中报错的代码行数与IDE中还一致,逐重启tomcat,异常消失. 故障复盘:没有重启tomcat,使用copy命令直接覆盖原来的war包.   是不是应该先删除war文件,等tomcat自动把这个context删除后,然后再copy 新的war文件过去? 启示:如果报错日志中的代码行数与实际部署的不一致时,可以认定实际运行的java byte code,不是最新.需要重启下tomcat 重启电脑后,Idea提示St

听同事说有一个功能不好使了,当时有事,过了一段时间来看看这个bug 解决问题时,看的是老的日志,根据老日志看来看去没有发现问题,觉得很困惑 然后手动执行了一下,发现问题没有重现.与另一个团队的同事沟通下,说是他们那边把代码回退了. 总结:解决问题时,要重现bug,并取最新的日志.从引发问题的最接近的原因开始一步步分析,一层层的排查故障

公众号做了新需求:菜单的click事件,支持多条客服消息. 上线后,只有一个功能不好使,是点击菜单,预期发一条文本类型的客服消息. 实际操作时,点这个菜单项后,什么也没有发生. elk上看日志,也没有什么报错.也不应该有报错,如果后端服务异常,公众号上会提示,“服务不可用”如果在后台打开 菜单管理 页面,什么也不做,再点个 保存 ,菜单 的功能就恢复正常了. ====================================================================

在学习<问题分析与解决>时学到了一种找到问题根源的方法——问五次为什么.具体内容是:当遇到一个问题,不要只看当前答案,要继续往下问,为什么,连问五次,就能够找到更深层次的问题.最近在复盘bug的时候,也使用了这种方法,屡试不爽. 案例 前端发布后,页面按钮点击失效,用户反馈问题,前端回滚代码后恢复.问题一.为什么按钮点击会失效?因为前端代码写出了一个bug,没有对空对象进行判空,导致页面js抛出异常,按钮失效.一般到这里就结束了,把代码加上对象判空,继续发布就完成了.但是大家集思广益,问五次为

写在前面的话 <Docker+SpringBoot+Mybatis+thymeleaf的Java博客系统开源啦> <Java开源博客My-Blog之docker容器组件化修改> My Blog项目已经开源了两个多月,也收获了不少star,在这里谢谢各位朋友的建议及帮助.由于个人原因,这个开源项目最初的定位其实是一个docker技术与springboot框架整合的Java博客系统实战项目,而且是一个容器技术的练手项目,技术的偏重也更多的在容器技术及容器编排上. 虽然上个版本做了一些改

在测试账户系统过程中遇到了线上大面积用户登录态失效的严重问题,事后对于其原因及测试盲点做了一些总结记录以便以后查阅,总结分为以下7点,其中原理性的解释有些摘自网络. 1.账户系统token失效问题复盘2.Redis 经典流程3.Redis分片部署方式4.Redis扩容导致缓存数据失效5.Redis Sharding一致性hash算法6.缓存失效,缓存击穿,缓存穿透7.Redis缓存测试总结 账户系统token失效问题复盘现象:redis扩容后线上大量用户登录态失效,需要重新登录.由于登录态可以持

说起程序猿,总绕不开的一个话题就是bug,估计每个程序猿听到某某测试跑过来一脸淫笑的告诉你这个功能有个bug的时候,总有种恨不得掐死他的想法.其实程序猿跟bug的关系,感觉有点像父亲和儿子的关系,自己制造的bug,哭着也要自己解决,就像自己生的儿子,哪天又犯了错,就算气得恨铁不成钢,也要教育他帮他改正一样.好了,扯远了,按照一般程序猿的心理,bug再正常不过了,解决就是了.可是你想过,解决bug的时间和人力成本吗? 1.bug从修复到解决的流程 通常情况下,一个bug从发现到解决的流程应该是这几

SQL Server 2017的Linked Server配置触发的bug"Exception Code    = c0000005 EXCEPTION_ACCESS_VIOLATION"   现象描述: 数据库版本:SQL Server 2017 (RTM-CU14) (KB4484710) - 14.0.3076.1 (X64) 出现大量的Dump File文件,如下所示: 其中一个SQLDump748.txt如下所示: Current time is 05:00:20 05/17

行进中的波折 革新总会面对一些阻力和风险,一种新的观念.一种新的模式要来替代既有的产品,从来都不是一件简单的事,在WMS改造这件事上我们一开始就提出两种概念货物驱动和任务驱动,并找到一个标杆产品Slack就是为了建立心理上的信任感,并从侧面证明这件事不是一件纯新的模式,提供成功案例来降低阻力,但在实际落地的时候还是没有多么顺利. 惯性的强大力量 有时候大家不支持和反对,并不是真的不支持和反对,而是因为习惯某一种模式和状态,而恰恰新的设计和他熟悉的不同. 习惯就意味着第一时间出现在脑中的就是那个样

itest 入选 2019 年度最受欢迎开源中国软件 开源工具的发展,离不开你我的支持,需要您投上宝贵的一票  去投票 itest 简介:查看简介 itest 开源敏捷测试管理,testOps 践行者.可按测试包分配测试用例执行,也可建测试迭代(含任务,测试包,BUG)来组织测试工作,也有测试环境管理,还有很常用的测试度量:对于发版频繁,需求常变,itest还可导出用例,线下修改.执行,新增后再导入(同步)到线上:且可根据测试策略来设置测试流程,并可实时调整:在测试看板中,能查看迭代报告,测试包

itest 入选 2019 年度最受欢迎开源中国软件 开源工具的发展,离不开你我的支持,需要您投上宝贵的一票  去投票 v4.2.0下载地址 :itest下载 itest 简介:查看简介 itest 开源敏捷测试管理,testOps 践行者.可按测试包分配测试用例执行,也可建测试迭代(含任务,测试包,BUG)来组织测试工作,也有测试环境管理,还有很常用的测试度量:对于发版频繁,需求常变,itest还可导出用例,线下修改.执行,新增后再导入(同步)到线上:且可根据测试策略来设置测试流程,并可实时调

线上BUG说处理方法:1.关于线上BUG问题,目前公司有一整套线上故障流程规范,包括故障定义.定级.处理流程.故障处理超时升级机制.故障处理小组.故障处罚(与故障存在时长有关)等:2.最主要的是,线上故障是研发和测试团队的KPI,KPI计算是分开的,线上只要出现BUG,研发必须承担责任:对于测试来说,是复盘的时候确认是不是漏测,只有漏测才会计算测试责任:3.最重要的是,公司从上下都重视这套故障流程规范,所以应该先建立规范:并让大家都认可,这样研发在开发的时候才会尽心尽力,测试也有更多时间做测试的

一个wap端改版项目完结了,总结下测试过程中的典型性bug:应该从哪个角度去总结? 有点疑问?不知道是以bug的影响度去总结,还是以优先级去总结(好像优先级和影响度是成正比的,优先级比较高的bug,影响度一般也是比较大的) 以测试角度去总结的bug:和开发自己总结的典型bug:好像都是不一样的(筛选角度不一样吧) 项目中功能测试占比90%,筛选典型bug,大都会以功能业务去筛选bug(一般这种bug出现的原因,就是开发对需求理解有偏差或者手下误) 接口测试占比比较少,还是有时间就测试接口:没有时

Bug复现 使用Webbench对服务器进行压力测试,创建1000个客户端,并发访问服务器10s,正常情况下有接近8万个HTTP请求访问服务器. 结果显示仅有7个请求被成功处理,0个请求处理失败,服务器也没有返回错误.此时,从浏览器端访问服务器,发现该请求也不能被处理和响应,必须将服务器重启后,浏览器端才能访问正常. 排查过程 通过查询服务器运行日志,对服务器接收HTTP请求连接,HTTP处理逻辑两部分进行排查. 日志中显示,7个请求报文为:GET / HTTP/1.0的HTTP请求被正确处理和

itest 简介 test 开源敏捷测试管理,testOps 践行者.可按测试包分配测试用例执行,也可建测试迭代(含任务,测试包,BUG)来组织测试工作,也有测试环境管理,还有很常用的测试度量:对于发版频繁,需求常变,itest还可导出用例,线下修改.执行,新增后再导入(同步)到线上:且可根据测试策略来设置测试流程,并可实时调整:在测试看板中,能查看迭代报告,测试包执行情况,测试任务进展,也可以在看板上直接执行用包用例,具体介绍详见下面开源中国连接:itest 入围2019 最受欢迎国产开源软件