单元测试规范V1.0

单元测试规范

V1.0

文档变更历史

第1章 1.1 第2章 2.1 2.2 2.3 第3章

引言 ............................................................................................................................................ 2 编写目的 ........................................................................................................................................ 2 概述 ............................................................................................................................................ 3 单元测试内容................................................................................................................................. 3 单元测试力度................................................................................................................................. 3 单元测试步骤................................................................................................................................. 4 单元测试步骤 ............................................................................................................................ 5

3.1 设计单元测试方案 ......................................................................................................................... 5 3.1.1 输入、输出............................................................................................................................. 5 3.1.2 任务 ........................................................................................................................................ 5 3.2 编写单元测试CASE ..................................................................................................................... 6 3.2.1 输入、输出............................................................................................................................. 6 3.2.2 任务 ........................................................................................................................................ 6 3.3 执行单元测试................................................................................................................................. 7 3.3.1 输入、输出............................................................................................................................. 7 3.3.2 任务 ........................................................................................................................................ 8 3.4 分析单元测试结果 ......................................................................................................................... 8 3.4.1 输入、输出............................................................................................................................. 8 3.4.2 任务 ........................................................................................................................................ 8 附录一单元测试案例设计指南 .................................................................................................................. 9 1. 2. 3.

单元测试目的 .................................................................................................................................... 9 常见模块单元的错误......................................................................................................................... 9 单元测试案例常见设计方法 ........................................................................................................... 10

附件二 JAVA语言单元测试规范 .............................................................................................................. 13

第1章引言

1.1 编写目的

为了提高整个开发中心产品和项目的测试效率，保证产品与项目内部系统集成测试的顺利进行，现要求技术部各项目组在提交项目之前必须进行严格的单元测试，即按照代码的单元组成逐个进行测试。

本文档是技术部内部使用的关于进行单元测试（Unit Test）的规范性文档，本文档中描述了单元测试的原则、流程和方法，是软件开发人员在进行单元测试的时候的工作指南。

本文档预期阅读对象为项目经理、项目开发工程师、测试人员等。

第2章概述

单元测试是对软件基本组成单元进行的测试，所谓“单元”是指：

 具有明确的功能

 具有明确的规格定义（详细设计规格说明书）  有与其他部分明确的接口定义  能够与程序的其他部分清晰的进行区分

2.1 单元测试内容

单元测试的依据是详细设计，应对模块内所有重要的控制路径设计测试用例，以便发现模块内部的错误。单元测试的测试类型主要包括：

1 模块接口测试； 2 模块局部数据结构测试； 3 模块边界条件测试；

4 模块中所有独立执行通路测试； 5 模块的各条错误处理通路测试；

6 模块的非法测试，例如在输入数字的地方输入字母；

7代码重用测试，在开发过程中有些模块功能几乎相同，程序员在重用代码时可能忘记在原有代码上修改或修改不全面，而造成的错误；

8系统兼容测试，例如浏览器的兼容性测试和系统的兼容性测试。

2.2 单元测试力度

要求测试力度满足：

语句覆盖：使被测程序的每条语句至少执行一次；判定覆盖：使被测程序的每一分支执行一次；

条件覆盖：要求判定中的每个条件均为“真”、“假”两种结果至少执行一次；

条件组合覆盖：让条件覆盖中的结果的所有可能组合至少出现一次；

2.3 单元测试步骤

单元测试的侧重点在于发现程序设计或者实现中的逻辑错误。它分为计划、设计、实现、执行和评估五个步骤。各步骤的定义如下：

1) 计划单元测试：确定测试需求，制订测试策略，确定测试所用资源，创建测试任务的时间

表。

2) 设计单元测试：设计单元测试模型，制订测试方案，确认测试过程

3) 实现单元测试：根据单元测试计划和方案，制订具体的测试用例，创建可重用的测试脚本。 4) 执行单元测试：根据单元测试的方案、用例对软件单元进行测试，验证测试结果并记录测

试过程中出现的缺陷。

5) 评估单元测试：对单元测试的结果进行评估，主要从需求覆盖和代码覆盖的角度进行测试

完备性的评估。

一般认为单元测试应紧接在编码之后，当源程序编制完成并通过复审和编译检查，便可开始单元测试。测试用例的设计应与复审工作相结合，根据设计信息选取测试数据，将增大发现各类错误的可能性。在确定测试用例的同时，应给出期望结果。项目组完成单元测试，向测试组提交验收版本的同时必须一并递交单元测试案例及测试问题报告记录。

测试组取得需测试系统的版本及相关文档，若在测试期间发现单元测试中记录的问题，如实记录。

第3章单元测试步骤

3.1 设计单元测试方案

3.1.1 输入、输出

3.1.2 任务

1. 设计单元测试的模型，一般如下图所示

构造单元测试模型需要：

 定义（设计）驱动模块，用以调用被测程序单元

 定义（设计）测试桩模块，用以模拟被测程序单元调用的函数接口  设计测试数据和状态，准备单元测试的动态结构  确定测试的流程

另外，测试模型也可能是由所采用的测试工具所决定的。

2. 指定测试项目：指定对不同特性（或者特性组合）进行足够测试的途径，包括测试工具、方法

和技术的描述以及对测试结果进行提取和分析的方法。

3. 定义测试完备性标准（例如代码覆盖、路径覆盖或者条件覆盖），并设计判定测试完备性的手段，

例如利用工具或者设计测试代码等。

3.2 编写单元测试CASE

3.2.1 输入、输出

3.2.2 任务

1. 根据《XXX单元测试方案》构造测试环境（将待测程序单元纳入测试工具；实现驱动模块和

桩模块），编写测试代码（自己开发或使用测试工具）。需要的时候生成或者导入测试所需要的数据。

2. 设计单元测试案例

设计测试案例的时候要根据《XXX单元测试方案》中所规定的测试方法、测试项目和完备性标准进行。单元测试案例的设计，主要有以下五个步骤： 1) 为系统运行起来设计测试用例

首先需要设计这样的测试用例，该用例的执行可以证明测试环境和被测单元是可用的。如果这样的测试案例失败了，其他的测试案例都失去了执行的基础 2) 为正向测试而设计测试用例

其次需要设计正向测试案例。这些案例也是基本的单元测试案例，它们是用来证明设计规格说明书中对应的功能和性能指标是否能够实现的。这些测试案例是按照设计说明书中的描述来开发的。

3) 为逆向测试而设计测试用例

逆向测试的测试用例是用来证明软件没有做不应该做的事情。这个步骤可以基于错误猜测的基础进行测试用例的构造。 4) 为特殊要求设计测试用例

从系统的性能、安全性、保密性的角度为具有这些要求的系统制订的测试用例。 5) 为覆盖率设计测试用例

测试案例的设计要保证一定的覆盖率要求，所以在最后一步还需要补充一些测试案例，以保证测试案例对代码、路径、或者条件的覆盖率。

在单元测试的设计当中，针对测试项目和测试覆盖率的要求经常采用如下的一些方法：

A) 规格导出法 B) 等价类划分法 C) 边界值分析法 D) 状态转移测试法 E) 分支测试法 F) 条件测试法

G) 数据定义－使用测试法 H) 内部边界值测试法 I)

错误猜测法

这些方法的具体描述，请参见附录一。

3. 将设计好的测试案例用工具或者文档记录下来。在需要的时候，标注某个测试案例是为了哪个

测试项目而设计的。一般来说，测试案例都需要注明：测试条件、测试输入、测试操作和预期输出这四大要素。

4. 将设计好的测试案例编写成为测试脚本（test script），如果设计自动化测试，驱动模块从测试

脚本中逐条读取测试案例并且通过程序或者测试人员的目测判断程序单元的行为或者输出是否符合预期。一般来说，测试工具或者驱动模块也需要将每一条测试案例执行的结果进行记录，以供分析之用。

3.3 执行单元测试

3.3.1 输入、输出

3.3.2 任务

1. 执行单元测试案例

对单元测试案例的执行一般意味着由驱动模块读取测试脚本，然后通过程序判断或者测试人员目测判断的方式确认测试案例是否执行通过。

a) 首先应该确保测试环境和测试程序能正常执行，如果不能正常执行则需要进行相应修改直

至正常。

b) 在遇到测试案例执行失败而无法执行之后的单元测试案例时，需要调整被测程序单元直到

该案例能够正常执行。修改之后需要重新执行之前的测试案例（回归测试）。使用测试工具或者编写自动化的测试驱动模块可以使这项工作相对容易些。

2. 对测试案例的执行结果进行记录，如果使用工具或者编写了自动化的测试驱动模块，这一步工

作可以自动化。

3. 根据测试结果修改源代码，重新构造测试环境；需要的时候修改测试案例。

3.4 分析单元测试结果

3.4.1 输入、输出

3.4.2 任务

1. 分析测试的完备性，判断是否执行了事先设计的所有测试案例以及在测试过程中新增加的测试

案例。

2. 使用工具或者其他自定义的方法判断单元测试的覆盖率是否符合事先定义的覆盖率。 3. 如果未能达成覆盖率，则补充测试案例，重新执行测试。

附录一单元测试案例设计指南

1. 单元测试目的

单元测试案例的设计要验证被测程序单元的如下这些方面：

1) 是否正确实现了规定的功能

2) 模块内部是否存在错误

2. 常见模块单元的错误

模块内部错误往往存在于下列方面：

1) 模块接口：测试模块的数据流

a) 调用所测模块时输入参数与模块的形式参数在个数、属性、顺序上是否匹配

b) 所测模块在调用其他模块时，它输入给其他模块的参数在个数、属性、顺序上是否匹配 c) 是否修改了只做输入用的形式参数

d) 输出给标准函数的参数在在个数、属性、顺序上是否匹配

e) 全局变量的定义在各模块中是否一致

f) 限制是否通过形式参数来传递

2) 局部数据结构：

g) 不正确的或者不一致的数据类型说明

h) 使用未赋值或者未初始化的变量

j) 错误的初始值或者错误的默认值变量名拼写错误

k) 不一致的数据类型

3) 路径错误：不正确的计算、比较和控制流

4) 错误处理

l) 出错的描述难以理解

m) 出错的描述不足以对错误定位和确定出错原因

n) 显示的错误与实际错误不符

o) 对错误条件的处理不正确

p) 在对错误进行处理之前，错误条件已经引起了系统的干预

5) 边界

q) 在循环的第0次，第一次和最后一次是否有错误

r) 运算或者判断中最大最小值是否有错误

s) 数据流、控制流中刚好大于、小于或等于最大或最小值时是否有错误

3. 单元测试案例常见设计方法

以下是一些单元测试案例的常见设计方法，通过对这些方法的综合运用，可以帮助我们发现上述这些错误。

1) 规格导出法

规格导出法是根据相关的规格说明来设计测试用例，每一个测试用例用来检验一个或多个规格陈述的语句。一个比较实际的办法是按照规格陈述的语句顺序来为被测单元设计测试用例。这种测试用例的设计可以保证在规格说明中所有的要求在测试案例中都能得到体现，但是它只是一种正向测试的思路，需要其他的测试用例的补充才能达成测试的完整性。

2) 等价类划分法

等价类划分是一种正式的测试用例设计方法，它基于被测单元的输入、输出所做的划分，对每一个划分中的所有输入、被测单元都有相同（等价）的反应。例如对一个范围是0-100的整数输入来说，2,38,66应该都具有相同的效力，而－1，120也有相同的效力。等价类划分法就是针对每一个等价类设计至少一个测试案例来确保被测程序单元的处理是完整的。等价类划分的设计方法也属于正向测试的技术。

3) 边界值分析法

边界值分析法使用与等价类划分法相同的划分，只是边界值分析假定错误更多地存在于两个划分的边界上，相应地为边界上及两侧的情况设计测试用例。

4) 状态转移测试

对于那些以状态机作为模型或者设计为状态机的软件，状态转移测试是合适的。状态转移测试法的测试案例涵盖能导致状态迁移的事件来测试状态之间的转换是否正确。用这种方法可以测试逆向的测试用例，如状态和事件的非法组合。

5) 分支测试法

在分支测试中，根据单元中控制流分支或者判断点来设计测试用例。这通常用于达到一定的测试覆盖率。在单元测试中，如果使用黑盒测试技术，那么需要去猜测存在哪些逻辑分支并相应为这些分支的执行准备测试用例，如果使用白盒测试技术，那么则需要根据该程序单元中的控制流设计测试案例，完成分支覆盖的要求。

6) 条件测试法

条件测试法中包涵了很多测试案例设计技术，它们都致力于弥补在遇到复杂逻辑条件的时候分支测试的弱点。条件测试的目标是测试在每个逻辑条件的单个成份及它们组合的情况下程序都是正确的。在考虑各个逻辑条件的组合的时候，决策表是一种有用的工具。

在条件测试法中，需要设计足够的测试案例，确保每种逻辑条件的组合都被测试到。

7) 数据定义－使用测试法

数据定义是指数据被赋值的地方，数据使用是指数据项被读取或者使用的地方。使用这种方法设计测试案例时，主要考虑用案例来驱动数据被定义到被使用的路径。这种方法主要用于检查数据的初始化和处理的正确性，也可以在静态检查中使用。

8) 内部边界值测试法

这种方法与边界值分析法类似，但是它偏重的是白盒测试技术，也就是说从程序单元的规格说明中导出等价类和边界值。除了外部可见的数据之外，程序的内部的数据也存在等价类和边界值，它们只能通过对程序单元的设计规格说明进行分析而得到。内部边界值测试法一般只作为测试案例设计的补充方法，与其他方法结合使用。

9) 错误猜测法

错误猜测是基于经验和其他一些测试技术的。在经验的基础上，测试设计者猜测错误的类型及在特定的软件中错误发生的位置，并设计测试用例去发现它们。例如，如果所有的资源需要动态申请，那么我们就需要判断是否所有的资源都被正确释放了。一个发现错误的好地方就是资源释放的地方。对一个有经验工程师，错误猜测法可能是最好的设计测试案例的方法，因为它可能发现别的设计方法所遗漏的错误。为了最大限度的利用有效的经验并逐步丰富测试用例的设计技术，建立一个错误类型的列表是一个好方法，这个列表可以帮助工程师猜测程序单元中的错误会在哪里。这个列表需要通过在实践中不断的维护和扩充来帮助达成错误猜测的有效性。

附件二 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 常量定义（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 语句来强调只执行两组语句中的一组。禁止 ELSE GOTO 和 ELSE RETURN。

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 程序与环境或状态发生关系时，必须主动去处理发生的意外事件，如文件能否

逻辑锁定、打印机是否联机等。

4.8 单元测试也是编程的一部份，提交联调测试的程序必须通过单元测试。

5. 可重用性要求

5.1 重复使用的完成相对独立功能的算法或代码应抽象为公共控件或类。

5.2 公共控件或类应考虑OO思想，减少外界联系，考虑独立性或封装性。

5.3 公共控件或类应建立使用模板。

命名规范

定义这个规范的目的是让项目中所有的文档都看起来像一个人写的，增加可读性，减少项目组中因为换人而带来的损失。（这些规范并不是一定要绝对遵守，但是一定要让程序有良好的可读性）

Package 的命名

Package 的名字应该都是由一个小写单词组成。

Class 的命名

Class 的名字必须由大写字母开头而其他字母都小写的单词组成

Class 变量的命名

变量的名字必须用一个小写字母开头。后面的单词用大写字母开头。

Static Final 变量的命名

Static Final 变量的名字应该都大写，并且指出完整含义。

参数的命名

参数的名字必须和变量的命名规范一致。

数组的命名

数组应该总是用下面的方式来命名：

byte[] buffer;

而不是：

byte buffer[];

方法的参数

使用有意义的参数命名，如果可能的话，使用和要赋值的字段一样的名字：

SetCounter(int size){

this.size = size;

}

Java 文件样式

所有的 Java(*.java) 文件都必须遵守如下的样式规则

版权信息

版权信息必须在 java 文件的开头，比如：

/**

* Copyright @ 2015 Uddtrip.com.

其他不需要出现在 javadoc 的信息也可以包含在这里。

Package/Imports

package 行要在 import 行之前，import 中标准的包名要在本地的包名之前，而且按照字母顺序排列。如果 import 行中包含了同一个包中的不同子目录，则应该用 * 来处理。

package hotlava.net.stats;

import java.io.*;

import java.util.Observable;

import hotlava.util.Application;

这里 java.io.* 使用来代替InputStream and OutputStream 的。

Class

接下来的是类的注释，一般是用来解释类的。

/**

* A class representing a set of packet and byte counters

* It is observable to allow it to be watched, but only

* reports changes when the current set is complete

接下来是类定义，包含了在不同的行的 extends 和 implements

public class CounterSet

extends Observable

implements Cloneable

Class Fields

接下来是类的成员变量：

/**

* Packet counters

protected int[] packets;

public 的成员变量必须生成文档（JavaDoc）。Proceted、private和 package 定义的成员变量如果名字含义明确的话，可以没有注释。

存取方法

接下来是类变量的存取的方法。它只是简单的用来将类的变量赋值获取值的话，可以简单的写在一行上。

/**

* Get the counters

* @return an array containing the statistical data. This array has been

* freshly allocated and can be modified by the caller.

public int[] getPackets() { return copyArray(packets, offset); }

public int[] getBytes() { return copyArray(bytes, offset); }

public int[] getPackets() { return packets; }

public void setPackets(int[] packets) { this.packets = packets; }

其它的方法不要写在一行上

构造函数

接下来是构造函数，它应该用递增的方式写（比如：参数多的写在后面）。

访问类型 ("public", "private" 等.) 和任何 "static", "final" 或 "synchronized" 应该在一

行中，并且方法和参数另写一行，这样可以使方法和参数更易读。

public

CounterSet(int size){

this.size = size;

}

克隆方法

如果这个类是可以被克隆的，那么下一步就是 clone 方法：

public

Object clone() {

try {

CounterSet obj = (CounterSet)super.clone();

obj.packets = (int[])packets.clone();

obj.size = size;

return obj;

}catch(CloneNotSupportedException e) {

throw new InternalError("Unexpected CloneNotSUpportedException: " + e.getMessage()); }

}

类方法

下面开始写类的方法：

/**

* Set the packet counters

* (such as when restoring from a database)

protected final

void setArray(int[] r1, int[] r2, int[] r3, int[] r4)

throws IllegalArgumentException

{

// Ensure the arrays are of equal size

if (r1.length != r2.length || r1.length != r3.length || r1.length != r4.length) throw new IllegalArgumentException("Arrays must be of the same size");

System.arraycopy(r1, 0, r3, 0, r1.length);

System.arraycopy(r2, 0, r4, 0, r1.length);

}

toString 方法

无论如何，每一个类都应该定义 toString 方法：

public

String toString() {

String retval = "CounterSet: ";

for (int I = 0; I

retval += data.bytes.toString();

retval += data.packets.toString();

}

return retval;

}

main 方法

如果main(String[]) 方法已经定义了, 那么它应该写在类的底部.

代码编写格式

代码样式

代码应该用 unix 的格式，而不是 windows 的（比如：回车变成回车+换行）

文档化

必须用 javadoc 来为类生成文档。不仅因为它是标准，这也是被各种 java 编译器都认可的方法。使用 @author 标记是不被推荐的，因为代码不应该是被个人拥有的。

缩进

缩进应该是每行2个空格. 不要在源文件中保存Tab字符. 在使用不同的源代码管理工具时Tab字符将因为用户设置的不同而扩展为不同的宽度.

如果你使用 UltrEdit 作为你的 Java 源代码编辑器的话，你可以通过如下操作来禁止保存Tab字符, 方法是通过 UltrEdit中先设定 Tab 使用的长度室2个空格，然后用 Format|Tabs to Spaces 菜单将 Tab 转换为空格。

页宽

页宽应该设置为80字符. 源代码一般不会超过这个宽度, 并导致无法完整显示, 但这一设置也可以灵活调整. 在任何情况下, 超长的语句应该在一个逗号或者一个操作符后折行. 一条语句折行后, 应该比原来的语句再缩进2个字符.

{} 对

{} 中的语句应该单独作为一行. 例如, 下面的第1行是错误的, 第2行是正确的:

if (i>0) { I ++ }; // 错误, { 和 } 在同一行

if (i>0) {

I ++

}; // 正确, { 单独作为一行

} 语句永远单独作为一行.

如果 } 语句应该缩进到与其相对应的 { 那一行相对齐的位置。

括号

左括号和后一个字符之间不应该出现空格, 同样, 右括号和前一个字符之间也不应该出现空格. 下面的例子说明括号和空格的错误及正确使用:

CallProc( Aparameter ); // 错误

CallProc(Aparameter); // 正确

不要在语句中使用无意义的括号. 括号只应该为达到某种目的而出现在源代码中。下面的例子说明错误和正确的用法:

if ((I) = 42) { // 错误 - 括号毫无意义

if (I == 42) or (J == 42) then // 正确 - 的确需要括号

程序编写规范

exit()

exit 除了在 main 中可以被调用外，其他的地方不应该调用。因为这样做不给任何代码代码机会来截获退出。一个类似后台服务地程序不应该因为某一个库模块决定了要退出就退出。

异常

申明的错误应该抛出一个RuntimeException或者派生的异常。

顶层的main()函数应该截获所有的异常，并且打印（或者记录在日志中）在屏幕上。

垃圾收集

JAVA使用成熟的后台垃圾收集技术来代替引用计数。但是这样会导致一个问题：你必须在使用完对象的实例以后进行清场工作。比如一个prel的程序员可能这么写：

„

{

FileOutputStream fos = new FileOutputStream(projectFile);

project.save(fos, "IDE Project File");

}

„

除非输出流一出作用域就关闭，非引用计数的程序语言，比如JAVA，是不能自动完成变量的清场工作的。必须象下面一样写：

FileOutputStream fos = new FileOutputStream(projectFile);

project.save(fos, "IDE Project File");

fos.close();

Clone

下面是一种有用的方法：

implements Cloneable

public

Object clone()

{

try {

ThisClass obj = (ThisClass)super.clone();

obj.field1 = (int[])field1.clone();

obj.field2 = field2;

return obj;

} catch(CloneNotSupportedException e) {

throw new InternalError("Unexpected CloneNotSUpportedException: " + e.getMessage()); }

}

final 类

绝对不要因为性能的原因将类定义为 final 的（除非程序的框架要求）

如果一个类还没有准备好被继承，最好在类文档中注明，而不要将她定义为 final 的。这是因为没有人可以保证会不会由于什么原因需要继承她。

访问类的成员变量

大部分的类成员变量应该定义为 protected 的来防止继承类使用他们。

注意，要用"int[] packets"，而不是"int packets[]"，后一种永远也不要用。

public void setPackets(int[] packets) { this.packets = packets; }

CounterSet(int size)

{

this.size = size;

}

单元测试规范

V1.0

文档变更历史

第1章 1.1 第2章 2.1 2.2 2.3 第3章

附件二 JAVA语言单元测试规范 .............................................................................................................. 13

第1章引言

1.1 编写目的

本文档预期阅读对象为项目经理、项目开发工程师、测试人员等。

第2章概述

单元测试是对软件基本组成单元进行的测试，所谓“单元”是指：

 具有明确的功能

 具有明确的规格定义（详细设计规格说明书）  有与其他部分明确的接口定义  能够与程序的其他部分清晰的进行区分

2.1 单元测试内容

单元测试的依据是详细设计，应对模块内所有重要的控制路径设计测试用例，以便发现模块内部的错误。单元测试的测试类型主要包括：

1 模块接口测试； 2 模块局部数据结构测试； 3 模块边界条件测试；

4 模块中所有独立执行通路测试； 5 模块的各条错误处理通路测试；

6 模块的非法测试，例如在输入数字的地方输入字母；

7代码重用测试，在开发过程中有些模块功能几乎相同，程序员在重用代码时可能忘记在原有代码上修改或修改不全面，而造成的错误；

8系统兼容测试，例如浏览器的兼容性测试和系统的兼容性测试。

2.2 单元测试力度

要求测试力度满足：

语句覆盖：使被测程序的每条语句至少执行一次；判定覆盖：使被测程序的每一分支执行一次；

条件覆盖：要求判定中的每个条件均为“真”、“假”两种结果至少执行一次；

条件组合覆盖：让条件覆盖中的结果的所有可能组合至少出现一次；

2.3 单元测试步骤

单元测试的侧重点在于发现程序设计或者实现中的逻辑错误。它分为计划、设计、实现、执行和评估五个步骤。各步骤的定义如下：

1) 计划单元测试：确定测试需求，制订测试策略，确定测试所用资源，创建测试任务的时间

表。

2) 设计单元测试：设计单元测试模型，制订测试方案，确认测试过程

试过程中出现的缺陷。

5) 评估单元测试：对单元测试的结果进行评估，主要从需求覆盖和代码覆盖的角度进行测试

完备性的评估。

测试组取得需测试系统的版本及相关文档，若在测试期间发现单元测试中记录的问题，如实记录。

第3章单元测试步骤

3.1 设计单元测试方案

3.1.1 输入、输出

3.1.2 任务

1. 设计单元测试的模型，一般如下图所示

构造单元测试模型需要：

 定义（设计）驱动模块，用以调用被测程序单元

 定义（设计）测试桩模块，用以模拟被测程序单元调用的函数接口  设计测试数据和状态，准备单元测试的动态结构  确定测试的流程

另外，测试模型也可能是由所采用的测试工具所决定的。

2. 指定测试项目：指定对不同特性（或者特性组合）进行足够测试的途径，包括测试工具、方法

和技术的描述以及对测试结果进行提取和分析的方法。

3. 定义测试完备性标准（例如代码覆盖、路径覆盖或者条件覆盖），并设计判定测试完备性的手段，

例如利用工具或者设计测试代码等。

3.2 编写单元测试CASE

3.2.1 输入、输出

3.2.2 任务

1. 根据《XXX单元测试方案》构造测试环境（将待测程序单元纳入测试工具；实现驱动模块和

桩模块），编写测试代码（自己开发或使用测试工具）。需要的时候生成或者导入测试所需要的数据。

2. 设计单元测试案例

3) 为逆向测试而设计测试用例

逆向测试的测试用例是用来证明软件没有做不应该做的事情。这个步骤可以基于错误猜测的基础进行测试用例的构造。 4) 为特殊要求设计测试用例

从系统的性能、安全性、保密性的角度为具有这些要求的系统制订的测试用例。 5) 为覆盖率设计测试用例

测试案例的设计要保证一定的覆盖率要求，所以在最后一步还需要补充一些测试案例，以保证测试案例对代码、路径、或者条件的覆盖率。

在单元测试的设计当中，针对测试项目和测试覆盖率的要求经常采用如下的一些方法：

A) 规格导出法 B) 等价类划分法 C) 边界值分析法 D) 状态转移测试法 E) 分支测试法 F) 条件测试法

G) 数据定义－使用测试法 H) 内部边界值测试法 I)

错误猜测法

这些方法的具体描述，请参见附录一。

3. 将设计好的测试案例用工具或者文档记录下来。在需要的时候，标注某个测试案例是为了哪个

测试项目而设计的。一般来说，测试案例都需要注明：测试条件、测试输入、测试操作和预期输出这四大要素。

4. 将设计好的测试案例编写成为测试脚本（test script），如果设计自动化测试，驱动模块从测试

3.3 执行单元测试

3.3.1 输入、输出

3.3.2 任务

1. 执行单元测试案例

对单元测试案例的执行一般意味着由驱动模块读取测试脚本，然后通过程序判断或者测试人员目测判断的方式确认测试案例是否执行通过。

a) 首先应该确保测试环境和测试程序能正常执行，如果不能正常执行则需要进行相应修改直

至正常。

b) 在遇到测试案例执行失败而无法执行之后的单元测试案例时，需要调整被测程序单元直到

2. 对测试案例的执行结果进行记录，如果使用工具或者编写了自动化的测试驱动模块，这一步工

作可以自动化。

3. 根据测试结果修改源代码，重新构造测试环境；需要的时候修改测试案例。

3.4 分析单元测试结果

3.4.1 输入、输出

3.4.2 任务

1. 分析测试的完备性，判断是否执行了事先设计的所有测试案例以及在测试过程中新增加的测试

案例。

2. 使用工具或者其他自定义的方法判断单元测试的覆盖率是否符合事先定义的覆盖率。 3. 如果未能达成覆盖率，则补充测试案例，重新执行测试。

附录一单元测试案例设计指南

1. 单元测试目的

单元测试案例的设计要验证被测程序单元的如下这些方面：

1) 是否正确实现了规定的功能

2) 模块内部是否存在错误

2. 常见模块单元的错误

模块内部错误往往存在于下列方面：

1) 模块接口：测试模块的数据流

a) 调用所测模块时输入参数与模块的形式参数在个数、属性、顺序上是否匹配

b) 所测模块在调用其他模块时，它输入给其他模块的参数在个数、属性、顺序上是否匹配 c) 是否修改了只做输入用的形式参数

d) 输出给标准函数的参数在在个数、属性、顺序上是否匹配

e) 全局变量的定义在各模块中是否一致

f) 限制是否通过形式参数来传递

2) 局部数据结构：

g) 不正确的或者不一致的数据类型说明

h) 使用未赋值或者未初始化的变量

j) 错误的初始值或者错误的默认值变量名拼写错误

k) 不一致的数据类型

3) 路径错误：不正确的计算、比较和控制流

4) 错误处理

l) 出错的描述难以理解

m) 出错的描述不足以对错误定位和确定出错原因

n) 显示的错误与实际错误不符

o) 对错误条件的处理不正确

p) 在对错误进行处理之前，错误条件已经引起了系统的干预

5) 边界

q) 在循环的第0次，第一次和最后一次是否有错误

r) 运算或者判断中最大最小值是否有错误

s) 数据流、控制流中刚好大于、小于或等于最大或最小值时是否有错误

3. 单元测试案例常见设计方法

以下是一些单元测试案例的常见设计方法，通过对这些方法的综合运用，可以帮助我们发现上述这些错误。

1) 规格导出法

2) 等价类划分法

3) 边界值分析法

4) 状态转移测试

5) 分支测试法

6) 条件测试法

在条件测试法中，需要设计足够的测试案例，确保每种逻辑条件的组合都被测试到。

7) 数据定义－使用测试法

8) 内部边界值测试法

9) 错误猜测法

附件二 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 常量定义（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 语句来强调只执行两组语句中的一组。禁止 ELSE GOTO 和 ELSE RETURN。

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 程序与环境或状态发生关系时，必须主动去处理发生的意外事件，如文件能否

逻辑锁定、打印机是否联机等。

4.8 单元测试也是编程的一部份，提交联调测试的程序必须通过单元测试。

5. 可重用性要求

5.1 重复使用的完成相对独立功能的算法或代码应抽象为公共控件或类。

5.2 公共控件或类应考虑OO思想，减少外界联系，考虑独立性或封装性。

5.3 公共控件或类应建立使用模板。

命名规范

Package 的命名

Package 的名字应该都是由一个小写单词组成。

Class 的命名

Class 的名字必须由大写字母开头而其他字母都小写的单词组成

Class 变量的命名

变量的名字必须用一个小写字母开头。后面的单词用大写字母开头。

Static Final 变量的命名

Static Final 变量的名字应该都大写，并且指出完整含义。

参数的命名

参数的名字必须和变量的命名规范一致。

数组的命名

数组应该总是用下面的方式来命名：

byte[] buffer;

而不是：

byte buffer[];

方法的参数

使用有意义的参数命名，如果可能的话，使用和要赋值的字段一样的名字：

SetCounter(int size){

this.size = size;

}

Java 文件样式

所有的 Java(*.java) 文件都必须遵守如下的样式规则

版权信息

版权信息必须在 java 文件的开头，比如：

/**

其他不需要出现在 javadoc 的信息也可以包含在这里。

Package/Imports

package hotlava.net.stats;

import java.io.*;

import java.util.Observable;

import hotlava.util.Application;

这里 java.io.* 使用来代替InputStream and OutputStream 的。

Class

接下来的是类的注释，一般是用来解释类的。

/**

* A class representing a set of packet and byte counters

* It is observable to allow it to be watched, but only

* reports changes when the current set is complete

接下来是类定义，包含了在不同的行的 extends 和 implements

public class CounterSet

extends Observable

implements Cloneable

Class Fields

接下来是类的成员变量：

/**

* Packet counters

protected int[] packets;

public 的成员变量必须生成文档（JavaDoc）。Proceted、private和 package 定义的成员变量如果名字含义明确的话，可以没有注释。

存取方法

接下来是类变量的存取的方法。它只是简单的用来将类的变量赋值获取值的话，可以简单的写在一行上。

/**

* Get the counters

* @return an array containing the statistical data. This array has been

* freshly allocated and can be modified by the caller.

public int[] getPackets() { return copyArray(packets, offset); }

public int[] getBytes() { return copyArray(bytes, offset); }

public int[] getPackets() { return packets; }

public void setPackets(int[] packets) { this.packets = packets; }

其它的方法不要写在一行上

构造函数

接下来是构造函数，它应该用递增的方式写（比如：参数多的写在后面）。

访问类型 ("public", "private" 等.) 和任何 "static", "final" 或 "synchronized" 应该在一

行中，并且方法和参数另写一行，这样可以使方法和参数更易读。

public

CounterSet(int size){

this.size = size;

}

克隆方法

如果这个类是可以被克隆的，那么下一步就是 clone 方法：

public

Object clone() {

try {

CounterSet obj = (CounterSet)super.clone();

obj.packets = (int[])packets.clone();

obj.size = size;

return obj;

}catch(CloneNotSupportedException e) {

throw new InternalError("Unexpected CloneNotSUpportedException: " + e.getMessage()); }

}

类方法

下面开始写类的方法：

/**

* Set the packet counters

* (such as when restoring from a database)

protected final

void setArray(int[] r1, int[] r2, int[] r3, int[] r4)

throws IllegalArgumentException

{

// Ensure the arrays are of equal size

if (r1.length != r2.length || r1.length != r3.length || r1.length != r4.length) throw new IllegalArgumentException("Arrays must be of the same size");

System.arraycopy(r1, 0, r3, 0, r1.length);

System.arraycopy(r2, 0, r4, 0, r1.length);

}

toString 方法

无论如何，每一个类都应该定义 toString 方法：

public

String toString() {

String retval = "CounterSet: ";

for (int I = 0; I

retval += data.bytes.toString();

retval += data.packets.toString();

}

return retval;

}

main 方法

如果main(String[]) 方法已经定义了, 那么它应该写在类的底部.

代码编写格式

代码样式

代码应该用 unix 的格式，而不是 windows 的（比如：回车变成回车+换行）

文档化

缩进

缩进应该是每行2个空格. 不要在源文件中保存Tab字符. 在使用不同的源代码管理工具时Tab字符将因为用户设置的不同而扩展为不同的宽度.

页宽

{} 对

{} 中的语句应该单独作为一行. 例如, 下面的第1行是错误的, 第2行是正确的:

if (i>0) { I ++ }; // 错误, { 和 } 在同一行

if (i>0) {

I ++

}; // 正确, { 单独作为一行

} 语句永远单独作为一行.

如果 } 语句应该缩进到与其相对应的 { 那一行相对齐的位置。

括号

左括号和后一个字符之间不应该出现空格, 同样, 右括号和前一个字符之间也不应该出现空格. 下面的例子说明括号和空格的错误及正确使用:

CallProc( Aparameter ); // 错误

CallProc(Aparameter); // 正确

不要在语句中使用无意义的括号. 括号只应该为达到某种目的而出现在源代码中。下面的例子说明错误和正确的用法:

if ((I) = 42) { // 错误 - 括号毫无意义

if (I == 42) or (J == 42) then // 正确 - 的确需要括号

程序编写规范

exit()

异常

申明的错误应该抛出一个RuntimeException或者派生的异常。

顶层的main()函数应该截获所有的异常，并且打印（或者记录在日志中）在屏幕上。

垃圾收集

„

{

FileOutputStream fos = new FileOutputStream(projectFile);

project.save(fos, "IDE Project File");

}

„

除非输出流一出作用域就关闭，非引用计数的程序语言，比如JAVA，是不能自动完成变量的清场工作的。必须象下面一样写：

FileOutputStream fos = new FileOutputStream(projectFile);

project.save(fos, "IDE Project File");

fos.close();

Clone

下面是一种有用的方法：

implements Cloneable

public

Object clone()

{

try {

ThisClass obj = (ThisClass)super.clone();

obj.field1 = (int[])field1.clone();

obj.field2 = field2;

return obj;

} catch(CloneNotSupportedException e) {

throw new InternalError("Unexpected CloneNotSUpportedException: " + e.getMessage()); }

}

final 类

绝对不要因为性能的原因将类定义为 final 的（除非程序的框架要求）

如果一个类还没有准备好被继承，最好在类文档中注明，而不要将她定义为 final 的。这是因为没有人可以保证会不会由于什么原因需要继承她。

访问类的成员变量

大部分的类成员变量应该定义为 protected 的来防止继承类使用他们。

注意，要用"int[] packets"，而不是"int packets[]"，后一种永远也不要用。

public void setPackets(int[] packets) { this.packets = packets; }

CounterSet(int size)

{

this.size = size;

}

相关文章