软件测试方法与技术实践指南-Java篇(第3版)(第4,5章)课件.ppt

第5章 软件测试计划的制定 为何要制定测试计划 可以让项目有条理有计划地进行 可以提前预知项目过程中可能出现的问题 明确测试目标、测试范围和测试重点 明确测试任务和测试方法，保证测试实施过程的顺畅沟通 说明： 测试计划是每一个测试项目组长一定要会写的，并且能准确执行的。 好的测试计划能让测试有条不紊的进行，做到事半功倍。 重点 熟记理解 第二篇　基于Java EE产品线的项目实践 4 第4章：项目初期各阶段的主要工作 第5章：软件测试计划的制定 第6章：软件测试用例的编写 第7章：软件项目各部门相互协作 第8章：执行测试案例并报告缺陷 第9章：产品功能完善与修复缺陷阶段 第10章：测试工程师在产品发布前后的工作 软件生产的几个主要阶段（第4至10章从测试角度逐步展开） 软件生产流程：(本篇重点) 该图能清晰看出软件生产各环节开发与测试的主要工作 学生需要清晰的知道每个英文代表的环节与意义 本书所有章节,以及软件工程师的工作都是围绕本图展开 第4章 项目初期各阶段的主要工作 项目立项与拟定产品的发展方向阶段 产品规格说明书制定阶段 产品技术文档设计阶段 第4章 项目初期各阶段的主要工作 项目立项与拟定产品的发展方向阶段 产品需求文档的形成及其实例 产品需求文档PRD PRD如何形成 PRD的主要内容与格式 PRD实例介绍 产品需求形成阶段测试工程师需要做什么 阅读PRD中的详细功能需求 给PM反馈信息并协助PM去修改 跟踪提交的问题解决状态 IEEE软件工程标准词汇表定义需求为： 用户解决问题或达到目标所需的条件或能力。 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。 一种反映上面(1)或(2)所描述的条件或能力的文档说明。 Merlin Dorfman 和 Richard H. Thayer 提出了一个包容且更为精练的定义： 用户解决某一问题或达到某一目标所需的软件功能。 系统或系统构件为了满足合同、规约、标准或其他正式实行的文档而必须满足或具备的软件功能。 软件的需求-需求的定义 需求分析的任务：确定用户需求，准确地回答 “系统必须做什么？” 的问题，获得需求规格说明书。 软件需求-需求分析的任务 业务需求（business requirement） 客户对系统的高层次的目标要求。 用户需求（user requirement） 用户使用产品必须要完成的任务 功能需求（functional requirement） 开发人员必须实现的软件功能，使得用户能完成他们的任务，满足业务需求 非功能需求（non-functional requirement ） 对系统提供的服务或者功能提出的约束，包括时间、开发过程、软件质量、标准等约束 软件需求-需求类型 需求获取的内容 系统分析人员通过与用户的交流、对现有系统的观察及对任务进行分析，确定： 系统或产品范围的限制性描述 与系统或产品有关的人员及特征列表 系统的技术环境的描述 系统功能的列表及应用于每个需求的领域限制 一组描述不同运行条件下系统或产品使用状况的应用场景 为更好地定义需求而开发的任意原型。 需求获取方法与策略 建立顺畅的通信途径 访谈与调查 观察用户操作流程 组成联合小组 第4章 项目初期各阶段的主要工作 产品规格说明书制定阶段 产品规格说明书的形成及其实例 产品规格说明书SPEC SPEC如何形成 SPEC的主要内容与格式 SPEC实例介绍 产品规格说明书阶段测试工程师需要做什么 阅读并查看SPEC中的功能是否符合PRD要求 和EM保持良好的沟通，并且一起阅读SPEC的详细内容 根据SPEC设计Test Case 跟踪SPEC中提出的问题解决状态 第4章 项目初期各阶段的主要工作 产品技术文档设计阶段 编写技术设计文档 什么是产品的技术文档 技术文档中包括哪些内容 技术文档实例介绍 技术设计文档阶段测试工程师需要做什么 为测试环境做准备 了解产品的逻辑流程，数据库结构，以及各个模块的具体功能 了解产品设计中的一些技术问题 了解产品的性能，为性能测试作准备 参与需求的分析及评审，从测试角度分析需求的可测试性，具体为： 阅读PRD中的详细功能需求，对需求文档进行检查 跟踪提交的问题解决状态 测试在需求阶段的工作 什么是评审 软件评审是对软件元素或者项目状态的一种评估手段，以确定其是否与计划的结果保持一致，并使其得到改进。 产品需求审查是软件开发重要环节之一，也是测试活动之一，即静态测试——需求验证。借助需求审查保证用户需求在市场/产品需求文档及其相关文档中得到准确、完整、无歧义的反映，并使各类开发人员在需求理解上达成一致。 1.软件缺陷并不只是在编程阶段才产生，