13年开发经验：总结了10条bug测试与解决方法

编码

这些是在过去給我带来棘手bug的所有问题：

1. 事件顺序：处理事件时，很有必要提出下列问题：事件是否可以以一种不同的顺序到达？如果我们从来没有收到该事件，会怎样？如果该事件连续出现两次，又会怎样？即使通常情况下这永远不会出现，但系统（或交互系统）的其他部分中的bug可能会导致这出现。

2. 处理太早：这是上述“事件顺序”的一种特殊情况，不过它已引起了一些棘手的bug，所以它自成一类。比如说，如果信令消息接收太早，在配置和启动过程完成之前接收，许多奇怪的行为就会出现。另一个例子：当某个网络连接还没有被列入空闲列表就被标为断开。调试这个问题时，我们总是假设它在处于空闲列表时被设为断开。没考虑到有时动作发生太早要怪我们没想到。

3. 隐蔽故障：一些跟踪起来最棘手的bug（一方面）是由出现隐蔽故障、继续执行而不是給出错误的代码引起的。比如说，系统调用（比如绑定）返回未加检查的错误代码。另一个例子：遇到错误元素后，直接返回而不是给出错误的解析代码。调用在故障状态下继续持续一段时间，这大大加大了调试的难度。最好一旦检测到故障情况，就返回错误。

4. if语句：有几个条件的if语句給我带来了许多bug。即使if语句概念上很简单，有多个条件需要跟踪时，它们也很容易搞错。如今我试着重写代码，力求更简单，避免要处理复杂的if语句。

5. Else：有几个bug是没有适当考虑如果条件为假会发生什么而引起的。几乎无一例外的是，每个if语句应该有一个else部分。此外，如果你在if语句的一个分支中设置了某个变量，可能应该在另一个分支也要设置该变量。与此相关的是标志（flag）被设定的情况。仅仅添加设定标志的条件很容易，但是容易忘了添加应该重新设定标志的条件。任由永久性设定的标志留在那里可能会在将来导致bug。

6. 不断变化的假设：一开始最难预防的许多bug是由不断变化的假设引起的。比如说，一开始，可能每天只有一个客户事件。然后，按照这种假设编写了许多代码。后来某个时候，设计发生了变化，允许每天有多个客户事件。出现这种情况后，就很难改变受到新设计影响的所有情况。很容易找到显式依赖该变化的所有项，但是难就难在，找到隐式依赖旧设计的所有情况。比如说，可能有代码读取某一天的所有客户事件。隐式的假设可能是，结果集从不大于客户数量。我没有好的办法可以预防这类问题，欢迎读者建议。

7. 日志：深入了解程序执行的任务至关重要，尤其是逻辑很复杂时。务必要添加足够多（但是别太多）的日志，那样你就能弄清楚为什么程序在执行它执行的任务。如果一切正常，日志并不重要，但是一旦出现了问题（这不可避免），你会很高兴添加了适当的日志记录。、

测试

作为一名开发者，除非进行了测试，否则我不会说搞完了一项功能。至少，这意味着每一行新代码或更改后的代码至少执行了一次。此外，单元测试或功能测试也很好，但还不够。新功能还必须在类似生产环境的环境下加以测试和探究。下面是bug在测试方面给予我的一些重要的经验教训：

1. 零和空：务必要以零和空（合适的情况下）来进行测试。对于字符串而言，这意味着既指长度为零的字符串，又指内容为空的字符串。另一个例子：在发送任何数据（零字节）之前，测试TCP连接的断开。没有使用这些组合来测试是bug悄然出现的头号原因，我在测试时是原本可以发现这些bug的。

2. 添加和删除：新功能常常需要能够为系统添加新配置，比如说用于电话号码翻译的新配置文件。所以测试它切实可行、以便添加新的配置文件很自然不过。然而，我发现很容易忘了还要测试配置文件的删除。

3. 错误处理：处理错误的代码常常很难测试。最好由自动测试来检查错误处理代码，但有时这不可能。这种情况下，我有时采用的一招就是，临时修改代码，让错误处理代码运行。要做到这一点，最容易的方法就是反转if语句，比如说将if语句由error_count > 0反转为error_count == 0。另一个例子是误拼数据库列名，让所需的错误处理代码运行。

调试

1. 讨论：在过去对我帮助最大的调试方法就是与同事讨论问题。我常常只要向同事描述问题，就足以认识到问题是什么。此外，即使同事不是很熟悉相应代码，常常也能給出好主意，表明哪里可能有问题。我在处理最棘手的bug时，与同事讨论这一招来得尤其管用。

2. 密切关注：调试某个问题花很长时间时，常常是由于我做了错误的假设。比如说，我以为问题出现在某个方法中，而实际上这个问题根本不会出现在这个方法中。或者抛出的异常并不是我假设的那个异常。或者我以为在运行软件的最新版本，实际上运行的是旧版本。因此，一定要核实这些细节，而不是犯想当然的毛病。很容易看见预期看见的问题，而不是实际摆在那里的问题。

3. 最近的变化：过去可以运行的代码现在无法运行时，这常常是最后一个变更的对象引起的。有一回，最近变化的对象只是日志，但是日志中的错误引起了更大的问题。为了让诸如此类的回归更容易找到，有必要在不同的提交代码中实行不同的变更，并且要清楚说明变更。

4. 相信用户：有时候用户报告问题时，我的本能反应是“这不可能。他们肯定是哪里弄错了。”但是我已学会了摈弃这样的反应。结果往往证明，用户报告的正是实际发生的问题。所以如今，我对用户报告的问题信以为真。当然，我仍反复核查各方面已正确设定。但是我碰过好多情况下，之所以发生奇怪的问题，是由于不同寻常的配置或意料之外的使用，而我默认的假设是，它们是正确的，程序是错误的。

5. 测试修正版：bug的修正版准备就绪后，它必须进行测试。先在没有修正版的情况下运行代码，观察bug。然后打上修正版，重复测试用例。现在，错误行为应该消失。遵照这些步骤可以确保它其实是个bug，确保修正版确实解决了问题。这很简单，又必不可少。

这13年来我一直在跟踪我遇到的最棘手的bug，这期间发生了很大的变化。我开发过一个小型嵌入式系统、一个大型电信系统以及一个基于Web的系统。我用C 、Ruby、Java和Python编写过代码。我用C 编码时期的几类bug已完全消失，比如堆栈溢出、内存损坏、字符串问题以及某些形式的内存泄漏。