软件测试：单元测试课件

1、软件测试：单元测试课件软件测试：单元测试课件目录 单元测试概述1代码缺陷模式34代码编程规范动态单元测试目录 单元测试概述1代码缺陷模式34代码编程规范动态单漫画：单元测试来源：西乔漫画单元测试漫画：单元测试来源：西乔漫画单元测试单元测试定义单元测试定义:即对软件基本组成单元进行的测试，确保被正确地编码。（功能正确，结构可靠健壮）名词术语测试依据：详细设计描述或函数说明进行测试执行者：由开发人员完成，测试人员辅助。测试方法： 静态测试（代码走读为主）+ 动态测试（白盒测试为主）测试对象: 函数, 组件, 模块单元测试定义单元测试定义:名词术语测试依据：单元测试的必要性编码过程中，每写100行代

2、码会犯150个错误编码与编译结束后，每100行代码中大约残留有1-3个Bug寻找与修改程序错误的代价占总体开发投资的40%-80%Bug被发现的越早，修改的代价就越低单元测试的必要性编码过程中，每写100行代码会犯150个错误单元测试的任务接口数据能否正确地流入和流出单元。单元其内部局部数据能否保持其完整性，包括：内部数据的形式、内容及关系不发生错误，也包括全局变量在单元中的处理和影响。 在数据处理的边界上，能否正确工作。单元的运行能否做到满足特定的逻辑覆盖要求。 单元中发生了错误，其中的出错处理措施是否有效。数据流(接口/局部数据/边界)+控制流(路径)+错误处理单元测试的任务接口数据能否正

3、确地流入和流出单元。数据流(接口发现代码问题的途径代码走读。快速发现缺陷的方法。 通过阅读代码快速找到缺陷的方法。经验数据：走读效率是单元测试35 倍。最多发现75%80%缺陷。代码分析。通过对代码规范、缺陷模式、代码结构等进行分析与度量，给出代码潜在问题、代规规范符合度、代码复杂度等数据。编译。语法、拼写错误、没有定义的符号等初级错误。 经验数据：约9.4%语法缺陷会通过编译。测试。发现错误最有效的方法。不同阶段不同类型缺陷。使用。软件交付用户使用后，仍可能存在遗漏出去的问题。静态测试动态测试发现代码问题的途径有哪些？发现代码问题的途径代码走读。快速发现缺陷的方法。 通过阅读代目录 单元测试

4、概述1代码缺陷模式34代码编程规范动态单元测试目录 单元测试概述1代码缺陷模式34代码编程规范动态单为什么总结代码缺陷模式模式：Pattern ,在物体或事件上，产生的一种规律变化与自我重复的样式与过程 （来源：wiki百科）缺陷：一经激活，就会导致系统故障。缺陷模式：发现缺陷的特征代码缺陷模式：代码中所呈现出的缺陷特征帮助快速识别缺陷不经过测试通过静态测试早期就可以发现缺陷为什么总结代码缺陷模式模式：Pattern ,在物体或事件上典型代码缺陷模式空指针引用（Null Pointer Dereference NPD）数组越界(Out Of Bound OOB)资源泄露(Resource Le

5、ak RL)非法计算(Illegal Arithmetic Operation IAO)死循环(Dead Cycle)其它：野指针、= 与=运算符的混淆、浮点数比较、 查询性能低下、安全漏洞、一些与语言相关的缺陷等等典型代码缺陷模式：典型代码缺陷模式空指针引用（Null Pointer Der系统运行之初，要初始化变量及运行环境，防止未经初始化的变量被引用 系统运行之初，要对加载到系统中的数据进行一致性检查 要时刻注意易混淆的操作符。防止拼写错误。（&与& 与|=与=）if语句尽量加上else分支；switch语句必须有default分支只引用属于自己的存贮空间 防止引用已经释放的内存空间 防

6、止内存操作越界过程/函数中分配的内存，在过程/函数退出之前要释放过程/函数中申请的（为打开文件而使用的）文件句柄，在过程/函数退出之前要关闭 参考：代码质量保证检查Checklist内存系统运行之初，要初始化变量及运行环境，防止未经初始化的变量被编程时，要防止差1错误 时刻注意表达式是否会上溢、下溢。 使用变量时要注意其边界值的情况。 认真处理程序所能遇到的各种出错情况系统应具有一定的容错能力，对一些错误事件（如用户误操作等）能进行自动补救 对一些具有危险性的操作（如写硬盘、删数据等） ，代码要仔细考虑，防止对数据、硬件等构成危害。为用户提供良好接口，使用户能充分地了解/理解系统、内部运行状态

7、及出错情况。 (可用性)不能随意改变与其它模块的接口 (兼容性)资源文件（多语言版本支持）如果对语言敏感，应让其与源代码文件脱离。 (可移植性)参考：代码质量保证检查Checklist可靠性边界编程时，要防止差1错误 参考：代码质量保证检查Checkli目录 单元测试概述1代码缺陷模式34代码编程规范动态单元测试目录 单元测试概述1代码缺陷模式34代码编程规范动态单难懂的代码/难懂的代码/排版程序块要采用缩进风格编写，缩进空格数为4个 一行程序小于80字符为宜，不要写得过长一个函数小于200行为宜，不要写得过长相对独立的程序块之间、变量说明之后必须加空行 一行只写一条语句。if、for、do、

8、while、case、switch、default等语句自占一行，且if、for、do、while等语句的执行语句部分无论多少都要加括号。 if (!valid_ni(ni) . / program coderepssn_ind = ssn_dataindex.repssn_index;repssn_ni = ssn_dataindex.ni;排版程序块要采用缩进风格编写，缩进空格数为4个 if (!v注释一般情况下，有效注释量必须在20以上 源文件头部应进行注释，列出：版权说明、版本号、生成日期、作者、模块目的/功能、主要函数及其功能、修改日志等。函数头部应进行注释，列出：函数目的/功能、输

9、入参数、输出参数、返回值、调用关系（函数、表）等 全局变量要有较详细的注释，包括对其功能、取值范围、哪些函数或过程存取它以及存取时注意事项等的说明。 在代码的功能、意图层次上进行注释，提供有用、额外的信息。注释内容无二义性。JAVA注释，符合JAVADOC标准，至少包含：方法描述参数： param 参数名 说明返回值： return 说明例外情况：exception 完整类名 说明/* this is a doc sample* param args array of string arguments* return No return value* exception exception N

10、o exceptions thrown*/注释一般情况下，有效注释量必须在20以上 JAVA注释，符标识符命名标识符命名的有明确含义、自解释。注意命名统一。对于变量命名，禁止取单个字符（如i、j、k.），建议除了要有具体含义外，还能表明其变量类型、数据类型等，但i、j、k作局部循环变量是允许的 命名规范必须与所使用的系统风格保持一致，并在同一项目中统一，比如：采用UNIX的全小写加下划线的风格、或大小写混排的方式 int liv_Width 变量名的含义如下：l 局部变量（Local） （其它：g 全局变量Global.）i 数据类型（Interger）v 变量（Variable） （其它：c

11、 常量Const.）Width 变量含义标识符命名标识符命名的有明确含义、自解释。注意命名统一。 可读性注意运算符优先级，并用括号明确表达式的操作顺序，避免使用默认优先级 避免使用不易理解的数字，用有意义的标识来替代。涉及物理状态或者含有物理意义的常量，不应直接使用数字，必须用有意义的枚举或宏来代替 源程序中关系较为紧密的代码应尽可能相邻。 不要使用难懂的技巧性很高的语句，除非很有必要时。if (Trunkindex.trunk_state = 0) Trunkindex.trunk_state = 1; . / program code#define TRUNK_IDLE 0#define

12、TRUNK_BUSY 1if (Trunkindex.trunk_state = TRUNK_IDLE) Trunkindex.trunk_state = TRUNK_BUSY; . / program code魔鬼数字!可读性注意运算符优先级，并用括号明确表达式的操作顺序，避免使变量/结构去掉没必要的全局变量 防止局部变量与全局变量同名。 结构的功能要单一，是针对一种事务的抽象 结构的设计要尽量考虑向前兼容和以后版本升级，并为未来可能应用保留余地 仔细设计结构中元素的布局与排列顺序，使结构容易理解。 typedef struct STUDENT_STRU unsigned char name

13、8; /* students name */ unsigned char age; /* students age */ unsigned char sex; /* students sex, 0 - FEMALE; 1 - MALE */ unsigned char teacher_name8; /* the student teachers name */ unisgned char teacher_sex; /* his teacher sex */ STUDENT;变量/结构去掉没必要的全局变量 typedef struct函数/过程一个函数仅完成一件功能 函数的功能应该是可以预测的，

14、也就是只要输入数据相同就应产生同样的输出 检查函数所有参数输入的有效性。 检查函数所有非参数输入的有效性，如数据文件、公共变量等。 使用动宾词组为函数命名。如果是OOP方法，可以只有动词（名词是对象本身）。对所调用函数的错误返回码要仔细、全面地处理。 函数的返回值要清楚、明了，考虑不同情况的错误。 防止将函数的参数作为工作变量 防止把没有关联的语句放到一个函数中 避免使用BOOL参数。设计高扇入、合理扇出（小于7）的函数。 对于提供了返回值的函数，在引用时最好使用其返回值 int add_sub( int a, int b, unsigned char add_sub_flg ) if (ad

15、d_sub_flg = INTEGER_ADD) return (a + b); else return (a - b); 函数/过程一个函数仅完成一件功能 int add_sub( 什么是坏木头来源：西乔漫画单元测试什么是坏木头来源：西乔漫画单元测试目录 单元测试概述1代码缺陷模式3代码编程规范4动态单元测试目录 单元测试概述1代码缺陷模式3代码编程规范4动态单质量死角int factor(bool* fsys, int* ptx, int lev)if(sym = ient) /* 因子为标识符 */ getsym; else if(sym = number)/* 因子为无符号整数 */

16、getsym; elseif (sym = lparen) /* 因子为表达式 */ expression(nxtlev, ptx, lev); if (sym = rparen) getsym; else error(22);/* 缺少右括号 */ else error(21) 逻辑关系复杂测试覆盖某需求：主机温度超过30上报 告警至监控台不好测质量死角int factor(bool* fsys, in单元测试过程测试计划测试设计测试实现测试执行测试结果分析测试结束评估缺陷跟踪测试总结新一轮测试回归测试单元测试过程测试计划测试设计测试实现测试执行测试结果分析测试单元测试过程阶段主要内容输出计

17、划确定测试需求，制定测试策略(出入口准则)，确定测试资源，创新测试任务时间表单元测试计划设计设计单元测试模型，制定测试方案，确定并结构化测试过程单元测试方案实现参考单元测试模型和方案，制定具体测试用例，创建可重用的测试脚本单元测试用例自动测试脚本执行根据单元测试模型、方案、用例、脚本对单元测试执行，测试测试结果并记录测试过程中存在缺陷单元测试脚本执行的测试结果集评估对测试测试结果进行评估，主要是需求覆盖和代码覆盖的角度评估测试完备性单元测试报告单元测试过程阶段主要内容输出计划确定测试需求，制定测试策略(Microsoft的单元测试测试从写软件测试规格书(Test Spec)开始Test Spe

18、c必须通过PM，Dev与同组Tester共同开会研究通过测试代码编写由软件开发设计者(SDE)自己开始测试代码主体由软件测试工程师(SDET,STE)编写测试代码根据不同测试的情景分为0-4级的优先级0级测试称为BVT (Build Verification Test)Dev主要功能实现Check-in前，0-1级测试代码必须已由测试工程师完成Dev进行产品代码的Check-in时，0级测试必须100%通过，1级测试必须至少有70%通过Dev进行产品代码的Check-in，Test进行测试代码的Check-in在随后的代码优化与稳定期内，测试工程师编写2-4级测试代码，并报告产品Bug，Dev

19、负责修改Bug，稳定并优化产品Microsoft的单元测试测试从写软件测试规格书(Test华为的单元测试规范要求单元测试要求至少达到语句覆盖 单元测试开始要跟踪每一条语句，并观察数据流及变量的变化 仔细设计并分析测试用例，使测试用例覆盖尽可能多的情况，以提高测试用例的效率 尽可能模拟出程序的各种出错情况，对出错处理代码进行充分的测试 仔细测试代码处理数据、变量的边界情况 测试时应设法使很少发生的事件经常发生 去除代码运行的随机性（如去掉无用的数据、代码及尽可能防止并注意函数中的“内部寄存器”等），让函数运行的结果可预测，并使出现的错误可再现 保留测试信息，以便分析、总结经验及进行更充分的测试华

20、为的单元测试规范要求单元测试要求至少达到语句覆盖 单元测试何时结束单元测试何时结束单元测试什么时候开始？单元测试越早越好!早到什么程度？-XP开发理论讲究TDD（测试驱动开发）。先编写测试代码再进行开发 编写用例(不可运行）编写实现(可运行）重构(优化设计)快速新增一个测试运行所有的测试，发现新增的测试不能通过做一些小小的改动，尽快地让测试程序可运行， 可以在程序中使用一些不合情理的方法运行所有的测试，并且全部通过重构代码，以消除重复设计，优化代码结构TDD开发过程：盖房子的故事。你是先砌墙再拉线，还是先拉线再砌墙呢？单元测试什么时候开始？单元测试越早越好! 编写用例编写实现单元测试什么时候结

21、束？通过单元测试的一般准则:软件单元功能与设计需求一致软件单元接口API与设计一致能够正确处理输入与运行中的错误在单元测试中发现错误已得到修正并通过了测试达到了相关覆盖率的要求完成软件单元测试报告覆盖率！代码逻辑结构覆盖、测试用例覆盖、单元功能覆盖单元测试什么时候结束？通过单元测试的一般准则:单元函数调用特点OpenDoor()Animo()PutElephantIntoIcebox()被调用者被调用者单元函数单元函数不是一个独立可运行的程序，怎么单独测试它？单元函数调用了一个未编写的函数怎么办？【示例】某动画场景：把大象放到冰箱中的故事。抽象CloseDoor()调用者。PutInIceBo

22、x()。单元函数调用特点OpenDoor()Animo()PutEl单元测试模型：驱动和桩驱动模块：被测试模块的上一级调用者，把测试数据传递给被测试单元桩模块：被测试单元需调用的其它函数接口，模拟生成测试数据或状态，为单元运行准备动态环境测试用例和测试结果在测试模型中体现的？桩模块被测试单元桩模块驱动模块测试用例测试结果名词术语单元测试模型：驱动和桩驱动模块：被测试模块的上一级调用者，把单元测试模型：驱动模块示例桩模块被测试单元桩模块驱动模块测试用例测试结果testcase1testcase2testTestpublic void testcase1() assertEquals(hw.Exe

23、rcise_3_6(1,11),11);Testpublic void testcase2() assertEquals(hw.Exercise_3_6(1,-1),0);assertEqualsExercise_3_6()测试用例本身即是驱动模块，直接调用被测试单元通过测试数据不同表现为不同测试用例单元测试模型：驱动模块示例桩模块被测试单元桩模块驱动模块测试单元测试：桩模块示例看一段程序代码：假如你有设置一个定时闹钟，每天早晨6点定时播放起床音乐public abstract Environmental boolean playedWav = false; public abstract l

24、ong getTime(); public abstract void playWavFile(String fileName); public abstract boolean wavWasPlayed(); public abstract void resetWav(); public class SystemEnvironment extends Environmental public long getTime() return System.currentTimeMillis(); public class MockSystemEnvironment extends Environm

25、ental private long currentTime; public long getTime() return currentTime; 单元测试：桩模块示例看一段程序代码：假如你有设置一个定时闹钟单元测试：桩模块示例Mock测试:产品代码所依赖的某些对象，用虚拟对象代替。使用一个接口来描述这个对象 在产品代码中实现这个接口 在测试代码中实现这个接口 在被测试代码中通过接口引用对象 (不知引用的是真实对象还是mock对象)Interface被测试单元桩模块驱动模块测试用例测试结果ClassMockClassEnvironmentalMockSystemEnvironmentSyste

26、mEnvironment单元测试：桩模块示例Mock测试:产品代码所依赖的某些对象，单元测试：用例设计为系统运行起来而设计用例第一个测试用例证明环境和被测单元可用、具备开始测试条件为正向测试而设计用例验证设计文档或函数说明的功能项为逆向测试而设计用例验证被测单元没有做它不应该做的事情为代码覆盖而设计用例为达到特点的测试覆盖目标为满足非功能质量要求而设计用例性能、安全性等，特别是要求高的关键代码单元测试：用例设计为系统运行起来而设计用例单元测试：测试数据正常数据：在测试中所用正常数据量是最大的，也是最关键的。边界数据：是界于正常数据和错误数据之间的一种数据。异常数据：编写与程序输入规范不符的数据，从而验证输入校验、错误处理等程序分支。单元测试：测试数据正常数据：单元测试：覆盖率单元测试用例需考虑达到的覆盖率要求逻辑覆盖：基于语句，基于路径与条件组合功能覆盖：功能点单元测试策略需考虑满足覆盖率基础上减少单元测试工作量给被测单元规划一个良好的测试顺序，尽可能减少测试桩的编写。SUT测试策略：先完成高层被测单元黑盒测试，统计白盒覆盖率，针对未覆盖的逻辑单位再设计测试用例覆盖它。A