分类： LINUX
2017-05-17 17:20:56
规则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，检查最初的设计方案。
