Bug 无论是对于测试还是开发 来说,应该都不陌生,虽然我们经历的大部分bug有的被其他人修复了并且在 互联网 分享出来了,这时候我们通过Stackoverflow、Baidu、 Google 等搜索引擎找到答案了。
但是我们在工作中也可能会遇到一些疑难的bug,这里bug我们在搜素引擎上找不到解决方案,可能好几天都不得其解,这些迟迟没有解决的bug往往搞得人焦头烂额。
那作为一个苦逼的程序员,究竟碰见过哪些高难度的bug呢? 下面,我们来看看他们与 bug的故事。
程序员小罗:
写JS,自己手机没电了,拿同事老张的安卓机调试,很简单的获取用户微信昵称,结果死活获取不到,一直显示为null。应该是跨平台问题,因为之前在自己iPhone上是没有bug的,拼命看api文档,但是都没提到这方面。急死我了。 ......刚刚老张告诉我他的昵称就是null。......老张已被打死......前面夸张修辞,老张最后当然没死,腿打断了而已。
电商行业 程序员 小马哥:
也谈谈自己遇到的一个bug吧,我之前是做电商的,某较大的电商平台,突然有一天,C2C的店主反馈,看到的订单不是自己的,看到后台的商品列表也不是自己的。 当时在睡午觉,看到这个问题,立马吓醒了,平时5个投诉就是一个故障单,那还都是一点体验上的小问题,这种订单混乱,商品混乱的错误,真是要紧急死了 于是,主管,总监都来看这个问题,一群大佬在后面看着,赶紧找最近几天的发布,测试情况,一个个回退,一个个检查,最后都无法解决问题,要知道时间一分一秒过去,半个小时还解决不了就要出大事了 后续又有用户来投诉,直接电话联系,远程控制电脑,发现操作起来巨慢,于是顺口问了一下用户的网络是什么网络。 结果他说是:“某城宽带”,一瞬间,有点感觉了,继续问其他几个投诉的客户都是“某城宽带”,然后我们打电话到那个宽带的运营商,得到的回复是“年底了,为了省流量,他们做了一部分缓存” 他们做了缓存做了缓存 …… 缓存 …… 存 …… 可是为毛TM的动态请求还做缓存啊,修改商品和订单的时候,随机返回成功或者失败 ...... 1.这个和时间戳也没关,我们都加了token的,他们也忽略了
2. 你没猜错,他们把POST和GET动态请求也缓存了,就是说你提交了一个POST修改商品的请求,他从环缓存里面随便丢个回复给用户,用户感觉修改成功了,其实请求根本没到我们这边 , 是的,就是这么丧心病狂。
系统管理员老王: 从前 我是个 系统管理员,平时去机房登录服务器时都是站着操作。有一次腰疼,搬了个凳子坐在了机器前面,完蛋,死活登录不进去,提示密码错误。于是 我 站了起来,重新输入了一次密码,进去了。 后来 我 觉得奇怪,于是抽时间做了测试,发现:只要一坐下,就密码错误,站起来就好了。 这个 Bug 在 我 的职业生涯中持续了好几年 ,一直以为是什么灵异事件。 直到有一天公司升级设备给 我 换了个键盘。原来是老键盘上有两个键装反了,站着打字是看着键盘,坐着盲打就错了 ,真的是很无语啊……
海外程序员Steven:
曾经听说过一个让人目瞪口呆的bug,分享给大家。 该bug发生于麻省理工,当时其系统管理员接到统计系主任的求助电话,主任在电话中说:“咱们的邮件系统无法发送距离 500 英里以外的地方,准确地说好像是 520 英里。”
此时的系统管理员内心是“毫无波澜”的,嗯!
然后,他开始了漫长且苦逼的测试,最后发现邮件服务器操作系统(SunOS)被人更新了,因为操作系统发行版往往配备旧软件,因此邮件软件实际上是被降级了(Sendmail 8 -> Sendmail 5) ,最后的结果是:Sendmail5 试图解析Sendmail8 的配置文件。
所以,为什么一定是 500 英里呢?且看大神讲解:
原因是这样的,Sendmail 5面对陌生的配置文件,凡是不理解的部分都会忽略,凡是没设置过的配置项自动设置成0。这样其中有一个被设置成0,只一向就是(连接远端SMTP服务器的超时时间)timeout to connect to the remote SMTP server。后来经过实验,发现0秒的timeout会导致Sendmail在3毫秒后中断连接。
所以,你会问为啥是500miles?
在当年,MIT的校园网是没有那么多router的,也就没那么多网络延迟,所以连接一个远端主机的时间大概是光所需的时间。于是3毫秒,就意味着:
0.003*3*10 8 *0.001*0.621=558.9000000000001
558英里。也就是588英里以外的服务器,都无法连接到,而588以内的服务器,都可以正常通信。
面对这些各式各样难调的bug,那 程序员如何快速高效的改 bug 呢 ?
先根据情况试一下下面的步骤: 1. 换个环境试试 2. 换个用户试试 3. 换个操作方式试试 4. 换一下数据试试 5. 换个浏览器试试 6. 换个版本试试 根据上的情况搞清楚下面这几个问题: 1. 这个BUG什么情况下出现?什么情况下不出现?两种情况的区别在哪里? 2. 这个BUG之前没有,现在出现了,中间都动了什么? 3. 这个BUG生产环境出现测试环境不出现,两个环境区别是什么? 4. 同样的功能,这样操作没有BUG,那样有BUG,两个操作的区别是什么? 这些问题搞清楚了,先尝试采用代码回退、配置调整、环境替换等方式验证BUG是否会消失,然后再找其中的原因。 下面列出一些常见的疑难BUG类型以及每种BUG的诊断方法: 1. 输出结果与预期不符, 这种BUG一般都是由于代码逻辑错误造成的,如果能在开发环境重现,最好解决方法就是单步调试,设定每一步代码的预期结果,然后跟踪判断实际结果是否与预期结果一致 。 2. 系统异常报错, 这种情况下需要提取日志,找出错误堆栈信息,这时候最重要的事情是要把堆栈信息看懂、看完整 , 而且往往堆栈信息是一个套一个输出的。 3. 系统Crash, 这个问题常见的原因是负载过高、并发过高、或者配置错误。最常见的就是内存溢出。这时候要首先排除配置错误的原因,主要靠查看Crash Log来分析原因, 再 排查硬件、内存、网络等方面的设置,看是否有配置错误的地方。再找不到就在测试环境用开发模式进行压测和调试。 4. 系统响应缓慢 ,这种问题一般是存在资源竞争或者系统资源不足的情况,先检查服务器内容、CPU、网络情况,如果服务器压力过大,排查应用系统负载情况是否异常,如果这些数据都正常,就需要排查代码中的性能瓶颈。特别需要留意依赖第三方接口的情况,比如同步的方式发送邮件、发送短信、写文件等。
总结:
bug千奇百怪,不是每个bug都需要经历所有流程的。每个步骤都有它的难点。 有些bug难在事发点的定位,比如多线程,异步逻辑中的bug; 有些bug难在原因很难分析,多数是你看不懂代码; 有些bug难在你不敢改,那是你的修改方案没有做好充分的分析。
欢迎加入 51软件测试大家庭,在这里你将获得【最新行业资讯】,【免费测试 工具 安装包】,【软件测试技术干货】,【面试求职技巧】... 51与你共同学习,一起成长!期待你的加入: QQ 群: 755431660
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:- 当 Structured Streaming 碰到 Kafka
- 「学习笔记」无法远程访问 MySQL 碰到的坑
- Junit单元测试碰到静态变量如何处理
- IT 职场新人碰到的几个常见误区
- React小知识(3) - 国际化中碰到的问题
- 无依赖开发中的碰到的问题——封装DOM操作
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
Base64 编码/解码
Base64 编码/解码
HEX HSV 转换工具
HEX HSV 互换工具