1.2 静态分析方法

静态分析（Static Analysis）方法是指通过对软件产品进行静态而非动态的分析，检查软件产品是否满足规定要求的方法。广义上的静态分析对象包括软件开发过程中产生的各种软件产品，如软件需求规格说明、软件概要设计文档、测试文档、源程序代码、评审报告等。静态分析技术包括多种形式，软件评审是其中的一种重要方式。软件评审通常包括管理评审、技术评审、审查、走查和审核。通常情况下，将对软件需求规格说明等文档的分析称为文档审查，而将对源程序代码的审查称为代码审查。

代码静态分析的对象是源程序代码，代码静态分析不需要实际执行程序，而是通过扫描源程序，从中找出违反编程规则的错误、内存管理、指针使用、以及程序结构异常、控制流异常、数据流异常等错误。

代码静态分析有人工和自动两种实现方式。人工方式主要通过测试人员或相关人员阅读源程序代码完成，代码审查和走查是两种常用的人工代码分析方法；自动方式主要借助于静态分析工具在宿主机上完成，不需要下载到目标板，不需要硬件支持。自动静态分析完成可重复、可归纳的分析活动，对于那些无法归纳和无规律的分析工作，需要人工进行分析。

静态代码自动分析原理看似与编译器类似，但它与编译器有着很大的区别。编译器只能检查程序中存在的部分词法和语法方面的错误，此外，编译器的主要目的是把源代码高效地翻译和转换成可执行的二进制代码，而不是通过代码检查来帮助你编写更干净、更健壮的代码；静态分析的主要目的是准确找到程序结构的错误和可疑代码位置，因此，要尽可能详细地记录源程序的特性，以便发现程序中存在的异常现象。

自动分析具有以下特点：

• 自动分析的综合效率一般比人工分析效率高（优秀程序分析员除外）；

• 自动分析的侧重点是可重复、可归纳的语法和语义方面的缺陷，人工分析的侧重点是高层的、面向语义的代码缺陷；

• 自动分析的平均成本通常低于人工分析的成本，因此，要尽可能多地采用自动分析方法；

• 自动分析和人工分析所发现的缺陷种类不同，两者具有良好的互补性。

1.2.1 文档审查

文档审查是对软件开发过程中产生的文档的齐套性、完整性、规范性、一致性和准确性所进行的检查。

在软件开发过程中，相关部门对文档编写颁布了相应的标准和规范，如国标、行业标准，这些标准是文档审查的依据。为了提高文档审查质量和效率，要根据这些标准制定文档审查单，根据文档审查单，对文档逐一进行审查，常用的文档审查单见附录。

1.2.2 代码审查

在GBT11457中，对审查做了如下定义：

审查：一种正式的评定技术。由除作者之外的某人或一小组仔细检查软件需求、设计或代码，以找出故障、违反开发标准之处和其他一些问题。

代码审查是针对代码所进行的审查，代码审查的概念是由IBM质量保证专家Michael Fagan于1976年提出的，AT&T贝尔实验室从1977年也开始使用此审查方法。1985年，IBM的Carolel、Jones和Robert Mays及Fangan本人对审查方法做了改进，提出了通用的审查周期策略、临时分析会议、行为数据库、行为小组等概念和方法，把最初的针对错误检查扩展为针对错误预防。

代码审查方法与一般的审查方法相同，只是审查的对象不同，下面具体介绍代码审查方法。

（1）人员组成

代码审查组通常由2至6名成员组成，分别担任审查组长、讲解员、记录员、程序员、审查员角色。所有参评人员都是审查员，程序员既不能兼任组长，也不能作为讲解员或记录员，其他角色可由审查组成员担当，个别成员可以担当一个以上的角色。为了保证公正性，审查组成员的管理者不应参加审查工作。

（2）各类人员职责

审查组长：审查组长由经过审查技术培训且公正的专业人员担任，负责制定审查计划，组织预审和审查会议。审查组长要确保审查会议有序进行并实现预定的目标，同时，还要收集审查数据，发布审查报告。

讲解员：讲解代码，并对重要的部分予以强调，引导审查组以全面、合乎逻辑的方式进行审查。

记录员：负责记录审查员发现的代码缺陷、提出的建议、应采取的措施以及决策等，此外，还负责记录用于过程分析的审查数据，记录员可由审查组长兼任。

程序员：负责提供满足进入审查条件的代码、解答问题、修改代码以保证代码满足审查出口条件。

审查员：确定并描述审查过程中发现的代码缺陷。应根据专业领域选择审查员，并兼顾其代表性（如委托方、用户、需求、设计、编码、测试项目管理、质量管理）。审查员应只提出与代码审查有关的观点。

为保证审查的充分性，应指定某些审查员负责特定的专题，例如，一个审查员可以关注于与某个或某些标准的符合性审查，另一个审查员关注整体相关性。

（3）进入条件

• 被审查的代码已完成并满足项目标准；

• 需要的支撑文档已准备完毕，包括审查程序、审查报告格式、代码缺陷单、审查单、相关的标准和规范等。

（4）审查流程

审查流程如图1.2所示。

其中，审查报告主要包含下列内容：

• 被审查的项目名称；

• 审查组成员；

• 审查会持续时间；

• 审查的代码；

• 审查的材料数量（如文本页数）；

• 审查的具体输入；

• 审查的目标以及这些目标是否达到；

• 包含缺陷位置、描述以及分类的缺陷表；

• 代码处置；

• 单个成员和审查组总的准备时间；

• 总的返工时间；

• 缺陷摘要（列出每类缺陷的数量）；

• 对返工工作量和返工完成时间的估计；

• 缺陷修改节省的成本估计（与后期修改比较）。

（5）审查注意事项

① 不要流于形式。要挑选业界有经验的人员担当审查员，提供的审查表要可操作并有针对性，检查表中不但要规定“做什么”，而且要规定“如何做”。

② 不要偏离审查会主题。审查会重在发现问题，而非解决问题，不要把审查会变成技术攻关会。

③ 审查时对事不对人。审查时只针对审查对象发表意见，不要涉及具体的人，不要把审查和评价混淆，避免用审查结果评价个人能力。

④ 掌握好审查进度。审查会议一般应限制在2小时以内，每小时审查的代码量应在100～200行。

⑤ 注意收集、分析审查数据。在审查过程中，要注意收集审查数据，如代码规模、发现的问题数量、解决的问题数量、缺陷清除率、审查工作效率等，通过分析这些数据，为改进审查过程提供依据。

1.2.3 技术评审

技术评审是指“一组合格人员对软件产品进行的系统性评价，以检查软件产品是否满足规定的要求，是否符合相关的规范和标准”。软件产品主要包括：软件需求规格说明、软件设计文档、软件测试文档、软件用户文档、维护手册、系统构建程序、安装程序、软件发布通告等。

技术评审中的角色有：决策者、组长、记录员、技术人员、管理人员（可选）、项目组其他成员（可选）、顾客或用户代表（可选）。

技术评审流程与代码审查流程大致相同，在此不再赘述。

与技术评审相比，代码审查更正式，角色更多。代码审查必须按照项目计划实施，不能随意进行。代码审查是一个特定的测试活动，而不是一个评估软件产品适用性的活动。

1.2.4 代码走查

代码走查是一种静态分析技术或评审过程，在此过程中，设计者或程序员引导开发组成员通读已书写的设计或编码，其他成员负责提出问题并对有关技术、风格、可能的错误、是否违背开发标准等方面进行评论。

在代码走查过程中，走查组成员（通常是设计者或程序员）事先提供若干测试用例，参会人员充当计算机，程序员引导参会人员针对每个测试用例用头脑来模拟程序执行过程，并在纸上或白板上监视程序状态（变量的值），这是代码走查与代码审查最大的不同之处。

代码走查有两个目的，第一个目的是评价软件产品，包括发现缺陷、改进软件产品、提供另外的实现方案、评估软件产品与标准和规范的一致性；第二个目的是技术人员的交流和培训。通过代码走查，可以使组内成员在编程风格和产品细节、走查的目的等方面达成一致。

代码走查的另一个优点是能够准确地定位错误，从而降低调试的成本，另外，代码走查通常能够发现批量错误。

（1）人员组成

代码走查至少由两人组成（包括程序员），分别担任组长、记录员、程序员以及成员角色。每个成员可担任多个角色，组长或程序员可以作为记录员，组长也可由程序员担任。为了保证公正性，走查组成员的管理者不得参加走查。

（2）各类人员职责

组长：对走查进行指导，处理与走查有关的管理工作，如分发文档、安排会议等，制定走查目标，发布走查报告。走查组长要确保走查以有序方式进行、确保为每一个讨论项作出决议或明确应采取的措施。

记录员：负责记录走查会议期间作出的决议或确定的整改措施。此外，记录员还应记录走查期间对发现的缺陷、风格方面的疑问、遗漏、矛盾、改进建议或备选方法等方面的意见。

程序员：负责介绍代码。

成员：履行所分配角色的职责。每一个走查组成员要为走查做好充分准备并积极参加走查，识别并描述发现的软件缺陷。

代码走查最佳的人选如下：极富经验的程序员、程序设计语言专家、新程序员、程序维护人员、其他不同项目人员、该软件编程小组的程序员。

（3）进入条件

• 代码已完成并满足项目标准；

• 需要的支撑文档已准备完毕，包括缺陷分类、走查单、相关的标准和规范等。

（4）走查流程

走查流程如图1.3所示。

其中，走查报告主要包含下列内容：

• 被走查的项目名称；

• 走查组成员；

• 走查的代码；

• 本次走查会所要实现的目标以及这些目标是否达到；

• 包含缺陷位置和描述的缺陷表；

• 走查组对每一个缺陷提出的建议；

• 措施、完成日期和责任人列表；

• 针对如何处理缺陷以及未解决的缺陷而提出的建议；

• 走查组对后续走查提出的建议。

（5）走查注意事项

代码走查中选用的测试用例不易太复杂，但一定要有代表性，通过这些用例，程序员能够举一反三。在大多数的代码走查中，很多问题是通过提问程序员发现的，而不是由测试用例本身直接发现的，因此，应重视其中的提问环节。其他的注意事项与代码审查基本相同。

1.2.5 评审类型比较

上面介绍了三种常用的评审方法，表1.1概要给出了技术评审、审查和走查三种方法的比较。

1.2.6 静态分析的优点

相对于动态测试而言，静态分析具有以下优点：

① 静态分析能够有效地发现软件中30%到70%的逻辑设计错误和编码错误；

② 静态分析成本较低。静态分析容易实现而且不依赖于特定的运行环境，因此，在动态测试之前进行静态测试，能够有效发现软件编码方面潜在的错误。静态分析能够很方便地检查软件中某些难以执行到的代码，如错误处理代码；

③ 静态分析可以提早进行。在软件文档和代码完成后，就可以开展静态分析，从而及早发现软件中存在的问题，同时，静态分析能够准确定位软件错误，从而减少软件修改成本；

④ 静态分析能够有效发现软件中的潜在缺陷。一个实现了所要求功能的软件产品，如果软件内部结构设计复杂、代码编写不规范，就会隐藏一些潜在缺陷，即使软件满足了用户目前的要求，这些潜在的缺陷在软件日后的维护和升级中也会带来很多困难，对于这类缺陷，难以通过动态测试发现。

静态分析不是无条件和万能的，静态分析对执行人员的要求高。执行人员除了具有相关领域知识外，还需要有较高的软件开发能力。另外，静态分析不太适合于多任务的软件以及与软件执行顺序密切相关的软件动态特性分析场合。