Ch3-需求的和设计评审.pptVIP

成功的产品开发和演化依赖于体系结构恰当的选择。软件设计一般可以分为概要设计和详细设计。 测试人员参与设计评审保证需求能在设计中得到准确和完整的表示，也就是保证产品设计说明书的质量。 架构设计即体系结构设计。 * * * 软件工程系 计算机与信息工程学院 软件工程系 申煜湘 Tel:shenyuxiang@xmut.edu.cn 《软件测试技术》 2015-2016-02 第3章 需求和设计评审 第3章 需求和设计评审 3.1 软件评审的方法与技术 3.2 需求评审 3.3 设计评审 什么是评审 IEEE对软件评审的定义：软件评审是对软件元素或者项目状态的一种评估手段，以确定其是否与计划的结果保持一致，并使其得到改进。 技术评审：旨在揭示软件需求、架构、逻辑、功能和算法上的各种错误，以确保需求规格说明书、设计文档等没有技术问题，而且相互之间保持一致，能正确地开发出软件产品。 文档评审：检查文档格式是否符合标准、是否符合已有的模板；审查其内容是否前后一致、逻辑是否清晰、描述是否清楚等。 管理评审、流程评审 评审的作用 通过软件评审，可以尽早地发现产品中的缺陷，可以减少大量的后期返工。 软件评审是从根本上提高产品的质量，降低软件开发的成本。 HP公司：审查投资回报率为10:1，每年可节省约2140万美元，在设计过程中进行评审使得软件上市时间平均提前18个月。 ATT贝尔实验室：审查使得发现错误的费用减低到10%，同时使质量提高了10倍，效率提高了14%。 评审的方式 最不正式的 最正式的 临时评审 轮查 （邮件分发） Email Pass-around 走查 Walkthrough 互为评审 （同行评审） Peer-to-peer 会议审查 Inspection 评审会议的流程 达到评审会议标准？ Yes 计划 总体介绍 准备 问题解决 跟踪 问题记录 会议纪要 Yes No 总结 评审 评审分析 过程改进建议 满足要求？ 参加评审会议的角色 评审组长 作者 记录员 列席人员 评审员 技术专业人员 检查表(checklist) 检查表是正式技术评审的必要工具，评审过程往往由检查表驱动。 一份精心设计的检查表，对于提高评审效率、改进评审质量具有很大帮助。 可靠性。借助检查表以确认被检查对象的所有质量特征均得到满足，避免遗漏任何项目。 效率。检查表归纳了所有检查要点，比起冗长的文档，使用检查表具有更高的工作效率。 如何制定检查表? 以下是一些经验： 不同类型的评审对象应该编制不同的检查表； 根据以往的经验收集同类评审对象常见缺陷； 基于以往经验和问题报告，对缺陷的严重性和可能性排序； 以简单的形势表达每一种缺陷； 根据评审对象的质量要求，对检查表的问题做必要的增删改调。 示例：一份需求评审检查表。 第3章 需求和设计评审 3.1 软件评审的方法与技术 3.2 需求评审 3.3 设计评审 需求评审的重要性 软件缺陷并不只是在编程阶段才产生，需求和设计阶段同样会产生缺陷。 需求阶段的缺陷甚至比设计阶段的还多！ 需求评审的目标 发现需求定义中的问题，尽早发现缺陷，降低劣质成本。 保证软件需求的可测试性。 与市场、产品、开发等相关人员在需求理解上认识一致，以免后期的争吵。 更好的理解产品的功能性与非功能性需求，为制定测试计划打下基础。 确定测试目标与范围。虽然此后需求还会发生变更，但能得到有效控制，降低测试风险。 正确理解需求的过程 需求评审的标准 IEEE建议的需求说明标准： 系统需求的质量标准： 正确性 可行性 规范性 可验证性 优先级 合理性 完备性 无二义性 兼容性 一致性 易追溯性 文档的质量标准： 规范性 易理解性 一致性 准确性 易修改性 读者 测试人员在需求评审中的作用 明确自己的角色和责任 熟悉评审内容，为评审做好准备 针对问题阐述观点，而非针对个人 从客户角度想问题，多问几个为什么 在会前或会后提出自己建设性的意见 对发现的问题跟踪到底 针对需求文档等报告问题 需求评审属静态测试范畴，包含了文档评审和技术评审双重内容，常采用正式评审会议形式。 而测试人员主要起着评审员的作用，检查需求定义是否合理和清楚。 如何对需求进行评审？ 分层评审方法 高层次评审 低层次评审 分类评审方法 业务需求 功能需求 用户操作性需求 分阶段评审方法 第3章 需求和设计评审 3.1 软件评审的方法与技术 3.2 需求评审 3.3 设计评审 软件设计的评审标准 设计技术的评审标准： 稳定性 清晰性 合理性 依赖性 结构简单性 系统的耦合度和内聚度 结构与数据的一致性 可测试性和可追溯性 不完整易变动或潜在的需求项 非功能性质量特性的设计评审要