ST-第2章需求和设计评审分解.ppt

* 设计审查 系统架构的审查 设计规格说明书的审查 系统部署设计的审查 多层次审查:high-level ? low-level 成功的产品开发和演化依赖于体系结构恰当的选择。软件设计一般可以分为体系结构设计和详细设计。测试人员参与设计评审保证需求能在设计中得到准确和完整的表示，也就是保证产品规格说明书的质量。 * 系统设计的评审标准 设计技术评审标准。 设计结果稳定 设计清晰 设计合理 结构简单 低耦合、高内聚 结构和数据的一致性 可测试性和可追溯性 依赖性 不完整、易变动或潜在的需求项 * 系统模块结构的复杂性描述 * 衡量系统复杂性的简单标准指标 深度 宽度 扇入值 扇出值 良好的软件结构： 顶层的扇出大，中间的扇出较小，底层的扇入较大 * 系统设计的评审标准 非功能性质量特性的设计评审要求。 安全性 性能 稳定性 扩展性 可靠性 * 系统架构设计的审查 采用分层评审和整体评审相结合，经过整体评审到分层评审、再从分层评审到整体评审的过程，这样既能确保评审的深度，又能确保评审的一致性 整个系统不应该存在单一故障点 系统是否建立了故障转移机制 是否建立了良好的负载平衡机制 关键业务 或关键任务 ？ 系统架构设计的基本要求就是保证系统具有高性能、高可靠性、高安全性、高扩展性和可管理性 。系统架构设计评审就是保证这些特性在设计中得到充分考虑。 * 组件设计的审查 功能和接口定义正确 算法的有效性和优化 合理的数据结构、数据流和控制流 可测试性等 * 界面设计的审查 (1) 易懂性、易用性 (2) 一致性和规范性 (3) 美观与协调性 (4) 遵守惯例和通用法则 (5) 独特性 (6) 快捷方式的组合 (7) 自助功能 (8) 错误保护 * 系统部署设计的审查 着重是否服从和遵守部署设计的技术规范 逻辑设计的审查 物理设计的审查 可用性设计的审查 可伸缩型设计的验证 安全性设计的验证 系统部署设计的审查是基于软件服务的质量目标，用来审查软件部署的目标、策略是否合理，是否得到彻底的执行。 * Q A 需求评审和测试计划并行进行 更重要是测试计划是建立在需求之上、对需求理解的基础之上 保证软件需求的可测试性 * 评审的技术 检查表（checklist）是一种常用的的质量保证手段，也是正式技术评审的必要工具，评审过程往往由检查表驱动。一份精心设计的检查表，对于提高评审效率、改进评审质量具有很大帮助。 可靠性。人们借助检查表以确认被检查对象的所有质量特征均得到满足，避免遗漏任何项目。 效率。检查表归纳了所有检查要点，比起冗长的文档，使用检查表具有更高的工作效率。 检查表(缺陷检查表)、场景分析、头脑风暴和工具等 * 内容 2.1 软的方件评审法与技术 2.2 产品需求评审 2.3 设计审查 * 2.2 产品需求评审 2.2.1需求评审的重要性 2.2.2 如何理解需求 2.2.3 需求评审的标准 2.2.4 如何对需求进行评审 * 问题 为什么在测试计划中谈需求评审？ * 需求缺陷 为什么软件需求定义中存在很多缺陷最多？ 软件缺陷并不只是在编程阶段才产生，需求和设计阶段同样会产生缺陷。 * 需求评审重要性的直观描述 * 需求评审期望达到的目标 发现需求定义中问题，发现缺陷，降低成本，减少后续变更，降低风险。 更好的理解产品的功能性需求和非功能性需求 明确了测试的目标和范围，使得后续的需求变更在有效的控制范围内 通过和不同人员的沟通对产品的认识达到了共识 保证了软件需求的可测试性 * 正确理解需求的过程 举例说明 * 测试需求 在制定测试计划之前，必须清楚测试需求 明确测试需求的优先级 测试需求分解得越细，对测试用例的设计质量越有帮助 详细的测试需求还是衡量测试覆盖率的重要依据 测试需求是规划具体项目资源和时间的基础。 测试目标取决于软件质量需求，而这种需求分为功能性需求和非功能性需求，功能性的需求相对容易确定，非功能性的测试需求难以确定。 * 功能性测试需求 程序安装、启动正常，有相应的提示框、错误提示 各项功能符合设计要求，正常运行并输出正确结果 功能逻辑合理，并能处理各种异常操作 能接受正确的数据输入，输出结果准确，格式清晰 系统的各种状态按照业务流程而变化并保持稳定 支持各种应用环境，能配合硬件设备 … … 功能性测试需求主要是根据产品规格说明书来检验被测试的系统是否满足软件各方面的功能的使用要求，包括用户界面的友好性。 * 用户界面及其显示要求 通用框架、浮动窗口和文字等整体布局合理 文字显示正常，且内容格式正确、美观。 色彩协调，风格前后一致， 文字标记和超链接可以打开和跳转成功 … … 用户界面是和用户进行交