编译器可以发现许多潜在的错误。一些这样的错误包括使用未初始化变量，在条件句，或C + +中意外将检查平等转让，与混合类型相关的错误，如指针和绑定约束。
格式输出谎言
由于操作系统通常缓冲I/O，所以在调试过程中使用格式输出是危险的。可能的话，使用调试器找出有问题的代码行，而不是缩小被格式输出和进位输出弄乱的代码。
清除输出
有些时候你要在日志文件中跟踪一些情况，需要从程序启动到出现错误时的所有数据。为了确保你收集了所有数据，一定要清除它：你可以用C 刷新缓冲区，或用C++输出endl 。 fflush把你要写入的文件指针的错误清除。
检查辅助函数
人们很容易激动时忘记这点：总是确认您的辅助函数运行正常，特别是在看似简单的代码缺失时。如果可能的话，先分离每个辅助函数并对它们进行单独测试，然后再进行代码测试。
当原因不能立刻生效时
即使辅助函数不是导致问题的直接原因，其副作用也可能导致潜在问题。举例来说，如果你有一个可以返回NULL的辅助函数，且你把它的输出传到处理C 字符串的库函数，你会看到直接原因是因为解除了NULL指针关联，但真正的原因是因为你写了问题函数(或是你没有在调用NULL后进行检查)。
代码可以多处使用
调试时的另一个问题是，你发现的问题由某种特别的函数调用引起，在那个函数里设置一个断点，然后会发现，在整个代码中对同一个函数有数百次调用。
最显而易见的办法是在冲击断点后检查调用栈，或在出错调用前有效设置断点。不幸的是，如果同样的调用出现1000次但在1001次时失败了，这就不一定起作用了。可能的解决方案包括清点函数调用次数，然后逐步通过设置在函数中的断点，或使用一个静态变量作为计数器。
文章来源于领测软件测试网 https://www.ltesting.net/
