开发人员单元测试规范样本

资料内容仅供您学习参考，如有不当之处，请联系改正或者删除。为了提高整个开发中心产品和项目的测试效率,保证产品与项目内部系统集成测试的顺利进行,现要求系统开发部各项目组在提交产品至项目监理部之前必须进行严格的单元测试,即按照代码的单元组成逐个进行测试。具体说明如下:

单元测试内容

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

1

模块接口测试;

2

模块局部数据结构测试;

3

模块边界条件测试;

4

模块中所有独立执行通路测试;

5

模块的各条错误处理通路测试;

6

模块的非法测试,例如在输入数字的地方输入字母;

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

8系统兼容测试,例如有些程序在IE6能运行正常,到IE5下不能运行。有些程序在WIN下能运行,而到WIN98却不能运行。

单元测试力度

要求测试力度满足:

语句覆盖:使被测程序的每条语句至少执行一次;

判定覆盖:使被测程序的每一分支执行一次;

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

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

单元测试步骤

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

测试部由项目监理部取得需测试系统的版本及相关文档,若在测试期间发现单元测试中记录的问题,如实记录。项目监理部视具体情况酌情对该项目组的绩效考核与项目评分加以控制。

不同语言及架构的单元测试见附件。附件一

c＋＋语言单元测试规范

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

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

1适用范围

本标准适用于利用Visul

C++

,Borland

C++进行软件程序开发的人员.。

.2变量命名

命名必须具有一定的实际意义,形式为xAbcFgh,x由变量类型确定,Abc、Fgh表示连续意

义字符串,如果连续意义字符串仅两个,可都大写.如OK.

具体例程:

BOOL类型

bEnable;

ch

*

char

chText

c

*

类对象

cMain(对象实例)

h

*

Handle(句柄)

hWnd

i

*

int

n

*

无符号整型

p

*

指针

sz,str

*

字符串

w

WORD

x,y

坐标

Char或者TCHAR类型

与Windows

API有直接联系的用szAppName[10]形式否则用

FileName[10]形式,单个字符也可用小写字母表示;

Int类型

nCmdShow;

LONG类型

lParam;

UINT类型

uNotify;

DWORD类型

dwStart;

PSTR类型

pszTip;

LPSTR类型

lpCmdLine

LPTSTR类型

lpszClassName;

LPVOID类型

lpReserved

WPARAM类型

wParam,

LPARAM类型

lParam

HWND类型

hDlg;

HDC类型

hDC;

HINSTANCE类型

hInstance

HANDLE类型

hInstance,

HICON类型

hIcon;

int

iTmp

float

fTmp

DWORD

dw*

String

,

AnsiString

str

*

m_

类成员变量

m_nVal,

m_bFlag

g_

全局变量

g_nMsg,

g_bFlag

局部变量中可采用如下几个通用变量:nTemp,nResult,I,J(一般用于循环变量)。

其它资源句柄同上

.3常量命名和宏定义

常量和宏定义必须具有一定的实际意义;

常量和宏定义在#include和函数定义之间;

常量和宏定义必须全部以大写字母来撰写,中间可根据意义的连续性用下划线连接,每一

条定义的右侧必须有一简单的注释,说明其作用;

资源名字定义格式:

菜单:IDM_XX或者CM_XX

位图:IDB_XX

对话框:IDD_XX

字符串:IDS_XX

DLGINIT:DIALOG_XX

ICON:IDR_XX

.4函数命名

函数原型说明包括引用外来函数及内部函数,外部引用必须在右侧注明函数来源:模

块名及文件名,

如是内部函数,只要注释其定义文件名;

第一个字母必须使用大写字母,要求用大小写字母组合规范函数命名,必要时可用下划线

间隔,示例如下:

void

UpdateDB_Tfgd

(TRACK_NAME);

file://Module

Name

:r01/sdw.c

void

PrintTrackData

(TRACK_NAME);

file://Module

Name

:r04/tern.c

void

ImportantPoint

(void);

file://Module

Name

:r01/sdw.c

void

ShowChar

(int

,

int

,

chtype);

file://Local

Module

void

ScrollUp_V

(int

,

int);

file://Local

Module

.5结构体命名

结构体类型命名必须全部用大写字母,原则上前面以下划线开始;结构体变量命名必须用

大小写字母组合,第一个字母必须使用大写字母,必要时可用下划线间隔。对于私有数

据区,必须注明其所属的进程。全局数据定义只需注意其用途。

示例如下:

typedef

struct

{

char

szProductName[20];

char

szAuthor[20];

char

szReleaseDate[16];

char

szVersion[10];

unsigned

long

MaxTables;

unsigned

long

UsedTables;

}DBS_DATABASE;

DBS_DATABASE

GdataBase;

6

控件的命名:

用小写前缀表示类别

用小写前缀表示类别:

fm

窗口

cmd

按钮

cob

combo,下拉式列表框

txt

文本输入框

lab

labal,标签

img

image,图象

pic

picture

grd

Grid,网格

scr

滚动条

lst

列表框

frm

fram

7注释

原则上注释要求使用中文;

文件开始注释内容包括:公司名称、版权、作者名称、时间、模块用途、背景介绍等,复

杂的算法需要加上流程说明;

函数注释包括:输入、输出、函数描述、流程处理、全局变量、调用样例等,复杂的函数

需要加上变量用途说明;

程序中注释包括:修改时间和作者、方便理解的注释等;

引用一:

文件开头的注释模板

/******************************************************************

**

文件名:

**

Copyright

(c)

1998-1999

*********公司技术开发部

**

创立人:

**

日

期:

**

修改人:

**

日

期:

**

描

述:

**

**

版

本:

**--------------------------------------------------------------------------

---

******************************************************************/

引用二:

函数开头的注释模板

/*****************************************************************

**

函数名:

**

输

入:

a,b,c

**

a---

**

b---

**

c---

**

输

出:

x---

**

x

为

1,

表示...

**

x

为

0,

表示...

**

功能描述:

**

全局变量:

**

调用模块:

**

作

者:

**

日

期:

**

修

改:

**

日

期:

**

版本

****************************************************************/

引用三:

程序中的注释模板

/*----------------------------------------------------------*/

/*

注释内容

*/

/*----------------------------------------------------------*/

8

程序

a.

程序编码力求简洁,结构清晰,避免太多的分支结构及太过于技巧性的程序,

尽量不采用递归模式。

b.

编写程序时,亦必须想好测试的方法,换句话说,”单元测试”

的测试方案应

在程序编写时一并拟好。

c.

注释一定要与程序一致。

d.

版本封存以后的修改一定要将老语句用/*

*/

封闭,不能自行删除或修改,并要

在文件及函数的修改记录中加以记录。

e.

程序中每个block

的开头

”{"

及

"}”

必须对齐,嵌套的block

每进一套,

缩进一个tab,TAB

为4个空格,block类型包括if、for、while、do等关键字引出的。

f.

对于比较大的函数,每个block

和特殊的函数调用,都必须注明其功能,举例如下

:

count.divisor

=

1193280

/

freq;

//

compute

the

proper

count

OutByte((unsigned

short)67,

(unsigned

char)182);

//

tell

8253

that

a

count

is

coming

OutByte((unsigned

short)66,

count.

c[0]);

//

send

low-order

byte

OutByte((unsigned

short)66,

count.

c[1]);

//

send

high-order

byte

×××××××××××××××××××××××××××××××××××××××

bcb,delphi中的变量命名:

遵循匈牙利命名法,命

名必须有意义,制定如下规定

窗体:以大写的W开始,如About版权窗体,

命名为WAbout

文件:以大写的F开始,如About版权窗体,文件命名为FAbout.cpp

按钮(Button):如退出按钮,命名为btnExit

……

基类:加base标记,如报表基类,窗体命名为:WBaseRep,

文件命名为FBaseRep.cpp

1.

在.h/.cpp的开头应有一段格式统一的说明,内容包括:

>

a.

文件名

(FileName);

>

b.

创立人

(Creater);

>

c.

文件创立时间

(Date);

>

d.

简短说明文件功能、用途

(Comment)。

好习惯

>

2.

除非极其简单,否则对函数应有注释说明。内容包括:功能、入口/出口参数,必

要

>

时还可有备注或补充说明。

还是好习惯

>

3.

每列代码的长度推荐为

80列,最长不得超过120列;折行以对齐为准。

太宽了,我的限制是60列,因为文本方式下屏幕一共80列,如果你用BC这一类的编辑

器,窗口边框等又要占据一定空间,因此80列太宽

>

4.

循环、分支代码,判断条件与执行代码不得在同一行上。

很对

>

5.

指针的定义,*

号既能够紧接类型,也能够在变量名之前。

>

>

例:可写做:int*

pnsize;

>

>

也可写做:int

*pnsize;

>

>

但不得写做:int

*

pnsize;

建议采用第二种,除非附加另外一条规定:一次只声明一个变量,否则就会让人混淆,

比如:

int*

a,

b;

看起来b仿佛也是个指针,其实不是。

>

6.

在类的成员函数内调用非成员函数时,在非成员函数名前必须加上"::"。

这一条我倒觉得并不是必须的,我的看法是决不要让你的类成员函数和全局函数的名称

相同(或类似)

>

7.

函数入口参数有缺省值时,应注释说明。

>

>

例:BOOL

CWpsDib::PaintDIB(CDC*

pDC,

CRect&

rc,

>

int

nBrightness,

file://*=0*//

>

BOOL

bGrayScale

file://*=FALSE*//

)

每个变量写一行,必要时加上/*in,

out*/注释

>

8.

else

if

必须写在一行。

应该尽量避免else

if这样的结构

>

9.

与„{‟、„}‟有关的各项规定:

>

>

9.1„{‟、„}‟应独占一行。在该行内可有注释。

>

9.2

„{‟必须另起一行,„{‟

之后的代码必须缩进一个Tab。„{‟与„}‟必须在

同

>

一列上。

>

9.3

在循环、分支之后若只有一行代码,虽然可省略„{‟、„}‟,但不推荐这么

>

做。若省略后可能引起歧义,则必须加上„{‟、„}‟。

持保留意见,因为GNU的代码规范是这样的:

if

(

NULL

==

ptr

)

{

//

do

something

here

}

或者

if

(

NULL

==

ptr

)

{

//

do

something

here

}

争论哪个更好并没有意义,关键是统一,如果用VC当然你的办法最方便,可是如果你用

emacs或者vi,就不是这样了。

>

10.

与空格有关的各项规定。

>

>

10.1

在所有两目、三目运算符的两边都必须有空格。在单目运算符两端不必空格。

但

>

在„—>‟、„::‟、„.‟、„[‟、„]‟等运算符前后,及„&‟(取地址)、„*

>

‟(取值)等运算符之后不得有空格。

>

10.2

for、while、if

等关键词之后应有1个空格,再接„(‟,之后无空格;在结

尾

>

的„)‟前不得有空格。

我认为在括号两端加空格并不是什么错误,特别是在一个条件十分复杂的if语句里

>

10.3

调用函数、宏时,„(‟、„)‟前后不得有空格。

>

10.4

类型强制转换时,„(‟„)‟前后不得有空格

同上

>

11.

与缩进有关的各项规定

>

>

11.1

缩进以

Tab

为单位。1

个

Tab

为

4

个空格

我认为这个值应该更大,我自己使用8个空格,如果你的代码因为缩进幅度太大而导致

折行,那么几乎能够肯定你的程序设计方案有问题。

>

11.2

下列情况,代码缩进一个

Tab:

>

1.

函数体相对函数名及'{'、'}'。

>

2.

if、else、for、while、do

等之后的代码。>

3.

一行之内写不下,折行之后的代码,应在合理的位置进行折行。若有

+

-

*

/

等

运

>

算符,则运算符应在上一行末尾,而不应在下一行的行首。

这一条我反对,运算符应该放在下一行行首,以使人能清楚的知道这一行是续上一行

的,比如

if

(

something

&&

somethingelse

&&

otherthings

)

如果写做

if

(

something

&&

somethingelse

&&

otherthings

)

反而看不清楚

>

11.3

下列情况,不必缩进: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

常量定义(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

?

Shanghai

XXX

Co.

Ltd.

*

All

right

reserved.

*/

其它不需要出现在

javadoc

的信息也能够包含在这里。

Package/Imports

package

行要在

import

行之前,import

中标准的包名要在本地的包名之前,而且按照字母顺序排列。如果

import

行中包含了同一个包中的不同子目录,则应该用

*

来处理。

package

.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

<

data.length();

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

++

};

//

正确,

{

单独作为一行

}

语句永远单独作为一行.

如果

}

语句应该缩进到与其相对应的

{

那一行相对齐的位置。

括号

左