ST-第2章 需求和设计评审

1、1第第2章章 需求和设计评审需求和设计评审任课教师：兰方鹏任课教师：兰方鹏Mobile:Q: 2本章内容本章内容2.1 软件评审的方法与技术软件评审的方法与技术2.2 产品需求评审产品需求评审2.3 设计审查设计审查3内容内容2.1 软件评审的方法与技术软件评审的方法与技术2.2 产品需求评审2.3 设计审查42.1 软件评审的方法与技术软件评审的方法与技术2.1.1 2.1.1 什么是评审什么是评审2.1.2 2.1.2 评审的方法评审的方法2.1.3 2.1.3 评审会议评审会议2.1.4 2.1.4 评审的技术评审的技术5什么是评审什么是评审技术评审技术评审文档

2、评审文档评审管理评审流程评审产品需求审查是软件开发重要环节之一，也是测试活动之一，即静态测试需求验证。借助需求审查保证用户需求在市场/产品需求文档及其相关文档中得到准确、完整、无歧义的反映，并使各类开发人员在需求理解上达成一致。6评审v通过软件评审，可以更早地发现需求工程、软件设计等各个方面的问题，大大减少大量的后期返工，将质量成本从昂贵的后期返工转化为前期的缺陷发现。v评审是对软件元素或者项目状态的一种评估手段，以确定其是否与计划的结果保持一致，并使其得到改进。检验工作产品是否正确地满足了以往工作产品中建立的规范。7为什么需要评审 从成本上来衡量 缺陷发现得越晚纠正费用越高，而软件评审的重要

3、目的就是通过软件评审尽早的产品中的缺陷，减少大量的后期返工。 8为什么需要评审 从技术上来衡量 前一阶段的错误自然会导致后一阶段的工作结果中有相应的错误，而且错误会逐渐累积，越来越多。9评审分类评审分类v管理评审管理评审v技术评审技术评审v文档评审文档评审v流程评审流程评审管理评审和技术评审属于质量保证和管理范畴，不属于软件测试范畴，我们讨论的软件评审仅限于技术评审和文档评审。10技术评审技术评审 评审的目的 评审的内容 评审检查单 其他必需文档技术评审技术评审技术评审报告会议的基本信息会议的基本信息 存在的问题和建议存在的问题和建议措施措施 评审结论和意见评审结论和意见问题跟踪表问题跟踪表技

4、术评审问答记录技术评审问答记录 输入输入输出输出11文档评审文档评审o 正确性o 完整性o 一致性o 有效性o 易测性o 模块化-系统和文档描述必须深入到模块。o 清晰性o 可行性o 可靠性o 可追溯性12评审方法评审方法最不正式的最正式的临时评审轮查互为复审走查会议审查Random review, Pass-round, Peer-to-Peer review , Walkthrough, Inspection13正式评审与非正式评审结合正式评审与非正式评审结合v 正式评审：开评审会，组织多个专家，将需求涉及到的人员集合在一起，并定义好参与评审人员的角色和职责v 非正式评审：不需要将人员集合

5、在一起，通过电子邮件、网络聊天等多种形式v 有时，非正式的评审比正式的评审效率更高，更容易发现问题 14评审会议流程评审会议流程达到评审会议标准?Yes计划全面纵览准备修正问题跟踪问题记录会议纪要满足执行要求?YesNo总结报告评审结果分析流程改进建议15评审会议角色评审会议角色主持人作者记录员列席人员内审员技术专业人员16评审的技术评审的技术检查表（检查表（checklist）是一种常用的的质量保证手段，也是正式技术评审的必要工具，评审过程往往由检查表驱动。一份精心设计的检查表，对于提高评审效率、改进评审质量具有很大帮助。p可靠性。人们借助检查表以确认被检查对象的所有质量特征均得到满足，避免

6、遗漏任何项目。p效率。检查表归纳了所有检查要点，比起冗长的文档，使用检查表具有更高的工作效率。检查表检查表( (缺陷检查表缺陷检查表) )、场景分析、头脑风暴和工具等、场景分析、头脑风暴和工具等17内容内容2.1 软的方件评审法与技术2.2 产品需求评审产品需求评审2.3 设计审查182.2 产品需求评审产品需求评审2.2.1需求评审的重要性需求评审的重要性2.2.2 如何理解需求如何理解需求2.2.3 需求评审的标准需求评审的标准2.2.4 如何对需求进行评审如何对需求进行评审19问题问题为什么在测试计划中谈需求评审为什么在测试计划中谈需求评审？20需求缺陷需求缺陷为什么软件需求定义中存在很

7、多缺陷最多？为什么软件需求定义中存在很多缺陷最多？软件缺陷并不只是在编程阶段才产生，需求和设计阶段同软件缺陷并不只是在编程阶段才产生，需求和设计阶段同样会产生缺陷样会产生缺陷。21需求评审重要性的直观描述需求评审重要性的直观描述22需求评审期望达到的目标需求评审期望达到的目标 发现需求定义中问题，发现缺陷，降低成本，减少后续变更，降低风险。 更好的理解产品的功能性需求和非功能性需求 明确了测试的目标和范围，使得后续的需求变更在有效的控制范围内 通过和不同人员的沟通对产品的认识达到了共识 保证了软件需求的可测试性23正确理解需求的过程正确理解需求的过程举例说明举例说明24测试需求测试需求p 在制

8、定测试计划之前，必须清楚测试需求在制定测试计划之前，必须清楚测试需求p 明确测试需求的优先级明确测试需求的优先级p 测试需求分解得越细，对测试用例的设计质量越有帮助测试需求分解得越细，对测试用例的设计质量越有帮助p 详细的测试需求还是衡量测试覆盖率的重要依据详细的测试需求还是衡量测试覆盖率的重要依据p 测试需求是规划具体项目资源和时间的基础。测试需求是规划具体项目资源和时间的基础。测试目标取决于软件质量需求，而这种需求分为功能性需测试目标取决于软件质量需求，而这种需求分为功能性需求和非功能性需求，功能性的需求相对容易确定，非功能求和非功能性需求，功能性的需求相对容易确定，非功能性的测试需求难以

9、确定。性的测试需求难以确定。25功能性测试需求功能性测试需求p程序安装、启动正常，有相应的提示框、错误提示程序安装、启动正常，有相应的提示框、错误提示p各项功能符合设计要求，正常运行并输出正确结果各项功能符合设计要求，正常运行并输出正确结果p功能逻辑合理，并能处理各种异常操作功能逻辑合理，并能处理各种异常操作p能接受正确的数据输入，输出结果准确，格式清晰能接受正确的数据输入，输出结果准确，格式清晰p系统的各种状态按照业务流程而变化并保持稳定系统的各种状态按照业务流程而变化并保持稳定p支持各种应用环境，能配合硬件设备支持各种应用环境，能配合硬件设备p 功能性测试需求主要是根据产品规格说明书来检验

10、被测试的系统是否满足软件各方面的功能的使用要求，包括用户界面的友好性。26用户界面及其显示要求用户界面及其显示要求p 通用框架、浮动窗口和文字等整体布局合理通用框架、浮动窗口和文字等整体布局合理p 文字显示正常，且内容格式正确、美观。文字显示正常，且内容格式正确、美观。p 色彩协调，风格前后一致，色彩协调，风格前后一致，p 文字标记和超链接可以打开和跳转成功文字标记和超链接可以打开和跳转成功p 用户界面是和用户进行交互的窗口，其友好程度直接影响用户对于软件产品或软件服务的满意度。良好的用户体验，简单、方便和明了，让用户舒畅、愉悦 KISS Keep it simple, stupidDont

11、make me think27非功能性需求非功能性需求p客户端软件，如字处理软件、媒体播放软件等客户端软件，如字处理软件、媒体播放软件等占用较少资源占用较少资源，在容错性、兼容性等方面要求高。在容错性、兼容性等方面要求高。pWebWeb应用系统对性能、安全性等有很高要求应用系统对性能、安全性等有很高要求p客户端客户端/服务器应用系统。服务器应用系统。p大型复杂企业级系统。大型复杂企业级系统。非功能性质量需求，包括系统性能、安全性、兼容性、扩充性，其测试需求会因不同的项目类型差异较大。28软件即服务软件即服务SaaSp 软件运行的服务质量（软件运行的服务质量（QoS, Quality of se

12、rvice）p QoS要求是指定某些系统特性的技术规范。要求是指定某些系统特性的技术规范。SaaS (Software as a Service)是软件服务模式，厂商将应用软件统一部署在自己的服务器上，客户可以根据自己实际需求定购所需的应用软件服务。On-Demand ServiceOn-Premise Service29SaaS的非功能性需求的非功能性需求p性能要求，系统响应能力。p可用性, 7x24 不间断服务p可伸缩性，系统容量扩充能力，使系统可以支持来自扩大用户群体的额外负载。p安全性要求，确定可能潜在的安全威胁并找到处理策略。p可维护性要求，对部署系统进行维护的难易程度，可维护性与可

13、用性之间关系密切30需求评审重要性表现方面需求评审重要性表现方面v 发现需求定义中的问题，尽早发现缺陷，降低劣质成本。v 保证软件需求的可测试性。v 与市场、产品、开发等相关人员在需求理解上认识一致，以免后期的争吵。v 更好的理解产品的功能性与非功能性需求，为制定测试计划打下基础。v 确定测试目标与范围。虽然此后需求会发生变更，但能得到有效控制，降低测试风险。31需求评审的标准需求评审的标准v 正确性v 完备性v 易理解性v 一致性v 可行性v 易修改性v 易测试性v 易追溯性32软件系统需求质量标准软件系统需求质量标准v 正确性v 可行性v 规范性v 可验证性v 优先级v 合理性v 完备性v

14、 无二义性v 兼容性v 一致性v 易追溯性33软件文档质量标准软件文档质量标准v 规范性v 易理解性v 一致性v 准确性v 易修改性v 读者34测试人员在需求评审中作用测试人员在需求评审中作用p 明确自己的角色和责任明确自己的角色和责任p 熟悉评审内容，为评审做好准备熟悉评审内容，为评审做好准备p 针对问题阐述观点，而非针对个人针对问题阐述观点，而非针对个人p 从客户角度想问题，多问几个为什么从客户角度想问题，多问几个为什么p 在会前或会后提出自己建设性的意见在会前或会后提出自己建设性的意见p 对发现的问题跟踪到底对发现的问题跟踪到底p 针对需求文档等报告问题针对需求文档等报告问题需求评审归为

15、静态测试范畴，包含了文档评审和技术评审需求评审归为静态测试范畴，包含了文档评审和技术评审双重内容，通常通过正式的评审会议来进行。而测试人员双重内容，通常通过正式的评审会议来进行。而测试人员主要起着评审员的作用，检查需求定义是否合理和清楚。主要起着评审员的作用，检查需求定义是否合理和清楚。35 如何做好需求评审如何做好需求评审 （1）分层次评审 （2）分类评审 （3）正式评审与非正式评审结合 （4）分阶段评审 （5）精心挑选评审员 （6）对评审员进行培训 （7）充分利用需求评审检查单 （8）建立标准的评审流程 （9）做好评审后的跟踪工作需求评审需求评审36 分层次评审分层次评审指导思想：先总体，

16、后细节v 高层次评审 v 低层次评审37 分类评审分类评审 按照业务需求、功能需求、非功能需求、用户操作性需求等进行分类评审 目标性需求：定义了整个系统需要达到的目标 （高层管理人员关注） 功能性需求：定义了整个系统必须完成的任务 （中层管理人员关注 ） 操作性需求：定义了完成每个任务的具体的人机交互 （具体操作人员关注） 38 正式评审与非正式评审结合正式评审与非正式评审结合v 正式评审：开评审会，组织多个专家，将需求涉及到的人员集合在一起，并定义好参与评审人员的角色和职责v 非正式评审：不需要将人员集合在一起，通过电子邮件、网络聊天等多种形式v 有时，非正式的评审比正式的评审效率更高，更容

17、易发现问题 39 分阶段评审分阶段评审v 在需求形成的过程中进行分阶段的评审，而不是在需求最终形成后再进行评审v 将原本需要进行的大规模评审拆分成各个小规模的评审 v 降低了需求返工的风险，提高了评审的质量 40 精心挑选评审员精心挑选评审员需求评审可能涉及的人员：v 需方：高层管理人员、中层管理人员、具体操作人员、IT主管、采购主管v 供方：市场人员、需求分析人员、设计人员、测试人员、质量保证人员、实施人员、项目经理以及第三方的领域专家等等 41v 这些人员所处的立场不同，对同一个问题的看法是不相同的，不同的观点可能形成互补的关系 v 要保证使不同类型的人员的都要参与进来，否则很可能会漏掉了

18、很重要的需求 v 不同类型的人员中要选择那些真正和系统相关的，对系统有足够了解的人员参与进来，否则使评审的效率降低 精心挑选评审员精心挑选评审员42 对评审员进行培训对评审员进行培训 v 很多情况下，评审员是领域专家而不是进行评审活动的专家，没有掌握进行评审的方法、技巧、过程等，需要培训v 对于主持评审的管理者也需要进行培训，使参与评审的人员能够围绕评审的目标来进行，能控制评审节奏，提高评审效率 43 充分利用需求评审检查单充分利用需求评审检查单 v 需求检查单：需求形式检查单和需求内容检查单。v 需求形式检查：由QA人员负责，主要是针对需求文挡的格式是否符合质量标准v 需求内容检查：是由评审

19、员负责，主要是检查需求内容是否达到了系统目标、是否有遗漏、是否有错误等等v 检查单可以帮助评审员系统全面地发现需求中的问题v 检查单随着工程经验的积累逐渐丰富和优化44 建立标准的评审流程建立标准的评审流程 v 需求评审会需要建立正规的需求评审流程，按照流程中定义的活动进行规范的评审过程 45 做好评审后的跟踪工作做好评审后的跟踪工作 v 根据评审人员提出的问题进行评价：v 确定哪些问题必须纠正（给出理由与证据）：书面的需求变更申请，进入需求变更的管理流程，并确保变更的执行。在变更完成后，要进行复审。 v 切忌评审完毕后，没有对问题进行跟踪，而无法保证评审结果的落实，使前期的评审努力付之东流

20、46内容内容2.1 软件评审的方法与技术2.2 产品需求评审2.3 设计审查设计审查472.3 设计评审设计评审2.3.1 软件设计评审标准软件设计评审标准2.3.2 系统架构设计的评审系统架构设计的评审2.3.3 组件设计的审查组件设计的审查2.3.4 界面设计的评审界面设计的评审48设计审查设计审查p 系统架构的审查系统架构的审查p 设计规格说明书的审查设计规格说明书的审查p 系统部署设计的审查系统部署设计的审查p 多层次审查多层次审查:high-level :high-level low-levellow-level 成功的产品开发和演化依赖于体系结构恰当的选择。软件设计一般可以分为体系结构设计和详细设计。测试人员参与设计评审保证需求能在设计中得到准确和完整的表示，也就是保证产品规格说明书的质量。49系统设计的评审标准系统设计的评审标准设计技术评审标准。v 设计结果稳定v 设计清晰v 设计合理v 结构简单v 低耦合、高内聚v 结构和数据的一致性v 可测试性和可追溯性v 依赖性v 不完整、易变动或潜在的需求项50系统模块结构的复杂性描述系统模块结构的复杂性描述51衡量系统复杂性的简单标准指标衡量系统复杂性的简单标准指标v 深度v 宽度v 扇入值v 扇出值良好的软件结构：顶层的扇出大，中间的扇出较小，底层的扇入较大52系统设计