Ch5-单元测试市公开课获奖课件省名师优质课赛课一等奖课件.ppt

,Click to edit Master title style,Click to edit Master text styles,Second level,Third level,Fourth level,Fifth level,*,本资料仅供参考，不能作为科学依据。谢谢。本资料仅供参考，不能作为科学依据。本资料仅供参考，不能作为科学依据。谢谢。本资料仅供参考，不能作为科学依据。,软件测试方法和技术,-Ch.5,单元测试,主讲教师：郭晓燕,1/79,第四章回顾,软件质量标准,软件测试规范,CMM,思想和结构体系,建立软件测试管理和评判体系,2/79,第五章 单元测试,5.1,什么是单元测试,5.2,单元测试目标和任务,5.3,静态测试技术利用,5.4,动态测试技术利用,5.5,调试与评定,5.6,单元测试过程与文档管理,5.7,单元测试惯用工具介绍,3/79,5.1,什么是单元测试,测试,4,个阶段：,单元测试,集成测试,系统测试,验收测试,按阶段进行测试是一个基本测试策略,4/79,单元测试定义,定义,:,单元测试是对软件基本组成单元进行测试。,时机,:,普通在代码完成后由开发人员完成,QA,人员辅助,.,对象,:,软件设计最小单位,模块（组件、单元）,5/79,为何要进行单元测试,?,尽早发觉错误,错误发觉越早,成本越低,.,开发人员过于自信,后期复杂,度高,发觉处理,BUG,困难,.,检验代码是否符合设计和规范,12,小时,6,小时,3,小时,单元测试,集成测试,系统测试,6/79,单元测试背景,开发流程时间表与修改Bug代价关系图,开发结束,开发早期,修改代价,7/79,单元测试背景,（续）,编程过程中，每写,100,行代码会犯,150,个错误,编程与编译运行结束后，每,100,行代码中大约残留有,1-3,个,Bug,寻找与修改程序错误代价占总体开发投资,40%-80%,Bug,在整个研发流程中被发觉越早，修改代价就越低,8/79,5.2,单元测试目标和任务,目标,:,单元模块被正确编码,信息能否正确地流入和流出单元；,在单元工作过程中，其内部数据能否保持其完整性，包含内部数据形式、内容及相互关系不发生错误，也包含全局变量在单元中处理和影响。,在为限制数据加工而设置边界处，能否正确工作。,单元运行能否做到满足特定逻辑覆盖。,单元中发生了错误，其中犯错处理办法是否有效。,9/79,任务,1,：模块接口测试,检验模块接口是否正确，,c,hecklist:,输入实际参数与形式参数是否一致。,个数、属性、量纲,调用其它模块实际参数与被调模块形参是否一致。,个数、属性、量纲,全程变量定义在各模块是否一致。,外部输入、输出,文件、缓冲区、错误处理,其它,10/79,任务,2,：模块局部数据结构测试,检验局部数据结构完整性,Checklist:,不适合或不相容类型说明。,变量无初值。,变量初始化或默认值有错。,不正确变量名或从来未被使用过。,出现上溢或下溢和地址异常。,其它,11/79,任务,3,：模块边界条件测试,检验临界数据处理正确性,Checklist:,普通正当数据处理。,普通非法数据处理。,边界值内正当边界数据处理。,边界值外非法边界数据处理。,其它,12/79,任务,4,：模块独立执行通路测试,检验每一条独立执行路径测试。确保每条语句被最少执行一次。,Checklist:,算符优先级。,混合类型运算。,精度不够。,表示式符号。,循环条件，死循环。,其它,13/79,任务,5,：模块各条错误处理通路测试,预见、预设各种犯错处理是否正确有效。,Checklist:,输出犯错信息难以了解。,统计错误与实际不相符。,程序定义犯错处理前系统已介入。,异常处理不妥。,未提供足够定位犯错信息。,其它,14/79,5.3,静态测试技术利用,定义:在,不执行软件,条件下有条理地仔细审查,软件设计、体系结构和代码,，从而找出,软件缺点,过程。有时也称为结构分析。,作用:,尽早发觉软件缺点，以找出动态黑盒白盒测试难以揭示或发觉软件缺点,为接收该软件测试黑盒测试员进行测试设计测试案例提供思绪，他们无须了解代码细节，不过依据审查备注，能够确定有问题或者轻易存在软件缺点特征范围,问题:认为会减慢软件开发过程。,15/79,编码标准和规范,标准：建立起来，经过修补和必须恪守规则。,规范：提议最正确做法，推荐更加好方法。,坚持编程标准和规范原因,可靠性：,事实证实按照按规范编写代码更可靠，软件缺点将更少；,可读性/维护性：,符合标准和规范代码易于阅读，了解和维护；,移植性：,假如代码符合设备标准，迁移到另一个平台就会轻易，甚至没有任何障碍。,16/79,正式审查三部曲,走查（,Walk Through,）,审查（,Inspection,）,评审（,Review,）,17/79,走查（,Walk Through,）,定义：编写代码程序员向5人小组或其它类似程序员或测试员做正式表述。,注意：,审查人员应该在审查之前接到软件拷贝，在走查前通读设计和编码，方便检验并编写备注和问题，在审查过程中提问。,表述者现场采取讲解或模拟运行方法解释代码怎样工作。,检验关键点在于代码编写是否符合规范和标准，是否存在逻辑错误；,限时，防止跑题。发觉问题适当统计，防止现场修改。,18/79,审查（,Inspection,）,定义：是最正式审查类型，含有高度组织化，采取讲解、提问方式进行，普通有正式计划、流程和结果。主要方法采取缺点检验表。,注意：,以会议形式，制订会议目标、流程和规则，结束后要编写汇报。,发觉问题适当统计，防止现场修改。,发觉重大缺点，更正后会议需要重开。,按缺点检验表逐项检验。检验关键点是缺点检验表，所以该表要依据项目不一样不停积累完善。,19/79,走查与审查比较,走 查,审 查,准备,通读设计和编码,应准备好需求描述文档、程序设计文档、程序源代码清单、代码编码标准和代码缺点检验表,形式,非正式会议,正式会议,参加人员,开发人员为主,项目组组员包含测试人员,主要技术方法,无,缺点检验表,注意事项,限时、不要现场修改代码,限时、不要现场修改代码,生成文档,会议统计,静态分析错误汇报,目标,代码标准规范，无逻辑错误,代码标准规范，无逻辑错误,20/79,评审（,Review,）,定义：通常在审查会后进行，审查小组依据统计和汇报进行评定。,注意：,充分审查了所要求代码，而且全部编码准则被恪守。,审查中发觉错误已全部修改。,21/79,5.4,动态测试技术利用,动态测试需要真正将程序运行起来，需要设计系列测试用例确保测试完整性和有效性。,白盒测试,黑盒（灰盒）测试,22/79,白盒测试方法,定义：（结构化测试）,利用,查看代码功效,（做什么）和,实现方式,（怎么做）得到信息来确定哪些要测试，哪些不要测试，怎样开展测试。,白盒测试针正确是程序内部逻辑和数据流程测试,动态白盒测试不但是,查看代码,，还包含,直接测试和控制软件,。,23/79,白盒测试方法,主要有逻辑驱动法和基本路径法。,语句覆盖。,判定覆盖。,条件覆盖。,判定,/,条件覆盖。,条件组合覆盖。,路径覆盖。,循环覆盖。,详细内容 第,14,章 软件测试用例设计,24/79,白盒测试用例设计方法,白盒测试用例设计方法,逻辑覆盖：以程序内部逻辑结构为基础，分为语句覆盖、判定覆盖、判定,-,条件覆盖、条件组合覆盖等,基本路径测试：在程序控制流程基础上，分析控制结构环路复杂性，导出基本可执行路径集合，从而设计测试用例。,白盒测试用例注意事项,因为测试路径可能非常多，因为时间和资源问题，选出足够多路径测试,因为深入到程序编码，通常开发人员帮助测试人员书写白盒测试用例,25/79,动态白盒测试与调试,测试和调试是不一样,。,白盒测试目标是,寻找软件缺点,；,调试目标是,修复软件缺点,。,它们,在隔离软件缺点位置和原因,上确实存在交叉现象。,测试员应该把问题缩减为能够演示软件缺点最简化测试案例。在白盒测试中，甚至要包含那些值得怀疑代码行信息。,进行调试程序员从这里继续，判断到底是什么造成软件缺点，并设法修复。,分清软件测试员和程序员工作。,程序员编写代码，修复软件缺点；,测试员寻找软件缺点，可能还要编写一些代码来驱动测试，要进行这么底层测试，就要使用与程序员相同工具。详细操作方法不一样,26/79,覆盖标准：,使得程序中每个语句最少都能被执行一次。,满足语句覆盖情况是,：,执行路径：,ace,选择用例,：,(,2,0,4),(,2,0,3),用例格式,，,由输入数据和预期输出结果两部分组成：,输入(A,B,X)，输出(A,B,X),1.语句覆盖,a,A1,AND,B=0,X:=X/A,A=2,OR,X1,X:=X+1,b,c,d,e,Y,N,Y,N,X:=X/A,X:=X+1,程序中除判定外，还有两条语句。,27/79,if(（A1)AND(B=0),X=X/A;,if(A=2)OR (X1),X:=X+1;,选择用例：,(2,0,4),(,4,0,3),假如写成：,if(（A1),OR,(B=0),X=X/A;,if(A=2)OR (X1),X:=X+1;,错误，但测试结果相同,28/79,覆盖标准,使得程序中每个判定最少为,TRUE,或,FALSE,各一次。,覆盖情况：,共有两个判定，应执行路径：,ace,abd,或：,acd,abe,选择用例，,两组用例中任选择,其一,(2,0,4),(2,0,3)ace,(1,1,1),(1,1,1)abd,(2,1,1),(2,1,2)abe,(3,0,3),(3,1,1)acd,A1,AND,B=0,X:=X/A,A=2,OR,X1,X:=X+1,a,b,c,d,e,Y,N,Y,N,2.判定覆盖,注：符号,表示“,AND”,运算,，,符号,表示“,OR”,运算。,29/79,覆盖标准：,使得判定中每个条件取得各种可能结果。,应满足以下覆盖情况,：,判定一:A1,A1,B=0,B0,判定二:A=2,A2,X1,X1,选择用例：,(2,0,4),(,2,0,3,),(1,1,1),(1,1,1),注意:,(1,0,3),(1,0,4),(2,1,1),(2,1,2),满足条件覆盖，但不满足判定覆盖。,3.条件覆盖,A1,AND,B=0,X:=X/A,A=2,OR,X1,X:=X+1,a,b,c,d,e,Y,N,Y,N,判定一,判定二,30/79,应满足以下覆盖情况,：,条件:A1,A1,B=0,B0,A=2,A2,X1,X1,应执行路径,ace,abd,或,acd abe,选择用例,：,(2,0,4),(2,0,3)（ace),(1,1,1),(1,1,1)(abd),A1,AND,B=0,X:=X/A,A=2,OR,X1,X:=X+1,a,b,c,d,e,Y,N,Y,N,4.判定/条件覆盖,覆盖标准：,同时满足判定覆盖和条件覆盖。即使得程序中每个判定最少为,TRUE,或,FALSE,各一次，同时使得判定中每个条件取得各种可能结果。,31/79,5.,条件组合覆盖,A1,X:=X/A,A=2,X:=X+1,a,b,c,d,e,B=0,X1,Y,N,Y,N,Y,N,Y,N,比如，红线所标注路径未被执行。,编译系统下执行情况,考虑到程序在编译状态下执行情况，可采取最深一个覆盖标准条件组合覆盖。,AND,OR,c,即使采取判定/条件覆盖普通比前面几个覆盖标准要好，但若考虑在编译系统下执行时，对条件“,AND”,和“,OR”,处理情况，部分路径未被执行。,32/79,满足以下覆盖情况：,A1,B=0 ,A,1,B,0,A1,B0,A,1,B=0,A=2,X1,A=2,X1,A,2,X1,A,2,X1,选择用例：,(2,0,4),(2,0,3),覆盖情况,(2,1,1),(2,1,2),覆盖情况,(1,0,3),(1,0,4),覆盖情况,(1,1,1),(1,1,1),覆盖情况,5.,条件组合覆盖,判定一,判定二,显然，条件组合覆盖所测试情况最多，不过选择用例较多，相对难度也大些。,部分路径未被执行,编译系统下执行情况,A1,X:=X/A,A=2,X:=X+1,a,b,c,d,e,B=0,X1,Y,N,Y,N,Y,N,Y,N,覆盖标准：,使得每个判定中条件各种可能组合都最少出现一次。,33/79,语句段：,if(A&(B|C)x=l,；,else x=O,；用例表：见右图,A,TRUE FALSE TRUE,B,TRUE FALSE FALSE,C,FALSE FALSE TRUE,D,TRUE TRUE FALSE,用例,1,用例,2,A,TRUE,FALSE,B,FALSE,C,TRUE,A&(B|C),FALSE,逻辑路径覆盖法是白盒测试用例主要设计方法，其中语句覆盖法是较为惯用方法，针对下面语句段，采取语句覆盖法完成测试用例设计，测试用例见下表，对表中空缺项,(True,或者,False),，正确选择是,_,。,34/79,基本路径测试,Goal:exercise,each independent path,at least once,.,使用代码，画出程序流程图；,(First drawing the activity diagram for the code may help,but is not required),计算程序流程图环路复杂性,V(G),；,导出线性无关基本程序路径集合；,为基本路径集合设置测试用例.,35/79,Example,Procedure:process records,1,.,Do While,records remain,2.,Read,record;,3.,If,record field 1=0,Then,4.,store in buffer;,5.,increment counter;,6.,Else If,record field 2=0,Then,7.,reset counter;,8.,Else,store in file;,9.,End If,10,.,End If,11,.,End Do,End,36/79,Example(continued),1,9,10,11,2,4,5,7,8,3,6,V(G)=4,37/79,基本路径测试,:,流程图,1,2,3,8,7,6,9,4,5,10,11,38/79,流程图复杂度确定,V(G)=number of regions(areas bounded by nodes and edgesarea outside the graph is also a region),V(G)=number of edges-the number of nodes+2,V(G)=number of(simple)predicate nodes+1,Cyclomatic complexity:,a quantitative measure of the logical complexity of code,provides an upper bound on the number of paths that need to be tested in the code,V(G),modules,modules in this range are more error prone,Higher Cycloramic Complexity,more possibility in error,39/79,流程图复杂度例子,V(G)=4,1,2,3,7,8,6,9,4,5,10,11,Region 1,Region 2,Region 3,Region 4,40/79,确定线性独立路径集合,Independent path,any path that introduces at least one new set of processing statements or a new condition,Basis set,set of,independent paths,through the code,Test cases,derived from a,basis set,are guaranteed to execute every statement at least one time during testing,Basis set is,not unique,41/79,Path1:,1-2-3-6-7-9-10-1-11,Basis path test example,Path2:,1-2-3-6-8-9-10-1-11,Path3:,1-2-3-4-5-10-1-11,Path4:1-11,1,9,10,11,2,4,5,8,7,3,6,42/79,测试用例覆盖集合中每条路径,Basis path testing does not test all possible combinations of all paths through the code;it just tests every path at least once.,you do not need an activity diagram,but the picture will help when you trace component paths,count each logical testcompound tests count as the number of Boolean operators+1(i.e.,count each simple predicate),basis path testing should be applied to all components,if possible,and to critical components,always,43/79,基本路径法设计出测试用例能够确保在测试中程序每一条可执行语句最少执行一次。以下代码由,C,什语言书写，请按要求回答下列问题。,void ReadPara(CString temp)if(temp=)m_oper.SetCurSel(0);elseif(temp=)m_oper.SetCurSel(1);elseif(temp=)m_oper.SetCurSel(2);elseif(temp=)m_oper.SetCurSel(3);elseif(temp=,2,3,=,4,=,5,=、=、=、=,2,3,=,4,=,5,=、=、=、=,2,3,=,4,=,5,=、=、=、=,=,=,=、=、=、之外字符组合,46/79,黑盒测试方法,运行单元程序有时需要基于被测单元接口，开发对应驱动模块和桩模块。,驱动模块（,drive,）,:,对底层,或子层模块进行测试所编写,调用这些模块程序。,桩模块（,stub,）：对顶层或,上层模块进行测试时所编写,替换下层模块程序。,47/79,黑盒惯用方法,等价类划分法,边界值分析法 三种数据：,错误推测法,-,正常数据,因果图法,-,错误数据,功效图法,-,边缘数据,另外还得考虑接口测试、性能测试、内存测试,性能分析,内存分析,48/79,5.3,等价类划分,在分析需求规格说明基础上划分等价类，列出等价类表。,将程序可能输入数据分成若干个等价区域，从中选取一个代表性数据作为测试用例,.,所谓等价类是就是在该区域内每个输入数据结果是一样。,all inputs,i,1,i,4,i,2,i,3,49/79,等价类划分,等价类分类：有效等价类和无效等价类。,有效等价类是有意义、合理输入数据，能够检验程序是否实现了规格说明中所要求功效和性能。,无效等价类与有效等价类意义相反。,设计测试用例时，要同时考虑这两种等价类。因为软件不但要能接收合理数据，也要能经受意外考验。经过正反测试才能确保软件含有更高可靠性。,50/79,确定等价类方法,在输入条件要求了,取值范围或值个数,情况下，则能够确立一个有效等价类和两个无效等价类,。,in range,greater than range,less than range,value,greater than value,less than value,51/79,在输入条件要求了,输入值集合或者要求了“必须怎样”,条件情况下，能够确立一个有效等价类和一个无效等价类。,在输入条件是,一个布尔量,情况下，可确定一个有效等价类和一个无效等价类,确定等价类方法（,2,）,not member of set,member of set,Boolean,Non-Boolean,52/79,确定等价类方式,(3),在要求了,输入数据一组值,(,假定,n,个,),，,而且程序要对每一个输入值分别处理情况下，可确立,n,个有效等价类和一个无效等价类。,在要求了输入数据,必须恪守规则,情况下，可确立一个有效等价类,(,符合规则,),和若干个无效等价类,(,从不一样角度违反规则,),。,个人月收入,-,x,税率,x,=1600 0%,1600,x,2100 5%,500 =,x,3600 10%,3600 =,x,6600 15%,6600 =,x,21600 20%,21600 =,x,101600 45%,53/79,等价类测试用例,-Example,等价类,1:Integer,等价类,2:Decimal fraction,等价类,3:Negative,等价类,4:Invalid input,54/79,练习：,银行提款机用户提款界面。用户输入想要取款数码进行分析，对输入数据要求：,有效数据,10,300,，并以,10,为最小单位数，不能够出现数字以外任何符号和文字。,55/79,边界条件,程序很多错误发生在输入或输出范围边界上，所以针对各种边界情况设置测试用例，能够发觉不少程序缺点；,边界值分析是一个,补充等价划分,测试用例设计技术。,设计方法：,确定边界情况（,选择等价类边界,）,选取,恰好等于,、,刚才大于,或,刚才小于,边界值作为测试数据,56/79,确定边界值方法,假如输入条件要求了值范围，则应取刚到达这个范围边界值，以及刚才超越这个范围边界值作为测试输入数据。,假如输入条件要求了值个数，则用最大个数、最小个数、比最小个数少一、比最大个数多一数作为测试数据。,a,b,a,b,57/79,确定边界值方法（,2,）,假如程序规格说明给出输入域或输出域是有序集合，则应选取集合第一个元素和最终一个元素作为测试用例。,假如程序中使用了一个内部数据结构，则应该选择这个内部数据结构边界上值作为测试用例。,Test cases for ABS(x):,class x=0,arbitrary value x =100,classes x=0,on boundary:x =0,classes x=0,below and above:x =-1,x=1,58/79,一些特殊边界值,数值,字符,位置,数量,速度,地点,尺寸,First/last,，,First-1/Last+1,Min/Max,，,Min-1/max+1,Star/Finish,，,Start-1/Finish+1,Empty/Full,Less than empty/more than full,Slowest/Fastest,Largest/Smallest,Over/Under,，,just Over/Just Under,Shortest/Longest,59/79,Test cases:,Class arbitrary value:X1=123123,Class boundary value:X2=12345,Class boundary value:X3=1234567,Class boundary value:X4=1,Class boundary value:X5=0,Class invalid value:X6=-123123,Class invalid value:X7=asdasd,Others?,边界测试实例,1,测试功效：要求用户输入,6,位正数,Class invalid value:X8=000123,X9=asd123,X10=Empty,60/79,边界测试实例,2,Test cases:,Class arbitrary value:Random select some options Class boundary value:Select all options Class boundary value:Select none option Class boundary value:Select 1 option,61/79,次边界条件,边界问题在软件内部，最终用户看不到,不要求测试员成为程序员，但要大致了解软件工作方式。,2,次幂,ASCII,表,62/79,二进制,Term,Range or Value,Bit,Nibble,Byte,Word,Kilo,Mega,Giga,Tera,0 or 1,0-15 ,0-255,0-65535 or 0-4294967295,1024,1048576,1073741824,1099511627776,Binary:0 and 1,byte is made up of 8 bits,word is made up of 4 bytes,63/79,ASCII Table,Character,ASCII Value,Character,ASCII Value,Null,Space,/,0,1,2,9,;,A,0,32,47,48,49,50,57,58,64,65,B,Y,Z,a,b,y,z,66,89,90,91,96,97,98,121,122,123,64/79,字符编辑域,默认,Default,空白,Empty,空值,Blank,Null,零值,Zero,无,None,65/79,BVA Example 3,Test cases:,Class arbitrary value:Random select some options Class boundary value:Select all options Class boundary value:Select none option Class boundary value:Select 1 option,66/79,错误推测法测试用例设计,基于经验和直觉推测程序中全部可能存在各种错误，从而有针对性地设计测试用例。,发觉程序经常出现错误方法：,单元测试中发觉模块错误；,产品以前版本曾经发觉错误；,输入数据为,0,或字符为空；,当软件要求输入时,(,比如在文本框中,),不是没有输入正确信息，而是根本没有输入任何内容，单单按了,Enter,键；,这种情况在产品说明书中经常忽略，程序员也可能经常遗忘，不过在实际使用中却时有发生。程序员总会习惯性认为用户要么输入信息，不论是看起来正当或非法信息，要不就会选择,Cancel,键放弃输入，,67/79,测试场景法设计测试用例,现在软件几乎都是用事件触发来控制流程，事件触发时情景便形成了场景，而同一事件不一样触发次序和处理结果就形成事件流。这种在软件设计方面思想也可引入到软件测试中，能够比较生动地描绘出事件触发时情景，有利于测试设计者设计测试用例，同时使测试用例更轻易了解和执行。,68/79,因果图法测试用例设计,各种输入条件组合，产生各种结果设计测试用例。,设计方法：,分析软件规格说明文档描述哪些是原因（输入条件），哪些是结果（输出条件），给每个原因和结果赋予一个标示符。,找出原因与结果，原因与原因之间对应关系，划出因果图,在因果图上标上哪些不可能发生因果关系，表明约束或限制条件,依据因果图，创建判定表，将复杂逻辑关系和各种条件组合很详细明确表示出来,把判定表每一行作为依据设计测试用例。,69/79,因果图法,Sample 1,Valid equivalence classes:,conditionvalid eq.classes .abs(N)N,0,N,0maxint,k ,maxint,k ,maxint,Test Cases:,maxintNresult maxintNresult,55105510000 5410error100-11 56105510011 000,Given inputs maxint and N compute result,:,K=0,|,N,|,k,result =if this =maxint,error otherwise,70/79,因果图法,Sample 2,k,maxint,k,maxint,N,0,N,0,k,error,and,xor,and,Causes,k,maxint,1100,Inputs,k,maxint,0011,N,01010,N,00101,Effects,k,1100,Outputs,error,001,1,71/79,因果图法,Sample 3,1,1,0,0,error,0,0,1,1,k,Effects,1,0,1,0,N,0,0,1,0,1,N,0,1,1,0,0,k,maxint,0,0,1,1,k,maxint,Cause,Case Matrix:,72/79,5.6,调试与评定,调试与测试对象及采取方法有很大程度上相同，调试还用到断点控制等排错方法，但其目标却完全不一样。测试是为了找出软件中存在缺点，而调试是为了处理存在缺点。,软件单元功效与设计需求一致。,软件单元接口与设计需求一致。,能够正确处理输入和运行中错误。,在单元测试中发觉错误已经得到修改而且经过了测试。,到达了相关覆盖率要求。,完成软件单元测试汇报,73/79,单元测试检验表,(1),借助单元测试检验表进行评定。,案例：,单元测试检验表,单元名称,_,系统,_,结构,_,任务编号,_,首次测试日期,_,关键测试项是否已纠正,有没有任何输入参数没有使用？有没有任何输出参数没有产生？,有没有任何数据类型不正确或不一致？,有没有任何算法与,PDL,或功效需求中描述不一致？,有没有任何局部变量使用前没有初始化？,有没有任何外部接口编码错误？即调用语句、文件存取、数据库错误。,有没有任何逻辑路径错误？,该单元是否有多个入口或多个正常出口？,74/79,单元测试检验表,(2),额外测试项,8.,该单元中有任何地方与,PDL,与,PROLOG,中描述不一致？,9.,代码中有没有任何偏离本项目标准地方？,10.,代码中有没有任何对于用户来说不清楚错误提醒信息？,11.,假如该单元是设计为可重用，代码中是有可能妨碍重用地方？,采取动作和说明,（请用单独一页或多页。每一项动作必须指出所引用问题。）,审查结果,1.,假如上述,11,个问题答案均为,否,，那么测试经过，请在此标识而且在最终署名。,2.,假如代码存在严重问题，比如多个关键问题答案为,是,，那么程序编制者纠正这些错误，而且必须重新安排一次单元测试。,下一次单元测试日期：,_,3.,假如代码存在小缺点，那么程序编制者纠正这些错误，而且仲裁者必须安排一次跟踪会议。,跟踪会议日期：,_,测试人署名：,_,日期：,_,75/79,5.6,单元测试过程和文档管理,过程,:,在详细设计阶段完成单元测试计划。,建立单元测试环境，完成测试设计和开发。,执行单元测试用例，而且详细统计测试结果。,判定测试用例是否经过。,提交,单元测试汇报,。,76/79,单元测试文档,软件需求规格说明书,、,软件详细设计说明书,单元测试计划,单元测试计划,、,软件详细设计说明书,单元测试用例,单元测试用例,文档及,软件需求规格说明书,、,软件详细设计说明书,缺点跟踪汇报,/,缺点检验表,单元测试用例,、,缺点跟踪汇报,、,缺点检验表,单元测试检验表,评定,单元测试汇报,77/79,5.7,单元测试惯用工具介绍,工具分类,:,静态分析工具,代码规范审核工具,内存和资源检验工具,测试数据生成工具,测试框架工具,测试结果比较工具,测试度量工具,测试文档生成和管理工具,78/79,Q&A,79/79,