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

第2章需求和设计评审
(2)评审方法
最不正式的
最正式的
临时评审
轮查
走查
互为评审
同行评审
审查
Random review, Pass-round, Walkthrough, Peer review, In功能性的需求相对容易确定，非功能性的测试需求难以确定。
功能性测试需求
程序安装、启动正常，有相应的提示框、错误提示
各项功能符合设计要求，正常运行并输出正确结果
功能逻辑合理，并能处理各种异常操作
能接受正确的数据输入，输出结果准确，格式清晰
系统的各种状态按照业务流程而变化并保持稳定
支持各种应用环境，能配合硬件设备
… …
功能性测试需求主要是根据产品规格说明书来检验被测试的系统是否满足软件各方面的功能的使用要求，包括用户界面的友好性。
用户界面及其显示要求
通用框架、浮动窗口和文字等整体布局合理
文字显示正常，且内容格式正确、美观。
色彩协调，风格前后一致，
文字标记和超链接可以打开和跳转成功
… …
用户界面是和用户进行交互的窗口，其友好程度直接影响用户对于软件产品或软件服务的满意度。良好的用户体验，简单、方便和明了，让用户舒畅、愉悦
KISS – Keep it simple, stupid
Don’t make me think
非功能性需求
客户端软件，如字处理软件、媒体播放软件等占用较少资源，在容错性、兼容性等方面要求高。
Web应用系统对性能、安全性等有很高要求
客户端/服务器应用系统。
大型复杂企业级系统。
非功能性质量需求，包括系统性能、安全性、兼容性、扩充性，其测试需求会因不同的项目类型差异较大。
软件即服务SaaS
软件运行的服务质量（QoS, Quality of service）
QoS要求是指定某些系统特性的技术规范。
SaaS (Software as a Service)是软件服务模式，厂商将应用软件统一部署在自己的服务器上，客户可以根据自己实际需求定购所需的应用软件服务。
On-Demand Service
On-Premise Service
SaaS的非功能性需求
性能要求，系统响应能力。
可用性, 7x24 不间断服务
可伸缩性，系统容量扩充能力，使系统可以支持来自扩大用户群体的额外负载。
安全性要求，确定可能潜在的安全威胁并找到处理策略。
可维护性要求，对部署系统进行维护的难易程度，可维护性与可用性之间关系密切

发现需求定义中的问题，尽早发现缺陷，降低劣质成本。
保证软件需求的可测试性。
与市场、产品、开发等相关人员在需求理解上认识一致，以免后期的争吵。
更好的理解产品的功能性与非功能性需求，为制定测试计划打下基础。
确定测试目标与范围。虽然此后需求会发生变更，但能得到有效控制，降低测试风险。
需求评审重要性的直观描述
正确理解需求的过程
举例说明

正确性
完备性
易理解性
一致性
可行性
易修改性
易测试性
易追溯性
如何对需求进行评审
内容
软件评审的方法与技术
产品需求评审
设计审查
设计评审
软件设计评审标准
系统架构设计的评审
组件设计的审查
界面设计的评审
设计审查
系统架构的审查
设计规格说明书的审查
系统部署设计的审查
多层次审查:high-level  low-level
成功的产品开发和演化依赖于体系结构恰当的选择。软件设计一般可以分为体系结构设计和详细设计。测试人员参与设计评审保证需求能在设计中得到准确和完整的表示，也就是保证产品规格说明书的质量。
(1)系统设计的评审标准
设计技术评审标准。稳定、清晰、合理
非功能性质量特性的设计评审要求。安全、性能、稳定、扩展、可靠。
评审的输入：体系结构文档、设计规范与指南、风险列表
评审的输出：经认可的软件体系结构文档、变更需求、评审记录
评审的检查点：软件体系结构、设计模式、部署视图、进程视图、封装体、协议。
(2)系统架构设计的审查
采用分层评审和整体评审相结合，经过整体评审到分层评审、再从分层评审到整体评审的过程，这样既能确保评审的深度，又能确保评审的一致性
整个系统不应该存在单一故障点
系统是否建立了故障转移机制
是否建立了良好的负载平衡机制
关键业务 或关键任务 ？
系统架构设计的基本要求就是保证系统具有高性能、高可靠性、高安全性、高扩展性和可管理性 。系统架构设计评审就是保证这些特