1、单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,2020/1/27,第六章 测试策略,#,第四章 测试过程,2,本章要点,软件开发测试过程,单元测试,集成测试,系统测试,3,4.1,测试层次传统观点,测试层次与传统开发,V,型瀑布模型的对应,自顶向下,功能分解,4,ATM,系统,终端,I/O,管理会话,引导事务,卡输入,PIN,输入,选择事务,瀑布模型应用示例:,ATM,系统的部分功能分解,概要设计的最终结果是将系统的功能分解为功能组件的树型结构,瀑布模型与通过功能分解进行的自顶向下开发和设计密切相关;传统集成测试的目标是根据功能分解树集成以前测过的单元。
2、5,产品开发测试基本过程,6,常见的软件开发过程,7,需求分析阶段,软件需求的检视、评审,系统测试计划、方案设计,系统测试计划、方案的检视和评审,软件系统测试用例设计,软件系统测试用例的检视和评审,8,SRS,的定义,是对在特定环境下要完成一定功能的软件产品、程序或一组程序的说明。,应该从以下方面去描述需求:,功能,:软件要做什么,外部接口,:如何与人、系统硬件、外部的硬件和软件交互,性能,:速度、响应时间、恢复时间等,属性,:可移植性、可靠性、可维护性、可用性等,实现的设计约束,:标准、实现语言、资源限制、操作环境等,9,软件需求规格说明书的目的,在客户和开发者之间达成一致,为编制计划和成
3、本计价提供基础,为设计提供了基础,为确认和验证提供一个基础,提高开发效率,便于移植,10,软件需求规格说明书的特点,软件需求的正确性,软件需求的无歧义性,软件需求的完整性,软件需求的一致性,软件需求的可验证性,软件需求的可追踪性,11,实例一,需求1:系统应在不少于每10秒的正常周期内提供状态信息;,系统应该以误差上下不超过1秒的10秒间隔,在用户界面的指定位置显示状态信息;,显示的状态信息应包括如下内容:,如果显示状态信息有误,应提示如下的错误信息:,12,实例二,需求2:,HTML,分析器可以产生,HTML,标记错误报告,帮助,HTML,入门者快速解决错误,HTML,分析器可以产生一个错误
4、报告,错误报告包含有在被分析文件中出错的,HTML,文本和行号以及错误的描述。如果没有错误,就不会产生错误报告,13,需求的属性,每个需求类型都有多个属性:,优先级,工作量,风险,可用于界定项目的范围,估计工作量,计划和平衡资源等,1.,“,必须的,”,如果该需求不能实现,软件产品功能不能成为特定类型的产品;,2.,“,重要的,”,如果该需求不实现,会影响其市场竞争力;,3.,“,最好有的,”,可以选择实现,针对特定目标客户群的个性化需求,或为了和同类产品展开差异化竞争而实现的需求。,14,需求阶段的角色和职责(,1,),带领项目组分析业务需求,带领项目组完成软件需求规格说明书,撰写软件,SR
5、S,参加软件,SRS,的评审,根据评审意见,修改,SRS,参加系统测试计划的评审,15,软件经理:在,SRS,评审结束后,批准,SRS,文档,QA,:,监督项目组遵循需求管理流程;参加相关文档评审;保证相关组参加文档评审,CCB,负责人:控制需求的变更,(Change Control Broad),16,需求阶段的角色和职责(,2,),参与开发人员的软件需求分析,提出可测试性需求,组织人员参与,SRS,的评审工作,软件系统测试计划、方案写作,组织软件系统测试计划的评审,参与软件需求规格的评审工作,协助软件测试项目经理完成软件系统测试计划、方案写作,参加系统测试计划的评审,17,软件系统测试设计
6、的技能要求,软件开发相关,软件需求的相关知识,可视化建模,/UML,相关知识,软件测试技术相关,软件系统测试方案的设计,软件系统测试用例设计,产品质量属性相关知识,软件测试管理相关,软件测试的项目管理,沟通能力,执行能力,产品业务知识,通讯的原理,财会知识,金融产品知识,18,概要设计阶段,软件概要设计的检视、评审,软件集成测试计划、方案设计,软件集成测试计划、方案的检视和评审,软件集成测试用例设计,软件集成测试用例的检视和评审,19,软件,集成测试,设计的技能要求,软件开发相关,软件架构设计的相关知识,可视化建模,/UML,相关知识,软件测试技术相关,软件集成测试方案的设计,软件集成测试用例
7、设计,软件测试管理相关,软件测试的项目管理,沟通能力,执行能力,20,概要设计阶段的角色和职责(,1,),在项目计划中标识设计活动并确保有足够的资源,从项目成员中标识出概要设计人员,负责设计工作,确保设计人员按照本流程开发相应的设计说明书,确保按照评审规程进行设计的评审,完成概要设计和接口文档,参加设计文档评审,根据评审专家意见,修改设计文档,21,概要设计阶段的角色和职责(,2,),组织所有的测试活动,制定测试策略,确保测试活动有合适的计划,撰写集成测试用例,22,详细设计阶段,软件详细设计的检视、评审,软件单元测试计划、方案设计,软件单元测试计划、方案的检视和评审,软件单元测试用例设计,软
8、件单元测试用例的检视和评审,23,软件单元测试设计的技能要求,软件开发相关,具有良好的编码能力,软件详细设计的评审能力,软件测试技术相关,代码逻辑覆盖率的相关知识,单元测试用例设计的相关知识,软件测试管理相关,软件测试的项目管理,沟通能力,执行能力,24,详细设计阶段的角色和职责(,1,),在项目计划中标识设计活动并确保有足够的资源,从项目成员中标识出设计人员,负责设计工作,确保设计人员按照本流程开发相应的设计说明书,确保按照评审规程进行设计的评审,完成设计文档,参加设计文档评审,根据评审专家意见,修改设计文档,25,详细设计阶段的角色和职责(,2,),组织所有的测试活动,制定测试策略,确保测
9、试活动有合适的计划,撰写单元测试用例,26,软件编码阶段,软件代码静态检查,软件代码走读,27,单元测试执行阶段,软件单元测试用例执行,软件单元测试软件缺陷记录、跟踪,软件单元测试日报写作,软件单元测试报告写作,软件单元测试缺陷的回归测试,28,软件集成测试执行阶段,软件集成测试用例执行,软件集成测试软件缺陷记录、跟踪,软件集成测试日报写作,软件集成测试报告写作,软件集成测试缺陷的回归测试,29,软件系统测试执行阶段,软件系统测试用例执行,软件系统测试软件缺陷记录、跟踪,软件系统测试日报写作,软件系统测试报告写作,软件系统测试缺陷的回归测试,ST,30,测试执行阶段开发人员的角色和职责,确保缺
10、陷分发给相关软件工程师并及时得到解决,参与需求变更评审,修正缺陷,验证相关的缺陷已经被修改,31,测试执行阶段开发人员的角色和职责,组织所有的测试活动,确保选择适合的测试工具以及测试环境的建立,确保测试活动的计划得到执行和获得资源,确保缺陷分发给相关软件工程师并及时得到解决,审核并批准测试报告,搭建测试环境,执行测试用例,将测试中发现的所有缺陷填写在缺陷报告中,回归测试,E.,准备测试报告,32,软件开发测试工作量分布,33,4.4,区分集成测试与系统测试,澄清不同层次的测试目标,理解在不同层次上如何标识测试用例。,集成测试所处的层次比系统测试细的多,集成测试假设已经过单元测试,主要考虑的是单
11、元之间的接口。,结构认识,系统端口事件为系统测试用例的,“,原语,”,,系统测试用例采用端口输入和端口输出事件的交替序列来描述。,行为认识,34,4.5,单元测试,单元测试,(,模块测试,),是对软件基本组成单元进行的测试(如:函数,/,子过程或类,/,类的方法);,单元具有一些基本属性,如:明确的功能、规格定义,明确的与其他部分的接口定义等,可清晰地与同一程序的其他单元划分。,35,单元测试的目的,单元测试的目的在于发现各模块内部可能存在的各种错误,主要是基于白盒测试,验证代码是与设计相符合的;,发现设计和需求中存在的错误;,发现在编码过程中引入的错误。,36,特点,多个模块可以平行地独立进
12、行单元测试;,最早的基于代码运行的测试,是在软件开发过程中要进行的最低级别的测试活动,是非常重要的测试;,能够在改善应用质量的同时大量削减开发时间和成本;比如:单元级修改一个类只会影响到原始的类,而在较高的层次上修改一个类可能会改变多个程序部件的设计和功能性。,37,单元测试的重要性,时间方面:低级错误造成后续阶段测试不顺利,测试效果:深层次问题,证明代码做了什么、如何做,是否做了该做的事情,测试成本,产品质量,单元测试是构筑产品质量的基石,不要因为节约单元测试的时间不作单元测试而在后期浪费太多的时间。,38,进行单元测试的原因,完成了单元测试工作,很多,Bug,将被纠正,开发人员能够进行更高
13、效的系统集成工作;即完整计划下的单元测试是对时间的更,高效,的利用;,高质量的测试需要高质量的,规格说明,,能找到更多的编码错误,甚至是一些规格说明中的错误;,39,进行单元测试的原因(续),每个人都会犯错误:,一般软件工程师平均缺陷引入率在,100个,/千行代码(包括编译错误);,受过,PSP,训练的工程师缺陷引入率在,50个,/千行代码;,工程师在编写代码的时候,一般每小时引入68个缺陷;,在设计阶段,一般每小时引入13个缺陷。,40,CMM、PSP,和,TSP,简介,CMM,是过程改善的第一步,它提供了评价组织的能力、识别优先改善需求和跟踪改善进展的管理方式。,PSP,(Person S
14、oftware Process),能够指导软件工程师如何保证自己的工作质量,估计和规划自身的工作,度量和追踪个人的表现,管理自身的软件过程和产品质量。,TSP(Team Software Process),结合了,CMM,的管理方法和,PSP,的工程技能。,41,进行单元测试的原因(续),单元测试是一个在早期抓住,Bug,的机会,单元测试的创建更简单,维护更容易,并且可以,方便地进行重复,,单元测试的费用很低。,3.25小时,6.25小时,11.5小时,11小时,单元测试,集成测试,系统测试,外场测试,各种测试的时间效率,42,单元测试和集成测试的区别,测试对象:,单元测试模块下实现具体功能的
15、单元,(详细设计),集成测试模块以及模块间的,组合,(概要设计),趋势:,单元测试和集成测试间的界限变得模糊了,如:单元测试方法中也引入了集成概念。,43,单元测试和系统测试的区别,单元测试早期测试;白盒测试;单元的具体实现、内部逻辑结构、数据流向;允许多个单元的测试同时开展。,系统测试后期测试,错误定位困难;黑盒测试;基于需求规格说明书;站在用户角度。,44,两个问题,测什么?,怎么测?,45,测什么?,46,单元测试分析,在单元测试时,测试者需要依据,详细设计说,明书,和,源程序清单,,了解该模块的,I/O,条件和,模块的逻辑结构。从5个方面进行考虑:,47,模块接口,对被测的模块,信息
16、能否正常无误地流入和流出。,局部数据结构,在模块工作过程中,其内部的数据能否保持其完整性,包括内部数据的内容、形式及相互关系不发生错误。,路径测试,发现由于计算错误、不正确的判定或不正常的控制流而产生的错误。,出错处理,模块工作中发生了错误,其中的出错处理设施是否有效。,边界条件,在为限制数据处理而设置的边界处,模块是否能够正常工作。,48,模块接口,调用所测模块时的输入参数与模块的形式参数在个数、属性、顺序上是否匹配;,所测模块调用子模块时,它输入个子模块的参数与子模块的形式参数在个数、属性、顺序上是否匹配;,是否修改了只做输入用的形式参数;,全局变量的定义在各模块中是否一致。,49,局部数
17、据结构,不正确的数据说明。,置初值错误或错误的缺省值。,使用尚未赋值或尚未初始化的变量。,变量名拼写错误或书写错误。,不相容的数据类型。,上溢、下溢或地址异常。,50,重要的逻辑路径,(1),计算中的错误,算术运算次序不正确和理解错误。,运算方式不正确:逻辑值的算术运算。,初始化不正确。,算法错误。,精度不够。,表达式符号表示不正确。,51,重要的逻辑路径,(2),控制流向(逻辑路径的选择),不同数据类型的数的比较。,逻辑运算符的不正确或优先次序不正确。,因浮点运算精度问题造成的不等,而又用相等条件进行控制转向。,“,差,1,错,”,,即不正确地多循环或少循环一次。,错误的的循环终止条件。,当
18、遇到发散的迭代时不能终止循环。,不正确地修改循环变量。,52,错误处理,有意识地不合理输入,检查错误处理能力。,错误说明不可理解(错误信息难理解)。,指示的错误与实际错误不符。,在错误处理之前,错误条件已引起系统干预。,对错误条件的处理不对。,错误描述所提供的信息不足以帮助确定错误定位。,53,边界测试,在,n,次循环的第,0,次、,1,次、,n,次是否有错误;,运算或判断中取最大最小值时是否有错误;,数据流、控制流中刚好等于、大于、小于确定的比较值时是否出现错误。,54,例,IF a=123 THEN,b=2,ENDIF,边界值测试用例应至少包括,a,的以下值:,122,、,123,、,12
19、4,。,当,a=123,时,,b=1,还是,2,?(找出逻辑判断的矛盾),55,怎么测?,模块并不是一个独立的程序,在考虑测试模块时,同时要考虑它和外界的,联系,在测试过程中使用一些辅助模块去模拟与被测模块相联系的其它模块,56,单元测试环境,提供必要数据,模拟下属模块,57,驱动模块,接收测试数据,包含测试用例输入和预期输出,把测试用例输入传送给要测试的单元,将被测单元的实际输出和预期输出进行比较,得到测试结果,将测试结果输出到指定位置,58,桩模块,桩模块的功能是模拟替代那些隶属于本单元的模块,桩模块需要针对不同的输入,返回不同的期望值,模拟所替代模块的不同的功能,桩模块返回的期望值根据输
20、入和被模拟模块的详细设计来确定,59,单元测试环境(续),驱动模块和桩模块都是,额外的开销,,都属于必须开发但又不能和最终软件一起提交的软件;,必须小心地设计桩和驱动,所有的隐性输入(系统时钟、文件状态、单元加载地点)必须被考虑;,实际环境的代表物(相同的编译器、加载者、操作系统、计算机、输入分布)也是测试环境必须考虑的。,60,常用单元测试用例设计方法,针对单元接口规格的用例设计方法,等价类分析法,(,内部,),边界值分析法,错误猜测法,针对单元内部逻辑控制流程的用例设计方法,语句覆盖,判定覆盖,条件覆盖,判定条件覆盖,路径覆盖,基本路径测试方法,数据流测试法(定义使用路径),61,在单元测
21、试的基础上,需要将所有模块按照设计要求组装成为系统。这时需要考虑的,问题,是:,4.6,集成测试(,Integrated Testing),在把各个模块连接起来的时侯,穿越模块接口的数据是否会丢失;,一个模块的功能是否会对另一个模块的功能产生不利的影响;,各个子功能组合起来,能否达到预期要求的父功能;,单个模块的误差累积起来,是否会放大,从而达到不能接受的程度。,全局数据结构是否有问题;,62,简介,集成测试的目的是确保各单元组合在一起后能够按既定意图协作运行,并确保增量的行为正确。,测试的内容包括单元间的接口以及集成后的功能。,对以前的集成进行回归测试。,63,集成测试举例,现在有一个模块包
22、含以下三个函数:,函数,A,:主控函数,int,ctr,(int x,int y),当,xy,时,调用,add,函数,否则调用,sub,函数,函数,B,:加法函数,int add(int x,int y),返回,x,和,y,的和,函数,C,:减法函数,int sub(int x,int y),返回,x,和,y,的差,需要对这三个函数进行集成,步骤如下:,先对函数,A,和,B,进行集成,函数,C,用桩替代,然后将集成的函数,A,、,B,和,C,进行集成,集成测试考虑的是,ctr,输入,1,,,1,;,add,是否可以,输出成功,不考虑,add,如何计算;,单元测试考虑的是,add,中的计算是否,
23、正确输出,2,64,集成测试的对象,(1),从最低层的单元测试到最终的产品,其中所有各层测试都要通过集成测试来完成,一般可把集成测试划分成,三个层次,:,模块内集成测试;,子系统内集成测试;,子系统间集成测试,65,子系统内集成测试,模块内集成测试,子系统间集成测试,集成测试的对象,(2),A,产品,子系统,1,子系统,2,软件模块,1,软件模块,2,软件模块,2,软件模块,3,软件模块,4,66,集成测试用例设计步骤,划分测试层次和范围,确定每个层次的集成测试策略,根据策略确定该层次的测试子项,针对每个测试子项设计测试用例,67,划分测试层次和范围,分析被测对象,HLD,的,0,层设计、,1
24、层设计、,2,层设计;,根据每层设计中各子系统、模块、子模块及其接口的优先级、测试人力资源状况、测试进度要求等确定集成测试的层次,并确定每层的测试范围,模块内集成测试;,子系统内集成测试;,子系统间集成测试,面向对象集成测试分为:,1,类内集成测试,2,类间集成测试,68,集成测试原则,所有公共接口必须被测试到,关键模块必须进行充分测试,集成测试应当按照一定层次进行,集成测试策略选择应当综合考虑质量、成本和进度三者之间的关系。,集成测试应当尽早开始,并以概要设计为基础,在模块和接口的划分上,测试人员应该和开发人员进行充分的沟通。,69,集成测试原则 续,7,当策划计划的结束标准满足时,集成测
25、试才能结束,当接口发生修改时,涉及的相关接口都必须进行回归测试。,集成测试应根据集成测试计划和方案进行,不能随意测试,项目管理者应保证审核测试用例,测试执行结果应当如实地记录,70,确定每个层次的集成测试策略,分析每层设计中模块间的层次、接口关系,确定该层的测试策略:,被测系统比较小,并且它的每个组件都经过了充分的单元测试,可以考虑用,大爆炸集成,;,该层模块间层次关系非常清楚,可以考虑用,自底向上,、,自顶向下集成,、,三明治集成,、,分层集成,等;,关注关键功能验证的时候,可以考虑,基于功能的集成,;,关注关键消息处理过程的验证的时候,可以考虑,基于消息的集成,;,71,根据策略确定该层次
26、的测试子项,根据各层确定的测试策略,进一步细分该层测试项为测试子项:,如果采用大爆炸策略,可以分析整个测试项涉及到对象的对外接口,根据接口细分成不同测试子项;,如果采用自底向上、自顶向下集成、三明治集成、分层集成等,则可根据各集成步骤来划分测试子项;,如果采用基于功能的集成,则可以根据各功能来划分测试子项;,如果采用基于消息的集成,则可以根据各消息来划分测试子项;,72,针对每个测试子项设计测试用例,分析每个测试子项涉及的接口,选择合适测试用例设计方法设计用例覆盖相关接口,等价类分析,边界值分析,错误猜测法,73,主要的集成测试策略,基于分解的集成,大爆炸集成(非增量式集成),自顶向下增量式集
27、成,自底向上增量式集成,三明治集成,基于调用图的集成,成对集成,相邻集成,基于路径的集成,74,以,SATM,为例详细分析集成测试的方法,一、功能的分解表示,功能分解描述,(表131),功能分解的图示,分解树表示(图131),75,1,A,D,B,2,3,4,5,6,7,8,9,10,11,12,13,B,14,15,C,16,17,F,22,18,19,20,21,23,24,25,26,27,C,图13-1,STAM,的功能分解树,76,从功能分解树进一步细化出单元调用图,1,11,17,18,19,23,22,4,13,25,27,26,24,6,8,2,3,1,4,1,5,5,7,20
28、21,9,10,12,16,图13-2,STAM,的调用图,77,由单元调用图得出邻接矩阵(表132),二、基于功能分解集成测试,1.大爆炸集成(,Big Bang Integration),属于非增量式集成的一种方法,又名一次性组装或整体拼装,先分别测试每个模块,再把所有模块组装在一起进行测试,最终得到要求的软件系统,78,实例,79,非增量式测试,方法的,优点,:,可迅速完成集成测试;,需要的测试用例最少;,该方法比较简单;,多个测试人员可以并行工作,对资源利用较高。,80,非增量式测试,方法的,缺点,:,一次试运行成功的可能性并不大;,在发现错误时,问题定位和修改都比较困难;,即使被测
29、系统能够被一次性集成,但还是会有许多接口错误很容易躲过测试而进入到系统范围测试内。,81,非增量式与增量式集成测试比较,非增量式测试的做法是先分散测试,然后集中起来一次完成集成测试,如果在模块的接口处存在错误,只会在,最后,的集成测试时一下子暴露出来,增量式测试使用逐步集成和逐步测试的办法,把可能出现的差错分散出来,便于找出问题和修改,一些模块在逐步集成的测试中,得到了较为频繁的考验,因而可能取得较好的测试效果,增量式测试与非增量式测试相比,具有一定的,优越性,82,增量式集成测试,将单元测试与集成测试交替进行,在组装的过程中边连接边测试,以发现连接过程中产生的问题,通过逐步组装成为要求的软件
30、系统,两种基本方法,自顶向下增量式集成,自底向上增量式集成,83,2.自顶向下增量式集成测试,集成是,逐步实现,的,集成测试是,逐步完成,的,最上面的模块最先测试,测试由桩模块控制,桩模块逐步由实际模块代替,整个过程一直重复直到最底层模块得到测试,包含树的,深度优先,(,Depth First Search),或,广度优先,(,Breadth First Search),遍历过程,84,自顶向下增量式集成测试的,步骤,主控模块作为测试驱动器;,根据集成的方式(深度或广度),下层的桩模块一次一次地被替换为真正的模块;,在每个模块被集成时,都必须进行单元测试。,重复第2步,直到整个系统被测试完成。
31、85,自顶向下集成示意图,深度优先组装方式,86,A,s1,s2,s3,A,B,s2,s3,s4,A,B,C,s3,s4,A,B,C,D,s4,s5,A,B,C,D,E,s5,A,B,C,D,E,F,测试,A,加入,B,加入,C,加入,D,加入,E,加入,F,广度优先组装方式,87,模块测试,结合顺序,深度优先,:A,、,B,、,E,、,C,、,D,、,F,广度优先,:A,、,B,、,C,、,D,、,E,、,F,A,D,B,E,C,F,88,顶层子树,第二层子树,底层子树,自顶向下集成,图13-3,89,特点:,可以较早发现较高层次或主控路径的问题。,可以较早实现软件部分功能,从心理上要增强
32、信心。,选用按深度方向组装的方式,可以首先实现和验证一个完整的软件功能。,不需驱动模块。,需要桩模块。,测试和设计可并行进行(和设计顺序一致)。,支持故障隔离。,桩的开发和维护成本大。,随着底层模块的不断增加,整个系统越来越复杂,导致底层模块的测试不充分。,90,3.自底向上增量式集成测试,最下面的模块先得到测试,测试由测试驱动控制,不需要桩模块,父单元用测试过的子单元测试,整个过程重复到最上面的模块测试结束,91,自底向上集成示意图,92,顶层子树,第二层子树,底层子树,图134,自底向上集成,93,特点,可以在任何一个叶子节点已经就绪的情况下进行集成测试;,不需桩模块;,支持故障隔离;,对
33、高层的验证被推迟到了最后,设计上的错误不能被及时发现;,随着集成到了顶层,整个系统将变得越来越复杂,并且对于底层的一些异常将很难覆盖。,94,自顶向下测试与自底向上测试方法的比较,集成测试方法,测试推进方法,优点,缺点,自底向上测试,要准备替代上层模块的测试驱动模块。,能够并行测试作业,同时对多个模块进行测试。,测试作业较分散,往往在测试的后期才能发现系统的重要缺陷。,自顶向下测试,要准备替代下层模块的测试桩模块。,能够在早期检测出接口界面的错误等重大缺陷。,可对上层模块进行反复测试,提高其可靠性。,仅由部分人员担任测试,测试期间较长。,测试驱动模块,模块,D,模块,A,测试桩模块,95,4.
34、三明治集成测试,有时也被称为混合式集成,一种综合自顶向下集成和自底向上集成测试策略的优点的方法,提高测试效率,把系统划分成三层,中间一层为目标层,对目标层上面的一层使用由顶向下的集成策略,对目标层下面的一层使用自底向上的集成策略,把目标层下面的一层与目标层集成,最后测试在目标层会合,96,三明治测试策略示例,测试,E,测试,F,测试,B、E,测试,D、F,测试,A,测试,ABCD,EF,A,B,C,D,E,F,底层,测试,顶层,测试,97,三明治集成测试优缺点,集合了自顶向下和自底向上的两种集成策略的优点;,桩和驱动器的开发工作比较小;,中间层在被集成前测试不充分;,在一定程度上增加了定位缺陷
35、的难度。,98,除了大爆炸集成,基于功能分解的集成测试:,缺陷定位清晰。只要发现失效,就怀疑最新加入的单元。,人工操作,需要开发大量的桩和驱动模块,自顶向下集成需要的桩为节点-1个,自底向上集成的驱动模块为节点-叶个,重复测试带来工作量,总结,99,集成测试过程,1,计划阶段,2,设计阶段,3,实施阶段,4,执行阶段,5,评估阶段,100,集成测试过程,-,计划阶段,输入:需求规格说明书,概要设计文档,产品开发计划时间表。,时间:概要设计评审后一周,内容:,确定被测试对象和测试范围,评估集成测试被测试对象的数量及难度,即工作量,确定角色分工和划分工作任务,标示出测试各阶段的时间、任务和约束条件
36、考虑一定的风险分析及应急计划,考虑和准备集成测试需要的测试工具、测试仪器、环境等资源,考虑外部技术支援的力量和深度,以及相关培训安排,定义测试完成标准、,101,集成测试过程,-,设计阶段,时间:详细设计开始,内容:,被测试对象结构分析,集成测试模块分析,集成测试接口分析,集成测试策略分析,集成测试工具分析,集成测试环境分析,集成测试工作量估计和安排,102,集成测试过程,-,实施阶段,工作:,集成测试用例设计,集成测试规程设计,集成测试代码设计(系统需要),集成测试脚本开发(系统需要),集成测试工具开发或选择(系统需要),103,系统测试,是将已经集成好的软件系统,作为整个基于计算机系统的
37、一个元素,与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起,在实际运行环境下,对计算机系统进行一系列的测试活动。,4.7,系统测试(,System Testing),104,系统测试的目的,通过与系统的需求定义做比较,发现软件与系统定义不符合或与之矛盾的地方,验证系统功能是否符合需求规格定义,验证系统的可靠性、可维护性、可用性、稳定性、容错性等其他属性,系统测试的测试用例应根据需求分析说明书来设计,并在实际使用环境下运行。,105,系统测试的对象,系统测试的对象是软硬件集合在一起的系统,不应是独立的软件与硬件环境。,验证时应尽可能模拟实际的运行环境与条件。,106,单元、集
38、成、系统测试比较,考察范围不同,单元测试主要测试单元内部的数据结构、逻辑控制、异常处理等,集成测试主要测试模块之间的接口和接口数据传递关系,以及模块组合后的整体功能,系统测试主要测试整个系统相对于需求的符合度,评估基准不同,系统测试的评估基准是测试用例对需求规格的覆盖率,单元测试评估的主要是逻辑覆盖率,集成测试评估的主要是接口覆盖率,107,配置主测试环境遵循的原则,主测试环境是测试软件功能、安全可靠性、性能、易用性等大多数指标的主要环境。,符合软件运行的最低要求。测试环境首先要保证能支撑软件正常运行。,选用比较普及的,OS,和软件平台,例如:一个软件若声称支持,“,Windows9X/ME/
39、NT/2000 professional,”,和,“,MS Office97/2000/XP,”,,一般我们会采用如,“,Windows2000 professional,MS Office2000,”,的流行环境,营造相对简单、独立的测试环境。除了,OS,,测试机上只安装软件运行和测试必需的软件,以免不相关的软件影响测试实施。,无毒的环境,利用有效的正版杀毒软件检测软件环境,保证测试环境中没有病毒。,108,配置辅测试环境遵循的原则,兼容性测试,在满足软件运行要求的范围内,可选择一些典型的,OS,和常用应用软件对其安装卸载和主要功能进行验证。,模拟真实环境测试,有些软件,特别是面向大众的商品
40、化软件,在测试时常常需要考察在真实环境中的表现。,横向对比测试,利用辅测试环境,“,克隆,”,出完全一致的测试环境,从而保证各个被测软件平等对比。,109,软件特性和常用系统测试类型的对应关系:,功能性:功能测试、安全性测试、互连测试,可靠性:可靠性测试、启动,/,停止测试、恢复测试、健壮性测试、备份测试,易用性:可用性测试、文档测试、安装测试,效率:强度测试、性能测试、指标测试、内存泄漏测试、容量测试、压力测试,维护性:可维护性测试,可移植性:配置测试、兼容测试、安装测试,110,系统测试用例编写原则,系统测试用例的设计根据是系统的需求规格说明书、各种规范,系统测试用例的依据不是软件本身,系
41、统测试用例不仅仅包括功能测试用例,同时还应该包含属性测试用例,111,系统测试用例编写思路,(1),为系统功能性设计用例,为系统可靠性设计用例,为系统易用性设计用例,为系统可移植性设计用例,为系统可维护性设计用例,为系统效率设计用例,为系统异常设计用例,112,系统测试用例编写思路,(2),一、根据,ISO9126,质量模型分析需求规格说明书,将需测试的需求项归纳到各特性、子特性下,质量特性,质量子特性,测试项,功能性,适合性,准确性,互操作性,安全性,功能依从性,效率,时间特性,资源利用性,113,系统测试用例编写思路,(3),二、对分析出来的测试需求项进行归纳、总结,确定需要进行何种类型的
42、测试,并把各测试项归类到各测试类型下:,功能测试,性能测试,压力测试,容量测试,安全性测试,GUI,测试,可用性测试,安装测试,配置测试,异常测试(恢复性测试),备份测试,健壮性测试,文档测试,在线帮助测试,网络测试,系统测试用例编写思路,(4),三、对各测试类型下的测试项细分,形成为测试子项:,需求标识,需求描述,系统测试,项标识,系统测试项描述,系统测试,子项标识,系统测试子项描述,Router_V100_SRS_001,路由管理,Router_V100_ST_AddRoute,路由增加,Router_V100_ST_AddRoute_HostRoute_,增加主机路由,Router_V1
43、00_ST_AddRoute_NetRoute_,增加网络路由,Router_V100_ST_AddRoute_SpecRoute_,增加特殊路由,Router_V100_ST_DelRoute,路由删除,Router_V100_ST_InqRoute,路由查询,Router_V100_SRS_002,路由协议,Router_V100_ST_OSPF,OSPF,协议测试,Router_V100_ST_RIP,RIP,协议测试,115,系统测试用例编写思路,(5),四、对各测试子项对应的具体需求规格进行分析,利用各种系统测试用例设计方法,从各角度设计用例去对需求规格进行覆盖,从而达到对需求的充分
44、覆盖:,等价类划分法,边值分析法,状态迁移图法,决策表,正交试验法,错误猜测法,116,系统测试过程,测试过程计划设计实现执行;,测试过程体现了测试设计和实现的分离,测试实现测试执行,系统测试计划阶段:完成系统测试计划,系统测试设计阶段:完成系统测试方案,系统测试实现阶段:完成系统测试用例和脚本、系统测试规程、系统测试预测试项,系统测试执行阶段:执行系统测试预测试项、提交系统预测试报告;执行系统测试用例,提交测试日报,发现问题并提交缺陷报告、系统测试报告;进行回归测试,117,系统测试执行的概念,按一定的系统测试计划,依据系统测试用例,完成测试的各项操作任务;,系统测试执行阶段应完成:环境准备
45、测试操作、测试记录、测试报告,118,系统测试预测试,目的:验证软件系统基本功能或预测主要的系统功能,以确保其后的系统测试执行能顺利进行,119,系统测试日报的写作目的,测试人员总结每天的测试工作,便于了解自己的测试进度和测试情况,用以调整下一天的工作计划,测试人员对被测对象每天给出评估结果,用以调整后续工作中的测试策略,测试人员向测试经理反映测试中的困难,保证测试的顺利进行,测试经理通过测试日报,了解每个测试人员的工作进度,把握测试的整体进度,发现进度上的风险及时调整计划,120,测试经理通过测试日报,了解各模块缺陷发展趋势,判断测试是否可以退出,开发经理可以通过软件测试日报了解当前被测试
46、软件的质量情况,并可以调整缺陷修改的人力资源,如果产品有多个测试组并行测试,测试日报可以提供彼此测试交流的手段,项目,ID,标题,版本,执行者,测试阶段,日期,概述,执行用例数,总用例数,计划执行用例数,累计已执行用例数,本日发现问题数,累计发现问题数,致命问题数,问题单号,严重问题数,问题单号,一般问题数,问题单号,困难,系统测试日报的格式,122,测试报告的写作目的,软件测试人员完成对上一个测试阶段的总结,完成对被测试对象的评估,并对下一阶段的测试工作给出建议,测试经理通过测试报告了解被测试产品的质量情况、测试过程的质量,软件开发项目经理通过软件测试报告了解开发产品的质量情况,并在下阶段的
47、开发工作中采取应对措施,在软件测试报告中,软件测试人员做出的软件产品质量评估,可以作为产品是否商用发布的重要参考依据。,123,系统测试报告写作要点,概述,测试时间、地点、人员,环境描述,总结和评价,测试结果统计,测试评估,测试总结和改进建议,遗留问题报告,附件,124,系统测试结果统计,工作量数据统计,(,规模:,KLOC,、测试执行:人时、工作量投入比例:人时,/KLOC),缺陷统计(致命、严重、一般、提示),版本缺陷统计(,V1,、,V2,、,V3,、,V4,),累计遗留问题统计(,V1,、,V2,、,V3,、,V4,),125,系统测试评估,(1),静态分析:效率分析,测试活动持续时间
48、X,人时,执行用例数:,Y,个,发现缺陷总数:,Z,个,平均每小时用例数执行用例数,/,测试活动持续时间,Y/X,平均每小时发现缺陷数发现缺陷总数,/,测试活动持续时间,Z/X,影响测试效率的原因分析:对影响测试的各种因素进行分析,如:测试环境,物料,突发任务等。,126,系统测试评估,(2),静态分析:充分性分析,千行代码用例数:根据用例统计对测试充分性进行点评分析,执行结果统计,根据结果统计对系统质量和测试过程进行点评,127,系统测试评估,(3),测试对象的整体质量:,质量稳定,适合大规模应用;,存在少数严重问题,但有规避措施,可以使用;,基本功能可用,但问题较多;,基本功能不可用。
49、也可采用打分方式。,128,系统测试总结和改进建议,总结本次测试活动的经验教训,总结主要的测试活动和事件,总结资源消耗数据,如总人员、总机时,每个主要测试活动花费的时间,提供对本次测试过程活动的测试设计和操作的改进建议,在测试过程中形成的对测试方案、测试用例的修改和补充的具体改进内容可列在本测试报告文档的附录中,129,系统测试遗留问题报告,遗留问题是指测试过程中发生的并且在测试报告时仍没有得到解决的测试问题。测试报告时已经得到解决,并已经过回归验证的测试问题不记入其中,可对遗留问题数和级别进行统计,要列出每个遗留问题的详细情况,包括问题单号、问题级别、详细描述、问题分析与对策等,130,功
50、能测试,性能测试,稳定性测试,负载测试,压力测试,安全性测试,恢复性测试,备份测试,GUI,测试,健壮性测试,兼容性测试,可用性测试,可安装性测试,文档测试,在线帮助测试,数据转换测试,可靠性测试,Web,网站测试,4.7.8,系统测试方法,131,1.,功能测试,功能测试是系统测试中最基本的测试,主要根据产品的,需求规格说明书,和,测试需求列表,,验证产品的功能实现是否符合产品的需求规格。,为了发现以下几类错误:,是否有不正确或遗漏了的功能?,功能实现是否满足用户需求和系统设计的隐藏需求?,能否正确地接受输入?能否正确地输出结果?,要求测试设计者对产品的规格说明、需求文档、产品业务功能都非常






