ST第2章需求和设计评审

1软件测试第2章需求和设计评审任课教师：兰方鹏MobileQ:275392011lfp424@163.com2本章内容2.1软件评审的方法与技术2.2产品需求评审2.3设计审查3内容2.1软件评审的方法与技术2.2产品需求评审2.3设计审查42.1软件评审的方法与技术2.1.1什么是评审2.1.2评审的方法2.1.3评审会议2.1.4评审的技术5什么是评审技术评审文档评审管理评审流程评审产品需求审查是软件开发重要环节之一，也是测试活动之一，即静态测试——需求验证。借助需求审查保证用户需求在市场/产品需求文档及其相关文档中得到准确、完整、无歧义的反映，并使各类开发人员在需求理解上达成一致。6评审通过软件评审，可以更早地发现需求工程、软件设计等各个方面的问题，大大减少大量的后期返工，将质量成本从昂贵的后期返工转化为前期的缺陷发现。评审是对软件元素或者项目状态的一种评估手段，以确定其是否与计划的结果保持一致，并使其得到改进。检验工作产品是否正确地满足了以往工作产品中建立的规范。7为什么需要评审从成本上来衡量缺陷发现得越晚纠正费用越高，而软件评审的重要目的就是通过软件评审尽早的产品中的缺陷，减少大量的后期返工。

8为什么需要评审从技术上来衡量前一阶段的错误自然会导致后一阶段的工作结果中有相应的错误，而且错误会逐渐累积，越来越多。9评审分类管理评审技术评审文档评审流程评审管理评审和技术评审属于质量保证和管理范畴，不属于软件测试范畴，我们讨论的软件评审仅限于技术评审和文档评审。10技术评审

评审的目的评审的内容

评审检查单其他必需文档技术评审《技术评审报告》会议的基本信息存在的问题和建议措施评审结论和意见问题跟踪表技术评审问答记录

输入输出11文档评审正确性完整性一致性有效性易测性模块化-系统和文档描述必须深入到模块。清晰性可行性可靠性可追溯性12评审方法最不正式的最正式的临时评审轮查互为复审走查会议审查Randomreview,Pass-round,Peer-to-Peerreview

,

Walkthrough,Inspection13正式评审与非正式评审结合正式评审：开评审会，组织多个专家，将需求涉及到的人员集合在一起，并定义好参与评审人员的角色和职责非正式评审：不需要将人员集合在一起，通过电子邮件、网络聊天等多种形式有时，非正式的评审比正式的评审效率更高，更容易发现问题14评审会议流程达到评审会议标准?Yes计划全面纵览准备修正问题跟踪问题记录会议纪要满足执行要求?YesNo总结报告评审结果分析流程改进建议15评审会议角色主持人作者记录员列席人员内审员技术专业人员16评审的技术检查表（checklist）是一种常用的的质量保证手段，也是正式技术评审的必要工具，评审过程往往由检查表驱动。一份精心设计的检查表，对于提高评审效率、改进评审质量具有很大帮助。可靠性。人们借助检查表以确认被检查对象的所有质量特征均得到满足，避免遗漏任何项目。效率。检查表归纳了所有检查要点，比起冗长的文档，使用检查表具有更高的工作效率。检查表(缺陷检查表)、场景分析、头脑风暴和工具等17内容2.1软的方件评审法与技术2.2产品需求评审2.3设计审查182.2产品需求评审2.2.1需求评审的重要性2.2.2如何理解需求2.2.3需求评审的标准2.2.4如何对需求进行评审19问题为什么在测试计划中谈需求评审？20需求缺陷为什么软件需求定义中存在很多缺陷最多？软件缺陷并不只是在编程阶段才产生，需求和设计阶段同样会产生缺陷。21需求评审重要性的直观描述22需求评审期望达到的目标发现需求定义中问题，发现缺陷，降低成本，减少后续变更，降低风险。更好的理解产品的功能性需求和非功能性需求明确了测试的目标和范围，使得后续的需求变更在有效的控制范围内通过和不同人员的沟通对产品的认识达到了共识保证了软件需求的可测试性23正确理解需求的过程举例说明24测试需求在制定测试计划之前，必须清楚测试需求明确测试需求的优先级测试需求分解得越细，对测试用例的设计质量越有帮助详细的测试需求还是衡量测试覆盖率的重要依据测试需求是规划具体项目资源和时间的基础。测试目标取决于软件质量需求，而这种需求分为功能性需求和非功能性需求，功能性的需求相对容易确定，非功能性的测试需求难以确定。25功能性测试需求程序安装、启动正常，有相应的提示框、错误提示各项功能符合设计要求，正常运行并输出正确结果功能逻辑合理，并能处理各种异常操作能接受正确的数据输入，输出结果准确，格式清晰系统的各种状态按照业务流程而变化并保持稳定支持各种应用环境，能配合硬件设备…

…功能性测试需求主要是根据产品规格说明书来检验被测试的系统是否满足软件各方面的功能的使用要求，包括用户界面的友好性。26用户界面及其显示要求

通用框架、浮动窗口和文字等整体布局合理文字显示正常，且内容格式正确、美观。色彩协调，风格前后一致，文字标记和超链接可以打开和跳转成功

……用户界面是和用户进行交互的窗口，其友好程度直接影响用户对于软件产品或软件服务的满意度。良好的用户体验，简单、方便和明了，让用户舒畅、愉悦KISS–Keepitsimple,stupidDon’tmakemethink27非功能性需求客户端软件，如字处理软件、媒体播放软件等占用较少资源，在容错性、兼容性等方面要求高。Web应用系统对性能、安全性等有很高要求客户端/服务器应用系统。大型复杂企业级系统。非功能性质量需求，包括系统性能、安全性、兼容性、扩充性，其测试需求会因不同的项目类型差异较大。28软件即服务SaaS

软件运行的服务质量（QoS,Qualityofservice）

QoS要求是指定某些系统特性的技术规范。SaaS(SoftwareasaService)是软件服务模式，厂商将应用软件统一部署在自己的服务器上，客户可以根据自己实际需求定购所需的应用软件服务。On-DemandServiceOn-PremiseService29SaaS的非功能性需求性能要求，系统响应能力。可用性,7x24不间断服务可伸缩性，系统容量扩充能力，使系统可以支持来自扩大用户群体的额外负载。安全性要求，确定可能潜在的安全威胁并找到处理策略。可维护性要求，对部署系统进行维护的难易程度，可维护性与可用性之间关系密切30需求评审重要性表现方面发现需求定义中的问题，尽早发现缺陷，降低劣质成本。保证软件需求的可测试性。与市场、产品、开发等相关人员在需求理解上认识一致，以免后期的争吵。更好的理解产品的功能性与非功能性需求，为制定测试计划打下基础。确定测试目标与范围。虽然此后需求会发生变更，但能得到有效控制，降低测试风险。31需求评审的标准正确性完备性易理解性一致性可行性易修改性易测试性易追溯性32软件系统需求质量标准正确性可行性规范性可验证性优先级合理性完备性无二义性兼容性一致性易追溯性33软件文档质量标准规范性易理解性一致性准确性易修改性读者34测试人员在需求评审中作用明确自己的角色和责任熟悉评审内容，为评审做好准备针对问题阐述观点，而非针对个人从客户角度想问题，多问几个为什么在会前或会后提出自己建设性的意见对发现的问题跟踪到底

针对需求文档等报告问题需求评审归为静态测试范畴，包含了文档评审和技术评审双重内容，通常通过正式的评审会议来进行。而测试人员主要起着评审员的作用，检查需求定义是否合理和清楚。35如何做好需求评审（1）分层次评审（2）分类评审（3）正式评审与非正式评审结合（4）分阶段评审（5）精心挑选评审员（6）对评审员进行培训（7）充分利用需求评审检查单（8）建立标准的评审流程（9）做好评审后的跟踪工作需求评审36⑴分层次评审指导思想：先总体，后细节高层次评审低层次评审37⑵分类评审按照业务需求、功能需求、非功能需求、用户操作性需求等进行分类评审目标性需求：定义了整个系统需要达到的目标（高层管理人员关注）功能性需求：定义了整个系统必须完成的任务（中层管理人员关注）操作性需求：定义了完成每个任务的具体的人机交互（具体操作人员关注）38⑶正式评审与非正式评审结合正式评审：开评审会，组织多个专家，将需求涉及到的人员集合在一起，并定义好参与评审人员的角色和职责非正式评审：不需要将人员集合在一起，通过电子邮件、网络聊天等多种形式有时，非正式的评审比正式的评审效率更高，更容易发现问题39⑷分阶段评审在需求形成的过程中进行分阶段的评审，而不是在需求最终形成后再进行评审将原本需要进行的大规模评审拆分成各个小规模的评审降低了需求返工的风险，提高了评审的质量40⑸精心挑选评审员需求评审可能涉及的人员：需方：高层管理人员、中层管理人员、具体操作人员、IT主管、采购主管供方：市场人员、需求分析人员、设计人员、测试人员、质量保证人员、实施人员、项目经理以及第三方的领域专家等等41这些人员所处的立场不同，对同一个问题的看法是不相同的，不同的观点可能形成互补的关系要保证使不同类型的人员的都要参与进来，否则很可能会漏掉了很重要的需求不同类型的人员中要选择那些真正和系统相关的，对系统有足够了解的人员参与进来，否则使评审的效率降低⑸精心挑选评审员42⑹对评审员进行培训

很多情况下，评审员是领域专家而不是进行评审活动的专家，没有掌握进行评审的方法、技巧、过程等，需要培训对于主持评审的管理者也需要进行培训，使参与评审的人员能够围绕评审的目标来进行，能控制评审节奏，提高评审效率43⑺充分利用需求评审检查单

需求检查单：需求形式检查单和需求内容检查单。需求形式检查：由QA人员负责，主要是针对需求文挡的格式是否符合质量标准需求内容检查：是由评审员负责，主要是检查需求内容是否达到了系统目标、是否有遗漏、是否有错误等等检查单可以帮助评审员系统全面地发现需求中的问题检查单随着工程经验的积累逐渐丰富和优化44⑻建立标准的评审流程

需求评审会需要建立正规的需求评审流程，按照流程中定义的活动进行规范的评审过程45⑼做好评审后的跟踪工作

根据评审人员提出的问题进行评价：确定哪些问题必须纠正（给出理由与证据）：书面的需求变更申请，进入需求变更的管理流程，并确保变更的执行。在变更完成后，要进行复审。切忌评审完毕后，没有对问题进行跟踪，而无法保证评审结果的落实，使前期的评审努力付之东流46内容2.1软件评审的方法与技术2.2产品需求评审2.3设计审查472.3设计评审2.3.1软件设计评审标准2.3.2系统架构设计的评审2.3.3组件设计的审查2.3.4界面设计的评审48设计审查系统架构的审查设计规格说明书的审查系统部署设计的审查多层次审查:high-levellow-level

成功的产品开发和演化依赖于体系结构恰当的选择。软件设计一般可以分为体系结构设计和详细设计。测试人员参与设计评审保证需求能在设计中得到准确和完整的表示，也就是保证产品规格说明书的质量。49系统设计的评审标准设计技术评审标准。设计结果稳定设计清晰设计合理结构简单低耦合、高内聚

结构和数据的一致性

可测试性和可追溯性依赖性不完整、易变动或潜在的需求项50系统模块结构的复杂性描述51衡量系统复杂性的简单标准指标深度宽度扇入值扇出值良好的软件结构：顶层的扇出大，中间的扇出较小，底层的扇入较大52系统设计的评审标准非功能性质量特性的设计评审要求。安全性性能稳定性扩展性可靠性53系统架构设计的审查采用分层评审和整体评审相结合，经过整体评审到分层评审、再从分层评审到整体评审的过程，这样既能确保评审的深度，又能确保评审的一致性

整个系统不应该存在单一故障点系统是否建立了故障转移机制是否建立了良好的负载平衡机制关键业务或关键任务？系统架构设计的基本要求就是保证系统具有高性能、高可靠性、高安全性、高扩展性和可管理性

。系统架构设计评审就是保证这些特性在设计中得到充分考虑。54组件设计的审查