《构建之法》-----单元测试

一、重要性

测试常常是程序员十分厌倦的一个活动。测试能给我们带来什么?了解这些是非常重要的,测试不可能保证一个程序是完全正确的,但是测试却可以增强我们对程序完整的信心,测试可以让我们相信程序做了我么期望它做的事情。测试能够使我们尽早的发现程序的 bug 和不足。

  一个 bug 被隐藏的时间越长,修复这个 bug 的代价就越大。在《快速软件开发》一书中已引用了大量的研究数据指出:最后才修改一个 bug 的代价是在 bug 产生时修改它的代价的10倍。

  当然,我们主要讨论的是单元测试。单元测试是一个方法层面上的测试,也是最细粒度的测试。用于测试一个类的每一个方法都已经满足了方法的功能要求。在开发中,对于自己开发的模块,只有在通过单元测试之后,才能提交到 SVN 库 或者 Git 库。

通常合格的代码应该具备以下性质:正确性、清晰性、规范性、一致性、高效性等(根据优先级别排序)。

  1. 正确性是指代码逻辑必须正确,能够实现预期的功能。

  2. 清晰性是指代码必须简明、易懂,注释准确没有歧义

  3. 规范性是指代码必须符合企业或部门所定义的共同规范包括命名规则,代码风格等等。

  4. 一致性是指代码必须在命名上(如:相同功能的变量尽量采用相同的标示符)、风格上都保持统一。

  5. 高效性是指代码不但要满足以上性质,而且需要尽可能降低代码的执行时间

二、单元测试步骤 

  在代码编写完成后的单元测试工作主要分为两个步骤人工静态检查动态执行跟踪

  人工静态检查是测试的第一步,这个阶段工作主要是保证代码算法的逻辑正确性(尽量通过人工检查发现代码的逻辑错误)、清晰性规范性一致性算法高效性。并尽可能的发现程序中没有发现的错误。

  第二步是通过设计测试用例,执行待测程序来跟踪比较实际结果与预期结果来发现错误。经验表明,使用人工静态检查法能够有效的发现30%到70%的逻辑设计和编码错误。但是代码中仍会有大量的隐性错误无法通过视觉检查发现,必须通过跟踪调试法细心分析才能够捕捉到。所以,动态跟踪调试方法也成了单元测试的重点与难点。

  人工静态检查步骤

  通常在人工检查阶段必须执行以下项目的活动:

  第一、 检查算法的逻辑正确性;确定所编写的代码算法、数据结构定义(如:队列、堆栈等)是否实现了模块或方法所要求的功能。

  第二、 模块接口的正确性检查;确定形式参数个数、数据类型、顺序是否正确;确定返回值类型及返回值的正确性。

  第三、 输入参数有没有作正确性检查;如果没有作正确性检查,确定该参数是否的确无需做参数正确性检查,否则请添加上参数的正确性检查。经验表明,缺少参数正确性检查的代码是造成软件系统不稳定的主要原因之一。

  第四、 调用其他方法接口的正确性;检查实参类型正确与否、传入的参数值正确与否、个数正确与否,特别是具有多态的方法。返回值正确与否,有没有误解返回值所表示 的意思。最好对每个被调用的方法的返回值用显湿代码作正确性检查,如果被调用方法出现异常或错误程序应该给予反馈,并添加适当的出错处理代码。

  第五、 出错处理;模块代码要求能预见出错的条件,并设置适当的出错处理,以便在一旦程序出错时,能对出错程序重做安排,保证其逻辑的正确性,这种出错处理应当是 模块功能的一部分。若出现下列情况之一,则表明模块的错误处理功能包含有错误或缺陷:出错的描述难以理解;出错的描述不足以对错误定位,不足以确定出错的 原因;显示的错误信息与实际的错误原因不符;对错误条件的处理不正确;在对错误进行处理之前,错误条件已经引起系统的干预等。

  第六、 保证表达式、SQL语句的正确性;检查所编写的SQL语句的语法、逻辑的正确性。对表达式应该保证不含二义性,对于容易产生歧义的表达式或运算符优先级 (如:《 、=、 》、 &&、||、++、 --等)可以采用扩号“()”运算符避免二义性,这样一方面能够保证代码的正确可靠,同时也能够提高代码的可读性。

  第七、 检查常量或全局变量使用的正确性;确定所使用的常量或全局变量的取值和数值、数据类型;保证常量每次引用同它的取值、数值和类型的一致性。

  第八、 表示符定义的规范一致性;保证变量命名能够见名知意,并且简洁但不宜过长或过短、规范、容易记忆、最好能够拼读。并尽量保证用相同的表示符代表相同功能,不要将不同的功能用相同的表示符表示;更不要用相同的表示符代表不同的功能意义。

  第九、 程序风格的一致性、规范性;代码必须能保证符合企业规范,保证所有成员的代码风格一致、规范、工整。例如对数组做循环,不要一会儿采用下标变量从下到上的 方式(如:for(I=0;I++;I<10)),一会儿又采用从上到下的方式(如:for(I=10;I--;I>0));应该尽量采用统 一的方式,或则统一从下到上,或则统一从上到下。建议采用for循环和While循环,不要采用do{}while循环等。

  第十、 检查程序中使用到的神秘数字是否采用了表示符定义。神秘的数字包括各种常数、数组的大小、字符位置、变换因子以及程序中出现的其他以文字形式写出的数值。 在程序源代码里,一个具有原本形式的数对其本身的重要性或作用没提供任何指示性信息,它们也导致程序难以理解和修改。对于这类神秘数字必须采用相应的标量 来表示;如果该数字在整个系统中都可能使用到务必将它定义为全局常量;如果该神秘数字在一个类中使用可将其定义为类的属性(Attribute),如果该 神秘数字只在一个方法中出现务必将其定义为局部变量或常量。

  第十一、 检查代码是否可以优化、算法效率是否最高。如:SQL语句是否可以优化,是否可以用1条SQL语句代替程序中的多条SQL语句的功能,循环是否必要,循环中的语句是否可以抽出到循环之外等。

  第十二、 检查您的程序是否清晰简洁容易理解。注意:冗长的程序并不一定不是清晰的。

  第十三、 检查方法内部注释是否完整;是否清晰简洁;是否正确的反映了代码的功能,错误的注释比没有注释更糟;是否做了多余的注释;对于简单的一看就懂的代码没有必要注释。

  第十四、 检查注释文档是否完整;对包、类、属性、方法功能、参数、返回值的注释是否正确且容易理解;是否会落了或多了某个参数的注释,参数类型是否正确,参数的限 定值是否正确。特别是对于形式参数与返回值中关于神秘数值的注释,如:类型参数 应该指出 1.代表什么,2.代表什么,3.代表什么等。对于返回结果集(Result Set)的注释,应该注释结果集中包含那些字段及字段类型、字段顺序等。

  动态执行跟踪

  对于单元测试来说,由于测试的目的主要是测试内部功能的准确性,因此应该采用白盒测试法对每个模块的内部作跟踪检查测试。

  动态测试的主要步骤:

  1、设置数据,主要是为了满足单元模块运行所需要的输入条件;

  2、使用被测试类型的功能,可以设计一个测试类(驱动模块(driver))来调用测试模块,并且设计测试模块所需要调用的模块(桩模块(stub));

  3、比较实际结果与预期结果,评估模块的功能是否达到设计要求。

三、好的单元测试标准

1、单元测试应该在最基本的功能/参数上验证程序的正确性

  单元测试应该测试程序中最基本的单元——如c++/c#/Java中的类,在此基础之上测试一些系统中最基本的功能点(这些功能点有几个基本类组成)。单元测试要测试API中每一个方法及参数。

2、单元测试由程序作者来写

3、测试之后,机器状态赢保持不变

  为了保证单元测试不收之前单元测试实例的干扰,测试过程中产生的临时数据或文件等记录应删除或每个单元测试使用单独的文件以防止相互干扰。

4、单元测试应该产生可重复、一致的结果

  对于测试过程中产生的错误应该是可以重复的。

5、单元测试的运行/通过/失败不依赖于别的测试,可以认为构造数据,以保存单元测试的独立性

  如果其他模块很不稳定或者运行比较费时,而且对本模块的正确性不起关键作用,可以人为构造数据,以保证单元测试的独立性。

6、单元测试应该覆盖所有代码路径

  为了保证代码覆盖率,单元测试必须测试公开的和私有的函数/方法。

7、单元测试应该集成到自动测试的框架中

8、单元测试必须与昌平代码一起保存和维护

  如果单元测试与代码不是一起进行版本维护的话,就会出现代码与单元测试不一致的现象,当测试出现错误时,就无法确定是由于程序的错误还是单元测试之后造成的错误。

参考:

谈谈单元测试之(一):为什么要进行烦人的单元测试? - 紫羽风的博客 - 博客频道 - CSDN.NET http://blog.csdn.net/happylee6688/article/details/37962283

如何进行单元测试_软件学园_科技时代_新浪网http://tech.sina.com.cn/s/2009-07-20/1529991506.shtml

代码覆盖率浅谈 - CoderZh - 博客园 http://www.cnblogs.com/coderzh/archive/2009/03/29/1424344.html

时间: 2024-11-07 10:46:07

《构建之法》-----单元测试的相关文章

构建之法--第二篇

构建之法--第二章 在这一周中,我计划学习了<构建之法>的第二章,我认为从第二章开始,才算真正进入到了这本书的主题.这一章讲到的是个人技术和流程.首先,个人技术是衡量你是否能成为一名合格的软件工程师.而想要组建一个优秀的软件开发团队,就必须要有一名软件工程师.流程则是团队来管理开发活动的经过. 个人技术:其中就包括了三点,即单元测试.回归测试.效能分析. 单元测试:我们为什么需要做单元测试呢?这是为了让自己负责的模块功能定义尽量明确,模块内部的改变不会影响其他模块,而且模块的质量能得到稳定的.

《构建之法》读书笔记二

这周读了<构建之法>的第二章.第二章主要讲到了个人技术和流程. 软件是由多人合作完成的,不同人员的工作相互有依赖关系.一个团队需要一定的流程来管理开发活动,每个工程师在软件生命周期所做的工作也应该有一个流程.所以就引进了一个新的名词叫做PSP--个人软件开发流程.但是要做到每个人的模块的质量得到稳定.量化的保证,单元测试就是一个很有效的解决方案.我们可以用vsts写单元测试,这是一个新的软件,我从来没有接触过,所以也不会用.只看了一下代码. 好的单元测试应该准确.快速地保证程序基本模块的正确性

构建之法现代软件工程(第二次)

构建之法现代软件工程(第二次) 单元测试是什么? 单元测试是为了让各个模块的质量能得到稳定的,量化的保证的一种有效解决方案.(VSTS) 好的单元测试的标准是什么? 1.单元测试应该在最基本的功能/参数上验证程序的正确性 2.单元测试必须由最熟悉代码的人(程序的作者)来写 3.单元测试过后,机器状态保持不变 4.单元测试要快 5.单元测试应该产生可重复,一致的结果. 6.独立性--单元测试的运行/通过/失败不依赖于别的测试,可以人为构造数据,以保持单元测试的独立性. 7.单元测试应该覆盖所有代码

《构建之法》的第一、二章学习

<构建之法>的第一章,这一章介绍了软件工程与计算机科学的关系.软件的特性,还向我们详细介绍了软件工程的定义与组成部分. 在第一节当中,本书为我们介绍了软件的生命周期,包括构建管理.源代码管理.软件设计和测试.项目管理等等.在这一节当中,我们要记住三个推论:程序=数据结构+算法.软件=程序+软件工程.软件企业=软件+商业模式.第二节围绕"软件是什么"展开话题,为我们讲解了软件的特殊性.软件工程与计算机科学的关系.软件工程的知识领域和目标. 在第二章当中,<构建之法>

关于 《构建之法》

1.关于<构建之法>: 看了第一章,关于<构建之法>的概述,通过一定的软件流程,在预计的时间内发布好的软件,软件工程对于开发一个好的软件很重要,在开发中,程序很重要,软件开发流程也很重要. 软件具有:复杂性,不可见性,易变性,服从性,非连续性.还有其他特性. 软件工程的目标:创造“足够好”的软件. 构建之法的目标: 研发出符合用户需求的软件: 通过一定的软件流程,在预计的时间内发布“足够好”的软件: 能证明所开发的软件是可以维护和继续发展的. 可行性分析->项目立项->

构建之法——读后感

好吧,其实一开始在课上接触到这本书的时候还是略有点抵触,毕竟不是通过自己“即可寻求”得来的资源,但是看着看着,慢慢也就好了. 在我感性认识上的构建之法,其内容不同于其他的“类教材”书本,甚至都不同于我之前阅读过的所有书(好吧,也不排除我认知局限性因素的干扰),构建之法的叙述方式相对于“书本”来说,更像是以写博客的感觉在写书,让读者有一种仿佛在杂志上阅读博客的享受. 对于计算机相关专业的学生来说,我们学习了很多的专业课程,像编程语言.算法.数据结构.编译原理.软件工程等.很多学生都会有这样的疑问:

《构建之法》读后感

<构建之法>给我的第一映像是“终于有一本我可以看的下去的关于软件的书了╥﹏╥...”.<构建之法>与其他的软件工程的书不同,没有密密麻麻的字,没有晦涩难懂的词汇,没有让人看不下去的感受.邹欣老师用一种特殊的方式告诉我什么是软件工程. <构建之法>最大的特点是那些虚拟人物的对话,他们之间的对话就是现实中许多工程师在工作中会遇到的问题.在书中邹欣老师通过阿超.国栋.小飞.小李等虚拟人物的对话以及他们答辩.讨论形象生动得说出了工程师们在遇到问题时的困惑,以及思维方式,并对他们

《构建之法——现代软件工程》

在读完邹欣老师的<构建之法——现代软件工程>后颇有感想,这本书的厉害之处是把软件的开发方法写的十分的清晰.有趣,将每一章的理论和知识点进行了归纳,举例说明,故事与企业相结合相联系,让我们进行了一次头脑风暴.在每一章要点中有重点字眼的加黑,图文搭配更加的生动形象,在阅读完代码.文字之后的图片不禁让人会心一笑.它结合了作者自身的开发经验,书中创造了一个虚拟环境,通过人物的对话和活动,讲述不同人物在软件工程中等不同角色和作用,展现出了软件工程这么学科,文中的代码有很强的实用性,更容易让人接受,让人有

第五次作业 关于《构建之法》的心得体会

阅读了邹欣老师的<构建之法>这本书,我感受颇多.上个学期在学习软件工程的课程的时候,并没有很大的学习兴趣.但是读了这本书,我完全有了新的感受.以下是我的学习心得. 阅读这本书使我对下面个人技术和流程.分析了软件工程师的成长.软件团队合作的几种模式和开发流程.敏捷流程.需求分析.项目经理.用户体验.软件测试.质量保障这些概念有了更深刻的理解. 我了解到了创建单元测试的主要步骤以及好的单元测试的标准是什么.还有团队的力量是无穷的,这让我懂得了我们应该增强团队合作意识,这样很多时候会事倍功半.通过阅

观《构建之法》有感

大学这三年,说实话很少去真正看一遍书,最近老师要求老师要求写个构建之法的读后感,本想是应付下任务.不过,在我阅读了十几页之后,渐渐对这本书产生了兴趣,特别是里面的讲解例子让我更加枯燥的软件书籍第一次有了改观.虽然本人学的是软件工程专业,但是说来惭愧,对于学习了三年的软件工程,软件工程这四个字的含义,我自己却也没能其真正理解.别人问我什么是软件工程专业,我只会通俗的解释就是设计软件的,敲代码,做程序的.阅读了构建之法后,我对软件工程及软件有更专业的认识,软件工程+程序=软件.而软件工程是把系统的,