随便聊聊找BUG的方法

[color=blue]一、现场环境证据收集[/color]
将一个bug比喻成一次案件。对案件进行分析时，可以从邻居口中得到线索，也可以从现场找到突破口。那么我更喜欢从邻居口中用较少的次数收集到我所需要的信息后，将更多的时间花费在从现场找到蛛丝马迹。找bug时也是如此，假设你的程序打印出人员的排序情况不一致，不应该马上就去查找你的排序代码。更应该从“现场”周围来收集更多情况：比如可以增加若干人员后看看排序情况；查看程序其他地方输出的排序是否正常。。。通过这些可以了解是一些索引越界了还是排序本身代码的问题。接着再去具体查看排序的子代码。

[color=blue]二、凶手范围的确认[/color]
这里《代码大全》中总结了几条
先怀疑有前科的人员：
1、怀疑已经发生过的程序
2、检查已经修改过的程序
3、当以上都检测不出错误时，可以列张表，将涉及到的程序模块列出来，进行分别的测试。
4、完全个人能力的左右。
[color=blue]
三、一些对你有帮助的心理手段[/color]
1、有时候，跟同事谈起一个错误时，先大声的将错误和你已经所采取的方法描述给他听，当你描述到最后时，你可能已经发现了错误；
2、终止对问题的考虑，先搁一边几天，回过头再来考虑它；
3、习惯的问题。
你可能定义有int i1;在某处又定义了int I1;或者这种类似的字眼。假设你的子程序为sub1，那么代码可能组织如下

int I1=0

sub1
{
  do with i1;//你想使用I1
}

你可能怀疑到I1的值问题，并疯狂的对他检测过了。这里的习惯问题就暴露出来了：当你看到sub里的i1时，你会认为你是在引用I1

再比如，我以前写了这样的代码

int i=0;
for(i=0;i<10;++i);
{
  do//

}

结果我拼命的在{}体里找问题，因为我看到for时，就认为它一定会到执行体里。但由于之前我可能手误多打了一个;号。

文中若干资料从《代码大全》中引自