软件测试第四章1

何时用静态测试或动态测试呢？ （1）在进行文档评审之前必须用静态分析，可以不费 成本地发现一些故障和不一致性，缩短评审时间 （2）即使没有计划进行评审活动，静态分析也应该进 行。通过静态分析发现和删除错误都能提高文档质量。 （3）动态测试不容易发现程序中的不一致性和可能存 在问题的区域。测试对象和编程标准的差异、禁止使 用的易生成错误的程序结构等类型的缺陷只可能通过 静态分析来发现 （4）而有些缺陷只能在程序运行时发现。例除法时分 母的值可以存储在一个变量中，而这个变量可以赋值 为0，那么运行程序就会出问题。这类缺陷只能动态运 行程序才能发现。
1. 走查 走查是以发现书面文档中的缺陷，含糊的表达和问题为的 的非正式评审。[IEEE1028]中提到了使听众了解软件产 品这个目的。标准中描述的走查的主要目的是发现异常、
改进产品、考虑替换方案以及评估对标准和规格的符合度。
2. 审查 审查是最正式的评审。它遵循一个正式而正规的流程。通 常每个参与者都是从作者的直接同事中选出，并且具有固 定的角色。事件的顺序按照一定的规则来定义。使用包含
主持人有如下职责：和评审有关的管理工作，计划、准备
并保证评审有序进行且满足它的目标，收集评审数据，发 布评审报告。
作者是提交评审的文档的创建者。如果是多个人参与文档
的创建，主要负责人应该指定为作者，由他担任作者这个 角色。 评审人员是几个（通常最多5个）在各自准备后检查评审 对象的技术专家。他们应该识别并描述评审对象中存在的
审对象，然后记录文档的不足、问题或意见。
4.评审会议
评审主持者必须保证所有的专家能表达他们的观点,保证 是产品而非作者被评估,必须预防并解决冲突。 12条评审会议的一些准则:
其中问题权重:
1. 严重缺陷（评审对象不能满足它的目的，在批准评审对象 之前必须修正相关缺陷）
2. 重要缺陷（影响评审对象的可用性，批准评审对象之前应 该修改相关缺陷）。
int Help;
if ( Min > Max) { Max=Help; Max=Min; Help=Min;
}
}
通过分析变量的使用情况，可以发现下面的异常： （1）变量Help的ur异常：变量的作用域局限在函 数内。变量的第一次使用是在赋值语句的右面部分。 这个时候，变量未赋值，而这里进行了直接引用。 变量声明时没有初始化。 （2）变量Max的dd异常：在赋值的左边，Max变量 连续使用了两次，因此赋值了两次。第一次的赋值 可以忽略，或者说第一次赋的值（在第二次赋值之 前）已经被遗忘了。 （3）变量Help的du异常：在函数的最后一个赋值 中，变量Help被赋予了一个任何地方都不能用的数 值，因为变量只有在函数内是有效的。
（6）注意点：评审的组织结构在很大程度上决定了使 用的评审类型。根据项目特殊的需要和需求，来对评审 进行相应的裁剪。二则与软件开发人员协同合作有利于 项目质量的提高。 （7）成功因素 a. 根据评审的目的，在检查中发现问题，如不清楚 的观点和偏差，是评审的要求和目的。发现的问题必须 以中性和客观的方式进行记录。 b. 人的特性和心理作用都会对评审产生很强的影响。 评审文档的作者应该将评审作为一种正面的经历。 c. 根据被评审文档的类型和级别以及参与评审人员的 知识水平，来选择不同适合的评审类型。 d.使用检查表和指南来提高评审过程中发现问题的效 率。 d. 需要必要的培训，特别是针对像审查这样正式的评 审类型。 f. 管理层可以为软件开发过程中的文档评审计划足够
管理评审（management review）[IEEE1028]（或项目 评审）的目的是进行过程监控，判断计划进展状态和进 度，进行需求确认和需求的系统分配，或评估为达到特定 目的所采用的管理方法的有效性。 项目整体以及对项目当前状态的确定都是评审的对象。管
理评审会从技术、经济、时间和管理等方面对项目的状态
评审成功的因素： 1. 每次评审都事先定义一个明确的目标 2. 根据每个人的知识与技能水平选择合格的评审参与者。 4.1.3 通用的评审过程 与IEEE的软件评审标准[IEEE1028]相一致。评审要有计划
6个步骤：计划、概述、准备、评审会议、返工和跟踪
1.计划：确定软件开发过程中的什么文档需要什么样的评审 技术。确定估算的评审工作量等。
除了降低缺陷，评审还有下面几个积极的作用。 1. 评审可以降低消除缺陷的成本。 2. 可以缩短开发时间 3. 如果在早期识别和修正了缺陷，用来执行动态测试的 成本和时间就减少，因为测试对象中存在的缺陷总数 少了。 4. 降低系统运行的故障率。
5. 可以通过团队工作相互学习。改进工作方法。
6. 由于评审涉及多人，需要一个清晰容易理解的情况描 述。而且编写一个明确的文档可以使作者发现一些遗 忘的问题。 7. 整个团队对被检查对象负责，且整个组将对文档的理 解达成共识。
g.成功运用评审的一个重要方面是不断从评审中学习经 验教训，比如评审过程的持续改进。
4.2 静态分析 和评审一样，是发现文档中的缺陷或者可能存在缺陷的地 方，经常是通过工具来完成的。如，检查评写的静态分析 器（static analyzer） (1)正式文档，可以是技术需求、软件架构或软件设计。例 UML中的类型图模型。HTML和XML产生的输出可以通过 工具支持来进行静态分析。也可以对设计阶段开发的正式 模型进行分析，找出不一致。在实践中，程序代码是软件 开发过程中唯一可以进行静态分析的正式文档。 在组件测试和集成测试之前或测试过程中，开发人员通常会 使用静态分析工具，来检查代码是否满足编程指南或编程 规范。集成测试中需分析测试对象是否满足接口设计指南。
从不同的角度来审视文档比没有目的文档评审更有效率。
2. 概述
为参加评审的人提供了所有必需的信息。 除了评审对象，这些评审相关人员还必须了解其他的文 档，包括用来判断具体的描述是否正确的参考文档。评审 是依据这些文档（需求规格说明、设计）来完成的。 3. 准备 评审人员集中学习评审对象并根据提供的基础文档检查评
（2）检查编程语言中数据和变量的数据类型的正确性。
（3）检查没有声明的变量
（4）检查不可达的代码 （5）检查域边界的上溢和下溢（静态选择） （6）检查接口的一致性 （7）检查所有作为跳转开始或跳转结束标签的使用。
下面的例子中解释不同类型的异常情况(以C++语言描 述)。下面函数是：假如变量Min的值大于变量Max的 值，则通过变量Help的帮助，来交换参数Max和Min的 整型值： Void exchange (int & Min, int & Max){
问题。他们可以代表不同的观点（例如：主办者、需求、
设计、编码、安全、测试等）。但是表达的观点必须和产 品评审相关。 记录员应该记录下评审团队提出的所有的发现（总是采取 的措施、决定和建议）必须以简短和准备的方式来记录，
抓住讨论的中心思想。
评审可能失败的原因：
（1）需要的人员没空或不具备必需的资格或技术能力。 （2）管理层在资源计划时不准确的估计导致评审的时间 压力而引起的令人不满意的评审结果 （3）评审的工作准备不足。 （4）评审也可能因为没有文档或者文档不足，在评审前 必须检查并验证所有的文档已经存在，并描述充分。 （5）必须取得管理层的支持。 4.1.5 评审的类型 根据评审对象的不同，评审主要分成以下两类。 a. 和技术产品或开发过程中创建的部分产品相关的评审。 b. 分析项目计划和开发流程的评审
第四章 静态测试
评审、基于软件工具的文档分析以及代码分析等静态检查 都是质量改进的有效方法 由手工检查和静态分析组成的。特点是： 测试对象不是以测试数据来执行的。 可以通过一个或多个人一起审查一个文档来完成。 注意：软件开发项目中的所有文档以及项目外的有价值的文 档都可以通过人工方式来审查。工具支持的静态分析只能用 于遵循可以被自动检查的规则的文档。
（1）ur 异常：程序路径上读限了没有定义（u）的变 量
（2）du异常：变量被赋值（d），但是这个变量已经 变成了无效的或者未定义（u）的状态，同时没有被引 用。 （3）dd异常：变量接收了第二个值（d），同时第一 个值没有被使用。
4.2.1 编译器作为静态分析工具
（1）产生不同程序元素的交叉引用列表（比如变量、 函数）
4.1.2 评审 1.评审是对所有人工静态分析和具体文档检查技术的 通称，也叫审查（inspection）。 2.所有的文档都可以提交进行评审或审查，例如：合 同、需求定义、设计规格说明、程序代码、测试计 划和手册。是检查文档语义准确性的唯一手段。 依赖文档作者的同事提供意见反馈。 3.通用V模型每个阶段结束时，确认检查通常都会使 用评审进行，开发活动必须建立在没有缺陷的文档 上。
4.2.3 数据流分析 在程序代码经过的路径上检查数据的用法。虽然并不 是经常能发现缺陷，但它认为可以发现异常 （anomaly）或数据流异常。可能会触发风险。
（1）已定义的（d）：变量已经赋值
（2）引用的（r）：读取或使用变量的值 （3）没有定义的（u）变量没有定义的具体的值 与下面三种数据流异常的3种情况
检查的主要目的：是从已有的规格说明、已定义 的标准甚至是项目计划中发现缺陷，尽可能早地 发现缺陷和偏差对将来的开发过程产生影响之前 发现并修改它们。否则会导致昂贵的返工。 4.1 结构化团体检查 4.1.1 基础
系统地使用人类的能力来思考和分析。
静态分析没有统一的术语，这里使用的术语参考了
ISTQB以及[IEEE1028]中的术语。
注：所有编译器都是一个分析工具。
静态分析可以发现如下问题：
（1）违背语法规则 （2）违背编程规范和标准 （3）控制流异常 （4）数据流异常
（5）安全问题，例缓冲区溢出保护，没有检查输入数 据越界。
4.2.2 检查和规范、标准一致性
通过工具也可检查测试对பைடு நூலகம்是否与规范、标准一致。 且编程人员代码需要按照规范进行检查，他们会自觉 按照规范来工作。