1.1 定义

单元测试是对软件基本组成单元进行的测试，这里的基本单元不一定是指一个具体的函数或一个类的方法。“单元”具有一些基本属性，如：明确的功能，规格定义，与其他部分明确的接口定义等，可清晰的与同个程序的其他单元划分开来。

1.2 单元测试的主要目的：

(1)

(2)

(3)

(4) 验证代码是与设计相符合的； 跟踪需求和设计的实现； 发现设计和需求中存在的错误； 发现在编码过程中引入的错误；

1.3 单元测试地策略

1.3.1 由顶向下地单元测试策略

先对最顶层地单元进行测试，把顶层所调用地单元做成桩模块。其次对第二层进行测试，使用上面已测试地单元做驱动模块。如此类推知道测试完成所有模块。

1.3.2 由低到上地单元测试策略

先对模块调用层次图上最底层地模块进行单元测试，模拟调用该模块的模块做驱动模块。软后再对上面一层做单元测试，用下面已被测试过的模块做桩模块。以此类推，直到测试完所有模块。

1.3.3 孤立测试

不考虑每个模块与其他模块之间的关系，为每个模块设计桩模块和驱动模块。每个模块进行独立的单元测试。

1.4 单元测试分析

1.4.1 模块接口

(1) 调用所测试模块时的输入参数与模块的形式参数在个

数、属性、顺序上是否匹配；

(2) 所测试模块调用子模块时，它输入给子模块的参数与子

模块中的形式参数在个数、属性、顺序上是否匹配；

(3)

(4)

(5)

(6) 是否修改了只做输入用的形式参数； 输出给标准函数的参数在个数、属性、顺序上是否正确； 全局变量的定义在每个模块中是否一致； 约束条件是否通过形式参数来传送。

1.4.2 局部数据结构

(1)

(2)

(3)

(4)

(5) 检查不正确或不一致的数据类型说明； 使用尚未赋值或尚未初始化的变量； 错误的初始值或错误的默认值； 变量名拼写错误或书写错误； 不一致的数据类型。

…… …… 余下全文

北 华 航 天 工 业 学 院

软件工程

-------单元测试报告

报告题目：  图书借阅系统单元测试     

                                          

作者所在系部：计算机科学与工程系     

作者所在专业：计算机应用技术         

作者所在班级：  11512                 

作 者 姓 名 ：  王邵南                

指导教师姓名：  李杰                  

…… …… 余下全文

一 单元测试概述

工厂在组装一台电视机之前，会对每个元件都进行测试，这，就是单元测试。 其实我们每天都在做单元测试。你写了一个函数，除了极简单的外，总是要执行一下，看看功能是否正常，有时还要想办法输出些数据，如弹出信息窗口什么 的，这，也是单元测试，老纳把这种单元测试称为临时单元测试。只进行了临时单元测试的软件，针对代码的测试很不完整，代码覆盖率要超过70%都很困难，未 覆盖的代码可能遗留大量的细小的错误，这些错误还会互相影响，当BUG暴露出来的时候难于调试，大幅度提高后期测试和维护成本，也降低了开发商的竞争力。 可以说，进行充分的单元测试，是提高软件质量，降低开发成本的必由之路。

对于程序员来说，如果养成了对自己写的代码进行单元测试的习惯，不但可以写出高质量的代码，而且还能提高编程水平。

要进行充分的单元测试，应专门编写测试代码，并与产品代码隔离。老纳认为，比较简单的办法是为产品工程建立对应的测试工程，为每个类建立对应的测试类，为每个函数（很简单的除外）建立测试函数。首先就几个概念谈谈老纳的看法。

一般认为，在结构化程序时代，单元测试所说的单元是指函数，在当今的面向对象时代，单元测试所说的单元是指类。以老纳的实践来看，以类作为测试单位， 复杂度高，可操作性较差，因此仍然主张以函数作为单元测试的测试单位，但可以用一个测试类来组织某个类的所有测试函数。单元测试不应过分强调面向对象，因 为局部代码依然是结构化的。单元测试的工作量较大，简单实用高效才是硬道理。

有一种看法是，只测试类的接口(公有函数)，不测试其他函数，从面向对象角度来看，确实有其道理，但是，测试的目的是找错并最终排错，因此，只要是包 含错误的可能性较大的函数都要测试，跟函数是否私有没有关系。对于C++来说，可以用一种简单的方法区隔需测试的函数：简单的函数如数据读写函数的实现在 头文件中编写(inline函数)，所有在源文件编写实现的函数都要进行测试(构造函数和析构函数除外)。 什么时候测试？单元测试越早越好，早到什么程度？XP开发理论讲究TDD，即测试驱动开发，先编写测试代码，再进行开发。在实际的工作中，可以不必过 分强调先什么后什么，重要的是高效和感觉舒适。从老纳的经验来看，先编写产品函数的框架，然后编写测试函数，针对产品函数的功能编写测试用例，然后编写产 品函数的代码，每写一个功能点都运行测试，随时补充测试用例。所谓先编写产品函数的框架，是指先编写函数空的实现，有返回值的随便返回一个值，编译通过后 再编写测试代码，这时，函数名、参数表、返回类型都应该确定下来了，所编写的测试代码以后需修改的可能性比较小。

…… …… 余下全文

单元测试总结

作者：张元礼

/vincetest

1 单元测试的重要性

1.1 一些错误的认识

在实际的单元测试过程中总会有一些错误的认识左右着我们，使之成为单元测试最大的障碍，在此将其一一分析如下：

? 它太浪费时间了，现在要赶进度，时间上根本不允许，或者随便做做应付领导。 ? 我是一个很棒的程序员，我写的代码肯定是没有问题的。

? 做单元测试太烦了，直接集成，到时有问题在集成测试时肯定能发现的，实在

不行在系统测试总该能发现吧。

? 它仅仅是证明这些代码做了什么。

对于以上错误认识的产生归根结底还是由于对单元测试的理解还是不够，没有真正认识到单元测试的重要性。

1.2 测试的重要性

单元测试是软件测试的基础，因此单元测试的效果会直接影响到软件的后期测试，最终在很大程度上影响到产品的质量。从如下几个方面就可以看出单元测试的重要性在何处。

? 时间方面：如果认真的做好了单元测试，在系统集成联调时非常顺利，因此会节约

很多时间，反之那些由于因为时间原因不做单元测试或随便做做的则在集成时总会遇到那些本应该在单元测试就能发现的问题，而这种问题在集成时遇到往往很难让开发人员预料到，最后在苦苦寻觅中才发现这是个很低级的错误而在悔恨自己时已经浪费了很多时间，这种时间上的浪费一点都不值得，正所谓得不偿失。 ? 测试效果：根据以往的测试经验来看，单元测试的效果是非常明显的，首先它是测

试阶段的基础，做好了单元测试，在做后期的集成测试和系统测试时就很顺利。其次在单元测试过程中能发现一些很深层次的问题，同时还会发现一些很容易发

现而在集成测试和系统测试很难发现的问题。再次单元测试关注的范围也特殊，它不仅仅是证明这些代码做了什么，最重要的是代码是如何做的，是否做了它该做的事情而没有做不该做的事情。

? 测试成本：在单元测试时某些问题就很容易发现，如果在后期的测试中发现问题所

…… …… 余下全文

1.软件测试：是由“验证（verrificatione）”和“有效性确认（validation）”活动构成的整体： “验证”是检验软件是否已正确地实现了产品规格书所定义的系统功能和特性。验证过程提供证据表明软件相关产品与所有生命周期活动的要求（如正确性、完整性、一致性、准确性等）相一致。相当于以软件产品设计规格说明书为标准进行软件测试的活动。

“有效性确认”是确认所开发的软件是否满足用户真正需求的活动。一切从客户出发，理解客户的需求，对软件需求定义、设计的怀疑，发现需求定义和产品设计中的问题。这主要通过各种软件评审活动来实现，包括让客户参加评审、测试活动。

软件测试过程：（1）测试组织和管理（2）测试计划（3）测试用例实际（4）测试实施（5）测试结果分析（6）测试评审与报告

软件测试方法：白盒测试方法、黑盒测试方法、静态测试与动态测试、主动测试与被动测试、形式化测试方法、基于风险的测试、模糊测试方法、ALAC测试和随机测试方法

2.单元测试：是对软件基本组成单元进行的测试，而且软件单元是在与程序的其他部分相隔离的情况下进行独立的测试。

静态测试就是静态分析，对模块的源代码进行研读，查找错误或收集一些度量数据，并不需要对代码进行编译和仿真运行。

动态测试是通过真正运行程序发现错误，通过观察代码运行过程，来获取系统行为、变量实时结果、内存、堆栈、线程以及测试覆盖度等各方面的信息，来判断系统是否存在问题，或者通过有效的测试用例，对于的输入输出关系来分析被测程序的运行情况，来发现缺陷。 静态测试、动态测试的区别：1.静态测试用于预防，动态测试用于矫正；2.多次的静态测试比动态测试的效率高；3，静态测试综合测试程序代码；4.在相当短的时间里，测试的覆盖率能达到100%，而动态测试经常只能达到50%测试左右；5.动态测试比静态测试更花时间；

6.静态测试比动态测试更能发现bug；7.静态测试的执行可以在程序编码编译前，动态是中能在编译后才能执行。

…… …… 余下全文

｛项目名称｝ 软件测试总结报告

编号：｛项目名称缩写｝

版本:X.X

变更记录

1 项目信息

2 测试结果

2.1测试活动总结

2.2测试用例覆盖率统计

2.4质量分析及调整措施

2.4.1偏差原因说明

对上述工作量、进度、测试用例覆盖率及质量目标的偏差原因进行综合分析

2.4.2影响分析

说明偏差对关键因素的影响，如对总体质量目标、阶段质量目标、项目总进度、阶段进度、工作量等

2.4.3纠正措施说明

说明将采取的纠正措施（如是否需要修订总体质量目标、是否需要修订项目计划，包括部分模块重新设计及开发等，是否需要修订测试计划，包括变更测试策略和测试用例，延长测试进度、增加资源再进行测试等）

2.5遗留缺陷说明

如系统在交付用户时仍存在缺陷需要填写本小节。

3 测试用例分析统计

3.1测试用例效率分析

4 测试结果分析

4.1能力陈述

经测试证实了的本软件的能力，如 实现所有功能需求 满足非功能性需求

系统设计文档完整，且符合规范 代码符合规范，且与系统设计一致

4.4发布前软件版本的质量综合评价

1）根据缺陷密度与同类产品的缺陷密度的比较情况评价软件产品质量（若小于/等于同类产品的缺陷密度，则该软件产品质量相对较好；反之，则相对较差）。

2）软件页面风格是否统一；所有功能是否达到了需求规格说明书的要求可以交付使用；该系统与其它系统的接口是否都已经测试通过等。

5 相关文档

《软件需求规格说明书》《软件项目开发计划书》《软件测试计划书》 《软件测试通过标准》 《缺陷分类指南》 《缺陷管理指南》 《单元测试总结》 《集成测试总结》 《系统测试总结》

…… …… 余下全文

测试基础

1、   软件测试的目的：证明（表达软件能够工作）→ 检测（发现错误）→ 预防（管理质量）

2、   测试执行：单元测试（UT执行）：一个测试用例的测试执行；

               集成测试（IT执行）：一个测试用例集的测试执行；

               系统测试（ST执行）：不同测试阶段的测试执行。

3、   回归测试的目的：a. 验证错误是否修复；

b. 检测对代码的修改是否引入了新的错误。

5、 软件测试的主要工作：a. 检视代码，评审开发文档；

b. 进行测试设计，写作测试文档（测试计划、测试方案、测试用例等）；

c. 执行测试，发现软件缺陷，提交缺陷报告，并确认缺陷最终得到了修正；

d. 通过测试度量软件质量。

6、 软件危机的出现主要表现在：a. 由于缺乏大型软件开发经验和软件开发数据积累，开发工作计划很难制定；

                              b. 开发早期需求分析不够明确，造成开发后期矛盾集中暴露；

                              c. 不遵循开发规范，开发文档不完整，软件难以维护；

…… …… 余下全文