单元测试方法范例，单元测试

单元测试方法范例篇1

　　功能测试主要通过单元测试和集成测试来完成系统的功能测试。单元测试的目的是测试源码中最小单元的代码是否正确处理它该处理的任务。单元测试重点测试了代码中分支比较多的地方，以验证程序是否能根据条件执行相应的分支；并重点测试了代码对于异常情况的处理，以验证代码是否能对于发生的异常情况进行相应的处理；再就是对源码中与数据库相关的代码和涉及用户输入输出的代码进行了重点测试。集成测试是在单元测试的基础上，将已经通过单元测试的软件单元组合起来，组成可以执行的功能单元，然后进行测试。通过测试的子功能单元再通过组合，组成更大一级的功能模块进行测试。集成测试重点测试软件单元的组合能否正常工作，模块之间的组合能否集成起来工作，还要测试构成系统的所有模块组合能否正常工作。集成测试主要有三种测试方案：自底向上进行测试，自顶向下进行测试，以及自底向上和自顶向下结合的方式进行测试。自底向上的集成测试方式是最常使用的方法，这种方式从程序模块结构中最底层的单元模块开始组装和测试。自顶向下的集成测试方式正好与自底向上的方式相反，需要编写桩模块以支撑上层的测试。最理想的方案是能将这两种集成方式结合起来，这样在早期的时候，既能发现重大的问题，又能及早展开人力。但是这种方式实施起来有难度，需要软件开发者一开始要做好合理的策划和设计。由于系统在需求和设计阶段做的工作比较扎实，本系统主要采用了自底向上的集成测试方式：先把最底层的软件单元组合，组成高一级的功能单元进行测试；测试通过的功能单元再进行组合，组成更高一级的模块单元，并对模块单元进行测试；最后，模块单元再集成到系统中进行测试。测试重点集中在各单元与各单元之间的接口和信息交互。

　　2.用户界面测试

　　通过用户界面测试来验证用户与系统的交互情况。界面测试的目标是确保系统向用户提供适当的访问和浏览被测对象功能的操作。测试方法，为每个窗口创建或修改测试，以核实各个应用程序窗口和对象都可正确进行浏览，并处于正常状态。完成标准，证实各个窗口与基准版本保持一致，或符合接受标准；需考虑的特殊事项，并不是所有定制或第三方对象的特征都可访问。

　　3.性能测试

　　性能测试采用了主观评测和软件评测相结合的方法，先部署上系统，在环保局内部试运行，通过工作人员的使用来了解系统的反应速度是否满足客户的需求。系统的性能需求主要是对系统web访问的response时间和系统负载能力的要求。在性能测试过程中，我们利用Loadrunner模拟用户向系统发送请求，并监控系统的CPU，Memory等参数。

　　4.安全性测试

　　本系统采用先登录，后操作的方式。因此，必须测试有效和无效的用户名和密码，并注意到是否大小写敏感。本系统是有超时的限制，也就是说，用户登录后在一定时间内(20分钟)没有点击任何页面，需要重新登录才能正常使用。所以，也必须对其进行测试。

　　5.测试结果

单元测试方法范例篇2

　　关键词关键词：Gtest；Gmock；单元测试；集成测试；企业软件

　　中图分类号：TP319

　　文献标识码：A 文章编号：16727800（2014）002007604

　　0引言

　　一个软件的生命周期，从用户需求规格说明开始，经过计划沟通（需求分析）、策划（制定计划、风险评估）、建模（概要和详细设计）、构建（编码与测试）和部署（交付、支持和反馈）过程，最终提供一个完整的软件设计，并提供持续的技术支持[1]。在整个生命周期中，测试（即质量控制QA）扮演着重要角色。软件测试不仅仅发生在软件生命周期后半部分，而是贯穿于整个软件生命周期，包括详细设计阶段，跟进项目设计测试大纲；在编码实现的同时，编写测试用例，进行单元测试和模块测试，继而进行集成测试、系统测试和压力测试等。

　　在软件系列测试中，单元测试和集成测试最能保证产品质量，也最能发现代码静态检查中的问题，单元测试易被忽视。对大型企业软件，特别是跨平台软件开发，由于软件分支多，项目庞杂，开发者疲于进行完整单元测试，错过了纠正错误的最佳时机[2]。根据经验，软件测试越早发现错误，纠正该错误的代价越小。

　　在工程实践领域，企业级软件产品通常实行敏捷开发，要求尽可能缩短迭代过程，不断集成，持续交付，对质量控制提出了更严格的要求。在持续集成过程中，软件代码不断变更，测试用例设计也经常改变，而企业级软件产品本身规模庞大、组件模块多，如果没有一套扩展性好的单元测试框架，在持续集成过程中极早发现问题，整个敏捷开发迭代过程都会受到影响，从而延迟产品，给开发者带来很大压力。

　　1.1Google C++ Testing Framework简介

　　Google C++ Test Framework （以下简称GTest）是Google专为C++项目开发的测试框架，该框架基于高独立性、高重用性、易迁移性、富信息性、高执行效率等原则设计。用户代码通过简单部署，进行批量化宏调用，就能完成所期望的绝大部分测试工作，并得到丰富的测试结果。

　　1.2GTest的三个级别和两种断言

　　GTest测试分为三个级别：测试、测试用例、测试程序。测试程序通常是一个项目的整体测试框架；测试用例是针对整个模块检测，一个测试程序会包括多个测试用例；测试则是对一个模块内具体方法的检测，因此一个测试用例包括很多个测试。这三个级别的具体实现方式将在后续给出试例。

　　断言是GTest的基础，它是一种监测被测代码行为的机制。一个断言是GTest宏的一次调用，而一次宏调用，就是一个测试。GTest的任何一个断言，将产生以下三种结果之一：成功、非致命错误、致命错误。成功和非致命错误不影响整个测试程序的进行，而致命错误会直接导致测试程序退出。

　　GTest将断言分为两类：EXPECT_*和ASSERT_*。前者在发生错误时，给出非致命错误，使后续测试继续进行；后者在发生错误时，强制整个测试程序退出。一般情况下，推荐使用EXPECT_*，除非该错误出现直接导致后续测试不能再按照所期望的情况执行[3]，如出现重大内存溢出，数据驱动文件读写错误等。

　　1.3Google C++ Mocking Framework简介

　　Mock的编程行为，在任何一种语言实现的任何一个工程中都有其适用范围和意义。Mock行为使用户代码可以模拟所依赖的功能模块，自行构建伪模块，独立进行单元测试[4]。使开发者在缺少外部环境（如数据库、网络等）支持、项目设计人员支持或其他开发人员支持的情况下，也能较完整地对本模块进行测试，减少某一方法的测试对其它模块的依赖性。

　　Google C++ Mocking Framework （以下简称GMock） 是Google为配合GTest而设计实现的一套Mock机制。Mock存在以下问题：①Mock工作繁杂、机械且易出错；②手工Mock的准确度因人而异，不易度量，测试结果的参考价值大打折扣；③Mock工作更具体，更涉及业务。因此，在一个Mock上的经验，不大可能应用到另一个Mock上。

　　GMock被同时设计成自动化设计工具和测试工具。在接口设计过程中，尽可能使用GMock进行接口功能性和易用性考察；在具体功能实现后，可以独立对功能模块进行测试。

　　1.4GMock的Mock范围

　　GMock推荐将所有方法虚化（接口化）[6]，因为Mock C++虚方法不论从编码角度，还是从GMock内部逻辑实现上，都更简单。这并不代表GMock只有这一种Mock支持。GMock几乎可以Mock任何C++方法机制，包括虚方法（接口）、实函数和静态方法。不论从测试代码实现难度上，还是用例维护难度上，都是目前市场上大部分C++测试和Mock框架所不能比拟的。

　　2CISCO JabberWerxCPP开发测试框架设计

　　CISCO JabberWerxCPP（以下简称JWCPP）是CISCO众多产品的底层通信库，是XMPP系列协议的C++跨平台实现。项目整体由数十个模块构成，实现代码约50余万行。其结构特点是功能组件化，模块之间依赖关系复杂。JWCPP的组件化模块组织方式如图1所示。

　　可见，JWCPP的最终产品，将JWXmppMgr、JWLoginMgr和JWConfigInfo三个模块暴露给上层用户，它们是API的提供者。iConnect模仿COM组件机制，将整个JWCPP的功能模块以组件化形式组织起来，对上述三个API模块而言，是功能的具体实例化者；在iConnect下层，则是每一个具体组件模块，它们从功能上被分为业务部分和工具部分。

　　基于JWCPP的产品特点可见：①对于集成测试，只需从上层接口入手，辅以良好的结构设计，执行产品标准初始化流程（iConnect的实例化过程），即可通过简单的接口调用，完成对功能的集成测试，通过GTest的断言机制，判断各功能实际执行结果；②对于单元测试，底层业务部分和工具部分中各个模块相互调用，关系错综复杂，而所有功能模块，都是从元组件conIUnknown、工厂组件conIClassFactory等组件中多重继承而来，继承层次繁多，在每一层继承中，又有各模块自己的静态方法、虚方法和方法覆盖与重构，这对单元测试的实现提出了挑战。GMock本身设计的出发点和特性，适用于这种庞大冗杂的项目测试。基于以上分析的开发测试框架如图2所示。

　　需要强调的是，本项目中单元测试和集成测试性质不同。集成测试关注功能完整性、各模块间信息传递的正确性和最终整个业务流程的正确性，要求集成测试必须模拟实际产品环境，将整个产品在内存中实例化，即执行标准组件初始化、子组件工厂化生产等过程。而单元测试更多关注代码级别的正确性，目的是尽可能遍历所有可能的逻辑分支，这就决定了单元测试不需要实例化整个库。该不同导致了集成测试的构建具有结构化、目标清晰、重用性良好的特点；而单元测试的构建则较为繁杂，庞大和琐碎。

　　3开发测试框架实现

　　3.1集成测试

　　3.1.1集成测试实现原理

　　由图1可知，将集成测试从产品代码中独立出来作为一个单独项目，继承产品所暴露的接口类，之后调用整个产品库的初始化API，在内存中实例化该库，并将其注册到操作系统中，即可实现集成测试。

　　在集成测试框架设计中，主要引入三个环境构建模块：TAWaitForMgr、TAWaitForTimer和TAEvents。整个集成测试框架，实际是一个调用-等待-处理回调-验证的过程，由事件机制驱动。TAWaitForMgr是事实上的API调用者，它调用API接口，激活TAWaitForTimer进行等待和轮询，当检测到状态变化时，激活事件机制TAEvents，产生回调事件，并对最终回调结果进行验证，给出测试结果。在实现上，API的调用和测试结果验证，都被包含在GTest的断言机制中。引入TestIClient模块，作为最终管理所有TA的功能模块。通过实例化一个TestIClient，可以实现对全局任意模块的即时调用。

　　3.1.2集成测试伪代码

　　3.2单元测试

　　3.2.1单元测试实现原理

　　就本项目而言，各模块间关系看似错综复杂，但采用GMock的Mock机制，实际上消除了模块间的依赖性，其实现要比集成测试更为简单。同时，由于单元测试不涉及业务逻辑，避免了集成测试实现过程中的调用—等待—处理回调—验证过程，也意味着单元测试不需要通过产品实例化过程进行耗时的初始化。本项目采用集成测试管理所有TA测试模块，引入TestUClient来统一管理TA单元测试模块。

　　3.2.2单元测试伪代码

　　5结语

　　本文在对企业级产品项目进行特性分析的基础上，阐述了采用基于GTest和GMock的测试框架的必要性；提供了集成测试和单元测试框架的设计实现过程；最后给出在实际环境中的运行结果，表明了该设计方案的可实现性、易用性和高效性。后续研究中，将尝试把该套测试框架与项目的持续集成系统相结合，实现项目开发测试的完全自动化。

　　参考文献：

　　[1]ROGER S PRESSMAN。软件工程：实践者的研究方法[M]。郑人杰，译。北京：机械工业出版社，2011.

　　[2]RUNESON P。A survey of unit testing practices[J]。IEEE Software，2006，23（4）。

　　[3]BOEHM B，V BASILI。Software defect reduction top 10 list[J]。IEEE Computer，2007，34（1）：135137.

　　[4]THOMAS D，HUNT A。Mock object[J]。IEEE Software，2002，19（3）：2224.

单元测试方法范例篇3

　　本文就如何运用反馈——矫正手段提高教学目标效果谈几点看法。

　　一、在课前通过诊断性测试，获得学生在学习新内容前的知识反馈，为上新课做好准备。

　　诊断性测试一般安排在新学期或新开课前进行，测试时间一般5～10分钟，测试应侧重于考查学习新课所需要掌握的基本知识和基本技能。例如，在上动物模拟人体手术实验课前，先测试学生关于无菌技术和无菌原则方面的知识并补偿，由此提高他们的学习外科手术的前提能力，最终提高实验目标。

　　二、在课前或课后，通过形成性测试了解学生的达标情况，及时查漏补缺。

　　1、编制形成性测试题，包括课堂测试题和单元测试题，要确保适合各自的特点。

　　（1）课堂测试题，要适合在课堂教学中进行测试。课堂教学时间一般以二学时为单位，共80分钟。其中用以进行课堂测试及反馈矫正的时间通常只有5分钟，故编制此类试题要突出重点，考虑课堂操作的可行性，试题量不能过多。例如，在“复苏”一章编制的课堂测试题为：①快速诊断心脏骤停的方法；②心肺初期复苏的abc步骤；③心脏按压有效的标志是什么；④心肺复苏有效的指标是什么等。这些题中包括了本章的重要知识点，学生掌握后，在遇到心脏骤停病人时就会懂得如何去诊断和处理，而且试题量适中，便于在课堂上进行测试和矫正。

　　（2）单元测试题，即教师根据教学的情况，一般按章节划分为一个教学单元，每学完一个单元后进行一次单元测试，以评价学生的单元达标情况。单元达标测试覆盖的目标范围较大，而且每一目标都应有相应的检测题，测试时间为20～30分钟，测试内容多时间少，因此编制此类题主张多用选择题和判断题，少用填空题、名词解释和问答题，以方便学生答题，做到既能检测目标又不影响课堂授课。此处，通过定期的单元测试，又能促使学生经常系统地进行复习，有利于知识的巩固和强化。

　　2、编制平行性测试题，此类试题适用于对矫正生的检测。

　　即用以检测单元测试中的未达标者，在经过补救矫正后是否已达标。编制此类别试题应与单元形成性测试题是同质不同形的，即用不同的试题形式去检测同一目标。例如，检测“补钾原则”这一目标时，如果在单元形成测试中采用选择形式，则在平行性测试中可采用判断或填空题的形式进行检测。

　　三、反馈——矫正是对经测试反馈的未达标者及时补救矫正，使其达标。

　　1、课堂反馈矫正。

　　课堂测试反馈一般采用提问、回答、接力填空等形式，其中最常用的是课堂提问的形式，而课堂提问的形式主要适合于对个别学生，这与目标教学要面向全体学生的宗旨是矛盾的，为了解决这一矛盾，在提问时应使所提问的学生具有代表性和随机性。所谓代表性是指所提问的学生能代表全班学生中的某一部分，如优生、中等生或差生。要做到有计划有目的地进行提问检测，尤其对差生要多进行检测矫正。随机性主要是针对课堂教学的具体情况，在全班同学中随机地进行提问。笔者曾在上“急性阑尾炎”一节时，发现一位同学在上课时开小差，当时立即对她进行提问检测：“急性阑尾炎最有特征的症状是什么？”她回答是“腹痛”。这样通过提问，可及时地使她调整思维、融入课堂。虽然她答得不全对，但是通过提问既能起到对她及时补救矫正的效果，同时也能引起其他同学的重视（尤其是对提问的这一问题的重视），结果在单元形成测试中全班同学都能答对这一题。这样通过抓典型、抓代表，达到“牵一发而动全身”的效果，既能及时纠正课堂上出现的个别问题，又能调动全班同学的课堂积极性和主动性，因而能有效地提高教学目标达成度。

单元测试方法范例篇4

　　【关键词】车顶单元；制冷量；设计

　　上世纪90年代后，随着铁路空调客车的飞速的发展，车顶单元式空调器的产量逐年增加。据不完全统计，目前国内拥有空调器约20000多台。值得注意的是投入运用的空调器早已到了大修期，其中绝大部分为车顶单元式空调器。为保证检修后的空调器的性能，客车车顶单元式空调器的检修试验就显得十分重要。

　　一、客车车顶单元式空调器的性能试验装置

　　1、空调器的型号

　　目前，我国铁路客车用空调器的主要型式是车顶单元式。该型空调器自1980年从日本引进，仿制改进，至今已经运用20多年，通过不断地改进完善，现在已经形成标准化，系列化。空调器的结构型式主要有三种：平底侧出风口型，代号为“—”；圆底下出风型，代号为“Y”；平底侧出风口型，代号为“P”。平底侧出风型空调器安装于客车车顶端部，新造客车安装的绝大部分都是这种型式。

　　2、空调器的构造

　　车顶单元式空调器是将机械制冷部分的压缩机、冷凝器、干燥过滤器、毛细管(或膨胀阀)、蒸发器、气液分离器、冷凝风机、蒸发风机和空气预热器等集中装在一个箱体内，组成一个单元，可方便地安装在车顶部。与空调器配套的电气控制柜安装在车内配电室，空调器与电气控制柜通过电气连接器(插头、插座)连接，由发电车集中供电(亦可由本车悬挂式发电机供电)。空调器出风口与车内主风道之间通过软风道连接，空调器处理后的空气经车内主风道由送风口送入客室内，达到调节车内空气温度的目的。由此可见，客车车顶单元式空调器性能试验装置的重要性。

　　3、设计原则

　　1）试验装置结构力求紧凑，占地面积尽量小，以求适应于各类生产车间的工艺布局；

　　2）外形应该美观，设备整体性强；

　　3）工艺布置应该灵活，工艺设计应该简单；

　　4）操作方便，参数的测试及数据处理要求准确

　　4、设计方案的确定

　　目前现场使用的车顶单元式空调器性能装置有闭路式和开路式两种原理方法：

　　1）闭路式测试原理方法

　　该方式需要一间室外侧试验室一间室内试验室，被试空调器安装于室外侧试验室内，该室内的空气温度需要调节到名义工况下空调器冷凝器进风温度，经空调器制冷后的空气由送风道引入置于室内侧试验室的空气流量测试装置进行空气流量测量，接着进入空气调节装置，调节后的空气再由回风道被空调器吸入，即完成了一次循环。空气 参数调节及空气流量测量均在风道内进行，该方式的特点是测试环路必须密闭，热湿损耗较小。

　　2）开路式测试原理方法

　　该方式与闭路式的区别在于，空气经过流量测量装置后直接排入室内侧试验室内，在房间内进行空气调节。其优点是室内侧试验室的空气参数易于稳定，但热湿损耗较大。

　　对于这两种方式，均需要设置独立的试验房屋，房屋面积随实际情况而定。被试空调器的安装可采用固定式安装架或试验小车。如果采用固定式安装架，则一般采用箱式结构，室外需设置空调器吊装设备。若采用试验小车则一般采用房间式结构（即由几间相互隔热的房间构成）可在有起重机的检修间将空调器吊装到小车上，试验小车推入室外侧试验室，接上管道即可进行试验。

　　相比于房间式结构，箱式结构相对构造简单，占地面积较小，它的工艺布置也相对灵活，工艺设置简单，不需要大量的土建工程。所以，本设计“以箱体式空调器试验装置”作为总体设计方案。针对箱体式试验装置的特点，其室内可以安装加热加湿装置，弥补室内的热湿损耗，所以我们选用开路式测试原理。综上所述，我们本次设计方案最后确定为：“箱体结构式的开路式测试”车顶单元式空调器性能装置

　　二、制冷量的测量方法设计

　　1、设计原则

　　1）测量精度高，范围宽，系统环节少；

　　2）测量装置结构力求紧凑，体积小，以适应在箱体内布局；

　　3）装置安装操作维护应该方便，参数的读取和数据的处理应该力求简单方便。

　　2、测量方案确定

　　目前，由于某些设计单位设计的试验装置仅仅采用一种方法测试制冷量，不能有效地控制室外侧空调器的冷凝器的进风温度，造成试验工况的不稳定，影响了测试精度。

　　《客车空调三机检修及运用管理规程》中规定，空调器制冷量达不到原参数的90％时，应该分解制冷系统。这就要求所建的试验装置工况要稳定，测试数据应该准确。TB/T2432-93《铁道客车车顶单元式空调器试验方法》中规定，空调器制冷量试验方法采用室内侧空气焓差法为主测试方法，室外侧空气焓差法为辅测试方法。对于检修性能试验装置也可以只采用室外侧空气焓差法。但是为了保证试验装置测试制冷量的的精度及使所测试空调器性能的稳定性，我们采用室内侧空气焓差法为主测试方法，室外侧空气焓差法为辅测试方法测试制冷。两种方法测试的结果相对偏差不大于6％，若超出6％，则要进行管路损耗修正。它的特点是稳定性好，不受外界因素变化的影响。

　　3、测量原理方法

　　所谓室内侧空气焓差法，即在规定工况下通过测得流经空调器室内侧空气焓差及量流量，经过计算获得有效制冷量的方法。

　　所谓室外侧空气温差法，即在规定工况下通过测得流经空调器室外侧空气温差及重量流量，经过计算获得有效制冷量的方法。

　　三、制热量的测量方法设计

　　我国车顶单元式空调器运行在制热状态时候一般在冬季，采用的制热方式一般是直接加热。当空调吸入的新鲜空气和室内的回风在空调器加热室内被混合加热后，将其直接送入客室内即可，它相对于制冷状态而言比较简单，所以我们测试其制热量时候可只用一种方法——室内空气焓差法测试即能满足要求，为了保证热损失在控制要求的范围以内，要用输入电加热器的瓦数所制得的热量来验算（验算公式为qd=3.41·x，x为输入电加热器的瓦数，x可以在试验装置控制柜上读出来），若误差大于6％则要进行管路损失修正。若需要修正，修正方法为将两种结果的差值加给室内空气焓差法计算的制热量。

　　结 语

　　目前车顶单元式空调器在铁道客车上的运用已经越来越多，但是空调器性能试验装置的价格都非常高。因此，空调器的检修和性能测试的是急需解决的问题，它直接关系铁道客车运营情况的好坏。车顶单元式空调器性能试验装置能得到广泛的应用，有助于提高客车空调器的性能，从而提高铁道客车乘坐的舒适度，也就在一定程度上提高了铁道客车和其它交通工具的竞争力。

　　参考文献

　　[1]王其伟。单元式空调器性能试验装置的工况控制[J]。铁道车辆，2008(12)

单元测试方法范例篇5

　　【关键词】软件测试；单元测试；用例；等价类

　　1.软件测试

　　软件测试是指利用相关测试工具，按照一定的测试方案和流程对软件系统的功能和性能进行测试，对可能出现的问题进行分析、评估，发现开发错误并跟踪，以确保所开发的软件满足用户需求。软件测试是保证软件质量的主要手段，是根据软件开发各阶段的规则说明和程序内部结构而精心设计的一批测试用例，并利用这些测试用例运行程序以发现软件是否存在错误的过程，软件测试的范围应当包括更广泛些，除了考虑正确性外，还应关心程序的效率、健壮性等因素。

　　软件测试过程包含单元测试、集成测试、确认测试和系统测试四个步骤：

　　（1）单元测试：对每一个程序单元进行独立测试，检查各程序模块是否正确地实现了预定的功能。

　　（2）集成测试：把已通过测试的模块组装起来，对软件体系构造的正确性进行测试。

　　（3）确认测试：检查已完成的软件系统是否已满足了需求规格说明中的各项需求，软件配置是否完全、正确。

　　（4）系统测试：将经过确认的软件系统置入实际的运行环境中，与其它系统成份结合在一起进行测试。

　　2.单元测试

　　单元测试又称模块测试，是以软件系统设计的最小单位——程序模块为对象，进行正确性检验的测试工作。单元测试常被看作编码的附属品，在代码被开发、编译调试、审查后，单元测试用例设计便开始了。进行充分的单元测试，是提高软件质量，降低研发成本的必由之路。几乎所有的开发人员都会对每一段代码做一定程度的单元测试。如果一个模块要完成多项功能，可以将该模块看成由几个小程序组成，对每个小程序分别进行单元测试。如果是关键模块，往往还要做性能测试。

　　单元测试以详细设计说明书和源程序清单为依据，常采用白盒测试的用例，辅之以黑盒测试的用例，以寻找模块内部可能存在的错误为目的，主要完成模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试等任务。

　　（1） 模块接口测试

　　单元测试开始时，要对通过被测模块的数据流进行测试。包括调用该模块的输入参数的正确性、调用其子模块时提供参数的正确性、全局变量的定义在各模块中是否一致等。

　　（2） 局部数据结构测试

　　包括数据类型的一致性、变量名、变量赋值、全局数据对模块影响的正确性等检验。

　　（3） 路径测试

　　对基本执行路径和循环进行测试，查找由于错误的计算、不正确的比较或不正常的控制流而导致的错误。

　　（4） 错误处理测试

　　检测对错误条件的响应是否正确，错误描述是否与实际的错误是否相符、是否能够对错误定位、是否易于理解等。

　　（5） 边界测试

　　通过设定边界值检测数据流、控制流中等于、大于或小于比较值时出错的可能性。

　　在面向过程编程时代，单元测试所说的单元一般是指函数，而在面向对象编程时代，单元测试所说的单元一般是指类。以类作为测试单位，测试的复杂度相对较高，所以目前通常采用的办法是为软件开发建立对应的测试工程，为每个类建立对应的测试类，为每个函数建立测试函数测试结构化的局部代码。

　　3.单元测试用例的设计

　　测试用例是指对某特定的软件系统进行测试任务的描述，它体现了测试的方案、方法和技术，包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。

　　测试用例的设计也就是测试需求细化的过程，测试需求分析和测试用例设计是密不可分的，前者是后者的依据，后者是前者的体现。测试用例的设计应与复审相结合，根据相关设计信息设计测试数据，以增大发现错误的可能性。

　　单元测试用例可以选取正确输入、边缘数据和错误输入作为测试数据。以系统用户注册模块中出生年、月、日的设置为例，通过等价类划分法设计测试用例。

　　在划分等价类时，我们将其划分为两类：1、有效等价类：是指输入完全满足程序输入的规范说明、合理的、有意义的输入数据所构成的集合。利用有效等价类可以检验程序是否满足规格说明书所规定的功能和性能。2、无效等价类：是指完全不满足程序输入的规格说明、不合理的、无意义的输入数据所构成的集合。使用无效等价类可以检验程序的容错性能。