为何修复每一个 bug 后都要问这 3 个问题？

你是否曾经修复了一个 bug ，随后又发现了一个跟刚修复 bug 有关的 bug ，又或是修复 bug 的方式引发了另外一个 bug ？当我修改 bug 时，我会问本身三个问题，以确保我已经仔细考虑了它的意义。每次你认为发现并修改了一个 bug 时，可使用这些问题来提升生产力和代码质量。

这些问题背后的主要思想就是：每个 bug 都是底层进程的一个不良表现。你必须处理这些症状，但若是你仅仅是处理这些外在症状，你就会有永远解决不完的问题。你应该找到产生 bug 的进程，而且修复这个进程。当你肯定究竟发生了什么和发生这些的缘由时，也许你就会明白产生 bug 的基础进程不是随机的，而是可控的。

在问这三个问题前，你须要克服面对 bug 的这种天生的抗拒，仔细分析 bug 。查看代码并解释出错的缘由，从能观察到的现象开始，向后分析，不断地问为何，直到你能够找到产生 bug 的模式。一般，你该跟同事一块儿作这件事, 由于解释你认为会发生的事情，将迫使你面对一些假设——这些程序是作什么的。

“它溢出了，由于下标J越界了。”

“为何？”

“J 是 10，但数组最大下标为 9。”

“为何？”

“J 是一个字符串长度，数组的起始下标是 0，因此字符串长度为 1 的最后一个字符的索引是 0。”

找到 bug 后，查找其余意外状况。检查程序出错时主要的程序变量的值，是否能够解释这些值。

“为何 name 是 null？”

“为何它老是输出错误信息呢？”

记录下你作了哪些操做，发生了哪些变化。你须要知道究竟发生了什么，这样作就意味着你时刻有一把标尺和历史记录。

当完成这些步骤后，你能够准备问第一个问题了。

1. 其余地方也会出现这个错误吗？

查看代码中使用相同模式的地方，系统地改变模式找出相似的 bug 。

“我还在其余什么地方使用长度做为下标的吗？”

“全部数组的起始下标都同样吗？”

“对于一个长度为 0 的字符串会发生什么？”

试着描述这部分代码中应该是正确的，可是这些 bug 没有遵循的规则。寻找这个不变量 [ 1 ]的过程将帮助你找到其余潜在的 bug 。

“起始偏移加上长度减去1就是结束的下标，除非数组长度为 0”。

对于你发现的每个 bug ，你均可以解决一批 bug ，这是很是高效的。尝试用归纳性的语言描述这些 bug 也能提高你对程序的理解程度，并帮助您避免在程序中引入更多的 bug 。

2. 这个 bug 后面隐藏着什么其它的 bug ？

一旦你肯定了如何修复这个 bug ，你就须要考虑一下修复后会发生什么。这个执行失败的语句后面的语句也可能有问题，可是程序尚未执行到此就不知道有没有 bug ，或者有些代码由于你修复 bug 而第一次出如今程序中，这些代码也可能有问题。查看这些未执行的语句，检查代码中的 bug 。

“下一条语句会正常运行吗？”

当你在想程序的控制流的时候，能够弄清楚还有哪些地方程序没有执行到。

“是否有我历来没有测试过的功能组合？”

在程序中插桩（instrumentation）并不会耗费太多时间，在运行程序各个部分的过程当中就能够进行检查，可是你会惊讶地发现开发者测试过的代码还有不少都不能正常运行。

“我能够测试出全部的错误信息吗？”

注意一个地方的改动可能会引发其余地方的 bug 。一些变量的局部改动可能会在执行时违反后来的假设。

“若是仅是从 J 中减去 1，当长度为 0 时，后面的语句会操做数组中 -1 位置的元素。”

若是程序已经作了大量改动，就要仔细考虑是否有必要增长另一个补丁，或者是时候考虑从新设计和从新实现了。

（有时候调 Bug 就是这样的）

3.我应该作些什么防止相似 bug 的产生呢？

问问本身如何改变编程方法，根据定义避免 bug 的出现，经过改变方法或者工具，常常能够移除整个类的错误而不用一个一个的解决 bug 。

若是对软件测试、接口测试、自动化测试、性能测试、LR脚本开发、面试经验交流。感兴趣能够175317069，群内会有不按期的发放免费的资料连接，这些资料都是从各个技术网站搜集、整理出来的，若是你有好的学习资料能够私聊发我，我会注明出处以后分享给你们。

从“ bug 是什么时候引入的”这个问题开始：在程序开发生命周期的哪个阶段能够阻止 bug 的产生？

“设计是没问题的；我在编程时引入了 bug 。”

仔细检查 bug 产生的缘由，考虑 bug 产生时正在运行的进程，并想一想怎么改变它来阻止 bug 的产生。

“将偏移的数据类型和长度分离出来将会在编译时捕获这个错误。”

“每个文本项能够用隐藏了下标计算的宏输出，而后我就能够一次找到它。”

不要知足于肤浅的答案。假如你对于一个 bug 的解释是，“我记不清了”，那还怎么改进这个过程，让你再也不须要记住它？你能够更改编程语言，使被忽略的细节能够彻底隐藏，不然你遗漏的部分会被检测到从而致使编译问题。对这个问题域，你可能使用了预处理器或者智能的编辑器，有默认值，错误检查，智能提示和快速文档。这个 bug 多是编程团队沟通的问题，亦或是须要讨论的设计冲突。

思考发现 bug 的方式，并问问本身如何能更早发现它。测试怎么能够更严密一些？可否进行自动化测试？是否要添加代码实时检测功能，以即可以及时捕获错误信息？

“我应该在个人测试单元中尝试长度为 0 的数组”。

“我应该进行下标检查，提早捕获不符合的下标”。

有必要建立一些系统方法和自动化工具，用于编译、构建和测试，它们能够减小长时间的调试和查明具体事实的过程。

这个技巧的应用

养成这样一种习惯：每当你发现一个 bug 时，问本身这三个问题，甚至你没必要等到有 bug 时才使用这三个问题。

在设计和审查过程当中，你均可以用这三个问题来处理你获得的每一条意见。审阅意见是潜在的沟经过程的结果，使你能够有所改进。若是你认为读者评论是错误的，好比，你可能会问是什么使你的文章没被理解，如何更好地与审稿人沟通。

设计评审和代码审查是找出 bug 的强有力手段，你能够对审查过程出现的每个缺陷都提出三个问题。若是审查完全，前两个问题不会出现太多新的 bug ，但第三个问题能够帮助你找到方法，用来避免将来可能会出现的 bug 。

扩展阅读

• 学软件测试最好的几本书，这8本书能帮你不少
• 软件测试7年的工程师，讲述当初是怎么突破的瓶颈？少走弯路