13条黄金调试规则
理解需求。
或许软件根本就没有故障，只是产生了误解，而不是bug。
制造失败。
需要一个测试用例，使程序运行失败。
简化测试用例。
读取恰当的错误消息。
第一个错误之后所发生的每件事都应该用一种怀疑的眼光来看待。
检查显而易见的问题。
软件的所有部分是否都已启动运行？系统内存是否足够？是否有正确的权限？足够的磁盘空间？
从解释中分离出事实。
不要直接下结论。整理一份对某一事实已知的情况和原因清单。
分而治之。
如果问题很容易解决，则直接解决；否则就将其分解为两个或多个更小的问题。
整理一份清单，列出潜在问题以及如何调试它们。
将环境更改和源代码更改区分开。
跟踪环境的更改。
撤销源代码的更改。
放大并治之。
内存调试。
常规的源代码调试。
同步调试。
工具要与bug匹配。
不要嫌麻烦，要调试的是出现问题的地方，而不是便于调试的地方。
一次只做一项更改。
保持审计跟踪。
涉及多个参数的问题，要记下都做了哪些事情、执行的顺序以及出现了什么结果。
获得全新观点。
陷入僵局时，可以找别人讨论一下。一定要在事实与你的理论之间划出明确的界限。
bug不会自己修复。
有时在修改了某些语句之后，bug可能会消失。但是，除非有很充分的理由说明修复很有效，否则最好假设bug仍然存在，并且未来还会发作。
即使有很好的解释，也要验证修复的有效性。方法是取消修复，并检查bug是否重新出现。
做出更改后重新构建。
用回归测试来检查bug修复。
将简化的测试用例（规则3）转化为回归测试。
评论（2）