单元测试与JUNIT(2)

　　JUnit就是对程序代码进行单元测试的一种Java框架。通过每次修改程序之后测试代码，程序员就可以保证代码的的少量变动不会破坏整个系统。官方对JUnit的定义是“JUnit is a simple framework to write repeatable tests.”。

　　1.5.2. 自己编写测试框架的弊病

　　自己编写测试框架进行单元测试一般有两个方法。第一种方法是在要测试的类的main()方法中编写测试代码。随着程序越变越大，这种开发方法很快就开始显现出了缺陷：

　　(1)混乱。类接口越大，main() 就越大。类可能仅仅因为正常的测试就变得非常庞大。

　　(2)代码膨胀。由于加入了测试，所以产品代码比所需要的要大。

　　(3)测试不可靠。main() 是代码的一部分，main() 就对其他开发者通过类接口无法访问的私有成员和方法享有访问权。出于这个原因，这种测试方法很容易出错。

　　(4)很难自动测试。要进行自动测试，必须创建另一程序来将参数传递给 main()。第二种方法是编写一个测试类框架，它虽然能够克服上个方法的缺陷，但增加了开发组织维护这个测试类框架的工作量，为立即大规模的重用设置障碍。而且，由于这个测试框架是内部开发的，存在着与业界难于交流和沟通的弊病。

　　1.5.3. JUnit的优势

　　(1)需要编写自己的框架。

　　(2)它是开放源代码，因此不需要购买框架。

　　(3)开放源代码社区中的其他开发者会使用它，因此可以找到许多示例。

　　(4)可以将测试代码与产品代码分开。

　　(5)易于集成到构建过程中。

　　2. 单元测试设计

　　2.1. 单元测试的一般过程

　　单元测试过程分为计划、设计、实现、执行、评估等几个步骤，各步骤的任务如下：

　　2.1.1. 计划

　　单元测试计划需明确如下目标：

　　(1)明确单元测试的测试对象，确定测试需求及测试通过的标准，明确活动的输出。

　　(2)明确测试方法和需要运行的工具需求。

　　(3)对工作量进行估计，确定测试所用资源(包括人力资源和设备资源)，创建测试任务的时间表，必要时需将一个单元测试任务分解成更细化的子任务进行明确。

　　(4)对测试风险进行分析，制定相应的应急措施。

　　(5)明确测试优先级，制定测试取舍策略。

　　(6)输出单元测试计划文档。

　　2.1.2. 设计

　　单元测试的设计主要是完成方案和模型的确认，包括如下几方面内容：

　　(1)测试需求的进一步细化，必要时需追溯到详细设计文档中的单元设计目标。

　　(2)设计单元测试模型，包括与模型相关的工具的选用。

　　(3)制定测试方案，包括模型的设计和实现、定义测试规程和用例的实现和组织。

　　(4)输出单元测试方案文档。

　　2.1.3. 实现

　　单元测试实现主要是针对用例的实现，包括如下几个方面：

　　(1)参考测试模型和测试方案，制定具体的测试用例，创建可重用的测试脚本。

　　(2)输出单元用例文档。

　　2.1.4. 执行

　　根据单元测试的方案、用例对单元进行测试，验证测试的结果并记录测试过程中出现的缺陷，主要保留执行过程数据以备问题定位的回归对比。

　　2.1.5. 评估

　　对单元测试的结果进行评估，主要有如下几个方面：

　　(1)实际测试过程的记录，描述与计划的差异和原因，包括补充或裁剪的测试项目清单。

　　(2)对测试过程完备性以及被测单元质量的评价，包括用例执行情况清单和汇总分析。

　　(3)主要从需求覆盖和代码覆盖的角度进行测试完备性的评估。

　　(4)遗留问题记录和可能的分析。

　　(5)输出单元测试报告。

　　2.2. 单元测试用例设计方法

　　测试用例的设计在单元测试中占有非常重要的地位，测试用例设计的好坏直接影响到测试的效果。确定测试用例之所以很重要，原因有以下几方面：

　　(1)测试用例构成了设计和制定测试过程的基础。

　　(2)测试的“深度”与测试用例的数量成比例。由于每个测试用例反映不同的场景、条件或经由产品的事件流，因而，随着测试用例数量的增加，对产品质量和测试流程也就越有信心。判断测试是否完全的一个主要评测方法是基于需求的覆盖，而这又是以确定、实施和/或执行的测试用例的数量为依据的。

原文转自：http://www.uml.org.cn/Test/201405272.asp