WatchStor.com — 领先的中文存储网络媒体 | 51CTO旗下网站

新闻资讯 > 商用办公 > 正文
如何写出一个让人很难发现的Bug?
作者: 佚名 2018-01-30 12:59 【五五】

程序员的日常三件事:写bug、改bug、背锅。连程序员都自我调侃道,为什么每天都在加班?因为我的眼里常含bug。

那么如何写出一个让(坑)人(王)很(之)难(王)发现的bug呢?

微信图片_20180129120634.jpg

1 -新手开发+新手测试=无敌巨坑

有一天凌晨,某组的程序员们被电话轰炸醒了。用户纷纷投诉自己的业务数据离奇消失了!

大伙排查半天,原来是新来的小王埋的坑。他三个月前开发的定时任务出bug了!

那时刚来的小王刷刷地将代码写完后,手把手教新来的测试实习妹子怎样测试这块代码,估计是妹子还没搞清楚里面的逻辑时便稀里糊涂地将代码上线了。

万万没想到这bug隐藏这么久,由于错误的逻辑导致错误的数据,错误的数据导致任务死循环执行,当执行的时间过长,到某个点时,系统如汽水开瓶般“砰”地崩了。

业务不熟导致逻辑理解有问题,是大部分新人都会存在的问题。此时最好安排个有经验的测试“调教”下,降低bug发生率。

微信图片_20180129120658.jpg

2 -不考虑系统拓展性,怎么方便怎么写

史上最出名的“千年虫”bug令全世界恐慌,甚至传出“世界末日”的谣言。

原因竟让人啼笑皆非:当时的程序员没考虑到软件会被使用至21世纪,为了节省内存省略掉代表年份的前两位数字”19”,或者默认前两位为”19”。

“千年虫“千年一遇,可日常关于时间的低级bug经常发生,而且通常等到一段时间后的某个特定时间点才暴露出来,让人防不胜防。

例如正则只匹配了“16”,“17”年,等到18年零点到来问题才暴露。

关于时间的bug非常多,大到闰年、夏令时、节假日、时区等,小到时间格式,每年都会碰到不小心遗漏的时间bug,所以很多公司对时间的通用测试用例就有许多条。

除了时间问题,程序员如果只考虑本次需求或者单个系统时,常常将字段设置不正确,后续业务拓展或者和别的系统交互时发现字段不够用,只能修改字段长度了。

微信图片_20180129120715.jpg

3 -不考虑上下游系统,招呼不打便随意改接口

曾遇到A系统上线后,大伙回归A系统正常运行后,正乐滋滋地松一口气之际,本来好端端运行的B系统突然坏了,B组人排查半天发现,原来是A提供的接口改了,B系统不兼容新接口。

大概程序员走过最长的路便是背锅之路了。

2005 年 12 月 8 日瑞穗证券的交易员因手误输入错的股价,2 分钟后这人试图通过交易软件撤销这笔卖单。可是连续输入 3 次撤单指令,都被东证的交易系统拒绝了。这次事故造成400 亿日元的损失。

后来查明是交易系统出 bug了,程序员在 2000 年某次程序修改时不小心埋进去的。

所以很多公司会严格要求在程序修改后必须经过严格的回归测试,来验证对其他业务流程有没有影响。

微信图片_20180129120737.jpg

4 -复制、粘贴,我闭着眼,有bug看不见,debug了没?

已发布已验证的代码,是安全可靠的,是可以拿来即用的,无需质疑,不用浪费时间去调试,这是程序员的惯性思维。

被记入史上bug王之一的阿丽亚娜5型自毁事件就是因代码复用而导致的。1996年6月4日,阿丽亚娜5型运载火箭发射点火后,由于bug,在发射39秒后火箭发生偏轨,最终被迫引爆自毁。

这件事情发生的原因是因为5型火箭是基于4型火箭开发的,发射系统的代码程序员也直接照搬4型的。

该段代码在4型火箭中被反复验证,但在5型却没有进行验证。实际上4型的飞行条件和5型的飞行条件截然不同,最终导致事故发生,此次事故损失3.7亿美元。

有测试工程师说,最害怕开发说这次没啥改动,跟线上某功能差不多。这时候反而要细心验证代码的正确性。

这是因为“安全心理”作祟:程序员直觉已信任上线的代码是正确的,便直接复制过来用,不会再花时间自测,因为这是“对的”,“毋庸置疑”的。

此时测试人员不可轻易听信开发的话,更要严谨对待,毕竟程序员的三大谎言有:没问题的;只改了两行代码;和线上一样。

微信图片_20180129120830.jpg

程序员花30分钟写程序,花2小时改bug。bug,子子孙孙无穷尽也。所以在面对测试人员的质疑时,程序员们一定要保持镇定,该甩锅时速速甩掉:这是历史问题,我没动过;刚刚在我这是好的,你环境配错了;你重启试试……

最后一招是两个字:我改!


标签:商用办公 

LecVideo