如何写出一个让人很难发现的Bug？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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