调试策略，小技巧以及陷阱

       调试策略，小技巧以及陷阱   软件测试工程师　

   　使用合适的工具

　　如果你正寻找分段错误，你就会想用调试器。如果你正要处理奇怪的内存问题(或难以诊断的分段错误)，那么在Linux中使用Valgrind或在Windows中使用Purify吧。

　　调试问题

　　有时候我们想出一个解决方案后却发现方案很难执行。事实上，换个角度问题或许可以更明朗。当我看到有人竭力调试一个复杂的大规模的代码时，我首先想到的是问问自己是否有更简便的办法。通常情况下，一旦你的代码写得很糟糕，你反而能清楚意识到好的代码应是怎样的。请记住，不能因为代码是你写的就要保留它!

　　诀窍是，明白你是要解决初始问题，还是要解决某一特定方案。如果是解决方案，那么你的问题就可能根本不是由初始问题造成，也许你过虑了或者尝试了一种错误的做法。例如，我最近需要分析文件并输入一些数据到Aclearcase/" target="_blank" >ccess数据库以还原分析工具。我的第一反应是编写一个与Access直接对接的Ruby脚本，使用SQL查询向数据库输入所有数据。由于我审视 了Ruby可以为此提供的支持，我很快意识到对这个问题的“解决办法”要比理论上的久得多。于是我掉转方向，写了个只是输出一个逗号分隔值文件的脚本，如此，我大约花了一小时完成数据输入。

　　关于错误代码

　　人们往往不愿抛出他们已经写了和重写过的错误码。原因之一是，写完的代码标志着工作的完成，再提出来会觉得走了回头路。但是在你调试时，重写代码似乎更具吸引力，因为你可能通过重写代码节省了调试的时间。诀窍在于，移除不良代码不需要重写整个程序(除非它无可救药)，只需要重写有问题的部分。

　　你的第二稿可能更清洁且漏洞更少，你也可以避免重写代码等问题，这样你能说清楚它的工作原理。

　　另一方面，当你绝对相信，看起来可怕的代码是要使用的正确代码时，你会想用你的理由为其注释，以防某人(或自己)犯同样的错。

　　避免“复制/粘贴”带来的错误

　　每当你复制并粘贴大量代码时，你都留给了自己一大堆麻烦。即便你还没有调试，你也将不得不这样做。如果你忘了在什么地方复制过代码，你很可能将重复调试相同的代码。

　　避免复制/粘贴综合症的最好方法是尽可能使用函数概括重复代码。有些东西在C + +中不容易避免，无论正在做什么你都会为循环写很多代码，所以你不能提取整个循环过程。但是，如果在多个地方存在同样的循环本体，就可能是应该退出到单独函数的一个信号。作为奖励，代码变得更简单，你也可以重复使用这一函数，而不必找到一大堆代码去复制。

　　何时复制代码

　　虽然复制代码通常是危险的，但有些时候它可能是最好的选择。例如，如果您需要对一大段代码进行缩减和不规则调整，其余部分保持不变，那么复制，粘贴和仔细编辑是可以的。通过复制代码可以避免因打字有误而带来的新错误。

　　早期测试

　　退出代码并把它变成函数的优点之一是，你可以分别测试这些函数。这意味着你可以避免调试由原函数中的简单错误引发的大问题。这样的单元测试需要一定的训练和对错误代码有良好的判断力。

　　早期测试的另一个优点是你会更关心你具体界面的类别。如果因为你使用的是断言而不是一个例外或错误代码而无法测试错误操作，这表明，你应该使用某种形式的错误报告，而不是断言。如果你的接口类别不灵敏，或你的函数有着无法被理解，更不用说被记住的自变量。那么是时候在编码前重新考虑一下。

　　编译器警告

原文转自：http://www.ltesting.net