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

第二篇 基于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.软件缺陷并不只是在编程阶段才产生，需求和设计阶段同样会产生缺陷 2.软件测试对需求的依赖,为什么需要需求评审,在制定测试计划之前，必须清楚测试需求 明确测试需求的优先级 测试需求分解得越细，对测试用例的设计质量越有帮助 详细的测试需求还是衡量测试覆盖率的重要依据 测试需求是规划具体项目资源和时间的基础。,需求评审的重要性： 1. 软件需求是软件开发最重要的一个输入 ，好的开始是成功的一半! 所以，需求的质量很大程度上决定了项目质量或产品质量。 2. 需求风险常常是软件开发过程中最大的一个风险 ，要降低需求阶段带来的风险，就要把需求评审做好。 3. 需求评审做不好的后果： 需求变更 需求不明确 需求不可测 需求不可实现 导致后续工作难于开展或经常出现变更。,需求评审的重要性,需求评审重要性的直观描述,评审会议角色,测试人员在需求评审中作用,明确自己的角色和责任 熟悉评审内容，为评审做好准备 针对问题阐述观点，而非针对个人 从客户角度想问题，多问几个为什么 在会前或会后提出自己建设性的意见 对发现的问题跟踪到底 针对需求文档等报告问题,需求评审归为静态测试范畴，包含了文档评审和技术评审双重内容，通常通过正式的评审会议来进行。而测试人员主要起着评审员的作用，检查需求定义是否合理和清楚。,相互评审、交叉评审：甲和乙在一个项目组，处在一个领域，但工作内容不同，甲的工作成果交给乙审查，乙的工作成果交给甲审查。相互评审是最不正式的一种评审形式，但应用方便、有效。 轮查：又称分配审查方法，是一种异步评审方式。作者将需要评审的内容发送给各位评审员，并收集他们的反馈意见 走查：作者将测试需求在现场向一组同事介绍，以收集大家的意见。希望参与评审的其他同事可以发现其中的错误，并能进行现场讨论。这种形式介于正式和非正式之间。 小组评审：通过正式的小组会议完成评审工作，是有计划的和结构化的评审方式。评审定义了评审会议中的各种角色和相应的责任，所有参与者在评审会议的前几天就拿到了评审材料，并对该材料进行了独立研究。 审查：审查和小组评审很相似，但更为严格，是最系统化、最严密的评审形式，包含了制定计划、准备和组织会议、跟踪和分析审查结果等。,评审的形式,软件需求评审的输入,1、软件需求规格说明书； 2、项目工作任务书； 3、软件需求规格说明书的检查列表（Checklist）；,检查表（checklist）是一种常用的的质量保证手段，也是正式技术评审的必要工具，评审过程往往由检查表驱动。一份精心设计的检查表，对于提高评审效率、改进评审质量具有很大帮助。 可靠性。人们借助检查表以确认被检查对象的所有质量特征均得到满足，避免遗漏任何项目。 效率。检查表归纳了所有检查要点，比起冗长的文档，使用检查表具有更高的工作效率。,产品需求的正确性 产品需求的实践性 产品需求的完整性 产品需求的可行性和成本预算 产品需求的质量属性 产品需求的可实验性,需求评审的内容,需求规格说明的正确性体现在： 是否有需求与其他需求相互冲突或者重复？ 是否清晰、简洁、无二义地表达了每个需求? 是否每个需求都通过了演示、测试、评审，分析是否得到了验证? 是否每个需求都没有内容和语法上的错误? 在现有的资源内, 是否能实现所有的需求? 是否每个需求都在项目的范围内? 每一条特定的错误信息，是否都是唯一的和具有含义的?,需求规格说明的正确性评审,实践性是指需求本身是否来源于目前企业的相关业务规则和文件制度,而非源于分析师们经验主义的臆测 。 有经验的系统分析师通常会迷信自己的经验,把从前的经验嫁接到目前的企业需求分析中。也许由于行业性质相同,但如果不经过当前的实践调研则给出需求，仍然会无法体现出企业自身的特征。因而不能为企业带来真正的价值,也会造成与用户需求的鸿沟。,需求规格说明的实践性评审,编写的所有需求，其详细程度是否一致和合适? 需求是否能为设计提供足够的基础? 所有对其他需求的内部引用是否正确? 是否包含了每个需求的实现优先级? 是否定义了功能说明的内在算法? 是否包含了所有已知的客户需求或系统需求? 是否遗漏了必要的信息?如果有遗漏的话,把他们标记为待确定的问题(TBD) ? 是否对所有预期的错误条件所产生的系统行为都编制了文档?,需求规格说明的完整性评审,需求方案的可行性和成本预算评审的目的，是从需求的多项方案中选择最优化的或者是性价比最高的方案。一般而言,需求说明书可以给出同一个问题的几种方案，并给出各自的优缺点和成本差异,经过比较由决策者作出最终选择。 如果可行性高,则还要考虑它需要哪些资源和预算。我们需要确定技术是否确实满足业务需求,同时, 也要考虑整个产品成本,包括开发人员、服务器、许可和升级费用,还需要考虑初始硬件、软件和支持、基础结构和培训的费用。,需求方案的可行性和成本预算评审,我们需要评审需求规格说明是否合理地确定了所有的性能目标，是否合理地确定了安全性方面要考虑到的问题。 用户通常难以忍受运行或响应速度过慢的系统。 系统的安全性也是一个很重要的指标,尤其是作为企业级的系统,它的安全考量完全继承于组织对安全的基本诉求 。,需求的质量属性评审,是否对每个需求都设置了维一性标志并且可以正确地识别它？是否每个功能需求都可以跟踪到高层需求 需求必须可以测试,每个需求在特定的输入条件下应当能给出已知的输出结果。 同时,需求应当层次分明,需要把单个需求下面的相关需求综合在一起形成一组需求功能。 需求的可实施性除了可跟踪性还包括可测试性。,需求的可实施性评审,软件需求评审输出,根据评审专家意见修改后的软件需求规格说明书 软件需求规格说明书评审表格（评审记录表单）,第5章 软件测试计划的制定,为何要制定测试计划 怎样设计测试计划 测试计划设计实例 测试计划修改与维护,第5章 软件测试计划的制定,为何要制定测试计划 可以让项目有条理有计划地进行 可以提前预知项目过程中可能出现的问题 明确测试目标、测试范围和测试重点 明确测试任务和测试方法，保证测试实施过程的顺畅沟通,说明： 测试计划是每一个测试项目组长一定要会写的，并且能准确执行的。 好的测试计划能让测试有条不紊的进行，做到事半功倍。,ANSI/IEEE把测试计划定义为： 一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。它确认了测试项。被测特征、测试任务、人员安排以及任何偶发事件的风险,测试计划的定义,ANSI/IEEE把测试计划定义为： 一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。它确认了测试项。被测特征、测试任务、人员安排以及任何偶发事件的风险,测试计划的定义,第5章 软件测试计划的制定,怎样设计测试计划 产品基本情况调研 测试需求说明 计划表 测试资源配置 系统风险评估 测试的策略和记录 问题跟踪报告 测试计划的发布,如何编制测试计划,根据测试策略，选定测试计划包含的测试范围 划分测试阶段，明确测试方法，确定测试任务 评估测试工作量 确定时间并生成进度计划 评估进度计划风险,测试策略一般描述软件测试活动的一般方法和目标。其中包括要进行的测试阶段（单元测试、集成测试和系统测试）以及要执行的测试类型（功能测试、性能测试、负载测试、强度测试等）。 确定测试需求：明确测试的工作范围，需要测试的对象、达到的指标等。可以来源于软件需求，个人经验，以前发生的错误等。,（一）确定软件测试策略,（二）确定测试任务,根据本阶段测试需求，细化测试任务 划分任务优先级，和主要任务关联关系 确定辅助任务清单（如培训等） 确定资源情况 形成WBS（工作任务细分）图,（三）评估测试工作量,目前没有任何一种方法能准确的评估出软件测试工作的工作量，要想更有效的做出估算，必须持之以恒的统计和分析历史数据 主要的估算方法为： 分析以前的同类项目 同行专家判断 分解细化项目 经验主意预估模型（LOC、FP等）,收集与进度相关的信息：总体工作量估算、人员数量、关键资源、项目时间安排等。 确定各阶段任务安排和资源分配，确定里程碑 依据项目总体时间安排，形成进度计划,（四）生成进度计划,风险分析是指对测试计划中所有要执行的内容进行潜在的风险分析并给出规避措施。 存在的风险有： 用户的需求发生重大变更或测试计划和设计大幅度地调整等因素所导致测试时间延长、经费增加 设计，编码，相关文档质量不规范，软件质量标准不清晰 测试初始阶段的软，硬件设备不到位 测试人员的技术不到位 特定的测试环境不能到位 主要的测试人员因故缺席 测试数据准备不充分 质量需求或产品的特性理解不准确，造成测试范围分析的误差 测试用例设计不到位，执行不完全,（五）评估风险,第5章 软件测试计划的制定,测试计划设计实例 测试设计的内容和书写格式 以“大学学籍管理系统”为实例进行介绍,第5章 软件测试计划的制定,测试计划修改与维护 测试计划为何需要修改 修改测试计划时有哪些规范 多人同时修改时如何管理,