单元测试必须由最熟悉代码的人（程序的作者）来写。——这是好的单元测试的标准之一。

代码的作者最了解代码的目的、特点和实现的局限性。所以，写单元测试没有比作者更适合的人选了。

问：如果我很忙，能不能让别人代劳做单元测试？

答：如果忙到连单元测试都没有时间做，那么你也没有时间写好这个功能。在一些极限编程的方法中，是可以考虑让别人来做单元测试的，但是，程序的作者还是要对单元测试负责。

好的单元测试还需有以下一系列标准：

单元测试应该在最低的功能/参数上验证程序的正确性。

单元测试应该测试程序中最基本的单元——如在C++/C#/Java中的类，在此基础上，可以测试一些系统中最基本的功能点（这些功能点由几个基本类组成），从面向对象的设计原理出发，系统中最基本的功能点也应该由一个类及其方法来表现。单元测试要测试API中的每一个方法及每一个参数。

单元测试过后，机器状态保持不变。

这样就可以不断地运行单元测试，如果单元测试创建了临时的文件或目录，应该在Teardown阶段把这些临时的文件或目录删除。

如果单元测试在数据库中创建或修改了记录，那么也许要删除这些记录，或者每一个单元测试使用一个新的数据库，这样可以保证单元测试不受以前单元测试实例的干扰。

单元测试要快（一个测试运行时间是几秒钟，而不是几分钟）。

快，才能保证效率。因为一个软件中有几十个基本模块（类），每个模块又有几个方法，基本上我们要求一个类的测试要在几秒钟内完成。如果软件有相互独立的几个层次，那么在测试组中可以分类，如数据库层次、网络通信层次、客户逻辑层次和用户界面层次，可以分类运行测试，比如只修改了“用户界面”的代码，则只需运行“用户界面”的单元测试。

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

如果单元测试的结果是错的，那一定是程序出了问题，而且这个错误一定是可以重复的。

问：如果用随机数以增加测试的真实性，好么？

答：一般情况下不好，如果某个随机数导致程序出错，但是下一次运行又不能重复这一错误，于事无补。要注意我们还是要用随机数等办法“增加测试的真实性”，但是不是在单元测试中。单元测试不能解决所有问题，所以也不必期望它会发现所有的缺陷。

独立性，单元测试的运行/通过/失败不依赖于别的测试，可以人为构造数据，以保持单元测试的独立性。

程序中的各个模块都是互相依赖的，否则它们就不会出现在一个程序中。一般情况下，单元测试中的模块可以直接引用其他的模块，并期待其他的模块能返回正确的结果。

如果其他的模块很不稳定，或者其他模块运行比较费时（如进行网络操作），而且对于本模块的正确性并不起关键的作用，这时可以人为地构造数据以保证这个单元测试的独立性。

单元测试应该覆盖所有代码路径，包括错误处理路径，为了保证单元测试的代码覆盖率，单元测试必须测试公开的和私有的函数/方法。

单元测试必须覆盖所测单元的所有代码路径。

问：啊！这样岂不是要写很多啰里啰唆的测试方法？

答：对，因为程序中很多缺陷都是从这些啰里啰唆的错误处理中产生的。如果你的模块中某个错误处理路径很难到达，那你也许要想想是否可以把这个错误处理拿掉。

大栓：这对于那些爱写复杂代码的人是一个很好的惩罚，不对，是一个很好的锻炼。

阿超：对，把单元测试的责任和代码作者绑定在一起后，代码作者就能更真切地体会到复杂代码的副作用，因为验证复杂代码的正确性要困难得多。要注意的一点是：100%的代码覆盖率并不等同于100%的正确性。在下面的情况下，100% 的覆盖率和100% 的正确性不是同一回事:

a) 代码中并没有处理错误情况。 例如代码打开了文件，但是并没有处理一些异常情况，例如文件不存在，权限有问题，等等

b) 代码中有效能问题，虽然代码执行了，并且也正确地返回了。但是代码执行得也许非常慢。

c) 多线程环境中的同步问题, 这个问题和本地代码执行与否关系不大。

d) 其它和外部条件相关的问题 (例如和设备相关，和网络相关的问题)

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

另一个重要的措施是要把单元测试自动化，这样每个人都能很容易地运行它，并且可以使单元测试每天都运行。每个人都可以随时在自己的机器上运行。团队一般是在每日构建中运行单元测试的，这样每个单元测试的错误就能及时被发现并得到修改。

单元测试必须和产品代码一起保存和维护。

单元测试必须和代码一起进行版本维护。如果不是这样，过了一阵，代码和单元测试就会出现不一致，而且所有代码的作者要花时间来确认哪些是程序出现的错误，哪些是由于单元测试更新滞后造成的错误。这样就失去了单元测试的意义，同时又给大家增加了负担。如此折腾多次以后，大家就会觉得维护单元测试是一件很费时费力的事。

很多开发人员有这样那样的借口不去提高单元测试的覆盖率, 其中一个就是: 这一部分代码永远测不到! 请看 MSDN 的视频讲解:

以上关于单元测试的内容，摘自我在里重点推荐的好书：。

JUnit的好处和JUnit单元测试编写原则：好处：可以使测试代码与产品代码分开；针对某一个类的测试代码通过较少的改动便可以应用于另一个类的测试；易于集成到测试人员的构建过程中，JUnit和Ant的结合可以实施增量开发；JUnit是公开源代码的，可以进行二次开发；可以方便地对JUnit进行扩展；编写原则：是简化测试的编写，这种简化包括测试框架的学习和实际测试单元的编写；是使测试单元保持持久性；是可以利用既有的测试来编写相关的测试；JUnit使用帮助1、junit3.x版本，我们通常使用junit3.8(1)、使用junit3.x版本进行单元测试时，测试类必须要继承于TestCase父类；(2)、测试方法需要遵循的原则：A、public的B、void的C、无方法参数D、方法名称必须以test开头(3)、不同的TestCase之间一定要保持完全的独立性，不能有任何的关联

《开发人员单元测试规范》由会员分享，可在线阅读，更多相关《开发人员单元测试规范（11页珍藏版）》请在人人文库网上搜索。

1、为了提高整个开发中心产品和项目的测试效率，保证产品与项目内部系统集成测试的顺利进行，现要求系统开发部各项目组在提交产品至项目监理部之前必须进行严格的单元测试，即按照代码的单元组成逐个进行测试。具体说明如下：单元测试内容单元测试的依据是详细设计，应对模块内所有重要的控制路径设计测试用例，以便发现模块内部的错误。单元测试的测试类型主要包括：1模块接口测试；2模块局部数据结构测试；3模块边界条件测试；4模块中所有独立执行通路测试；5模块的各条错误处理通路测试；6模块的非法测试，例如在输入数字的地方输入字母；7代码重用测试，在开发过程中有些模块功能几乎相同，程序员在重用代码时可能忘记在原有代码上修改或

2、修改不全面，而造成的错误；8系统兼容测试，例如有些程序在IE6能运行正常，到IE5下不能运行。有些程序在WIN2000下能运行，而到WIN98却不能运行。单元测试力度要求测试力度满足：语句覆盖：使被测程序的每条语句至少执行一次；判定覆盖：使被测程序的每一分支执行一次；条件覆盖：要求判定中的每个条件均为“真”、“假”两种结果至少执行一次；条件组合覆盖：让条件覆盖中的结果的所有可能组合至少出现一次；单元测试步骤一般认为单元测试应紧接在编码之后，当源程序编制完成并通过复审和编译检查，便可开始单元测试。测试用例的设计应与复审工作相结合，根据设计信息选取测试数据，将增大发现各类错误的可能性。在确定测试用

3、例的同时，应给出期望结果。项目组完成单元测试，向项目监理部提交验收版本的同时必须一并递交单元测试案例及测试问题报告记录。测试部由项目监理部取得需测试系统的版本及相关文档，若在测试期间发现单元测试中记录的问题，如实记录。项目监理部视具体情况酌情对该项目组的绩效考核与项目评分加以控制。不同语言及架构的单元测试见附件。附件一c语言单元测试规范1.基本要求1.1程序结构清析，简单易懂，单个函数的程序行数不得超过100行。1.2打算干什么，要简单，直接了当，代码精简，避免垃圾程序。1.3尽量使用标准库函数和公共函数。1.4不要随意定义全局变量，尽量使用局部变量。1.5使用括号以避免二义性。2.可读性要求

4、2.1可读性第一，效率第二。2.2保持注释与代码完全一致。2.3每个源程序文件，都有文件头说明，说明规格见规范。2.4每个函数，都有函数头说明，说明规格见规范。2.5主要变量（结构、联合、类或对象）定义或引用时，注释能反映其含义。2.7常量定义（DEFINE）有相应说明。2.8处理过程的每个阶段都有相关注释说明。2.9在典型算法前都有注释。2.10利用缩进来显示程序的逻辑结构，缩进量一致并以Tab键为单位，定义Tab为6个字节。2.11循环、分支层次不要超过五层。2.12注释可以与语句在同一行，也可以在上行。2.13空行和空白字符也是一种特殊注释。请预览后下载！2.14一目了然的语句不加注释。

5、2.15注释的作用范围可以为：定义、引用、条件分支以及一段代码。2.16注释行数（不包括程序头和函数头说明部份）应占总行数的1/5到1/3。3.结构化要求3.1禁止出现两条等价的支路。3.2禁止GOTO语句。3.3用IF语句来强调只执行两组语句中的一组。禁止ELSEGOTO和ELSERETURN。3.4用CASE实现多路分支。3.5避免从循环引出多个出口。3.6函数只有一个出口。3.7不使用条件赋值语句。3.8避免不必要的分支。3.9不要轻易用条件分支去替换逻辑表达式。4.正确性与容错性要求4.1程序首先是正确，其次是优美4.2无法证明你的程序没有错误，因此在编写完一段程序后，应先回头检查。4

6、.3改一个错误时可能产生新的错误，因此在修改前首先考虑对其它程序的影响。4.4所有变量在调用前必须被初始化。4.5对所有的用户输入，必须进行合法性检查。4.6不要比较浮点数的相等，如：10.0*0.1=1.0，不可靠4.7程序与环境或状态发生关系时，必须主动去处理发生的意外事件，如文件能否逻辑锁定、打印机是否联机等。4.8单元测试也是编程的一部份，提交联调测试的程序必须通过单元测试。5.可重用性要求5.1重复使用的完成相对独立功能的算法或代码应抽象为公共控件或类。5.2公共控件或类应考虑OO思想，减少外界联系，考虑独立性或封装性。5.3公共控件或类应建立使用模板。1适用范围本标准适用于利用Vi

9、部变量中可采用如下几个通用变量：nTemp，nResult，I，J（一般用于循环变量）。其他资源句柄同上.3常量命名和宏定义常量和宏定义必须具有一定的实际意义;常量和宏定义在#include和函数定义之间;常量和宏定义必须全部以大写字母来撰写,中间可根据意义的连续性用下划线连接,每一条定义的右侧必须有一简单的注释,说明其作用;资源名字定义格式:菜单:IDM_XX或者CM_XX位图:IDB_XX对话框:IDD_XX字符串:IDS_XXDLGINIT:DIALOG_XXICON:IDR_XX.4函数命名函数原型说明包括引用外来函数及内部函数，外部引用必须在右侧注明函数来源：模块名及文件名,如是内部

12、：用小写前缀表示类别用小写前缀表示类别：fm窗口cmd按钮cobcombo，下拉式列表框txt文本输入框lablabal，标签imgimage，图象picpicturegrdGrid，网格scr滚动条lst列表框frmfram7注释原则上注释要求使用中文;文件开始注释内容包括:公司名称、版权、作者名称、时间、模块用途、背景介绍等,复杂的算法需要加上流程说明;函数注释包括:输入、输出、函数描述、流程处理、全局变量、调用样例等,复杂的函数需要加上变量用途说明;程序中注释包括:修改时间和作者、方便理解的注释等;引用一:文件开头的注释模板/*文件名:*Copyright(c)*公司技

13、术开发部*创建人:*日期:*修改人:*日期:*描述:*版本:*-请预览后下载！*/引用二:函数开头的注释模板/*函数名:*输入:a,b,c*a-*b-*c-*输出:x-*x为1,表示.*x为0,表示.*功能描述:*全局变量:*调用模块:*作者:*日期:*修改:*日期:*版本*/引用三:程序中的注释模板/*-*/*注释内容*/*-*/8程序a.程序编码力求简洁，结构清晰，避免太多的分支结构及太过于技巧性的程序，尽量不采用递归模式。b.编写程序时，亦必须想好测试的方法，换句话说，”单元测试”的测试方案应在程序编写时一并拟好。c.注释一定要与程序一致。d.版本封存以后的修改一定要将老语句用/*/封闭

16、件名(FileName)；b.创建人(Creater)；c.文件创建时间(Date)；d.简短说明文件功能、用途(Comment)。好习惯2.除非极其简单，否则对函数应有注释说明。内容包括：功能、入口/出口参数，必要时还可有备注或补充说明。还是好习惯3.每列代码的长度推荐为80列，最长不得超过120列；折行以对齐为准。太宽了，我的限制是60列，因为文本方式下屏幕一共80列，如果你用BC这一类的编辑器，窗口边框等又要占据一定空间，所以80列太宽4.循环、分支代码，判断条件与执行代码不得在同一行上。很对5.指针的定义，*号既可以紧接类型，也可以在变量名之前。例：可写做：int*pnsize;也可写

17、做：int*pnsize;请预览后下载！但不得写做：int*pnsize;建议采用第二种，除非附加另外一条规定：一次只声明一个变量，否则就会让人混淆，比如：int*a,b;看起来b好像也是个指针，其实不是。6.在类的成员函数内调用非成员函数时，在非成员函数名前必须加上:。这一条我倒觉得并不是必需的，我的看法是决不要让你的类成员函数和全局函数的名称相同（或类似）7.函数入口参数有缺省值时，应注释说明。例：BOOLCWpsDib:PaintDIB(CDC*pDC,CRect&rc,intnBrightness,file:/*=0*/BOOLbGrayScalefile:/*=FALSE*/)每个变

18、量写一行，必要时加上/*in,out*/注释8.elseif必须写在一行。应该尽量避免elseif这样的结构9.与、有关的各项规定：9.1、应独占一行。在该行内可有注释。9.2必须另起一行，之后的代码必须缩进一个Tab。与必须在同一列上。9.3在循环、分支之后若只有一行代码，虽然可省略、，但不推荐这么做。若省略后可能引起歧义，则必须加上、。持保留意见，因为GNU的代码规范是这样的：if(NULL=ptr)/dosomethinghere或者if(NULL=ptr)/dosomethinghere争论哪个更好并没有意义，关键是统一，如果用VC当然你的办法最方便，可是如果你用emacs或者vi，就

19、不是这样了。10.与空格有关的各项规定。10.1在所有两目、三目运算符的两边都必须有空格。在单目运算符两端不必空格。但在、:、.、等运算符前后，及&（取地址）、*（取值）等运算符之后不得有空格。10.2for、while、if等关键词之后应有1个空格，再接(，之后无空格；在结尾的)前不得有空格。我认为在括号两端加空格并不是什么错误，尤其是在一个条件十分复杂的if语句里10.3调用函数、宏时，(、)前后不得有空格。10.4类型强制转换时，()前后不得有空格同上11.与缩进有关的各项规定11.1缩进以Tab为单位。1个Tab为4个空格我认为这个值应该更大，我自己使用8个空格，如果你的代码因为缩进幅

20、度太大而导致折行，那么几乎可以肯定你的程序设计方案有问题。11.2下列情况，代码缩进一个Tab:1.函数体相对函数名及、。2.if、else、for、while、do等之后的代码。3.一行之内写不下，折行之后的代码，应在合理的位置进行折行。若有+-*/等运算符，则运算符应在上一行末尾，而不应在下一行的行首。这一条我反对，运算符应该放在下一行行首，以使人能清楚的知道这一行是续上一行的，比如if(something&somethingelse&otherthings)如果写做if(something&somethingelse&otherthings)反而看不清楚请预览后下载！11.3下列情况，不

21、必缩进：switch之后的case、default。附件二java语言单元测试规范java语言的编程规范遵照公司的开发规范。1.基本要求1.1程序结构清析，简单易懂，单个函数的程序行数不得超过100行。1.2代码精简，避免垃圾程序。1.3尽量使用标准库函数和公共函数。1.4不要随意定义全局变量，尽量使用局部变量。1.5使用括号以避免二义性。2.可读性要求2.1可读性第一，效率第二。2.2保持注释与代码完全一致。2.3每个源程序文件，都有文件头说明，说明规格见规范。2.4每个函数，都有函数头说明，说明规格见规范。2.5主要变量（结构、联合、类或对象）定义或引用时，注释能反映其含义。2.7常量定义

22、（DEFINE）有相应说明。2.8处理过程的每个阶段都有相关注释说明。2.9在典型算法前都有注释。2.10利用缩进来显示程序的逻辑结构，缩进量一致并以Tab键为单位，定义Tab为6个字节。2.11循环、分支层次不要超过五层。2.12注释可以与语句在同一行，也可以在上行。2.13空行和空白字符也是一种特殊注释。2.14一目了然的语句不加注释。2.15注释的作用范围可以为：定义、引用、条件分支以及一段代码。2.16注释行数（不包括程序头和函数头说明部份）应占总行数的1/5到1/3。3.结构化要求3.1禁止出现两条等价的支路。3.2禁止GOTO语句。3.3用IF语句来强调只执行两组语句中的一组。禁止

23、ELSEGOTO和ELSERETURN。3.4用CASE实现多路分支。3.5避免从循环引出多个出口。3.6函数只有一个出口。3.7不使用条件赋值语句。3.8避免不必要的分支。3.9不要轻易用条件分支去替换逻辑表达式。4.正确性与容错性要求4.1程序首先是正确，其次是优美4.2无法证明你的程序没有错误，因此在编写完一段程序后，应先回头检查。4.3改一个错误时可能产生新的错误，因此在修改前首先考虑对其它程序的影响。4.4所有变量在调用前必须被初始化。4.5对所有的用户输入，必须进行合法性检查。4.6不要比较浮点数的相等，如：10.0*0.1=1.0，不可靠4.7程序与环境或状态发生关系时，必须主动

24、去处理发生的意外事件，如文件能否逻辑锁定、打印机是否联机等。4.8单元测试也是编程的一部份，提交联调测试的程序必须通过单元测试。5.可重用性要求5.1重复使用的完成相对独立功能的算法或代码应抽象为公共控件或类。5.2公共控件或类应考虑OO思想，减少外界联系，考虑独立性或封装性。5.3公共控件或类应建立使用模板。命名规范定义这个规范的目的是让项目中所有的文档都看起来像一个人写的，增加可读性，减少项目组中因为换人而带来的损失。（这些规范并不是一定要绝对遵守，但是一定要让程序有良好的可读性）请预览后下载！Package的命名Package的名字应该都是由一个小写单词组成。Class的命名Class的

25、名字必须由大写字母开头而其他字母都小写的单词组成Class变量的命名变量的名字必须用一个小写字母开头。后面的单词用大写字母开头。StaticFinal变量的命名StaticFinal变量的名字应该都大写，并且指出完整含义。参数的命名参数的名字必须和变量的命名规范一致。数组的命名数组应该总是用下面的方式来命名：bytebuffer;而不是：bytebuffer;方法的参数使用有意义的参数命名，如果可能的话，使用和要赋值的字段一样的名字：SetCounter(intsize)this.size=size;Java文件样式所有的Java(*.java)文件都必须遵守如下的样式规则版权信息版权信息必须

33、空格.下面的例子说明括号和空格的错误及正确使用:CallProc(Aparameter);/错误CallProc(Aparameter);/正确不要在语句中使用无意义的括号.括号只应该为达到某种目的而出现在源代码中。下面的例子说明错误和正确的用法:if(I)=42)/错误-括号毫无意义if(I=42)or(J=42)then/正确-的确需要括号程序编写规范exit()exit除了在main中可以被调用外，其他的地方不应该调用。因为这样做不给任何代码代码机会来截获退出。一个类似后台服务地程序不应该因为某一个库模块决定了要退出就退出。异常申明的错误应该抛出一个RuntimeException或者派

34、生的异常。顶层的main()函数应该截获所有的异常，并且打印（或者记录在日志中）在屏幕上。垃圾收集JAVA使用成熟的后台垃圾收集技术来代替引用计数。但是这样会导致一个问题：你必须在使用完对象的实例以后进行清场工作。比如一个prel的程序员可能这么写：FileOutputStreamfos=newFileOutputStream(projectFile);project.save(fos,IDEProjectFile);除非输出流一出作用域就关闭，非引用计数的程序语言，比如JAVA，是不能自动完成变量的清场工作的。必须象下面一样写：FileOutputStreamfos=newFileOutpu

（注：可编辑下载，若有不当之处，请指正，谢谢!） 请预览后下载！