单元测试用例课件.ppt

《单元测试用例课件.ppt》由会员分享，可在线阅读，更多相关《单元测试用例课件.ppt（48页珍藏版）》请在三一办公上搜索。

1、,软件测试方法和技术第2版第5章 单元测试,第4章 回顾,4.1 测试过程模型 V模型、W模型、TMap4.2 测试过程改进模型 TMM、TPI、CTP、STEP4.3 软件测试标准和规范4.4 建立软件测试管理和评判体系,第二篇 软件测试的技术,在实际项目的测试过程中，我们会面对许多复杂的问题和具体的困难，不仅要采用前面所学的方法，还要拥有很好的技术，熟悉业务领域知识，深入系统架构、设计模式和开发框架，灵活运用测试工具，才能真正解决问题。,第5章 单元测试第6章 集成测试和系统测试第7章 验收测试第8章 面向对象软件的测试第9章 基于应用服务器的测试第10章 软件本地化测试第11章 软件测试

2、自动化,第五章 单元测试,5.1 什么是单元测试5.2 单元测试的目标和任务5.3 静态测试5.4 驱动程序和桩程序5.5 调试与评估5.6 单元测试的管理5.7 单元测试工具,5.1 什么是单元测试,测试的4个阶段： 单元测试集成测试 系统测试验收测试,按阶段进行测试是一种基本的测试策略,单元测试的定义,定义: 单元测试是对软件基本组成单元进行的测试。时机: 一般在代码完成后由开发人员完成,QA人员辅助.概念: 模块, 组件, 单元,为何要进行单元测试?,尽早发现错误错误发现越早,成本越低.开发人员过于自信,后期复杂度高,发现解决BUG困难.检查代码是否符合设计和规范,举例-单元测试的必要性

3、,假定在开发一个网站程序。将整个程序设计为三层：数据访问层、业务逻辑层和表现层。首先是编写数据访问层，如果没有进行单元测试，那么就得等到业务逻辑层和表现层开发完毕后才能打开页面进行测试。而这中间，业务逻辑层要调用数据访问层，表现层要调用业务逻辑层的代码。如果通过页面发现某个功能没有通过，就需要进行调试，调试时要一步一步地跟踪代码，好不容易找到bug所在了，原来是数据访问的一个方法里出了问题，把该方法改好了，编译不通过！看来还得修改另外两层的代码，好，把代码都改好了，再次打开页面进行测试，糟糕还是没通过。上面的过程再来一次上面这种方式的缺点可以总结为：,为何要进行单元测试?,错误难以定位：每次要

4、打开页面、输入值、调试，单元测试可能也需要这些过程，但其工作量则会小很多。 执行时间长：较之单元测试，上面的方式显然耗时得多。 代码覆盖：可以理解的是，涉及的代码层次越多，就越是难以确定被测代码和测试值之间的关系。我们要覆盖到所有的数据访问层的代码，就要花费很大的精力。 在应用了单元测试后，可以快速定位错误，执行的时间也要短得多，代码覆盖也更容易进行。如果一开始就对数据访问层和业务逻辑层进行了良好的单元测试，那么接下来表现层的开发就顺利得多了，可以编写后面的代码。一旦出了问题，也很容易定位和修改。,单元测试的背景,开发流程时间表与修改Bug代价的关系图,开发结束,开发早期,修改代价,单元测试的

5、背景（续）,编程过程中，每写1000行代码会犯150个错误编程与编译运行结束后，每100行代码中大约残留有1-3个Bug寻找与修改程序错误的代价占总体开发投资的40%-80%Bug在整个研发流程中被发现的越早，修改的代价就越低,5.2 单元测试的目标和任务,目标: 单元模块被正确编码信息能否正确地流入和流出单元；在单元工作过程中，其内部数据能否保持其完整性，包括内部数据的形式、内容及相互关系不发生错误，也包括全局变量在单元中的处理和影响。 在为限制数据加工而设置的边界处，能否正确工作。单元的运行能否做到满足特定的逻辑覆盖。 单元中发生了错误，其中的出错处理措施是否有效。,任务： 模块独立执行通

6、路测试,检查每一条独立执行路径的测试。保证每条语句被至少执行一次。Checklist:误解或用错了运算符优先级。 混合类型运算。变量初值错 。精度不够 。表达式符号错 。 其它,变量初值错-举例,函数说明：当i_flag=0；返回 i_count+100 当i_flag=1；返回 i_count +10 否则 返回 i_count +20输入参数：int i_count ， int i_flag输出参数： int i_return; 代码： 1 int Test(int i_count, int i_flag)2 3 int i_temp = 0;,任务2： 模块局部数据结构测试,检查局部数据

7、结构完整性Checklist: 不适合或不相容的类型说明。 变量无初值。 变量初始化或默认值有错。 不正确的变量名或从来未被使用过。 出现上溢或下溢和地址异常。 其它,任务： 模块接口测试,检查模块接口是否正确，checklist: 输入的实际参数与形式参数是否一致。个数、属性、量纲 调用其他模块的实际参数与被调模块的形参是否一致。个数、属性、量纲 全程变量的定义在各模块是否一致。 外部输入、输出文件、缓冲区、错误处理 其它,任务： 模块边界条件测试,检查临界数据处理的正确性Checklist: 普通合法数据的处理。 普通非法数据的处理。 边界值内合法边界数据的处理。 边界值外非法边界数据的处

8、理。 其它,任务5：模块的各条错误处理通路测试,预见、预设的各种出错处理是否正确有效。Checklist: 输出的出错信息难以理解。 记录的错误与实际不相符。 程序定义的出错处理前系统已介入。 异常处理不当。 未提供足够的定位出错的信息。 其它,对于没有被运行的代码,对于没有被运行到的代码一定要做检查，很可能会从中发现问题，并进而补充遗漏的测试用例。有些函数如分配内存的malloc()等操作一般不会失败，所以它的返回值校验分支中的代码通常不会被执行到；资源释放操作代码没有被运行，比如内存释放、锁的释放、句柄关闭等操作没有被执行到，通常意味着程序中可能有资源泄露。这一类未执行代码一定要小心检查；

9、一些重要的路径没有覆盖到导致有代码未被执行。这时需要补充测试用例。有些代码是死代码，程序永远也执行不到。碰到这种情况时需要将死代码删除，并检查详细设计是否有问题。,如何设计单元测试用例,Class_operation 类标识符：MSGSD003,如何设计单元测试用例,5.3 静态测试技术的运用,静态测试技术： 不运行被测试程序，对代码通过检查、阅读进行分析。三步曲： 走查 （Walk Through）。 审查 （Inspection）。 评审 （Review）,编码的标准和规范,标准：建立起来必须遵守的规则。规范：建议最佳做法，推荐更好方式。实施标准和规范的原因： 可靠性。 可读性和可维护性。

10、 可移植性。,走查 （Walk Through）,定义：采用讲解、讨论和模拟运行的方式进行的查找错误的活动。注意： 引导小组成员在走查前通读设计和编码。 限时，避免跑题。 发现问题适当记录，避免现场修改。 检查要点是代码是否符合标准和规范，是否有逻辑错误。,审查 （Inspection）,定义：采用讲解、提问方式进行，一般有正式的计划、流程和结果。主要方法采用缺陷检查表。注意： 以会议形式，制定会议目标、流程和规则，结束后要编写报告。 按缺陷检查表逐项检查。 发现问题适当记录，避免现场修改。 发现重大缺陷，改正后会议需要重开。 检查要点是缺陷检查表，所以该表要根据项目不同不断积累完善。,走查与

11、审查的比较,评审 （Review）,定义：通常在审查会后进行，审查小组根据记录和报告进行评估。注意： 充分审查了所规定的代码，并且全部编码准则被遵守。 审查中发现的错误已全部修改。,5.4 驱动程序和桩程序,动态测试需要真正将程序运行起来，需要设计系列的测试用例保证测试的完整性和有效性。 白盒测试 黑盒（灰盒）测试,驱动程序和桩程序,运行单元程序有时需要基于被测单元的接口，开发相应的驱动模块和桩模块。 驱动模块（drive）:对底层或子层模块进行测试所编写的调用这些模块的程序。 桩模块（stub）：对顶层或上层模块进行测试时所编写的替代下层模块的程序。,桩函数的概念,BINTREE *BinT

12、ree_Create(void) BINTREE *pBinTree; pBinTree = (BINTREE *) malloc(sizeof(BINTREE); if (pBinTree !=NULL) pBinTree-pRoot=NULL; pBinTree-uNodeCount=0; return pBinTree;桩函数就是替代被测函数而进行测试的函数,使用桩函数进行测试,与malloc()函数的桩函数中，需要模拟出失败返回null的情况，我们写桩函数时，只要设置一个标志变量，在桩函数中直接判断标志变量是否为0，如果为0就返回null,其它情况仍然调用malloc()函数。代码如下

13、：Static INT g_nMallocFlag=1;Void *Stub_malloc(size_t size) if (g_nMallocFlag=0) return NULL; else return malloc(size); 在写测试驱动函数时，对应的测试用例中只要将g_nMallocFlag赋值为0就可以模拟出malloc()函数返回null的情况,使用桩函数进行测试,当测试BinTree_Create()函数时，需要将其中的malloc ()函数用Stub_malloc()函数替换掉，下面便是用桩函数替换后的代码：BINTREE *BinTree_Create(void) BI

14、NTREE *pBinTree; pBinTree = (BINTREE *) Stub_malloc(sizeof(BINTREE); if (pBinTree !=NULL) pBinTree-pRoot=NULL; pBinTree-uNodeCount=0; return pBinTree;,驱动函数,Void DRV_ABS(int nTestNo) UINT uRet; switch (nTestNo) case 1: /参数ab的情况 uRet = ABS(15,10); if (uRet != 5 ) cout“ABS()测试用例2执行失败n”endl; break; defa

15、ult: break; ,5.5 调试与评估,调试与测试的对象及采用的方法有很大程度上的相似，调试还用到断点控制等排错方法，但其目的却完全不同。测试是为了找出软件中存在的缺陷，而调试是为了解决存在的缺陷。 软件单元功能与设计需求一致。 软件单元接口与设计需求一致。 能够正确处理输入和运行中的错误。 在单元测试中发现的错误已经得到修改并且通过了测试。 达到了相关的覆盖率的要求。 完成软件单元测试报告,单元测试该测什么，不该测试什么,理解设计是很重要的，特别是要搞清楚被测试模块在整个软件中所处的位置，这对测试的内容将会有很大的影响。需要记住的一个原则就是：好的设计，各模块只负责完成自己的事情，层次

16、与分工是很明确的。在单元测试的时候，可以不用测试不属于被测试模块所负责的功能，以减少测试用例的冗余，集成测试的时候会有机会测试到的。 举例：1. /*2. 3. * 判断三条边是否能够组成三角形4.5. * 返回值：true-是； false-否,单元测试该测什么，不该测试什么（续）,6.7. */8.9. bool isTriangle(int a, int b, int c); 测试该函数的时候，只需要测试三条边（在合法的取值范围内的整数）是否能够满足两边之和是否大于第三边的功能，而不需要测试三条边是否在合法的范围（0， 200）之间的整数，因为调用该函数之前，一定要先通过下面函数的检查，

17、要是检查不通过，就不会执行isTriangle函数。,单元测试该测什么，不该测试什么（续）,1. /*2.3. * 判断三条边是否合法(即：判断三条边都在合法的范围内)4.5. * 返回值：true-是； false-否6.7. */8.9. bool isLegal(int a, int b, int c);所以，单元测试主要是关注本单元的内部逻辑，而不用关注整个业务的逻辑，因为会有别的模块去完成相关的功能。,单元测试检查表 (1),借助单元测试检查表进行评估。 案例：单元测试检查表单元名称_ 系统 _ 构造_任务编号_ 初次测试日期_关键测试项是否已纠正有无任何输入参数没有使用？有无任何输

18、出参数没有产生？有无任何数据类型不正确或不一致？有无任何算法与PDL或功能需求中的描述不一致？有无任何局部变量使用前没有初始化？有无任何外部接口编码错误？即调用语句、文件存取、 数据库错误。有无任何逻辑路径错误？该单元是否有多个入口或多个正常的出口？,单元测试检查表 (2),额外测试项8.该单元中有任何地方与PDL与PROLOG中的描述不一致？9.代码中有无任何偏离本项目标准的地方？10.代码中有无任何对于用户来说不清楚的错误提示信息？11.如果该单元是设计为可重用的，代码中是有可能妨碍重用的地方？采取的动作和说明（请用单独的一页或多页。每一项动作必须指出所引用的问题。）审查结果1.如果上述1

19、1个问题的答案均为否，那么测试通过，请在此标记并且在最后签名。2.如果代码存在严重的问题，例如多个关键问题的答案为是，那么程序编制者纠正这些错误，并且必须重新安排一次单元测试。下一次单元测试的日期：_3.如果代码存在小的缺陷，那么程序编制者纠正这些错误，并且仲裁者必须安排一次跟踪会议。跟踪会议的日期：_测试人签名：_ 日期：_,5.6 单元测试的管理,过程:在详细设计阶段完成单元测试计划。 建立单元测试环境，完成测试设计和开发。 执行单元测试用例，并且详细记录测试结果。 判定测试用例是否通过。 提交单元测试报告。,单元测试的文档,软件需求规格说明书、软件详细设计说明书 单元测试计划 单元测试计

20、划、软件详细设计说明书 单元测试用例 单元测试用例文档及软件需求规格说明书、软件详细设计说明书 缺陷跟踪报告/缺陷检查表 单元测试用例、缺陷跟踪报告、缺陷检查表 单元测试检查表 评估单元测试报告,5.7 单元测试常用工具简介,JUnit介绍在Eclipse中JUnit应用举例Junit+Ant构建自动的单元测试CheckStyle/PMD与FindBug的使用SourceMonitor检测代码复杂度开源的单元测试工具商业的单元测试工具,5.7 单元测试常用工具简介,JUnit介绍,JUnit是一个开放源代码的Java测试框架，用在编写和运行可重复的的测试上，它是单元测试框架体系xUnit的一个

21、实例，包括如下特性。用于测试期望结果的断言用于共享共同测试数据的测试工具用于方便地组织和运行测试的测试套件Junit的优点可以使测试代码与产品代码分开，这更有利于代码的打包发布和测试代码的管理针对某一个类的测试代码，通地较少的改动便可以应用另一个类的测试，JUnit提供了一个编写测试类的框架，使测试代码的编写更加方便。易于集成到程序中的构建过程中，JUnit和Ant的结合还可以实施增量开发。JUnit的源代码是公开的，故而可以进行二次开发。JUnit具有很强的扩展性，可以方便地对JUnit进行扩展,5.7 单元测试常用工具简介,在Eclipse中JUnit应用举例,5.7 单元测试常用工具简介

22、,Junit+Ant构建自动的单元测试,Ant (Another Neat Tool) 是一种基于Java的build工具。,5.7 单元测试常用工具简介,CheckStyle/PMD与FindBug的使用,5.7 单元测试常用工具简介,SourceMonitor检测代码复杂度,利用SourceMonitor可以为C+、C、C#、Java、Delphi、Visual Basic和HTML的源代码文件测试代码数量和性能。最终结果可以描绘成图、输出打印。众多的实践与经验证明如果一个代码过于复杂那么这个代码出现BUG会成几何级数的上升，并且给后期的维护带来很大的困难，所以用SourceMonitor检查后一方面测试人员可以对代码自身复杂度高，深度嵌套深的类进行有针对性的加强测试，开发人员也应该要考虑重构，对已有方法进行合理的抽取提练与分层。,Q & A,