13年的Bug调试经验总结

在《LearningFromYourBugs》一文中，我写出了关于我是如何跟踪我所遇上的一些最有意思的bug。最近，我总结了我所有的194个条目（从13岁开始），想到有什么经验教训是我可以自学的。下面是我总结的最重要的经验教训，还包括编码，测试和调试三个方面。

　　编码　　下面这些都是我经历过的会造成难题bug的问题：　　1.事件顺序。在处理事件时，明确提出下列问题不会很有效益：事件可以以有所不同的顺序抵达吗？如果我们没接管到此事件不会怎么样？如果此事件屡屡再次发生两次不会怎么样？哪怕一般来说会再次发生，但系统（或交互系统）其他部分的bug可能会造成事件再次发生呢。　　2.过早。

这是第一点“事件顺序”的一个特例，但它显然不会引发一些棘手的bug，因此我把它分开小黑出来解释。例如，如果信令消息在配备和启动程序已完成之前就被过早接管，那么有可能就不会有很多怪异的不道德再次发生。

另一个例子：相连在被放入空闲列表之前就被标记为down。在调试这类问题时，我们总是假设在空闲列表中的时候相连被设置为down（但当时为什么不把它放在列表外面呢？）。这是我们思维的严重不足，没考虑到有时候事情不会过早再次发生。　　3.悄无声息的故障。

一些最无以追踪的bug有部分是由那些静静告终并拓展而不是抛错误的代码所造成的。例如，没检查代码却回到错误的系统调用（如bind）。又如：解析代码在它遇上错误元素的时候只是回到而非抛错误。

在错误状态中持续了一段时间的调用，不会使调试显得更加无以。最差一旦检测到故障就回到错误。　　4.If。有若干条件的if语句，if(a或b)，尤其是若有链接的时候，if(x)elseif(y)，都给我引起了很多bug。

即使if语句在概念上很非常简单，但当有多个条件要追踪的时候仍然很更容易错误。这些天，我尝试改写代码使之更加非常简单，以防止处置简单的if语句。　　5.Else。有一些bug是因为没准确考虑到如果条件为false时会再次发生什么而引发的。

完全在所有的情况下，都应当有一个else部分来应付每一条if语句。此外，如果你在if语句的分支中设置变量，那么也许你在另一个分支中也要设置。与此种情况涉及的是标记被设置的情况。

只加到用作设置的标记的条件难于，但是很更容易忘了加到当标记应当再度重置时的条件。留给一个总有一天设置的标志可能会造成之后接连不断的bug。　　6.转变假设。许多一开始最无以防治的bug是因为转变了假设所导致的。

例如，在开始时，有可能每天只有一个客户事件。于是很多代码是在这样的假设下写的。

但是后来，设计转变了，容许每天有多个客户事件了。再次发生这种情况时，很难转变新的设计影响到的所有情况。

寻找关于转变的所有显式倚赖关系难于，无以的是要寻找所有隐性依赖原有的设计的情况。例如，可能会有提供等价某一天所有客户事件的代码。其中的说明了假设是结果集总有一天会多达客户的数量。关于这方面的问题我也没很好的策略方法，如果各位有的话，还请求不吝赐教。

　　7.日志记录。可视化程序做到什么至关重要，尤其是当逻辑很简单的时候。保证补足充足多的（但不要过于多）日志记录，这样你就可以解释为什么程序要这么做到。

如果一切正常，那也没关系，但要是有问题再次发生，你不会很难过自己加到了这些日志。　　测试　　作为一个开发人员，直到要测试了我才不会去处置功能。最少，这意味著每一行新的或转变了的代码行最少早已被继续执行过一次。

此外，单元测试和功能测试都很不俗，但还过于。新的功能也必需展开测试，并在类似于产品的环境中探寻。只有这样，我才能说道我已完成了一个功能。

下面是我经历过的bug所教会我的关于测试的一些最重要的经验教训：　　8.零和null。如果不切实际的话，保证总是用零和null来测试。对于字符串，这意味著要测试长度为零的字符串以及字符串为null两种情况。

又如：测试TCP相连的插入，要在发送数据给它发送到之前。不用于这些人组方法测试是造成bug经常出现的首位原因。　　9.加到和移除。

一般来说，新的功能还包括需要加到新的配备到系统中——例如，一个用作手机号码切换的新的配置文件。测试它能否加到新的配置文件是很大自然的。但是，我找到我们很更容易记得去测试移除配置文件是不是某种程度ok。

　　10.错误处理。处理错误的代码往往是无法测试的。最差有能检查错误处理代码的自动测试，但有时这是不有可能的。

我有时不会用于的一招是临时改动代码，使得错误处理代码运行一起。要做这一点最简单的方法是翻转if语句——例如，从iferror_count0改为error_count==0。另一个例子是拼错数据库入选为，从而造成希望的错误处理代码运行。

　　11.随机输出。一般来说，揭发bug测试的一种测试方法是用于随机输出。例如，H.323协议的ASN.1解码用于二进制数据操作者。

通过发送到随机字节去解码，我们找到了解码器中的几个bug。另一个例子是用测试调用来分解脚本，此时调用持续时间，电话延后，第一方挂断等等都是随机分解的。这些测试脚本不会曝露许多bug，尤其是一起再次发生的事件不会产生肘阻碍。

本文来源：皇冠游戏中心官网-www.sriingenieria.com