第2次大课 软件测试策略及过程

Software,Testing,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,单击此处编辑母版标题样式,软件工程系,软件测试基础,Software Testing Technology,第二章 软件测试策略与过程,第2章 软件测试策略与过程,2.1,软件测试的复杂性分析,2.2,软件测试方法与策略,2.3 测试计划,2.4,单元测试,2.5,集成测试,2.6,确认测试,2.7,系统测试,2.8,验收测试,2.9,测试后的调试,2.10,面向对象的软件测试,2,本章教学目标,理解软件测试的复杂性,理解软件测试的方法与策略,测试计划的制定,明确单元测试的主要任务和过程,明确集成测试的方法和确认测试的准则,明确系统测试的八个领域测试要点,明确验收测试的主要内容和相关配置,3,2.1 软件测试的复杂性分析,1、无法对程序进行完全测试,（1）测试所需要的输入量太大,（2）测试的输出结果太多,（3）软件实现的途径太多,（4）软件规格说明没有一个客观标准,2、测试无法显示潜在的软件缺陷和故障,通过软件测试只能报告软件已被发现的缺陷和故障，无法报告隐藏的软件故障。,3、存在的故障现象与发现的故障数量成正比,结论：应当对故障集中的程序段进行重点测试,Return,4,软件测试的复杂性分析,（续）,4、不能修复所有的软件故障,原因：没有足够的进行修复；修复的风险较大； 不值得修复；可不算做故障的一些缺陷；“杀虫剂现象”。,结论：关键是要进行正确的判断、合理的取舍，根据风险分析决定哪些故障必须修复，哪些故障可以不修复。,5、软件测试的代价,工作原则：就是如何将无边无际的可能性减小到一个可以控制的范围，以及如何针对软件风险做出恰当选择，去粗存精，找到最佳的测试量，使得测试工作量不多也不少，既能达到测试的目的，又能较为经济。,5,软件测试的复杂性分析,（续）,软件缺陷故障数量,测试工作量,测试中,测试后,测试费用,遗漏缺陷数目,优化测试量,图2-1 测试工作量和软件缺陷数量之间的关系,6,2.2 软件测试方法与策略,2.2.1,静态测试与动态测试,2.2.2,黑盒测试与白盒测试,2.2.3,软件测试过程,Return,7,软件测试策略,什么是软件测试策略？,是为软件工程过程定义的一个软件测试的模板，也就是把特定的测试用例方法放置进去的一系列步骤。,软件测试策略包含的特征：,（1）测试从模块层开始，然后扩大延伸到整个基于计算机的系统集合中。,（2）不同的测试技术适用于不同的时间点。,（3）测试是由软件的开发人员和（对于大型系统而言）独立的测试组来管理的。,（4）测试和调试是不同的活动，但是调试必须能够适应任何的测试策略。,8,软件测试充分性准则,对任何软件都存在有限的充分测试集合。,如果一个软件系统在一个测试数据集合上的测试是充分的，那么再多测试一些数据也应该是充分的。这一特性称为,单调性,。,即使对软件所有成分都进行了充分的测试，也并不表明整个软件的测试已经充分了。这一特性称为,非复合性,。,即使对软件系统整体的测试是充分的，也并不意味软件系统中各个成分都已经充分地得到了测试。这个特性称为,非分解性,。,软件测试的充分性应该与软件的需求和软件的实现都相关。,软件越复杂，需要的测试数据就越多。这一特性称为,复杂性,。,测试得越多，进一步测试所能得到的充分性增长就越少。这一特性称为,回报递减率,。,9,2.3 测试计划,2,.3.1 概述,2.3.2 测试计划过程,2.3.3测试目标,2.3.4 测试策略,2.3.5 制定有效的测试计划,10,测试计划概述,软件测试计划的作用,制定测试计划的原则,如何制订软件测试计划,制定测试计划时面对的问题,衡量一份好的测试计划书的标准,制定测试计划,11,什么是测试计划？,测试计划就是描述所有要完成的测试工作，包括被测试项目的背景、目标、范围、方式、资源、进度安排、测试组织，以及与测试有关的风险等方面。,12,什么是测试计划？,测试,计划,是项目计划的组成部分,测试,计划,依赖于软件组织过程、质量文化和方针。,测试,计划,是指导今后一系列测试活动的文件,测试计划,更是一个过程，随着项目的进展不断更新,子曰：凡事预则立，不预则废，预即是计划。要想成功完成软件测试这项工作，必须首先建立测试计划。,13,测试计划的作用,1使软件测试工作进行更顺利,2促进项目参加人员彼此的沟通,3及早发现和修正软件规格说明书的问题,4 使软件测试工作更易于管理,14,会遇到哪些问题？,制定测试计划时，测试人员可能面对以下问题，必须认真对待，并妥善予以处理。,1与开发者意见不一致,2缺乏测试工具,3培训不够,4管理部门缺乏对测试工作的理解和支持,5缺乏用户的参与,6测试时间不足,7过分依赖测试人员,8测试人员处于进退两难的状态,9不得不说“不”,15,制定测试计划的原则,制定测试计划是软件测试中最有挑战性的一个工作。以下原则将有助于制定测试计划工作。,1制定测试计划应尽早开始,2保持测试计划的灵活性,3保持测试计划简洁和易读,4尽量争取多渠道评审测试计划,5计算测试计划的投入,16,如何制订软件测试计划,1认真做好测试资料的搜集整理工作,2明确测试的目标，增强测试计划的实用性,3坚持“5W”规则，明确内容与过程,4采用评审和更新机制，保证测试计划满足实际需求,17,衡量一份好的测试计划书的标准,一份好的测试计划书应具备哪些特点呢？,1,它应能有效地引导整个软件测试工作正常运行，并配合编程部门，保证软件质量，按时将产品推出。,2,它所提供的方法应能使测试高效地进行，即能在较短的时间内找出尽可能多的软件缺陷。,3,它提供了明确的测试目标、测试的策略、具体步骤及测试标准。,4,它既强调测试重点，也重视测试的基本覆盖率。,5,它所制定的测试方案尽可能充分利用了公司现有的、可以提供给测试部门的人力,/,物力资源，而且是可行的。,6,它所列举的所有数据都必须是准确的,比如外部软件,/,硬件的兼容性所要求的数据、输入,/,输出数据等。,7,它对测试工作的安排有一定的灵活性，可以应付一些突然的变化情况，如当时间安排或产品出现的一些变化的时候。,18,测试计划的内容,确认测试目标、范围和需求,识别测试风险，制订相应的测试策略,对测试任务和工作量进行估算,确定所需的时间和资源,进度安排和资源分派，包括团队角色、责任和培训,测试阶段划分，包括阶段性任务和成果,跟踪和控制机制,19,完整的测试计划书,目标和范围：产品特性、质量目标、范围和限制。,项目估算：工作量、资源的估算,风险计划：风险分析、识别与回避/缓解对策,进度安排：分解项目工作结构，指定时间/资源表,资源配置：人员、硬件和软件等分配。,跟踪和控制机制：质量保证、变更控制等,20,测试计划标准格式,-1,16 components of Test Plan (IEEE,1983),Test plan identifier （,测试计划标识),Instruction (,引言）,Test Items （,定义或主题词),Features to be tested （,需要被测试的功能),Features not to be tested (,无需被测试的功能),Approach (,方法和途径）,Items pass/ fail criteria （,测试通过、失败的标准),Suspension criteria and resumption requirements （,延迟的标准和再恢复的要求),Test deliverables (,测试交付的内容),Testing Tasks (,测试任务,21,测试计划标准格式, 2,16 components of Test Plan (IEEE,1983),Environmental needs （,必备的环境),Responsibilities (,职责),Staffing and training needs (,人员和必需的培训),Schedule (,时间进度表),Risk and contingencies (,风险和相关费用）,Approvals （,批准),22,测试计划的过程,计划初期,计划起草,内部审查,计划讨论和修改,测试计划的多方审查,测试计划的定稿和批准,计划执行跟踪和修改,23,测试目标,在开始制定测试计划之前，需要确定测试目标,测试目标也分为整体目标和阶段性目标、特定的任务目标,24,功能测试目标,业务逻辑,基本操作,输入/输出,接口,各种使用场景,异常操作,25,性能测试目标,通过性能测试，不仅要通过压力测试发现性能瓶颈，还要获得系统的容量和系统所需要的各项具体的性能指标,26,测试策略的内涵,针对风险（工作量、时间等压力）采取对策，包括遵照的标准取舍、测试任务的优先级等。,如何更好地执行测试用例以及如何执行后续的回归测试。,选定使用测试技术和工具。,考虑影响资源分配的特殊情况。,测试策略描述当前测试项目的目标和所采用的测试方法，描述不同测试阶段的测试对象、范围和方法以及每个阶段内所要进行的测试类型，或者说是在一定的软件测试标准、测试规范的指导下，依据测试项目的特定环境约束而规定的软件测试的原则、方式、方法的集合。,27,测试策略制定的基本要素,输入,，作为制定测试策略的依据，包括限制条件和已具有的资源。,输出,，制定策略的成果，即最终对所制定策略的定义或说明。,制定策略的过程,，测试组分析需求，参与设计的讨论，要求开发、编写针对所有测试级别的测试策略，并和项目组一起复审测试策略和计划。,28,制定策略的过程,29,如何有效制定测试策略,全面细致地了解产品的项目信息,分析各个因素对产品的影响,确定测试范围、等级和测试重点,使用尽可能少的有效测试用例,发现尽可能多的缺陷,测试既不能失败、不足，也不能过度，而是寻求一个最佳平衡点,30,制定有效的测试计划,在确定测试项目的任务之前，应清楚测试的范围和目标,让所有合适的相关人员参与测试项目的计划制定，特别是在测试计划早期,对测试的各阶段所需要的时间、人力及其它资源进行预估，测试范围能分解应尽量分解，针对每个测试任务仔细分析到位，尽量做到客观、准确、留有余地。,制定测试项目的输入、输出和质量标准，并和有关方面达成一致。,建立变化处理的流程规则，识别出在整个测试阶段中哪些是内在的、不可避免的变化因素，如何进行控制。,31,IEEE软件测试计划文档模板,32,IEEE829 测试计划16大纲要,根据IEEE8291998软件测试文档编制标准的建议，测试计划包含了16个大纲要项，简要说明如下。,1测试计划标识符,一个测试计划标识符是一个由公司生成的惟一值，它用于标识测试计划的版本、等级，以及与该测试计划相关的软件版本。,33,2简要介绍,在测试计划的介绍部分主要是测试软件基本情况的介绍和测试范围的概括性描述。,34,3测试项目,测试项部分主要是纲领性描述在测试范围内对哪些具体内容进行测试，确定一个包含所有测试项在内的一览表。具体要点如下。,功能的测试,设计的测试,整体测试,35,IEEE标准中指出，可以参考下面的文档来完成测试项：,需求规格说明,用户指南,操作指南,安装指南,与测试项相关的事件报告,36,4测试对象,这一部分列出了待测的单项功能及功能组合。,5 不需要测试的功能,这一部分列出了不测试的单项功能及组合功能并说明不予测试的理由。,37,6测试方法（策略）,测试策略描述测试小组用于测试整体和每个阶段的方法。要描述如何公正、客观地开展测试，要考虑模块、功能、整体、系统、版本、压力、性能、配置和安装等各个因素的影响，要尽可能地考虑到细节，越详细越好，并制作测试记录文档的模板，为即将开始的测试做准备。测试记录具体说明如下:,公正性声明,测试用例,特殊考虑,经验判断,设想,38,7,测试项通过,/,失败的标准,测试计划中这一部分给出了“测试项”中描述的每一个测试项通过,/,失败的标准。正如每个测试用例都需要一个预期的结果一样，每个测试项同样都需要一个预期的结果。,下面是通过,/,失败的标准的一些例子：,通过测试用例所占的百分比；,缺陷的数量、严重程度和分布情况；,测试用例覆盖；,用户测试的成功结论；,文档的完整性；,性能标准。,39,8,测试中断和恢复的规定,测试计划中这一部分给出了测试中断和恢复的标准。常用的测试中断标准如下：,关键路径上的未完成任务,大量的缺陷,严重的缺陷,不完整的测试环境,资源短缺,40,9,测试完成所提交的材料,测试完成所提交的材料包含了测试工作开发设计的所有文档、工具等。例如，测试计划、测试设计规格说明、测试用例、测试日志、测试数据、自定义工具、测试缺陷报告和测试总结报告等。,41,10,测试任务,测试计划中这一部分给出了测试工作所需完成的一系列任务。在这里还列举了所有任务之间的依赖关系和可能需要的特殊技能。,42,11,测试所需的资源,测试所需的资源是实现测试策略所必须的。例如：,人员,人数、经验和专长。他们是全职、兼职、业余还是学生？,设备,计算机、测试硬件、打印机、测试工具等。,办公室和实验室空间,在哪里？空间有多大？怎样排列？,软件,字处理程序、数据库程序和自定义工具等。,其他资源,软盘、电话、参考书、培训资料等。,特殊的测试工具。,43,12,测试人员的工作职责,测试人员的工作职责是明确指出了测试任务和测试人员的工作责任。,有时测试需要定义的任务类型不容易分清，不像程序员所编写的程序那样明确。复杂的任务可能有多个执行者，或者由多人共同负责。,44,13,人员安排与培训需求,前面讨论的测试人员的工作职责是指哪类人员（管理、测试和程序员等）负责哪些任务。人员安排与培训需求是指明确测试人员具体负责软件测试的哪些部分、哪些可测试性能，以及他们需要掌握的技能等。实际责任表会更加详细，确保软件的每一部分都有人进行测试。每一个测试员都会清楚地知道自己应该负责什么，而且有足够的信息开始设计测试用例。,培训需求通常包括学习如何使用某个工具、测试方法、缺陷跟踪系统、配置管理，或者与被测试系统相关的业务基础知识。培训需求各个测试项目会各不相同，它取决于具体项目的情况。,45,测试进度是围绕着包含在项目计划中的主要事件（如文档、模块的交付日期，接口的可用性等）来构造的。,作为测试计划的一部分，完成测试进度计划安排，可以为项目管理员提供信息，以便更好地安排整个项目的进度。,进度安排会使测试过程容易管理。通常，项目管理员或者测试管理员最终负责进度安排，而测试人员参与安排自己的具体任务。,14测试进度表,46,15,风险及应急措施,软件测试人员要明确地指出计划过程中的风险，并与测试管理员和项目管理员交换意见。这些风险应该在测试计划中明确指出，在进度中予以考虑。有些风险是真正存在的，而有些最终证实是无所谓的，重要的是尽早明确指出，以免在项目晚期发现时感到惊慌。,47,一般而言，大多数测试小组都会发现自己的资源有限，不可能穷尽测试软件所有方面。如果能勾画出风险的轮廓，将有助于测试人员排定待测试项的优先顺序，并且有助于集中精力去关注那些极有可能发生失效的领域。下面是一些潜在的问题和风险的例子：,不现实的交付日期,与其他系统的接口,处理巨额现金的特征,极其复杂的软件,有过缺陷历史的模块,发生过许多或者复杂变更的模块,安全性、性能和可靠性问题,难于变更或测试的特征,风险分析是一项十分艰巨的工作，尤其是第一次尝试进行时更是如此，但是以后会好起来，而且也值得这样做。,48,16,审批,审批人应该是有权宣布已经为转入下一个阶段做好准备的某个人或某几个人。测试计划审批部分一个重要的部件是签名页。审批人除了在适当的位置签署自己的名字和日期外，还应该签署表明他们是否建议通过评审的意见。,49,试验课要求,参照测试计划模板：,测试计划（GB856788）.doc,编写测试计划报告,50,Q & A,51,