（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、产品经理等)联合进行，也是采用讲解、提问并使用编码模板进行的查找错误的活动。一般也有正式的计划、流程和结果报告。
开始静态测试的时机和准备
理论上讲，静态测试应从项目立项即开始测试，然后始终贯穿整个项目。但在实际操作中，基本上是上一个版本系统测试结束的时候才进入下一个版本的静态测试阶段。这个时候，基本系统规格书和软件需求说明书都已经完成初稿，因此静态测试开始的原则是越早越好。
（1）测试前的重要准备：熟悉业务流程和背景
静态测试能否成功有一个很重要的前提条件，就是测试人员要对测试系统的业务流程有一定的认识和基础，这样测试才能更加全面和深入的进行。例如，如果要对新增的业务流程进行测试，建议先在类似的业务系统中熟悉业务基础流程。如果是要对变更类项目进行测试，建议将原有的系统先熟悉起来，以便对变更和修改的内容有更明确清晰的认识。其次，对于静态测试内容的业务背景和总体设计的了解也是非常重要的。例如：通过对业务背景和总体方案的研读，了解系统要实现哪些内容，清晰了解所测试的内容的轮廓，透彻的审视系统规格书和软件需求说明书。只有充分的前期准备，才会在静态测试过程中取得比较满意的效果。如果涉及到比较复杂的情况时，测试人员较难搞清楚的，最好提前跟对应的开发沟通，搞清楚项目的测试要点，或是去求证测试思路是否正确。这样有助于缩短准备时间，更好的进行静态测试。
（2）静态测试前先准备好产品说明书
静态测试前需要先对产品说明书进行高级审查，测试产品说明书的目的不是钻进去找软件缺陷，而是在一个高度上审视。审查产品说明书是为了找出根本性的大问题、疏忽和遗漏之处。也许这更像是研究而不是测试，但是产品说明书的研究主要是为了更好地了解软件要做什么。如果能够很好地理解产品说明书背后的原因和操作方式，就可以更好地仔细进行静态测试检查了。因此，测试人员在第一次接到需要审查的产品说明书时，应该要把自己代入客户的角色想思考。代入客户的角色思考和看问题是很重要的，这涉及到静态测试的准备工作是否做到位的问题。再加上有一定的业务背景了解，在审视产品说明书的时候才有可能发现功能上设计不合理的地方。
（3）审查和测试同类软件
审查和测试同类软件中存在的缺陷问题和功能，可以给测试人员一个好的提示和借鉴，让测试人员在静态测试更加有的放矢。比如说一个软件系统中要设计一个新的功能，而这个功能在同类软件中已经有成形的产品，借鉴现有的经验，就很容易比对出目前的设计是否存在某些缺陷或欠缺。
高效进行静态测试的策略和方法
人员和过程是决定软件静态测试质量的关键因素，因此高质量的人员和良好的过程是必须要重视和控制的。
（1）挑选合适的审查成员
静态测试对参与人员的经验要求非常高，因此静态测试的要点是要挑选合适的审查成员。因为审查人员是否具有丰富的经验和知识，将在缺陷讨论、判断和争议的环节中起到决定性的作用。
（2）审查活动前的准备必须要充分
静态测试一般是在编译和动态测试之前进行，这个时候系统是否能正常运行也是一个未知之数。因此在静态检查前，必须充分准备好需求描述文档、程序设计文档、程序源代码清单、代码编码标准和代码缺陷检查表等。
（3）组织和控制好审查会议过程
静态测试的代码检查阶段是需要召开会议形式的审查活动，而活动是否有效的进行和控制就意味着是否高质量的进行静态测试。因此，必须要组织和控制好审查会议的过程，审查过程本身的目的是提出问题，引发讨论和争议，而不是现场解决这些缺陷。否则，缺乏控制的审查会议过程，会很容易本末倒置的变成了现场缺陷修改会议。
| 欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) | Powered by Discuz! X3.2 |