代码大全2（读书笔记16）

170、某些方法在检测缺陷方面比其他方法更加有效，而且不同的方法能找出不同类型的缺陷。

 

171、数据强烈提醒我们，如果项目的开发者要向更高的缺陷检测率发起冲击，他们需要综合运用各种技术。

 

172、大部分研究都发现，检查比测试的成本更小。NASA软件工程实验室的一项研究发现，阅读代码每个小时能够检测出的缺陷要比测试高出80%左右，另一个组织则发现使用测试来检测缺陷的成本是检查的6倍。后来，IBM的一项研究又发现，检查发现一个错误只需要3.5个工作时，而测试则需要花费15~25个工作时。

 

173、测试用例可以将从引入缺陷到发现并排除缺陷之间的时间缩减至最短。

 

174、开发人员往往去做一些检验代码能否工作的测试（干净测试），而不是做所有可能让代码失效的测试（肮脏测试）。在不成熟的测试机构里，肮脏测试同干净测试的数量比例是1：5.成熟的测试机构倾向于让肮脏测试的数量是干净测试的5倍。这个比率不能够通过减少干净测试的方式来扭转，应该让肮脏测试的量增到目前的25倍。

 

175、80%的错误存在于项目20%的类或者子程序当中。

     50%的错误被发现存在于项目5%的类当中。

     20世纪60年代IBM做了一个经典的研究，对OS/360操作系统所做的一次分析发现，错误并非平均地分布在所有的子程序里面，而是集中在少数几个子程序里面。

 

176、回归测试

    假设你已经对某产品进行了彻底的检查，而且没有发现任何错误。在此之后该产品的某个部分被修改，你想确定修改后的产品仍然能通过此前的所有测试---也就是说，这次的修改没有给产品引入任何新的错误。为确保软件没有倒退，或者没有“回归”而设计的测试，被称为“回归测试”。

    除非在每次修改后重新对程序进行系统化的测试，否则要开发出一个高质量的软件产品几乎是痴人说梦。而如果每次修改后都使用了不同的测试用例，那么你将无法保证本次修改没有给程序引入任何新的错误。因此回归测试每次都应该使用相同的测试用例。有时候，随着产品的不断成熟，你会添加新的测试用例，但仍然应该当保留旧的测试用例。

 

    管理回归测试唯一可行的方法，就是将其变成一个自动化的过程。

 

177、就重要性而言，测试应当与设计和编码平起平坐，就就要求项目为测试分配时间，重视测试并保障这一过程的质量。

 

178、

179、

假设你要调查一桩谋杀悬案，下面两种做法哪一种会更为有趣？是在整个城镇里挨家挨户确认每个是否有10月17日晚不在现场的证据，还是通过蛛丝马迹推断凶手的身份？绝大多数人都会选择后者，绝大多数的程序员也会发现开动脑筋进行调试会给自己带来更多的满足感。更何况，高效的程序员只需花费低效程序员的1/20的时间，他们并不是随机地猜测如何修正程序。他们使用科学的方法------即所有科学探索所必需的发现和实证的过程。

 

180、抛开问题，休息一下

有时你太关注于你的问题了，已经到了无法思考的程度。你有多少次从工作中暂停下来去泡一杯咖啡，在你走向咖啡机的路上却灵光一现解决了问题。或者是正在吃饭的时候，或者是在回家的路上？甚至在第二天清晨洗澡的时候？如果你高度了很久却毫无进展，只要你尝试完成所有的可能，把问题放在一边吧!出去散散步，做些其他的事情，回家休息一天。让你的神经在潜意识中释放出问题的解决方案。

    暂时放松思考的好处是可以减少调试带来的焦虑。不时潜入头脑中的焦虑感是一个明确的信号：到了该休息的时候了。