本帖最后由 suyong_yq 于 2015-5-8 00:00 编辑
之前有一段时间特别研究了一下调试的方法，系统地看了一些书，其中有一本书比较推荐，《调试九法：软硬件错误的排查之道》。这本书本身很薄，很快就能读完，但内容很实用，后来我在调板子时若是没有头绪的，按照调试的原则挨个过一遍，基本上都能解决问题。
这里列出来亚马逊对本书的简介： “《调试九法:软硬件错误的排查之道》主要介绍了调试方面的9条黄金法则，并结合实际的环境讲述了如何合理地运用它们。《调试九法:软硬件错误的排查之道》的内容没有针对任何平台、任何语言或者任何工具，讲述的重点是找到出错的原因并修复它们，高效地追踪和解决不易察觉的软硬件问题。《调试九法:软硬件错误的排查之道》适合所有软硬件从业人员阅读。”
下面是从书上摘录下来的内容，对软硬件调试很有帮助。
规则1：理解系统
阅读手册：手册里有正确使用系统的方法。 仔细阅读每个细节：出现问题的地方可能就在你不感兴趣的那一章，不要惧怕手册的厚度。 掌握基础知识：知道什么是正常的，才能知道什么是错误的。 了解工作流程：有助于定位bug。 了解工具：调试工具能干什么，不能干什么。 查阅细节：去阅读手册，而不是猜测或回想手册上的内容。
规则2：制造失败
制造失败：目的是为了观察它，找到原因，并检查是否已修复。 从头开始：bug可能由一系列操作或者运行造成的，回到最初状态开始制造失败。 引发失败：试着让失败出现，而不是被动的等，尤其是间歇性失败。 但不要模拟失败：不要猜测失败产生的机理而去模拟一个系统，模拟的系统可能没有体现bug的根源，甚至产生新的bug。 查找不受你控制的条件（正是它导致了间歇性失败）：改变能改变的任何参数，或者将变量设成常量，直到bug再次出现并一直出现。 记录每件事情，并找到间歇性bug的特征：记录运行状态，分析并找到出现bug时的状态特征。 不要过于相信统计数据：获得足够多的信息并分析，不要猜测。 要认识到“那”是可能会发生的：bug的根源可能是意想不到的，不要大喊“不可楞！！！”。 永远不要丢掉一个调试工具：没准哪天就能派上用场。
规则3：不要想，而要看
观察失败：发现bug不要猜测问题根源，而是要仔细观察bug到底是什么地方造成了bug。 查看细节：缩小范围。 植入插装工具：使用源代码调试器、调试日志、状态消息和printf。 添加外部插装工具：使用分析器、示波器、量表、金属检测仪、心电图仪和肥皂泡。 不要害怕深入研究：不要害怕找到更多的bug，虽然软件已经是成品，bug还是必须要修复的。 注意海森堡效应：测不准原理。当你为了观察失败而改变系统或插装工具时，避免所做的改变影响系统。 猜测只是为了确定搜索的重点：猜测还是必要的，但不要过多的猜测。
规则4：分而治之
通过逐次逼近缩小搜索范围：猜测1～100内的一个数字，只需7次。 确定范围：不要把初始范围设定的太小，如果数字是135而你却认为他在1～100内，那么你必须扩大范围。 确定你位于bug的哪一侧：在某一点检查系统，如果状态正确，则bug位于上游，反之位于下游。 使用易于查看的测试模式：从干净、清澈的水开始，以便当排放物进入河流时很容易看到它。 从有问题的一段开始搜索：正确的部分总是多于错误的部分，应该从有问题的地方开始，向后追查原因，不要在正确的地方浪费时间。 修复已知bug：bug互相保护，互相隐藏，因此一旦找到，立即修复它们。 首先消除噪声干扰：注意那些导致系统问题的干扰因素，但对一些无足轻重的问题不要过于极端，也不要为了追求完美而去修改所有地方，虽然他看起来不美，但它可以正确工作。
规则5：一次只改一个地方
隔离关键因素：当你观察某一个bug的问题时，不要改变与此bug不相关的因素。 用双手抓住黄铜杆：不要猜测并改变系统的不同部分，以便看看他们是否对问题有影响，这可能引起更多错误。 一次只改一个测试：使用步枪点射，而不是霰弹射击。 与正常情况进行比较：如果所有出错的情况都有一些特征，而这些特征是正常情况所没有的，那么你就找到了问题所在。 确定自从上一次正常工作以来你改变了什么地方：这个改变的地方是一个很好的调试起点。
规则6：保持审计跟踪
把你的操作、操作的顺序和结果全部记录下来：当出现bug时你能查看之前更多的细节。 要知道，任何细节都可能是重要的：不要忽略不起眼或者不可楞的细节。 把事件关联到一起：尽量详细并量化的描述问题。 用于设计的审计跟踪在测试中也非常有用：Git、CVS、Subversion…… 把事情记录下来：好记性不如烂笔头。
规则7：检查插头
置疑你的假设：是否运行了正确的代码？问题的根源可能没有想象的那么复杂。 从头开始：可能一开始就错了，以后怎么都不对了。 对工具进行测试：你的工具好用么？你会用么？（见规则1）
规则8：获得全新的观点
征求别人的意见： 获取专业知识： 听取别人的经验： 帮助无处不在：同事、供应商、网络、书店…… 放下面子： 报告症状，而不要讲你的理论：不要把别人拖进你的思维定势中。 你提出的问题不必十分肯定：提出任何你觉得可以的因素，没准哪个就有帮助。
规则9：如果你不修复bug，它将依然存在
查证问题确实已被修复：不要假设bug已经修复了，你修改的地方可能不是造成bug的根本。 查证确实是你的修复措施解决了问题：撤销这个修复，看看bug是否再次出现。 要知道，bug从来不会自己消失：就算你再也找不到它了，它还是会在某一天跳出来，不要有侥幸心理。 从根本上解决问题：不要敷衍。 对过程进行修复：如果总是出现同类bug，检查最初的设计方案。
| 
/3 
发表于 2015-5-7 23:58:41
沉默卡
照妖镜
