【文档说明】软件测试：单元测试课件.ppt，共(44)页，1.383 MB，由小橙橙上传

转载请保留链接：https://www.ichengzhen.cn/view-45257.html

以下为本文档部分文字说明：

软件测试：单元测试课件目录单元测试概述1代码缺陷模式3２4代码编程规范动态单元测试漫画：单元测试来源：西乔漫画《单元测试定义单元测试定义:即对软件基本组成单元进行的测试，确保被正确地编（功能正确，结构可靠健壮）名词术语测试依据：详细设计描述或函数说明迚行测试执行者：由开发人员完成，测试人员辅

助。测试方法：静态测试（代码走读为主）+动态测试（白盒测试为主）测试对象:函数,组件,模块单元测试的必要性编码过程中，每写100行代码会犯150个错误编码与编译结束后，每100行代码中大约残留有1-3个Bu

g寻找与修改程序错误的代价占总体开发投资的40%-80%Bug被发现的越早，修改的代价就越低单元测试的任务接口数据能否正确地流入和流出单元。单元其内部局部数据能否保持其完整性，包括：内部数据内容及关系不发生错误，也包括全局变量在单元中的处理在数据处理的边界上，

能否正确工作。单元的运行能否做到满足特定的逻辑覆盖要求。单元中发生了错误，其中的出错处理措施是否有效。数据流(接口/局部数据/边界)+控制流(路径)+错误处理发现代码问题的途径代码走读。快速发现缺陷的方法。通过阅读代

码快速找经验数据：走读效率是单元测试3~5倍。最多发现75%代码分析。通过对代码规范、缺陷模式、代码结构等进给出代码潜在问题、代规规范符合度、代码复杂度等数编译。语法、拼写错误、没有定义的符号等初级错误。经验数据：约9.4%语法缺陷会通过编译。测试。发现错误最有效

的方法。不同阶段不同类型缺陷使用。软件交付用户使用后，仍可能存在遗漏出去的问静态测试动态测试发现代码问题的途径有哪些？目录单元测试概述1代码缺陷模式3２4代码编程规范动态单元测试为什么总结代码缺陷模式模式：Pattern,在物

体或事件上，产生的一种规律变化与自样式与过程（来源：wiki百科）缺陷：一经激活，就会导致系统故障。缺陷模式：发现缺陷的特征代码缺陷模式：代码中所呈现出的缺陷特征帮助快速识别缺陷不经过测试通过静态测试早期就可以发现缺陷典型代码缺陷模式空指针引用（

NullPointerDereferenceNPD）数组越界(OutOfBoundOOB)资源泄露(ResourceLeakRL)非法计算(IllegalArithmeticOperationIAO)死循环(DeadCycle)其它：野指针、==与=运算符的混淆、浮点数比较、查询性能

低下、安全漏洞、一些与语言相关的缺陷等等典型代码缺陷模式：系统运行之初，要初始化变量及运行环境，防止未经初始化的变量被引系统运行之初，要对加载到系统中的数据进行一致性检查要时刻注意易混淆的操作符。防止

拼写错误。（&与&&｜与||=与if语句尽量加上else分支；switch语句必须有default分支只引用属于自己的存贮空间防止引用已经释放的内存空间防止内存操作越界过程/函数中分配的内存，在过程/函数退出之前要释放过程/函数中申请的（

为打开文件而使用的）文件句柄，在过程/函数退参考：代码质量保证检查Checkl内存编程时，要防止差1错误时刻注意表达式是否会上溢、下溢。使用变量时要注意其边界值的情况。认真处理程序所能遇到的各种出错情况系统应具有一定的容错能力，对一些错误事件（如用户误操作等）

能进对一些具有危险性的操作（如写硬盘、删数据等），代码要仔细考虑，硬件等构成危害。为用户提供良好接口，使用户能充分地了解/理解系统、内部运行状态及(可用性)不能随意改变与其它模块的接口(兼容性)资源文件（多语言版本支持）如果对语言敏感，应让其

与源代码文件脱参考：代码质量保证检查Checkl可靠性边界目录单元测试概述1代码缺陷模式3２4代码编程规范动态单元测试难懂的代码http://www.排版程序块要采用缩进风格编写，缩进空格数为4个一

行程序小于80字符为宜，不要写得过长一个函数小于200行为宜，不要写得过长相对独立的程序块之间、变量说明之后必须加空行一行只写一条语句。if、for、do、while、case、switch、default等一行，且if、for、do

、while等语句的执行语句部分无论多少都要加括if(!valid_ni(ni)){...//programcode}repssn_ind=ssn_data[index].repssn_index;repss

n_ni=ssn_data[index].ni;注释一般情况下，有效注释量必须在20％以上源文件头部应进行注释，列出：版权说明、版本号、生成日期、作者、能、主要函数及其功能、修改日志等。函数头部应进行注释，列出：函数目的/功能、

输入参数、输出参数、关系（函数、表）等全局变量要有较详细的注释，包括对其功能、取值范围、哪些函数或过及存取时注意事项等的说明。在代码的功能、意图层次上进行注释，提供有用、额外的信息。注释内JAVA注

释，符合JAVADOC标准，至少包含：方法描述参数：@param参数名说明返回值：@return说明例外情况：@exception完整类名说明/**thisisadocsample*@paramargsarrayofstringar*@returnNoreturnvalue*@

exceptionexceptionNoexc**/标识符命名标识符命名的有明确含义、自解释。注意命名统一。对于变量命名，禁止取单个字符（如i、j、k...），建议除了要有具体含表明其变量类型、数据类型等，但i、j、

k作局部循环变量是允许的命名规范必须与所使用的系统风格保持一致，并在同一项目中统一，比UNIX的全小写加下划线的风格、或大小写混排的方式intliv_Width变量名的含义如下：l局部变量（Local）（其它

：g全局变量Global...）i数据类型（Interger）v变量（Variable）（其它：c常量Const...）Width变量含义可读性注意运算符优先级，并用括号明确表达式的操作顺序，避免使用默认优避免使用不

易理解的数字，用有意义的标识来替代。涉及物理状态或者义的常量，不应直接使用数字，必须用有意义的枚举或宏来代替源程序中关系较为紧密的代码应尽可能相邻。不要使用难懂的技巧性很高的语句，除非很有必要时。if(Trun

k[index].trunk_state==0){Trunk[index].trunk_state=1;...//programcode}#defineTRUNK_IDLE0#defineTRUNK_BUSY1if(Trunk

[index].trunk_stat{Trunk[index].trunk_stat...//programcode}魔鬼数字!变量/结构去掉没必要的全局变量防止局部变量与全局变量同名。结构的功能要单一，是针

对一种事务的抽象结构的设计要尽量考虑向前兼容和以后版本升级，并为未来可能应用仔细设计结构中元素的布局与排列顺序，使结构容易理解。typedefstructSTUDENT_STRU{unsignedchar

name[8];/*student'sname*/unsignedcharage;/*student'sage*/unsignedcharsex;/*student'ssex,0-FEMALE;1-MALEunsignedcharteacher_nam

e[8];/*thestudentteacher'sname*/unisgnedcharteacher_sex;/*histeachersex*/}STUDENT;函数/过程一个函数仅完成一件功能函数的功能应该是可以预测的，也就是只要输入数据相同就应产生同样检查函数所有参数输入的有效性。检

查函数所有非参数输入的有效性，如数据文件、公共变量等。使用动宾词组为函数命名。如果是OOP方法，可以只有动词（名词是对对所调用函数的错误返回码要仔细、全面地处理。函数的返回值要清楚、明了，考虑不同情况的错误。防止将函数的参数作为工作变量防止把没有关联的语句放到一个函数中

避免使用BOOL参数。设计高扇入、合理扇出（小于7）的函数。对于提供了返回值的函数，在引用时最好使用其返回值intadd_sub(inta,intb,unsignedcharadd_sub_flg){if(add_sub

_flg==INTEGER_ADD){return(a+b);}else{return(a-b);}}什么是坏木头来源：西乔漫画目录单元测试概述1代码缺陷模式3２代码编程规范4动态单元测试质量死角intfactor(bool*fsys,int*ptx,intlev){i

f(sym==ient)/*因子为标识符*/getsym;else{if(sym==number)/*因子为无符号整数*/getsym;else{if(sym==lparen)/*因子为表达式*/{expression(nxtlev,ptx,lev);if(sym==rparen)getsym;

elseerror(22);/*缺少右括号*/}elseerror(21)}}某需求：主机温度告警至监控单元测试过程测试计划测试设计测试实现测试执行测试结果分析测试结束评估缺陷跟踪测试总结新一轮测试回归测试单元测试过程阶段主要内容输出计划确定测试需求，制定测试策略(出入口准则)，确定

测试资源，创新测试任务时间表单元测试计划设计设计单元测试模型，制定测试方案，确定并结构化测试过程单元测试方案实现参考单元测试模型和方案，制定具体测试用例，创建可重用的测试脚本单元测试用例自动测试脚本执行根据单元测试模型、方案、用例、脚本对单元测试执行，测试

测试结果并记录测试过程中存在缺陷单元测试脚本试结果集评估对测试测试结果进行评估，主要是需求覆盖和代码覆盖的角度评估测试完备性单元测试报告Microsoft的单元测试测试从写软件测试规格书(TestSpec)开始TestSp

ec必须通过PM，Dev与同组Tester共同开会研究通过测试代码编写由软件开发设计者(SDE)自己开始测试代码主体由软件测试工程师(SDET,STE)编写测试代码根据不同测试的情景分为0-4级的优先级0级测试称为BVT(BuildVerifi

cationTest)Dev主要功能实现Check-in前，0-1级测试代码必须已由测试工程师完成Dev进行产品代码的Check-in时，0级测试必须100%通过，1级测试必须至少Dev迚行产品代码的Check-in，Test迚行测试代码的Check-in在随后的代码优化不

稳定期内，测试工程师编写2-4级测试代码，并报告产品责修改Bug，稳定并优化产品华为的单元测试规范要求单元测试要求至少达到语句覆盖单元测试开始要跟踪每一条语句，并观察数据流及变量的变化仔细设计并

分析测试用例，使测试用例覆盖尽可能多的情况，以提高测尽可能模拟出程序的各种出错情况，对出错处理代码进行充分的测试仔细测试代码处理数据、变量的边界情况测试时应设法使很少发生的事件经常发生去除代码运行的随机性（如去掉无用的数据、代码及

尽可能防止并注意寄存器”等），让函数运行的结果可预测，并使出现的错误可再现保留测试信息，以便分析、总结经验及进行更充分的测试单元测试何时结束单元测试什么时候开始？单元测试越早越好!早到什么程度？-XP开发理论讲究TDD（测试驱动开发）。先编写

测试代码编写(不可重构(优化设计)①快速新增一个测试②运行所有的测试，发现新增的测试丌能通过③做一些小小的改动，尽快地让测试程序可运行，可以在程序中使用一些丌合情理的方法④运行所有的测试，并且全部通过⑤重构代码，以消除重复设计，优化代码结构TDD开发过程

：盖房子的故事。你是先砌墙再拉线，还是先拉线再砌墙呢？单元测试什么时候结束？通过单元测试的一般准则:软件单元功能与设计需求一致软件单元接口API与设计一致能够正确处理输入与运行中的错误在单元测试中发现错

误已得到修正并通过了测试达到了相关覆盖率的要求完成软件单元测试报告覆盖率！代码逻辑结构覆盖、测试用例覆盖、单元功能覆盖单元函数调用特点OpenDoor()Animo()PutElephantIntoIcebox()被调用者单元函数单元函数丌是

一个独立可运行的程序，怎么单独测试它？单元函数调用了一个未编写的函数怎么办？【示例】某动画场景：把大象放到冰箱中的故事。抽象CloseDoor()调用者。。。PutInIceBox()。。。单元测试模

型：驱动和桩驱动模块：被测试模块的上一级调用者，把测试数据传递给被测试单元桩模块：被测试单元需调用的其它函数接口，模拟生成测试数据或状态，为单元运行准备动态环境测试用例和测试结果在测试模型中体现的？桩模块被测试单元桩模块驱动模块

名词术语单元测试模型：驱动模块示例桩模块被测试单元桩模块驱动模块测试用例测试结果testcase1testcase2…@test@Testpublicvoidtestcase1(){assertEquals(hw.Exerc

ise_3_6(1,11),11);}@Testpublicvoidtestcase2(){assertEquals(hw.Exercise_3_6(1,-1),0);assertEqualsExerc

ise_3_6()－测试用例本身即是驱模块，直接调用被测试元－通过测试数据丌同表为丌同测试用例单元测试：桩模块示例看一段程序代码：假如你有设置一个定时闹钟，每早晨6点定时播放起床音乐publicabstractEnvironmental{

booleanplayedWav=false;publicabstractlonggetTime();publicabstractvoidplayWavFile(StringfileName);publicabstractboo

leanwavWasPlayed();publicabstractvoidresetWav();}publicclassSystemEnvironmentextendsEnvironmental{publiclonggetTime(){returnSystem.currentTimeMil

lis();}…}publicclassMockSystemEnvironmentextendsEnvironmental{privatelongcurrentTime;publiclonggetTime(){returncurrentTime;}…}单元

测试：桩模块示例Mock测试:产品代码所依赖的某些对象，用虚拟对象代替。使用一个接口来描述这在产品代码中实现这个在测试代码中实现这个在被测试代码中通过接(不知引用的是真实对象还是Interface被测试单元桩模块驱动

模块测试用例测试结果ClassMockClassEnvironmentalMockSystemEnvironmentSystemEnvironment单元测试：用例设计为系统运行起来而设计用例第一个测试用例证明环境和被测单元可用、具备开始

测试条件为正向测试而设计用例验证设计文档或函数说明的功能项为逆向测试而设计用例验证被测单元没有做它不应该做的事情为代码覆盖而设计用例为达到特点的测试覆盖目标为满足非功能质量要求而设计用例性能、安全性等，特

别是要求高的关键代码单元测试：测试数据正常数据：在测试中所用正常数据量是最大的，也是最关键的。边界数据：是界于正常数据和错误数据之间的一种数据。异常数据：编写与程序输入规范不符的数据，从而验证输入校验、错误处单元测试：覆盖率单元测试用例需

考虑达到的覆盖率要求逻辑覆盖：基于语句，基于路径与条件组合功能覆盖：功能点单元测试策略需考虑满足覆盖率基础上减少单元测试给被测单元规划一个良好的测试顺序，尽可能减少测试桩SUT测试策略：先完成高层被测单元黑盒测试，统计白盒覆盖的逻辑单位再设计测试用例覆盖它。C1B1基于语句是最基本覆盖

基于路径+条件组合是全覆盖单元测试工具代码规范审核工具CheckStyle静态分析工具SourceMonitorLogiscope，McCabeQA，CodeTes代码检查工具FindbugPC-LINT，CodeChk，Logiscope内存和资源检查工具Purify，

BoundsCheck,CodeTest测试框架工具:xUnit测试度量工具Logiscope，PureCoverage,TrueCoverage,McCabeTest，CoPureCoverage，EMMAJUNIT简介单元测试实施时遇到的问题测试路径和分支多，编程工作量大驱动与

桩编写困维被测试对象需要传入的参数过多。需要构造的作为参数的对象本身过于复杂和界面显示部分交互过于频繁（耦合性太强）被测对象过多的调用了其他类或方法。代码变更维护本质上是代码可测试性，重构代码本章小结静态单元测试：常见

的代码缺陷模式：空指针、数组越界、资源泄漏、非法计算代码编程规范：注释、标识符命名、变量/结构、函数/过程、可动态单元测试：单元测试实施过程、策略等单元测试模型：驱动和桩函数本章练习单元测试是白盒测试，必须在了解代码实现逻辑分支后才可以迚行。单元测试依据源代码写测试代码，

必须在编码完成后才可以迚行。代码走读就是读代码，必须把代码看懂了才能发现其中的BUG。丌符合编码规范的代码就是缺陷，必须要修改。通过代码缺陷模式发现的问题是潜在的缺陷，必须通过运行后才能确认测试函数调用被测试对象，本质上就是驱动函数为避免被测试函数所调用函数的缺陷影响测试结果，

原则上都需要做成对于系统测试很难测试到的异常分支，通过单元测试很容易测试到。