如何彻底消灭Bug？

提高缺陷响应力有助于提升软件质量，如果我们不能把Bug扼杀在摇篮里，就尽快干掉它，把它变为一个happy accident吧！

太长不读版

Why do programmers prefer dark mode？ Cause light attracts bugs.

Bug从哪儿来？

对任何人来讲，搞清楚“我是谁、我从哪儿来、我要到哪儿去”都不是件容易的事情。对Bug来说也一样。

Bug从哪儿来，如果这里的Bug是指单词的话，问的就是这个词是怎么来的；如果是指词义的话，Bug这个词很多种词性，放在这里应该是个名字，名词的Bug有三种解释，臭虫、故障和窃听器。如果我们不指明上下文的话，读者可能会按照自己的背景去解读这句话，显然对于生物学家、码农和间谍来讲，对这句话的理解是完全不同的。

逻辑语言是有限的，而现实世界是无限的。佛系青年庄周说：“吾生也有涯，而知也无涯。以有涯随无涯，殆已！”，什么意思呢？就是说软件是不可能没有Bug的。软件是对现实世界的抽象，以有限的软件逻辑去抽象拥有无限可能的现实世界，必然会有不match的情况，于是便有了Bug。

好，看上去我们已经达成了共识，软件不可能没有Bug。对于这句话，以发现Bug为己任的QA们并不买账，他们会把毕生的精力投入到让Bug数无限趋近于0的测试活动中去。那么，如果说我们不可能穷尽测试去找出软件中所有的Bug，我们该做些什么才能让Bug少一点呢？让我们先来研究Bug是如何产生的吧。

Bug产生的原因多种多样

想象一个典型的场景，QA同学找到Dev提一个Bug，可能收到的回复有哪些呢？

“Sorry，打错了。”

“我去，Copy忘改名了！”

“这是哪个XX动了老子的代码！”

“哦我周末没事重构了一把，忘了跟你说。”

“这块功能从我来公司就是这样的。”

“在我这儿是好的呀，你环境问题吧？”

“这不是Bug，这是designed so，我们找BA去。”

“Story里没写呀，我不知道。”

“靠，这个case太corner了吧，真想不到。。。”

我们来把这些回复归归类，就能得到Bug是从哪儿来的了。如下图：

基于我们上面说的“现实世界是无限的”，所以这个图现在不是完备的，以后也不会。（我能说这个图的精髓在于省略号吗？）就像项目上经常做的“Bug Root Cause Analysis - 缺陷根因分析”，我们试图用一张图穷尽Bug产生的原因，一个维度不够再加一个维度，而这个图却迟迟出不了终版，估计以后也不会有，但这并不妨碍大家追求完美软件的心。

消灭Bug v0.1：加测试 & 提升代码质量

企图从所有原因上堵死Bug这条路看来走不通，有的同学说了，我不想知道Bug是怎么来滴，我就想知道Bug是怎么没滴。老生常谈的是增加测试和提升代码质量。我们来看一下，不管是测试左移鼓励测试早介入，还是测试金字塔鼓励测试下沉，都说明了增加测试是一个有效的方法。但是，就好像TDD不是银弹一样，如果你没测到呢？我们再来看一下，Code Review和结对编程确实能提升代码质量，但是，如果大家都没测到呢？如果Bug就是产生了呢？如果重大Bug就是上了生产呢？

我们再来讨论“提升代码质量”，关于这一点我是存疑的。首先说出发点是好的，确实需要提升代码质量，但是我不认为这是一个完全有效的消灭Bug的方法，相反的，“只要开发人员好好写代码，就能消灭Bug”，就好像说“只要我们付出努力，就能走向人生巅峰”一样苍白。提升代码质量非一朝一夕之功，这是其一。其二，就算是技能再好的程序员，只要是人，就有可能犯低级错误，而据统计低级错误占Bug产生原因的比例可是不低的。让我们走出完美世界的幻想，面对现实吧。

消灭Bug v0.2：提升缺陷响应力

就像大禹治水疏而不堵，我们换个角度来考虑一下，万一重大Bug上了生产，如果能飞速解决掉，用户甚至毫无感知，那么也算是及时止损了。如何能更快的解决Bug呢？经验告诉我们，如果修复一个Bug总共花了两天，那么定位Bug大约会花一天半，大部分的时间都会花在“找Bug”这件事情上。如果能缩短“找Bug”的时间，就能提高我们的测试效率，提高我们的缺陷响应力（缺陷响应力这个词没见过吧，现编的）。

何为高缺陷响应力？分为三个含义，一是能在开发阶段尽早发现问题，二是上线后能快速定位分析问题，三是生产环境有问题能及时反馈。

为了快速发现问题，我们提倡小步提交，提升自动化测试覆盖率，测试挂了CI很快就反馈了，有问题的代码不会被部署上去，况且变量少也好排查。这就是为啥QA总在孜孜不倦的提醒大家“补测试”。当然了，就算测试覆盖率达到99.99%，也不能保障完全没有Bug，所以我们还有其他的实践来作为补充。

为了快速定位分析问题，我们提倡日志监控和收集，提倡测试右移至生产，引入更多方便有效的工具帮助我们快速定位。举个例子，很多项目都会建立完善的监控和告警机制，上线后持续监控，以便于发现重大缺陷后马上修复滚动部署。持续监控是一方面，而另一方面，我们还要保证监控到的日志包含需要定位问题的有效信息，这就要求我们建立完善的日志规范，严格遵守日志分级，日志描述内容应该和程序的行为保持一致。怎样输出有效的日志是另一个话题，在此不展开讨论。

为了保证问题的及时反馈，我们也需要建立快速的响应机制。在某些对实时正确性要求比较严格的行业，如实时交易系统等，可以通过滚动部署和切换灾备服务器的方式来快速响应重大线上事故。而对于一些业务较为复杂的大型管理系统而言，建立分级的响应机制必不可少，针对不同严重性的问题，可以采取不同的响应措施，确保重大问题的及时反馈。

这些项目常用的敏捷实践不再赘述，但需要强调一点，即测试工作的本质——控制变量。任何时候，先想清楚再做事情总是不差的，在遇到问题时，先尽可能的缩小排查范围，是事半功倍的关键。

总结一下，提高缺陷响应力有助于提升软件质量，如果我们不能把Bug扼杀在摇篮里，就尽快干掉它，把它变为一个happy accident吧！（为啥happy？因为Bug修了呀）面对这些恼人的Bug，希望我们不论身处什么角色，都能保持一份乐观向上的积极心态，就像本文的小标题一样，永远有持续改进的上升空间，因为我们必将永远行进在无限逼近完美的道路上。

最后送一个段子，皮这一下挺开心。

要想Bug少，需求关把好；

场景考虑全，用户体验好；

编码需细心，逻辑知多少；

Copy一时爽，忘改不得了；

测试需有效，环境管理好；

缺陷响应快，用户都说好。

来源于圆小豆的美梦工场 ，作者喜乐本豆