《调试九法:软硬件错误的排查之道》学习笔记 - 老萧的专栏 - 博客频道 - CSDN.NET



《调试九法:软硬件错误的排查之道》学习笔记 - 老萧的专栏 - 博客频道 - CSDN.NET

阅读手册:手册里有正确使用系统的方法。
仔细阅读每个细节:出现问题的地方可能就在你不感兴趣的那一章,不要惧怕手册的厚度。
掌握基础知识:知道什么是正常的,才能知道什么是错误的。
了解工作流程:有助于定位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,检查最初的设计方案。


Read full article from 《调试九法:软硬件错误的排查之道》学习笔记 - 老萧的专栏 - 博客频道 - CSDN.NET


No comments:

Post a Comment

Labels

Algorithm (219) Lucene (130) LeetCode (97) Database (36) Data Structure (33) text mining (28) Solr (27) java (27) Mathematical Algorithm (26) Difficult Algorithm (25) Logic Thinking (23) Puzzles (23) Bit Algorithms (22) Math (21) List (20) Dynamic Programming (19) Linux (19) Tree (18) Machine Learning (15) EPI (11) Queue (11) Smart Algorithm (11) Operating System (9) Java Basic (8) Recursive Algorithm (8) Stack (8) Eclipse (7) Scala (7) Tika (7) J2EE (6) Monitoring (6) Trie (6) Concurrency (5) Geometry Algorithm (5) Greedy Algorithm (5) Mahout (5) MySQL (5) xpost (5) C (4) Interview (4) Vi (4) regular expression (4) to-do (4) C++ (3) Chrome (3) Divide and Conquer (3) Graph Algorithm (3) Permutation (3) Powershell (3) Random (3) Segment Tree (3) UIMA (3) Union-Find (3) Video (3) Virtualization (3) Windows (3) XML (3) Advanced Data Structure (2) Android (2) Bash (2) Classic Algorithm (2) Debugging (2) Design Pattern (2) Google (2) Hadoop (2) Java Collections (2) Markov Chains (2) Probabilities (2) Shell (2) Site (2) Web Development (2) Workplace (2) angularjs (2) .Net (1) Amazon Interview (1) Android Studio (1) Array (1) Boilerpipe (1) Book Notes (1) ChromeOS (1) Chromebook (1) Codility (1) Desgin (1) Design (1) Divide and Conqure (1) GAE (1) Google Interview (1) Great Stuff (1) Hash (1) High Tech Companies (1) Improving (1) LifeTips (1) Maven (1) Network (1) Performance (1) Programming (1) Resources (1) Sampling (1) Sed (1) Smart Thinking (1) Sort (1) Spark (1) Stanford NLP (1) System Design (1) Trove (1) VIP (1) tools (1)

Popular Posts