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

ANSI/IEEE把测试计划定义为： 一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。它确认了测试项。被测特征、测试任务、人员安排以及任何偶发事件的风险 测试计划的定义 第5章 软件测试计划的制定 怎样设计测试计划 产品基本情况调研 测试需求说明 计划表 测试资源配置 系统风险评估 测试的策略和记录 问题跟踪报告 测试计划的发布 如何编制测试计划 根据测试策略，选定测试计划包含的测试范围 划分测试阶段，明确测试方法，确定测试任务 评估测试工作量 确定时间并生成进度计划 评估进度计划风险 测试策略一般描述软件测试活动的一般方法和目标。其中包括要进行的测试阶段（单元测试、集成测试和系统测试）以及要执行的测试类型（功能测试、性能测试、负载测试、强度测试等）。确定测试需求：明确测试的工作范围，需要测试的对象、达到的指标等。可以来源于软件需求，个人经验，以前发生的错误等。 （一）确定软件测试策略 （二）确定测试任务 根据本阶段测试需求，细化测试任务 划分任务优先级，和主要任务关联关系 确定辅助任务清单（如培训等） 确定资源情况 形成WBS（工作任务细分）图 （三）评估测试工作量 目前没有任何一种方法能准确的评估出软件测试工作的工作量，要想更有效的做出估算，必须持之以恒的统计和分析历史数据 主要的估算方法为： 分析以前的同类项目 同行专家判断 分解细化项目 经验主意预估模型（LOC、FP等） 收集与进度相关的信息：总体工作量估算、人员数量、关键资源、项目时间安排等。 确定各阶段任务安排和资源分配，确定里程碑 依据项目总体时间安排，形成进度计划 （四）生成进度计划 风险分析是指对测试计划中所有要执行的内容进行潜在的风险分析并给出规避措施。存在的风险有： 用户的需求发生重大变更或测试计划和设计大幅度地调整等因素所导致测试时间延长、经费增加 设计，编码，相关文档质量不规范，软件质量标准不清晰 测试初始阶段的软，硬件设备不到位 测试人员的技术不到位 特定的测试环境不能到位 主要的测试人员因故缺席 测试数据准备不充分 质量需求或产品的特性理解不准确，造成测试范围分析的误差 测试用例设计不到位，执行不完全 （五）评估风险 第5章 软件测试计划的制定 测试计划设计实例 测试设计的内容和书写格式 以“大学学籍管理系统”为实例进行介绍 第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