下面开始本书第四部分的读书笔记部分

第四部分 开发中的调试和测试思想

　　第8章 调试；第9章 极限测试思想

第8章 调试

　　调试是执行一次成功的测试（发现软件中的错误）之后所要进行的工作。也就是说如果程序测试中发现了问题，就需要程序员对程序进行调试来解决问题。调试包括两个部分：定位问题和修改错误。测试到调试的关系图如下所示

1） 确定相关数据

　　将所有可能的数据或现象均考虑进去，正确和不正确的数据和现象都需要得到；

2）组织（解析）获取的数据

　　通过组织相关数据，以便观察数据之间的关系，进而对数据进行解析，解析数据的方法可以按照，“是什么”、“在何处”，“在何时”，“多大程度”进行分析。

　　“是什么”，对症状或现象的描述；“在何处”，描述这些症状出现的位置；“在何时”，描述这些症状什么时候发生；“多大程度”，描述这些症状的范围和重要性；注意“是”，“否”列，描述的矛盾之处最终可能会导致对错误的假设。

3）做出假设

　　这时候需要研究线索之间的联系，假设一下产生错误的原因，如果找不出来，则需要更多数据；

4）证明假设

　　将假设同最初的线索或数据进行比较，看看假设是否具有合理性，如果假设无效，则需要重新构造假设，或需要更多数据；

5）解决问题

　　完成前面几步后，则可以修复这个问题。有一条需要记住：做回归测试，确保修复错误的同时没有引入其他新的错误。

　　3、演绎法调试

演绎法：是从一般理论或前提出发，使用排除法，提炼剩余的假设，进而达到结论（错误的位置）。

与归纳法正好相反，演绎法是先找出所有可能的原因或假设，然后排除不可能的原因或假设，最后剩下的那个原因可能就是最终的结论。

演绎法调试有以下几个步骤：1.找出所有可能的原因或假设；2.排除不可能的原因或假设；3.提炼剩下的假设；4.证明剩下的假设；5.修改错误（解决问题）。

1）列举出所有可能的原因或假设

　　当收集到有问题的数据时，需要先列出数据出现问题的原因或假设的列表（仅仅是猜测）。

2）利用数据排除掉不可能的原因

　　利用归纳法调试中解析数据的方法（是什么，在哪里，在何时，多大程度上）排除掉不可能的原因，剩下的原因可能就是真正的原因。当所有原因都排除掉了，需要设计新的测试用例。

3）提炼剩下的假设

　　剩下的假设也许是正确的，但是不够具体，可以根据当前有的线索，将假设具体化。

4）证明剩下的假设

　　将假设同最初的线索或数据进行比较，看看假设是否具有合理性，如果假设无效，则需要重新构造假设，或需要更多数据；

5）修改错误（解决问题）

　　完成前面几步后，则可以修复这个问题，有一定需要记住：做回归测试，确保修复的错误没有引入其他新的错误。　

　　4、回溯法调试

此方法一般用在小型程序中进行错误定位。

当发现错误后，可以从出现错误的位置开始，开始逆向执行程序，直到找出程序逻辑出错的位置。

重复使用“如果程序在此处的状态是这样，那么程序在上面的位置的状态就必然是那样的”过程，可以很快定位错误。

　　5、测试法调试

两种测试用例：供测试用的测试用例；供调试用的测试用例。

供测试用的测试用例：目的是暴露出以前尚未发现的错误，涵盖的条件较多；供调试用的测试用例：目的是提供有用信息，供定位某个被怀疑的错误之用，涵盖的条件较少。

当发现某个测试用例发现了错误，需要编写与原先有变化的（瘦身的）测试用例，尽量确定错误的位置。

工作中这种方法也可以叫做：复现问题，通过设计一种与原来的测试用例相似的用例，让错误再次发生。

结合归纳法使用，获得进行或证明假设的信息；结合演绎法使用，排除有嫌疑的原因，提炼剩下的假设，并证明假设。

　　6、调试的原则

调试原则，实质上也是心理学的原则。调试过程分定位错误和修改错误。

6.1 定位错误原则

1）动脑筋

调试是一个解决问题的过程，最有效的调试方法是动脑筋对错误症状的有关信息进行分析，以下列出一些思考的诀窍。

• • • 让自己置身于安静、没有干扰的环境中
    • 不看代码，在脑海中思考程序是怎么设计，并思考表现异常的地方本该是什么样的
    • 将注意力集中在思考程序正确行为的过程上，并想象那些可能导致错误设计的代码实现方式

2）如果遇到了僵局，就留到稍后解决

如果在合理时间内（小程序30分钟，大程序1个小时），还不能定位问题，就离开它，做些其他的事情。

忘记这个问题一段时间后，再重新检查问题的症状，思维会焕然一新。

不仅调试，开发过程也可以这样。

3）如果遇到了困境，就把问题描述给其他人听

与其他人交谈可能会帮助我们发现一些新的东西。

仅仅将问题描述给倾听者，而无须倾听者提供任何帮助，就会突然找到问题的解决之道。

4）仅将调试工具作为第二中手段

在试过其他方法后才是用调试工具。

将调试工具作为头脑思考的辅助手段，而不是替代手段。因为对工具的过分依赖，可能减少对已经获得的线索的关注，可能这些线索就能帮你直接解决问题。

5）避免使用试验法–仅将其作为最后的手段

不要为了调试程序而去试验性地去修改程序。

6.2 修改错误的技术

1）存在一个缺陷的地方，很有可能还存在其他缺陷

　　因为错误有扎堆出现的倾向。在修改某个问题的同时，应检查一下紧邻的地方，看看有没有可能是错误之处。

2）应纠正错误本身，而不仅是其症状

　　应从根本上解决问题，而不应该只修改错误的一部分。

3）正确纠正错误的可能性并非100%

　　应对错误的修改进行测试，也许比对原先程序的测试还要严格（回归测试）。

4）随着程序规模的增加，正确修改错误的可能性反而降低

　　经验：由于修改不正确而引入的错误与原始错误之比，在规模较大的程序中呈递增趋势。对于广泛使用的大程序，每发现6个新错误，就有1个错误是由于先前对程序的改正而造成的。

5）应意识改正错误会引入新错误的可能性

　　对错误的修改点进行测试，同时应执行回归测试。

6）修改错误的过程也是临时回到设计阶段的过程

　　在设计阶段使用的任何规程、方法和形式都同样适用于错误修改阶段。例如，项目证明代码检查很管用，那么在修改错误之后进行代码检查就显得倍加重要。

　　7、错误分析

　　调试除了消灭程序中的错误，还告诉我们软件错误的本质，这些软件错误本质的信息可以为改进将来的设计、编码和测试过程提供有价值的反馈。

　　通过详细分析发现的错误，可以获得关于软件有价值的信息，详细的错误分析包括：

　　1）错误出现在什么地方span>

通过对程序文档和项目历史进行追溯，找到该错误的源头和发生时间。

比如，错误源头可能是：1.规格说明书中模棱两可语句；2.对上次错误的修改；3.对最终用户需求的错误理解。

　　2）谁制造了这个错误span>

如果30%的错误都是某个程序员产生，不是很有用吗是为了惩罚，而是为了进行培训）

　　3）哪些做得不正确span>

需要判断错误发生的原因。比如，1.错误是由于某人写得不清楚；2.错误是由于某人缺乏对编程语言的培训；3.错误是打字错误；4.错误假设做得不对；5.错误是没有考虑有效输入；

　　4）如何避免该错误的出现span>

在下一个项目中应如何避免该问题的出现就是最宝贵的经验和信息）

　　5）为什么错误没有早些发现span>

如果错误是在测试阶段发现的，需要研究：为什么更早的测试阶段、代码审查和设计阶段中没有发现错误。

　　6）该如何更早地发现错误span>

如何改进评审和测试过程，以便在将来的项目中更早发现同类型的错误。

　　通过对错误进行分析，可以积攒开发和测试的经验，保证质量的同时节省开发和维护的成本。

相关资源：GHOST系统只剩C盘数据恢复软件_ghost分区丢失只剩c盘数据恢复…