1、第2章 静态测试技术2.1 静态测试技术概要 不在计算机上实际执行所测试的软件而进行的测试（区别于动态测试）包含各种对需求规约、分析和设计规约、代码及开发过程中的各种文档的检查，静态结构分析等可借助软件工具自动进行成本更低，效率更高，可在软件开发生命周期早期阶段发现软件的缺陷。评审 由软件工作产品生产者的同行遵循已定义的规程对软件工作产品所做的审查，目的在与识别工作产品的错误或缺陷及需要改进之处。2.2 评审技术概述 非正式评审工作产品正在开发中，不需要遵循明确定义。正式评审 作者确认工作产品完成后，遵循一个明确定义的评审过程。一般每个评审人员有明确的职责和检查表。根据评审对象，关注内容等不同
2、，正式评审又分为代码检查（包括桌面检 查、代码审查和走查），正规技术评审或正规检视。评审过程一般包括计划阶段、准备阶段、自评审阶段、评审会阶段、重新修改阶段和分析总结阶段。责任和角色在正式的评审中一般包括如下角色：协调负责人、作者、记录员、评审者。他们在正式的评审中承担不同的责任。不同的评审形式所包含的角色及评审人员数量可能不同。2.2 评审技术概述 包括桌面检查、代码审查和走查等主要检查代码和设计的一致性，代码对标准的遵循、可读性，代码逻辑表达的正确性，代码结构的合理性等方面。目的是发现违背程序编写标准的问题，程序中不安全、不明确和模糊的部分，找出程序中不可移植部分、违背程序编程风格的问题，
3、包括变量检查、命名和类型审查、程序逻辑审查、程序语法检查、程序结构检查等内容。2.3 代码检查 桌面检查程序员在程序通过编译之后，对源程序代码进行分析、检验，并补充相关的文档，目的是发现程序中的错误或缺陷。代码审查由若干程序员和测试员组成审查小组，通过阅读、讨论和争议，对程序进行静态分析的过程。2.3 代码检查 小组负责人提前把设计规格说明书、控制流程图、程序文本及有关要求、规范等分发给小组成员，作为审查的依据。召开程序审查会。在此过程中，程序员或其他小组成员可以提出问题，展开讨论，审查错误或缺陷 是否存在。检查表：一份常见错误或缺陷的清单。它把程序中可能发生的各种错误或缺陷进行分类，对每一类
4、列举出尽可能多的典型错误或缺陷，然后把它们制成表格，供再审查时使用。2.3 代码检查 走查与代码审查类似，但开会的程序不同。首先由测试组成员为所测程序准备一批有代表性的测试用例，提交给走查小组。走查小组开会，集体扮演计算机角色，让测试用例沿程序的逻辑运行一遍，随时记录程序的踪迹，供分析和讨论用。借助测试用例能发现更多程序的逻辑和功能问题。具体的走查应当遵循以下过程：(1)计划走查会议(2)走查产品(3)走查会议(4)解决问题(5)记录走查(6)返工产品2.3 代码检查 代码检查应在编译和动态测试之前进行在实际使用中，代码检查能快速找到错误或缺陷，发现 30%70%的逻辑设计和编码缺陷，而且代码
5、检查看到的是问题本身而非征兆。代码检查可以使用测试软件进行自动化测试检查变量的交叉引用表重点是检查未说明的变量和违反了类型规定的变量检查标号的交叉引用表验证所有标号的正确性，检查所有标号的命名是否正确，转向指定位置的标号是否正确。检查子程序、宏、函数验证每次调用与所调用位置是否正确等价性检查检查全部等价变量的类型的一致性，解释所包含的类型差异。常量检查确认常量的取值和数制、数据类型，检查常量每次引用及它的取值、数制和类型的一致性。2.3 代码检查 2.3.2 代码检查内容标准检查用标准检查工具软件或手工检查程序中违反标准的问题。风格检查检查发现程序在设计风格方面的问题。比较控制流比较由程序员设
6、计的控制流图和由实际程序生成的控制流图。选择、激活路径在程序员设计的控制流图上选择路径，再到实际的控制流图上激活这条路径。对照程序的规格说明，比较实际的代码和期望的代码，从差异中发现程序的问题和错误补充文档。2.3.2 代码检查内容2.3 代码检查 总体规范封装规范多态和继承的使用规范重载规范2.3.3 编码规范2.3 代码检查 代码格式规范代码注释规范命名规范2.3.4 代码缺陷检查表代码缺陷检查表中一般包括容易出错的地方和在以往的工作中遇到的典型错误或缺陷。样例见课本P68 表2-12.4 正规技术评审 定义 正规技术评审（Formal Technical Review）是一种审查技术，其
7、主要特点是由一组评审者按照规范的步骤对软件需求、设计、代码或其他技术文档进行仔细的检查，以找出和消除其中的错误或缺陷。目的 发现软件在功能、逻辑、实现上的错误或缺陷。验证软件是否符合它的需求规格。确认软件符合预先定义的开发规范和标准。保证软件在统一的模式下进行开发。便于项目管理。2.4 正规技术评审 评审小组成员 评审小组至少由3人组成，一般为 47 人。应包括：评审员职责是在会前准备阶段和会上检查被审查材料，找出其中的错误或缺陷。主持人会前负责正规技术评审计划和会前准备的检查，会中把握评审会方向，会后负责对问题分类及问题修改后的复核。宣读员在评审会上通过朗读和分段来引导评审小组遍历被审材料。
8、记录员将评审会上发现的软件问题记录在“技术评审问题记录表”。作者负责在评审会上回答评审员提出的问题2.4 正规技术评审 技术评审活动过程 1.计划主持人检查作者提交的被审材料是否齐全，是否满足评审条件，确定评审会时间、地点。2.预备会如果评审小组不熟悉被审材料和有关背景，主持人可以决定是否召开预备会。3.会前准备（自评审）在评审会之前，每一位评审员应根据检查要点逐行检查被审材料，对发现的问题做好标记或记录。4.评审会评审会由主持人主持，由全体评审员共同对被审材料进行检查。5.修正错误作者在会后对评审会上提出的问题根据评审意见进行修正。6.复审7.复核 2.4 正规技术评审 技术评审注意事项 （
9、1）评审应针对被审材料而不是被审材料的作者。（2）每次评审会的时间最好不要超过2小时，具体评审时间的确定要综合考虑被审材料的难易程度、组织内评审标准规范等因素。（3）限制争论和辩驳。（4）阐明问题而不要试图解决问题。2.5 面向对象分析和设计的静态测试 面向对象的需求及分析规约的静态测试 传统系统分析方式：把功能分解，分析结果不可控。面向对象分析方式：围绕映射问题空间展开，将具体的问题空间实例抽象为对象，用对象的结构反映问题空间的复杂实例和复杂关系，用属性和服务表示实例的特性和行为。面向对象的分析过程包含如下内容：（1）已获取的用户需求（一般用模型或者是文档方式给出）。（2）以既定需求为参考的
10、确认类和对象。（3）定义系统类的属性与操作。（4）建立对象关系模型。（5）建立对象操作模型2.5 面向对象分析和设计的静态测试 面向对象的需求及分析规约的静态测试 需求及分析规约测试的内容：（1）对需求的测试 主要是以用例图为依据进行需求的验证。（2）对确认对象的测试 主要放在检查已确认对象是否有冗余的方法和属性，是否有遗漏的信息等。（3）对确认结构的测试 确认的结构主要反映的是目标系统框架的映射。这一部分的测试 主要是检查既定需求的正确性和完整性，找出潜在冲突的需求。2.5 面向对象分析和设计的静态测试 面向对象的需求及分析规约的静态测试 （4）对确认的主题（子系统或包）的测试 比较抽象，主
11、要目的是检查分析结果中是否有遗漏的服务，是否有冗余对象。（5）对定义的属性和实例关联的测试。确保对象的属性可以正常关联。（6）对定义的服务和消息关联的测试。测试系统结构的消息机制能否满足系统运行要求，系统消息的发送方式是否正确，是否存在遗漏的消息接收者或者消息链丢失。2.5 面向对象分析和设计的静态测试 面向对象设计规约的静态测试 面向对象的设计对分析规约中产生的对象进行抽象，将共同的特性提取出来并细化；根据目标系统的层次结构进行系统的结构设计，把系统分解成多个子系统；设计类、类的接口以及类、接口之间的关系。另外，还会涉及界面设计和数据库设计等。面向对象设计阶段会产生一系列的中间结果，这些工作
12、产品包括：(1)详细类定义及类图。(2)消息的详细定义。(3)类的状态图。(4)类或子系统或系统的活动图。(5)Use Case 的合作图（协助图）或顺序图。2.5 面向对象分析和设计的静态测试 面向对象设计规约的静态测试 面向对象测试的内容（1）对确认的类的测试需要对类的定义进行验证，定义的类必须涵盖所有确认的对象，并且具有一定的独立性，不能过分依赖其他的类。（2）对构造的类层次结构的测试类的层次定义与系统框架确定是相对应的，类测试的重点应放在验证类的特性（如继承、封装、多态）和结构的完整性上。（3）对类库的支持的测试类库的测试最主要的是强调可复用类必须足够独立，不能有业务逻辑的引用和实现。（4）对系统架构的测试需要将定义的类进行预先部署，生成系统架构，对于系统需求中的约束需要在这一阶段进行验证。2.5 面向对象分析和设计的静态测试 面向对象设计规约的静态测试 面向对象测试的方法OOD 测试的执行是一个交互的过程，执行测试的时候需要建立一个包括前提条件的消息序列图。交互模型：描述系统内类之间信息交互的机制行为模型：表述类内部结构和行为OOD 测试产生的测试报告需要通过具有行业经验的专家审核，确保执行结果具有指导意义，避免造成开发成本不必要的开销。
