古人有云：千里之行，始于足下；九层之台，起于垒土。在软件测试中把每一个缺陷遏制在初期萌芽状态，以低的成本修复缺陷是每一个测试人员的基本守则，也是每一个测试人员的梦想。近期，我在所负责的一个软件测试项目中，因为时间紧张在接手项目后立即开始运行程序进行测试，结果不尽人意。在反思中我得到一个经验教训是：软件测试不应该忽视静态测试，否则事后的补救将会是积重难返。

忽视静态测试，后果将会积重难返

在G.J.Myers的经典著作《软件测试之艺术》（The Art of Software Testing）中，软件测试被定义为：程序测试是为了发现错误而执行程序的过程。他认为测试是执行程序的过程，也是在代码完成后，通过运行程序来发现程序代码或软件系统中错误的过程。但是，这种测试方式并不能在代码完成之前发现系统需求、系统设计上的缺陷，而是把需求、设计上的问题遗留到后期，结果会造成设计、编程的部分返工。而且，需求阶段和设计阶段的缺陷还会产生放大效应，大大增加了软件开发的成本和周期。这是非常不利于保证软件质量的，这种测试思想主要是受软件开发瀑布模型影响。

一般来说，在进行系统测试的功能测试阶段时，基本上编码工作已经完成。这个时候所发现的缺陷问题，是需要付出比较高的代价去修正它的。在分析缺陷成本上，有以下公认的结论，是缺陷发现的越晚，修正的成本越高。测试阶段修正缺陷的成本是编码阶段约4倍的关系。所以，为了减少修正成本，缺陷被发现的越早越好。

因此，在编程阶段找到代码缺陷是很多测试人员的梦想。幸运的是，我们的确有这样的方法，是不用等到编码结束可先做静态测试，它可以在系统开始时的需求讨论、功能设计的时候进行测试。例如，所有的书面的甚至非书面的文档、资料、方案等都可以成为静态测试的对象。通过静态测试在编码之前把问题遏制在萌芽中，从而大大降低开发和测试的成本。所以，为了更早地发现问题，我们需要将测试观念延伸到需求评审、设计审查的活动中去。延伸后的软件测试引出了两个概念，分别是静态测试和动态测试，而且静态测试显得更为重要。

什么是静态测试？

（1）什么是静态测试

静态测试是指不运行被测试程序而寻找程序代码中可能存在的错误或评估程序代码的过程。静态测试的特点是不需要运行代码，也不需要对代码编译、链接和生成可执行文件。它是通过分析或检查源程序的方法、结构、过程、接口等来检查程序的正确性。目的在于找出缺陷和可疑之处，纠正软件系统的描述、表示和规格上的错误，也是进一步执行其它测试的前提。

（2）静态测试的基本内容

在实际使用中，静态代码检查比动态测试更有效率，更能快速找到缺陷。按经验估算，一般能发现30%～70%的逻辑设计和编码错误的缺陷。但是静态代码检查非常耗费时间，而且代码检查需要丰富的知识和经验积累。

静态测试包括代码检查、静态分析两种途径。它可以由人工进行，充分发挥人的逻辑思维优势，也可以借助软件工具自动进行。代码检查包括桌面检查、代码审查、代码走查和技术评审等。主要检查代码的设计是否一致性、代码是否遵循标准性和可读性、代码的逻辑表达是否正确性、以及代码结构是否合理性等。静态分析则是一种计算机辅助的静态分析方法。主要对程序进行控制流分析、数据流分析、接口分析和表达式分析等。静态分析的对象是软件程序，程序设计语言不同，相应的静态分析工具也不同。

（3）重点介绍代码检查流程

代码检查包括桌面检查（Desk Checking）、代码审查(Inspection)、代码走查（Walk through）和技术评审(Review)四种情况。当然在实际工作，我们完全不必要被概念所束缚住，而应根据项目的实际情况来决定采取哪种静态测试形式，不用严格去区分到底是代码走查，代码审查和还是技术评审。

①桌面检查（Desk Checking）

是由程序员自己检查自己编写的程序。程序员在程序通过编译之后，进行单元测试设计之前，对源程序代码进行分析，检验，并补充相关的文档，目的是发现程序中的错误。检查项目有：检查变量的交叉引用表、检查标号的交叉引用表、检查子程序、宏、函数、等值性检查、常量检查、标准检查、风格检查和补充文档等。这种桌面检查由于程序员熟悉自己的程序和自身的程序设计风格，可以节省很多的检查时间，但应避免主观片面性。

② 代码审查（Code Reading Review）

代码审查是由若干程序员和测试人员共同组成一个会审小组，通过阅读、讲解、讨论和模拟运行的方式，对程序进行静态分析的过程。代码审查主要是依靠有经验的程序设计和测试人员根据软件设计文档，通过阅读程序发现软件缺陷。特点是一般有正式的计划、流程和结果报告。现在也可借助软件工具自动进行，例如 LOGICSCOPE、C++ TEST、LDRA TESTBED、PRQA C/C++、MACABE IQ、以及Rational的Purify、Quantify和PureCoverage等。

代码审查一般分为两个步骤：第一步是小组负责人把设计规格说明书、控制流程图、程序文本及有关要求、规范等分发给小组成员，作为评审的依据。第二步是召开程序代码审查会，在会上由程序员逐句讲解程序的逻辑，在此过程中其他的程序员可以提出问题，展开讨论，以审查错误是否存在。实践经验表明，程序员在讲解过程中能发现许多原来自己没有发现的缺陷和错误，而讨论和争议则更会促进缺陷问题的暴露。

③代码走查（Walk throughs）

走查与代码审查基本相同，其过程也分为两步。第一步也把材料先发给走查小组每个成员，让他们认真研究程序代码后再开会。但第二步开会的程序与代码审查不同，不是简单地读程序和对照错误检查表进行检查，而是让与会者"充当"计算机。即首先由测试组成员为被测程序准备一批有代表性的测试用例，提交给走查小组。走查小组开会时集体扮演计算机角色，让测试用例沿程序的逻辑运行一遍，随时记录程序的踪迹，供分析和讨论用。人们借助于测试用例的媒介作用，对程序的逻辑和功能提出各种疑问，结合问题开展热烈的讨论和争议，以求发现更多的问题。

④技术评审(Review)

技术评审(Review)是指开发组、测试组和相关人员(QA、产品经理等)联合进行，也是采用讲解、提问并使用编码模板进行的查找错误的活动。一般也有正式的计划、流程和结果报告。