第2章需求和设计评审.pptVIP

软件质量保证与测试 第2章 需求和设计评审 本章内容 2.1 软件评审的方法与技术 什么是评审 (1)什么是评审 内容评审的检查列表 正确性 完整性 一致性 有效性 易测性 模块化 清晰性 可行性 可靠性 可追溯 (2)评审方法 (3)评审会议流程 评审会议角色 测试人员在需求评审中作用 (4)评审的技术 2.2 产品需求评审 问题 需求缺陷 测试需求 功能性测试需求 用户界面及其显示要求 非功能性需求 软件即服务SaaS SaaS的非功能性需求 2.2.1需求评审重要性表现方面 发现需求定义中的问题，尽早发现缺陷，降低劣质成本。 保证软件需求的可测试性。 与市场、产品、开发等相关人员在需求理解上认识一致，以免后期的争吵。 更好的理解产品的功能性与非功能性需求，为制定测试计划打下基础。 确定测试目标与范围。虽然此后需求会发生变更，但能得到有效控制，降低测试风险。 需求评审重要性的直观描述 2.2.2 正确理解需求的过程 2.2.3需求评审的标准 正确性 完备性 易理解性 一致性 可行性 易修改性 易测试性 易追溯性 如何对需求进行评审 内容 2.3 设计评审 设计审查 (1)系统设计的评审标准 设计技术评审标准。稳定、清晰、合理 非功能性质量特性的设计评审要求。安全、性能、稳定、扩展、可靠。 评审的输入：体系结构文档、设计规范与指南、风险列表 评审的输出：经认可的软件体系结构文档、变更需求、评审记录 评审的检查点：软件体系结构、设计模式、部署视图、进程视图、封装体、协议。 (2)系统架构设计的审查 (3)组件设计的审查 (4)界面设计的审查 系统部署设计的审查 Q A 2.3.1 软件设计评审标准 2.3.2 系统架构设计的评审 2.3.3 组件设计的审查 2.3.4 界面设计的评审 系统架构的审查 设计规格说明书的审查 系统部署设计的审查 多层次审查:high-level ? low-level 成功的产品开发和演化依赖于体系结构恰当的选择。软件设计一般可以分为体系结构设计和详细设计。测试人员参与设计评审保证需求能在设计中得到准确和完整的表示，也就是保证产品规格说明书的质量。 采用分层评审和整体评审相结合，经过整体评审到分层评审、再从分层评审到整体评审的过程，这样既能确保评审的深度，又能确保评审的一致性 整个系统不应该存在单一故障点 系统是否建立了故障转移机制 是否建立了良好的负载平衡机制 关键业务 或关键任务 ？ 系统架构设计的基本要求就是保证系统具有高性能、高可靠性、高安全性、高扩展性和可管理性 。系统架构设计评审就是保证这些特性在设计中得到充分考虑。 功能和接口定义正确 算法的有效性和优化 合理的数据结构、数据流和控制流 可测试性等 (1) 易懂性、易用性 (2) 一致性和规范性 (3) 美观与协调性 (4) 遵守惯例和通用法则 (5) 独特性 (6) 捷方式的组合 (7) 自助功能 (8) 错误保护 * * * 需求评审和测试计划并行进行 更重要是测试计划是建立在需求之上、对需求理解的基础之上 保证软件需求的可测试性 2.1 软件评审的方法与技术 2.2 产品需求评审 2.3 设计审查 2.1.1 什么是评审 2.1.2 评审的方法 2.1.3 评审会议 2.1.4 评审的技术 产品需求审查是： 软件开发重要环节之一，也是测试活动之一； 即静态测试——需求验证。 借助需求审查： 保证用户需求在市场/产品需求文档及其相关文档中得到准确、完整、无歧义的反映， 并使各类开发人员在需求理解上达成一致。 软件评审是对软件元素或者项目状态的一种评估手段，以确定其是否与计划的结果保持一致，并使其得到改进。 技术评审 文档评审 管理（流程）评审 最不正式的 最正式的 临时评审 轮查 走查 互为评审 同行评审 审查 Random review, Pass-round, Walkthrough, Peer review, Inspection 达到评审会议标准? Yes 计划 总体介绍 准备 修正问题 跟踪 问题记录 会议纪要 满足执行要求? Yes No 总结报告 评审 评审分析 流程改进建议 主持人 作者 记录员 列席人员 内审员 技术专业人员 明确自己的角色和责任 熟悉评审内容，为评审做好准备 针对问题阐述观点，而非针对个人 从客户角度想问题，多问几个为什么 在会前或会后提出自己建设性的意见 对发现的问题跟踪到底 针对需求文档等报告问题 需求评审归为静态测试范畴，包含了文档评审和技术评审双重内容，通常通过正式的评审会议来进行。而测试人员主要起着评审员的作用，检查需求定义是否合理和清楚。 检查表（ch