代码检查、走查和评审.PDFVIP

第3 章 Chapter 3 代码检查、走查与评审 多年以来，软件界的大多数人都持有一个想法，即编写程序仅仅是为了提供 给机器执行，并不是供人们阅读的，软件测试的惟一方法就是在计算机上执行它。 20世纪70年代早期，一些程序员最先意识到阅读代码对于构成完善的软件测试和 调试手段的价值，通过他们的努力，原有的观念开始发生变化。 今天，并不是所有的软件测试人员都要阅读代码，但是研读程序代码作为测 试工作的一部分，这个观念已经得到了广泛认同。以下几个因素会影响到特定的 测试和调试工作需要人工实际阅读代码的可能性：软件的规模和复杂度、软件开 发团队的规模、软件开发的时限（例如时间安排表是松散还是紧密）等，当然还 有编程小组的技术背景和文化。 基于这些原因，在深入研究较为传统的基于计算机的测试技术之前，我们首 先讨论非基于计算机测试的过程（即“人工测试”）。人工测试技术在查找错误方 面非常有效，以至于任何编程项目都应该使用其中的一种或多种技术。应该在程 序开始编码之后、基于计算机的测试开始之前使用这些方法。同样，也可以在编 程过程的更早阶段就开始设计和应用类似的方法（例如在每个设计阶段的末尾）， 但是这些内容超出了本书讨论的范围。 在开始讨论人工测试技术之前，有一条重要的注意事项：由于包含了人为因 素在内，导致很多方法的正规性要差于由计算机执行的数学证明，人们可能会 怀疑某些如此简单和不正规的东西是否有用。反之亦然。这些不正规的方法并 没有妨碍测试取得成功；相反，它们从以下两个方面显著地提高了测试的功效 和可靠性。 首先，人们普遍认识到错误发现得越早，改正错误的成本越低，正确改正错 误的可能性也越大。其次，程序员在开始基于计算机的测试时似乎要经历一个心 16 软件测试的艺术 理上的转变。从内部产生的压力似乎会急剧增长，并产生一个趋势，要“尽可能 快地修正这个缺陷”。由于这些压力的存在，程序员在改正某个由基于计算机测试 发现的错误时所犯的失误，要比改正早期发现的问题时所犯的失误更多一些。 3.1 代码检查与走查 代码检查、走查以及可用性测试是三种主要的人工测试方法。这些测试方 法可以应用在软件开发的任何阶段，包括在一个应用程序编码基本结束或者每 一个模块（单元）编码结束之后（阅读第5章关于模块或单元测试的更多内容）。 本章将主要介绍前两种针对代码的（白盒级别的）测试方法。在第7章我们会 讨论可用性测试。 由于代码走查和检查这两种方法具有很多共同之处，所以在这里我们将讨 论它们的相似点，而它们的不同之处将在后续章节中介绍。 代码检查与走查都要求人们组成一个小组来阅读或直观检查特定的程序。无 论采用哪种方法，参加者都需要完成一些准备工作。准备工作的高潮是在参加者 会议上进行的所谓“头脑风暴会”。“头脑风暴会”的目标是找出错误来，但不必 找出改正错误的方法。换句话说，是测试，而不是调试。 代码检查与走查已经广泛运用了很长时间。我们认为，它们的成功与本书第2 章所述的一些原则有关。 在代码走查中，一组开发人员（三到四人为最佳）对代码进行审核。其中 只有一人是代码的作者。因此，代码走查的主要工作是由其他人，而不是作者 本人完成的，这和软件测试的第2 原则，也即“软件编写者往往不能有效地测 试自己的软件”相符合。（参见第2 章，表2.1 ，本书将陆续涉及表中归纳的10 条测试原则。） 代码检查与走查是对过去桌面检查过程（在提交测试前由程序员阅读自己程 序的过程）的改进。与原方法相比，代码检查与走查更为有效，同样是因为在实 施过程中，除了软件编写者本人，还有其他人参与进来。 代码走查的另一个优点在于，一旦发现错误，通常就能在代码中对其进行精 确定位，这就降低了调试（错误修正）的成本。另外，这个过程通常发现成批的 错误，这样错误就可以一同得到修正。而基于计算机的测试通常只能暴露出错误 的某个表症（程序不能停止，或打印出了一个无意义的结果），错误通常是逐个地 第3章 代码检查、走查与评审 17 被发现并得到纠正的。 在典型的程序中，这些方法通常会有效地查找出30%～70% 的逻辑设计和编码 错误。但是，这些方法不能有效地查