测试流程图.pptx

,Click to edit Master title style,Click to edit Master text styles,Second level,Third level,Fourth level,Fifth level,#,测试总体流程图,F,验收测试,B,单元测试,C,整合测试,D,系统测试,E,性能测试,A,测试计划、测试设计,立项,结束,测试分类,.,黑盒测试,.,白盒测试,.,灰盒测试,软件中的难题,1.,开发的不是客户需要的,2.,计划赶不上变化，进度无法按期完成,3.,挖坑还是开渠？永远的资源不足,4.,不能正确实现功能,5.,如何维护大量的已有软件？,软件与硬件的区别,软件,硬件,易变,确定，需求和产物,非组件化,组件化，由构建组成,随时间而消退,随时间而磨损,成本在研发上，,copy,过程几乎没有成本,生产工程成本高,软件工程,1.,软件工程是为创造高质量软件提供的一个框架,2.,将系统化，规范化，可度量的方法应用于软件的开发，运行和维护，即将工程化应用于软件中,3.,包括过程，方法和工具三个层面,4.,过程，方法和人对质量的影响,过 程,1.,过程是项目管理的基础,2.,定义关键过程区域框架,3.CMM,中的,KPA,方 法,1.,技术上需要如何做？,2.,方法涵盖一系列的任务：需求，设计，编码，测试，维护,工 具,1.,为工程，方法提供自动，半自动化的支持,2.,组建起来被另外一个工具使用,3.,组成软件工程环境,过程篇,关于,CMM,CMM,（,Capability Maturity Model,）,能力成熟度模型,用于软件开发过程和开发能力的改进与评估的模型,对软件工程的全过程进行考察和评估,不告诉你怎么做，但告诉你不用成熟度应该关注的关键过程,何为,CMM/CMMI,CMMI,，目标：第一个是质量，第二个是时间表，第三就是要用最低的成本。,与原有的能力成熟度模型,CMM,相比，,CMMI,涉及面更广，专业领域覆盖软件工程、系统工程、集成产品开发和系统采购,CMMI,即,CMM,集成，是系统工程和软件工程的集成成熟度模型，,CMMI,更适合于信息系统集成企业。,CMMI,是在,CMM,基础上发展起来的，它继承并发扬了,CMM,的优良特性，借鉴了其他模型的优点，融入了新的理论和实际研究成果。它不仅能够应用在软件工程领域，而且可以用于系统工程及其他工程领域。,CMMI,阶段模型,5.,优化级：持续过程改进，组织性快速重新配置,4.,量化管理级：过程和产品被量化度量并控制，组织性能提升,3.,已定义级：组织内项目改进和执行,2.,已管理级：能重复以前的成功，有纪律性,1.,初始级：过程能力不可预测，无秩序,Level 1,在级别,1,：,过程是随机，混乱和无序的。这种通常没有一个稳定的环境，它的成功依赖于组织中个人的能力和英雄主意，而不是依赖使用经过验证的过程。尽管这种混乱，无序的环境，对成熟度,1,的组织也经常能制造出能工作的产品和服务，但是，他们的项目经常是超成本和进度的。,它们有过度承诺的趋势，在危机时放弃过程，不能重复他们过去的成功。,Level 2,1.,组织中的项目确保需求得到管理，过程已经计划，执行，度量和控制。,2.,即使在时间压力下，依然能够保留现有的实践。,3.,管理层在某些已定义点上对工作产品的状态和提交的服务具有可视性。,4.,在干系人（风险承担者）之间建立了承诺，在必要的时候进行修正。,Level 3,工程得到很好地表现和理解，被描述成标准，规程，关键和方法。,作为,3,级基础的组织标准过程集已经简历和不断改进。,2,，,3,级的区别在于标准，过程和规程的范围,3,级比,2,级的描述更具体和更严格,Level 4,使用统计和量化技术进行控制,建立了质量和过程性能的量化目标，作为过程管理的准则,收集了过程性能的详细度量，进行统计分析,质量和过程性能度量数据组成组织的度量库，来支持将来的基于事实的决策,3,，,4,级的区别在于过程性能的可预测性。,Level 5,基于对过程中的固有偏差的一般原因的定量理解，持续的进行过程改进,通过渐进的和革新的技术改进，集中在持续地过程性能改进上,指出过程偏差的一般原因和可测地改进组织过程的过程改进得到识别，评估和实施,敏捷和创新的过程优化依赖于授权员工的参与，他们与业务价值和组织目标保持一致,Level 2,CMM2,：可重复性,KPA,：软件配置管理,软件质量保证,子合同管理,Level 2,软件项目跟踪和监控,软件项目计划,需求管理,配置管理,1.,定义并文档化配置项的功能和物理属性,2.,控制这些属性的变更,3.,记录和报告变更处理结果和实施状态,4.,遵从制定的需求进行验证,同行评审,为什么进行评审？,.,促进文档化，提升可读性，易理解性等,.,查找错误，收集建议,.,扩散知识，产生后备力量,评审什么？,.,项目中的一系列计划,.,项目各阶段的输出：文档，代码等,谁来评审？,项目组成员，,PPQA,，上级领导，客户等,同行评审,.,评审的输入,-,待评审的文档，代码,-XXX,评审检查表,.,评审的输出,-,评审报告,-,评审过程检查表,正确看待文档,.,文档是所有事情能够继承的保证,.,如果认为不必要，多一分也是多，如果认为必要，多少都不够,.,文档是一个人水平高低的体现,.,需要提高每个人的写作能力，练好内功,软件开发模型,瀑布型,1.,需求,2.,设计,3.,代码,4.,测试,5.,运行,/,维护,软件开发模型,原型,1.,用户需求不明确是采用,2.,快速设计，快速开发,3.,迭代的过程,4.,与用户一起明确需求,5.,最终会被抛弃,软件开发模型,演化模型,.,线性迭代,.,每个线性过程产生一个版本,.,分阶段提供给用户,敏捷式开发,1.,是一种以人为核心、迭代、循序渐进的开发方法。,2.,在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。,决定软件质量的因素,1.,过程,2.,方法,3.,工具,4.,人,测试目的,在产品投入使用前，通过综合的智力活动,，发现程序中的显性和隐形的错误和缺陷,。控制发布产品的质量，提升客户满意度,测试目的,测试的目的是发现和确认系统有问题，而不是验证系统没有问题,确认软件生命周期中的各个阶段的产品是否正确,确认最终交付的产品是否符合用户需求,使用测试数据检验系统运行的行为是否是按照预期目标执行的,测试原则,所有测试都应该追溯到用户需求,应该在测试工作真正开始的较长时间内就进行测试,测试中发现的,80%,的问题可能集中在模块的,20%,中,测试原则,测试顺序应从简单到复杂，从模块到集成，从白到黑,穷举测试是不可能的,Bug,不可避免,常用的测试技术,1.,在产品成型前，对规约，设计，代码进行,Review,，确认与需求是否一致,-,静态测试,2.,了解产品内部结构，确认内部逻辑是否符合需求，且内部构件被充分利用,-,白盒测试,3.,如果了解特定的功能，在各种功能中寻找错误,黑盒测试,静态测试和动态测试,1.,静态测试：指不用执行程序的测试。主要采用,Review,，代码走查，同级评审，,check list,检查单的方法对软件产品进行测试。,2.,动态测试：通过执行程序，找出产品问题的测试过程。黑盒，白盒都是动态测试。,白 盒 测 试,白盒测试发现的错误类型：,1.,语法错误,2.,编译错误,3.,逻辑错误,4.,判定条件问题,5.,编程规范,6.Memory Leak,7.Performance Problem,白 盒 测 试,逻辑驱动测试,基本路径测试,逻辑驱动测试,逻辑驱动测试：,主要是测试覆盖率，以程序内在逻辑结构为基础的测试。包括以下,6,种类型：,1.,语句覆盖,2.,判断覆盖,3.,条件覆盖,4.,判定,-,条件覆盖,5.,条件组合覆盖,6.,路径覆盖,逻辑驱动测试,主要是测试覆盖率，以程序内在逻辑结构为基础的测试。包括以下,6,种类型：,1.,语句覆盖：,语句覆盖就是设计若干个测试用例，运行测试程序，使得每一条可执行语句至少执行一次,2.,判断覆盖：,也叫分支覆盖设计若干个测试用例，运行测试程序，使得每个判断的取真分支和取假分支至少执行一次,3.,条件覆盖：,设计足够多的测试用例，运行测试程序，使得每个判断的每个条件的每个可能取值至少执行一次,4.,判定,-,条件覆盖：,设计足够多的测试用例，运行测试程序，使得每个判断的所有可能的条件取值组合至少执行一次,5.,条件组合覆盖：,设计足够多的测试用例，运行测试程序，使得程序中每个判断的所有可能的条件取值组合至少执行一次,6.,路径覆盖：,设计足够多的测试用例，运行测试程序，要覆盖程序中所有可能的路径,For Example,Void DoWork(int x,int y,int z),int k=0,j=0;,if(x3)&(z5),j=x*y+10;/,语句块,2,j=j%3,；,/,语句块,3,流程图如下：,语 句 覆 盖,为了说明简略，分别对各个判断的取真，取假分支编号为,b,，,c,，,d,，,e,为了测试语句覆盖率只要设计一个测试用例就可以把三个执行语句块中的语句覆盖。,测试用例输入为：,x=4,，,y=5,z=5,程序执行的路径是：,a b d,该测试用例虽然覆盖了可执行语句，但是并不能检查判断逻辑是否有问题，例如在第一个判断中把,&,错误的写成,|,，上面的测试用例仍然可以覆盖所有的执行语句。可以说语句覆盖率是最弱的逻辑覆盖准则,判 定 覆 盖,如果设计两个测试用例则可以满足分支覆盖的要求：,测试用例的输入为：,x=4,y=5,z=5,x=2,y=5,z=5,虽然可以满足分支覆盖的要求，但是也不能对判断条件做完整的检查,条 件 覆 盖,对于这个简单例子的所有条件取值加以标记。如：,对于第一个判断：,条件,x3,取真值为,T1,，取假值为,-T1,条件,z5,取真值为,T4,，取假值为,-T4,设计测试用例如下：,测试用例,通过路径,条件取值,覆盖方式,x=4,y=6,z=5,a b d,T1,T2,T3,T4,b d,x=2,y=5,z=5,a c e,-T1,T2,-T3,-T4,c e,x=4,y=5,z=15,a c d,T1,-T2,T3,-T4,c d,上面的测试用例不但覆盖了所有分支的真假两个分支，,而且覆盖了判断中的所有条件的可能值,测试用例如下：,但是如果设计了下面的测试用例，则虽然满足了条件覆盖，但是只覆盖了第一个条件的取假分支和第二个条件的取真分支，不满足分支覆盖的要求,测试用例,通过路径,条件取值,覆盖分支,x=2,y=6,z=5,a c d,-T1,T2,-T3,T4,c d,x=4,y=5,z=5,a c d,T1,-T2,T3,-T4,c d,分支条件覆盖,根据定义只需要设计以下两个测试用例便可以覆盖,8,个条件值以及,4,个判断分支,测试用例,通过路径,条件取值,覆盖分支,x=4,y=6,z=5,a b d,T1,T2,T3,T4,b d,x=2,y=5,z=11,a c e,-T1,-T2,-T3,-T4,c e,分支条件覆盖,条件分支覆盖从表面上看，它测试了所有条件的取值，但是实际上某些条件掩盖了另外的一些条件，例如对于条件表达式（,x3,）,&,（,z10,）来说，必须两个条件都满足才能确定表达式为真。如果（,x3,）为假，则一般的编译器不再判断是否（,z5,）来说，若,x=4,测试结果为真，就认为表达式的结果为真，这是不在检查（,y5,）的条件了。因此，采用分支条件覆盖，逻辑表达式的错误不一定能够查出来了。,条件组合覆盖,设计足够多的测试用例，运行测试程序，使得程序中每个判断的所有可能的条件取值组合至少执行一次。,现在对例子中的各个判断的条件取值组合加以标记如下：,x3,z3,z=10,记做,T1,，,-T2,，第一个判断的取假分支,x=3,z5,记做,T3,，,T4,，第一个判断的取真分支,x=4,y5,记做,-T3,，,T4,，第一个判断的取真分支,x!=4,y=5,记做,-T3,，,-T4,，第一个判断的取假分支,条件组合覆盖,测试用例,通过路径,条件取值,覆盖组合号,x=4,y=6,z=5,a b d,T1,T2,T3,T4,1,和,5,x=4,y=5,z=15,a c d,T1,-T2,T3,-T4,2,和,6,x=2,y=6,z=5,a c d,-T1,T2,-T3,T4,3,和,7,x=2,y=5,z=15,a c e,-T1,-T2,-T3,-T4,4,和,8,上面的测试用例覆盖了所有条件的可能取值的组合，覆盖了所有判断的可取分支，但是却丢失了一条路径,abe,。,基本路径测试,1.,根据源代码导出流程图,2.,分析程序逻辑复杂度,3.,导出测试,Case,基本路径测试举例,-PDL,分析,计算不超过,100,个数字的平均值，使用,PDL,语言,INTEFACE RETURNS average,total.input,total.valid;,INTEFACE RETURNS value,minimum,maxium,sum;,TYPE value(1:100)IS SCALAR ARRAY;,TYPE i IS INTEGER;,i=1;,Total.input=total.valid=0;,1,Sum=0,DO WHILE,value,（,i,）,-999,2 and,total.input=minimum,5 and,value(i)0,;10,THEN average=sum/total.valid;,11,ELSE average=-999;,12,ENDIF,13,END average,数 据 流 分 析,环形复杂度,V,（,G,）,=,判定节点,+1=5+1,基本测试路径：,1.1-2-10-11-13,1-2-10-12-13,1-2-3-10-11-13,1-2-3-4-5-8-9-2,1-2-3-4-5-6-8-9-2,1-2-3-4-5-6-7-8-9-2,基本路径测试用例,测试路径,输入,预计输出,条件,1,Value(k)=,有效输入,Value(i)=-999,KI,2100,个的值,前,100,个被正确处理,4,Value(i)=,有效输入,Value(k)minimum,i100,kmaxmum,i=j,基于,k,的正确平均值和总数,6,Value(i)=,有效输入,i100,基于,k,的正确平均值和总数,从基本路径测试想到的,穷举测试是不可能的,尽量选择有代表性的主要路径，更易发现问题，且对质量的贡献很大,环形复杂度的方法也可以应用到黑盒测试中,单元测试,单元测试是对最小软件开发单元的测试,单元测试重点测试程序的内部结构,主要使用白盒测试方法,由开发人员负责,单元测试中的常见错误,不正确的算法,混合情况下的条件判断错误,不正确的初始化,计算结果的精度不精确,语法错误,不正确的逻辑优先级,需求实现上的偏差,单元测试中的常见错误,不正确的循环处理,缺少对错误输入的有效处理,对错误输入的处理提示不准确,接口协议错误,接口处理逻辑错误,内存溢出,语句处理效率低,单元测试的方法,确定测试的基本路径,进行边界测试,进行接口测试,通过打桩的方法，确认关键路径中的功能,通过,DEBUG,工具，内存检查工具，代码覆盖率工具,探 针,设置探针值,在程序中增加,DEBUG,信息，跟踪探针结果,主要用于程序调试,单元测试中实践问题,问题：,1.,开发工程师习惯认为代码完成后，就可以提交了，而省略了单元测试过程,2.,开发时间紧，没有时间做,3.,没有规范化的要求，质量不一,上述问题对开发的影响,1.,在正式的测试环节，延长测试时间,2.,降低测试效率,3.,增加了问题逃逸几率,对大家的要求和建议,1.,开发中增加单元测试规范,2.,制定测试程序标准,3.,开发在提交程序时，提交单元测试,Case,Junit,使用步骤,1.,覆盖,setUp,（）和,tearDown,（）方法,2.,使用,Assert.assert(),单元测试的工具,Rational Purify Plus,包括三个工具,1.,测试,VC,和,java,代码编写的程序,2.Purify,检查内存泄露,3.Purecoverage,检查代码覆盖率,