Chinaunix首页 | 论坛 | 博客
  • 博客访问: 304820
  • 博文数量: 97
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 636
  • 用 户 组: 普通用户
  • 注册时间: 2014-10-12 22:41
文章分类

全部博文(97)

文章存档

2017年(8)

2015年(87)

2014年(2)

我的朋友

分类: LINUX

2017-05-17 17:20:56

规则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,检查最初的设计方案。

阅读(1765) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~