软件测试第9章 软件评审.pptVIP

9.2.2 代码评审的成功实例 许多研究工作都用事实和数据证明了代码评审是很有意义的，也是查找软件缺陷最为成功的方法。 1．Fagan的实例 2．Jones的实例 查找故障活动 每千行代码发现的故障数 查找故障活动 每千行代码发现的故障数 需求评审 2.5 集成测试 3.0 设计评审 5.0 验收测试 2.0 代码审查 10.1 表9.8 各种查找故障活动的效果对比 9.2.3 评审与其他验证方法的比较 1．Jones的比较 C．Jones也对多种不同的方法作了分析和对比。 实践的数据是最有说服力的。 表9.9提供了软件开发中采用不同的方法查找隐蔽的故障的百分比，表中的数字指的是故障的根源，如一个代码的故障，其实是需求规格说明中的问题引发的，那就将其列入需求栏内。 表9.9 故障发现的百分比 表9.9中加方框的数据是该行数据的最大值。 它表明，建立原型和实施需求评审对发现需求的缺陷，设计评审对发现设计缺陷，代码审查和单元测试对代码缺陷的发现最为有效。并且代码审查的效果优于单元测试。 C．Jones进一步给出各种方法使用效果的对比（参见表9.10）。 方 法 需 求 故 障 设 计 故 障 代 码 故 障 文 档 故 障 评审 尚好 优 优 好 原型 好 尚可 尚可 不适用 测试 差 差 好 尚可 正确性证明 差 差 尚可 尚可 表9.10 不同方法发现各类故障的效果 2．Olsen等人的观点 在分析了一家财务软件开发公司使用C、Objective C、汇编语言和Script等语言编写的184?000行代码系统的情况后，从相关各项验证活动发现的故障是有差别的。 表9.11中给出了采用不同方法发现故障的情况对比。 方 法 发现故障比例 方 法 发现故障比例 系统设计审查 17.3% 集成测试 29.4% 部件设计审查 19.1% 系统测试与回归测试 16.6% 代码审查 15.1% 系统运行后发现故障 0.1% 表9.11 用不同方法发现故障的对比 ● 实施评审的项目其生产率比未曾采用正式评审的项目其生产率要高出一倍以上。 ● 有些情况下，50%～80%的缺陷是通过测试之前的评审发现的。 ● IBM Federal Systems Division追求的目标是在测试之前找出85%的缺陷，以减轻测试的压力，降低测试工作的成本。 缺陷是对软件产品预期属性的偏离现象，这包括： 对产品规格说明（specification）的偏离。软件产品中任何与规格说明不一致的特性都应视为缺陷； 对客户或用户期望的偏差现象。这种被偏差的客（用）户期望有的属于不言而喻，无须在规格说明中规定的产品特性，也可能是由于疏漏而未将其纳入规格说明中； 故障（fault）在计算机硬件中的含义是缺陷暴露后的表现，在软件中往往把它和缺陷不加以区别，认为是同样含意的。本章中后面的讨论中也认为两者是同意义的。 （3）3种缺陷 ① 错误（wrong或error） ② 遗漏（missing） ③ 额外的实现（extra） （4）缺陷和事故（failure） 2．软件评审（review） ① 按IEEE的说法，评审是软件开发组之外的人员或小组对于软件需求、设计或代码进行详细审查的一种正式评价方法。其目的在于发现软件中的缺陷，找出违背执行标准的情况以及其他问题。 ② 通常认为软件评审具有以下特点。 目的在于发现隐藏的软件缺陷。 参加评审的人应以软件项目开发组以外的同行人员为主，如有项目组人员参加也只是起帮助理解评审对象的作用。 被评审的对象通常指的是软件开发中的各种技术产品，如需求规格说明、用户手册、系统设计文档、源程序或测试计划等。事实上某些管理文件也可能当作评审的对象，如软件开发计划等。 评审有多种形式。所谓正式评审要以评审会形式进行。本章后面的内容将作具体的介绍。而非正式评审也可能用相关的评审人员分散阅读，并提出书面意见的方式进行，但也必须有评审人员的签名，以体现评审的责任。 9.1.4 相关国际标准及能力成熟度模型中对软件评审的要求 在此给出若干国际标准中有关软件评审的要求摘要。 （1）国际标准ISO/IEC 12207—2008《系统与软件工程—软件生存期过程》 （2）国际标准ISO/IEC 9001—2000《质量管理体系——要求》中对评审作了规定（参见表9.3）。 （3）过程能力成熟度模型集成CMMI——Capability Maturity Model Integration在多个过程域中将评审当作过程实施的手段。 节 号 过 程 评价与评审对象 评 价 准 则 7.1.2 软件需求分析过