软件测试方法和技术实践指南-Java篇[第3版][第4-5章].pptVIP

第二篇　基于Java EE产品线的项目实践;软件生产的几个主要阶段（第4至10章从测试角度逐步展开）;第4章 项目初期各阶段的主要工作;第4章 项目初期各阶段的主要工作;IEEE软件工程标准词汇表定义需求为： 用户解决问题或达到目标所需的条件或能力。 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。 一种反映上面(1)或(2)所描述的条件或能力的文档说明。 Merlin Dorfman 和 Richard H. Thayer 提出了一个包容且更为精练的定义： 用户解决某一问题或达到某一目标所需的软件功能。 系统或系统构件为了满足合同、规约、标准或其他正式实行的文档而必须满足或具备的软件功能。 ;需求分析的任务：确定用户需求，准确地回答 “系统必须做什么？” 的问题，获得需求规格说明书。; 业务需求（business requirement） 客户对系统的高层次的目标要求。 用户需求（user requirement） 用户使用产品必须要完成的任务 功能需求（functional requirement） 开发人员必须实现的软件功能，使得用户能完成他们的任务，满足业务需求 非功能需求（non-functional requirement ） 对系统提供的服务或者功能提出的约束，包括时间、开发过程、软件质量、标准等约束 ;需求获取的内容 ;需求获取方法与策略 ;第4章 项目初期各阶段的主要工作;第4章 项目初期各阶段的主要工作; 参与需求的分析及评审，从测试角度分析需求的可测试性，具体为： 阅读PRD中的详细功能需求，对需求文档进行检查 跟踪提交的问题解决状态 ;什么是评审;1.软件缺陷并不只是在编程阶段才产生，需求和设计阶段同样会产生缺陷 2.软件测试对需求的依赖;需求评审的重要性： 1. 软件需求是软件开发最重要的一个输入 ，好的开始是成功的一半! 所以，需求的质量很大程度上决定了项目质量或产品质量。 2. 需求风险常常是软件开发过程中最大的一个风险 ，要降低需求阶段带来的风险，就要把需求评审做好。 3. 需求评审做不好的后果： 　　需求变更 　　需求不明确 　　需求不可测 　　需求不可实现 　　导致后续工作难于开展或经常出现变更。;需求评审重要性的直观描述;评审会议角色;测??人员在需求评审中作用;相互评审、交叉评审：甲和乙在一个项目组，处在一个领域，但工作内容不同，甲的工作成果交给乙审查，乙的工作成果交给甲审查。相互评审是最不正式的一种评审形式，但应用方便、有效。 轮查：又称分配审查方法，是一种异步评审方式。作者将需要评审的内容发送给各位评审员，并收集他们的反馈意见 走查：作者将测试需求在现场向一组同事介绍，以收集大家的意见。希望参与评审的其他同事可以发现其中的错误，并能进行现场讨论。这种形式介于正式和非正式之间。 小组评审：通过正式的小组会议完成评审工作，是有计划的和结构化的评审方式。评审定义了评审会议中的各种角色和相应的责任，所有参与者在评审会议的前几天就拿到了评审材料，并对该材料进行了独立研究。 审查：审查和小组评审很相似，但更为严格，是最系统化、最严密的评审形式，包含了制定计划、准备和组织会议、跟踪和分析审查结果等。 ;软件需求评审的输入;产品需求的正确性 产品需求的实践性 产品需求的完整性 产品需求的可行性和成本预算 产品需求的质量属性 产品需求的可实验性 ;需求规格说明的正确性体现在： 是否有需求与其他需求相互冲突或者重复？ 是否清晰、简洁、无二义地表达了每个需求? 是否每个需求都通过了演示、测试、评审，分析是否得到了验证? 是否每个需求都没有内容和语法上的错误? 在现有的资源内, 是否能实现所有的需求? 是否每个需求都在项目的范围内? 每一条特定的错误信息，是否都是唯一的和具有含义的? ;实践性是指需求本身是否来源于目前企业的相关业务规则和文件制度,而非源于分析师们经验主义的臆测 。 有经验的系统分析师通常会迷信自己的经验,把从前的经验嫁接到目前的企业需求分析中。也许由于行业性质相同,但如果不经过当前的实践调研则给出需求，仍然会无法体现出企业自身的特征。因而不能为企业带来真正的价值,也会造成与用户需求的鸿沟。 ;编写的所有需求，其详细程度是否一致和合适? 需求是否能为设计提供足够的基础? 所有对其他需求的内部引用是否正确? 是否包含了每个需求的实现优先级? 是否定义了功能说明的内在算法? 是否包含了所有已知的客户需求或系统需求? 是否遗漏了必要的信息?如果有遗漏的话,把他们标记为待确定的问题(TBD) ? 是否对所有预期的错误条件所产生的系统行为都编制了文档? ;需求方案的可行性和成本预算评审的目的，是从需求的多项方案中选择最优化的或者是