严格来说，不能算是读书笔记，只能说是阅读的快速翻译，加一些个人理解。

我推崇通过通读经典的原著，可以帮我们找到最具有历史痕迹的概念，厘清思路！而不是看那些被人消化反复咀嚼再吐出来的书籍！

这个文章里。个人理解的表达用下划线表达​，翻译有疑问的地方用斜体字表达

​------------------------------------------------------------------------------

第三章   程序评审、走查和复查

人工测试的方法在典型的程序中一般可以发现30%-70%的逻辑设计和代码的错误。但是这种方法不能检测出高层设计错误，例如出现在需求分析阶段的错误。我们注意到成功的比率是30%-70%，也就是说在找到的错误中不超过70%。回顾第二章中所描述的，我们无法知道程序中全部的错误。因此，这说明这种方法可以有效的在测试过程发现超过已知缺陷的70%。

当然，一个更严苛的统计是人工的过程只能发现“简单的”错误（那些可以在基于计算机的测试中所发现的）和那些困难的、晦涩的或隐藏的错误只可能通过计算机的执行过程所发现。然而，一些测试者使用这些技术发现，人工过程趋向于比基于计算的过程在某些类型的错误的发现上更有效，那些相反对于另一种类型的错误来说是真实的。（例如：未初始化变量，对应于被0除）。

human testing  methods  相当于静态测试，computer​-based testing 相当于动态测试

评审/走查和基于计算机的测试是互为补充的，其中一个未出现，则难以保证有效的错误检测。

最后，虽然这些过程对测试新程序是​非常有价值的，与程序修正是同等重要或者会更重要。我们的经验是，修改现存的程序相比写新的程序，可能导致更多错误的过程（每多一个声明就可能有一批的错误）。因此，程序修正后，需要再经历被测试的过程，也就是回归测试技术。

代码审查​

​代码审查是一套团队阅读代码的错误检测技术的规程。关于代码审查焦点的大多数争论是在程序上，填写表格等等。这里，做一个通用过程的简短的阐述，我们将着重介绍事实上的错误检测技术。

评审团队

​一般一个评审团队由4个人组成。一个是主持人的角色，在这里相当于质量控制工程师。这个主持人希望是一名有能力的程序员，但是他或者她不是代码编写者，并且不熟悉程序的细节。主持人的职责包括：

1、​分发评审会议的材料、安排进度；

2、主持会议；

3、记录所有被发现的缺陷；

​4、确保所有的缺陷，在会后被更正。

​第二个成员是程序员本人。其他的会议成员一般是程序设计者（如果与程序员不同的话），还有一个测试专家。测试专家应该精通软件测试，并熟悉大多数一般的程序缺陷，也就是我们在后面要讨论到的。

评审议程​

开评审会议的之前几天，主持人分发程序清单、设计规格说明文档给其他参与者。参与者期望让他们自己对会议的材料更熟悉。在会议期间，会有两个活动：

1、对于程序论述、声明、程序逻辑结构等，在讨论期间，其他参与者应提出那些用于追踪是否有缺陷的问题。这有点像程序员而不是其他团队的成员，在叙述中将发现许多错误的定义。换句话说，简单的对着观众大声读出程序的行为，就是显然有效的错误检测技术。

2、程序分析遵循检查表（Checklists），这张表是从历史上通用的程序错误中总结出来的。（这份检查表将会在下一次的评审会议中讨论）

主持人负责确认讨论进程沿着产品的线索，参与者将他们的关注点放在发现缺陷上，而不是订正它们。（程序员在评审会议结束后修正缺陷）

在评审过程中通常集中在发现缺陷而不是修改缺陷。有时候，一些2-3个人的团队当发现小问题时，包括负责代码的程序员，可能打算设计改变来处理这样特殊的案例，对于小问题的讨论，可能会变成全组将注意力特别地放在设计的领域。在讨论期间最好的方法是区别开设计和处理这个小问题，因为有些人可能会关注后者。关于设计方面，团队还有两个问题，每几个句子就可能评论频频。几分钟的时间，设计整个领域会被完全探索到，任何一个问题都会显而易见。

评审会议的时间和地点应该选择避免被打扰。最佳的时间长短是90-120分钟，会议是智力耗费的实践，长时间的会议反而效率降低。大多数评审会议的速度一般是每小时150个代码行。基于此原因，大型程序将会跨越多个评审会议，每个会议处理一个或多个模块或子程序。

人员议程

为让评审会议更有效，测试团队必须采取恰当的态度。例如，如果一个程序员的认为评审会议是对他或她的个人攻击，而采取对抗的态度，那么会议将是不会效果的。正确的做法是，程序员必须把撇开自我本位的态度，而采取积极和建设性的态度，保持注意力在客观的评审而发现程序的错误，这样才能提高工作质量。正因为如此，大多数人建议对评审结果保密，而只与参与者共享。尤其是，如果管理者需要利用评审结果（例如，为明确或暗示程序员的低效率或低能力），那么就与检查过程的目的背道而驰了。

评审过程的好处

除了评审的主要作用是发现缺陷外，评审还有其他的好处。第一，程序员通常接收关于编程风格的，算法选择和编程技术的有价值的反馈。第二，其他参与者通过查看程序，接触到程序员的错误和编程风格，同样受益。通常，这种类型的软件测试帮助提高团队的凝聚力。减少对抗关系的潜在演变的可能，而更利于合作关系，以项目为核心可以引导更多有效而可靠的开发模式。

最后，评审过程是一种早期发现错误倾向部分的方法，可以帮助确定在基于计算机测试阶段的测试方向。（这就是我们说的第二章说的第9个测试准则）