单元测试规范.docx

上传人:b****1 文档编号:1430078 上传时间:2023-05-01 格式:DOCX 页数:10 大小:20KB
下载 相关 举报
单元测试规范.docx_第1页
第1页 / 共10页
单元测试规范.docx_第2页
第2页 / 共10页
单元测试规范.docx_第3页
第3页 / 共10页
单元测试规范.docx_第4页
第4页 / 共10页
单元测试规范.docx_第5页
第5页 / 共10页
单元测试规范.docx_第6页
第6页 / 共10页
单元测试规范.docx_第7页
第7页 / 共10页
单元测试规范.docx_第8页
第8页 / 共10页
单元测试规范.docx_第9页
第9页 / 共10页
单元测试规范.docx_第10页
第10页 / 共10页
亲,该文档总共10页,全部预览完了,如果喜欢就下载吧!
下载资源
资源描述

单元测试规范.docx

《单元测试规范.docx》由会员分享,可在线阅读,更多相关《单元测试规范.docx(10页珍藏版)》请在冰点文库上搜索。

单元测试规范.docx

单元测试规范

密级:

普通

文件编号:

文件类别:

测试管理体系文件

发放号:

1001

华中8型软件

单元测试规范

版本:

华中数控软件开发部

版本说明

日期

版本号

发布说明

作者

批准人

2015/1/28

王蓉

2015/2/10

王蓉

 

1引言

1.1编写目的

1.1.1编写目的

本文档规定了HNC8软件单元测试方法和步骤、测试用例的设计方法、测试代码的书写规范、流程以及单元测试的产品提交和验收规范,目的在于控制单元测试的质量,加强项目的质量管理,从而提高整个产品的质量。

1.1.2适用范围

主要是8型软件的单元测试、部分系统平台软件模块测试。

1.1.3预期读者

本文档的预期读者为项目的项目经理、产品经理、系统软件主研人员、应用软件主研人员、高级测试人员等。

1.2背景

HNC8系统软件平台是各产品和项目的重要组成部分,为HNC8软件开发人员提供必要的测试环境。

本规范的提出和制订旨在为软件单元测试提供依据和支持。

1.3定义

被测模块:

需要进行模块级测试的应用软件系统的一个单元或模块,也称被测单元。

测试单元:

用于对被测模块进行单元级测试,由源代码、测试脚本和输入数据等构成的程序单元。

1.4参考文档

[1]C++Test用户手册

[2]单元测试快速起步

2单元测试

2.1单元的定义

对于结构化的编程语言,程序单元指程序中定义的函数或子程序。

单元测试是指对函数或子程序所进行的测试。

对于面向对象的编程语言,程序单元指特定的一个具体的类或相关的多个类。

单元测试主是指对类方法的测试。

2.2角色工作体系

角色

职责

开发/测试组长

审查单元测试过程,对测试结果进行评估。

根据单元测试发现的缺陷提出变更申请。

开发/测试工程师

对单元代码进行检查,设计单元测试用例,加载运行测试用例,记录和分析测试结果,提交单元测试Bug。

配置管理员

管理测试需要的资源,包括软硬件环境,版本管理和Bug管理。

2.3单元测试规程

包括静态的代码审查和动态测试两个阶段。

静态代码审查是按照《静态检查规范》中的条项对单元模块进行逐项检查,并填写《单元测试Bug清单》。

动态测试阶段首先设计相应的测试用例。

测试用例应该覆盖单元模块的所有功能项,如果单元模块有性能、余量等其它测试特性要求,则必须设计相应的测试用例测试这些特性。

执行测试用例,运行得到测试结果,比对测试结果查看单元测试覆盖率是否达标。

如果发现错误或Bug,提交单元测试Bug。

2.3.1静态代码检查

要求:

根据《静态检查规范》中的要求,对被测试单元进行逐项检查,检查后在对应的条项后进行标记,发现问题后,提交单元测试Bug。

2.3.2测试用例设计

测试用例是测试数据及与之相关的测试规程的一个特定的集合,它是为验证被测试程序(为测试路径或验证是否符合特定需求)而产生的。

测试用例设计用于白盒测试和黑盒测试。

白盒测试进入的前提条件是在测试人员已经对被测试对象有了一定的了解,基本上明确了被测试软件的逻辑结构。

过程是通过针对程序逻辑结构设计和加载测试用例,驱动程序执行,检查在不同点程序的状态,以确定实际的状态是否与预期的状态一致。

1、白盒测试主要是对被测试对象进行如下测试项目:

对程序模块的所有独立的执行路径至少覆盖一次;

对所有的逻辑判定,真假两种情况都至少覆盖一次;

在循环的边界和运行界限内执行循环体;

测试内部数据结构的有效性等。

白盒测试达到的目标:

语句覆盖率达到100%,分支覆盖率达到100%,覆盖程序中主要的路径,主要路径是指完成需求和设计功能的代码所在的路径和程序异常处理执行到的路径。

黑盒测试是要首先了解软件产品具备的功能和性能等需求,再根据需求设计一批测试用例以验证程序内部活动是否符合设计要求的活动。

2、黑盒测试主要是对被测试对象进行如下测试项目:

测试程序单元的功能是否实现;

测试程序单元性能是否满足要求(可选);

可选的其它测试特性,如边界、余量、安全性、可靠性、强度测试、人机交互界面测试等。

黑盒测试达到的目标:

程序单元正确地实现了需求和设计上要求的功能,满足性能要求,同时程序单元要有可靠性和安全性。

2.4单元测试工具

规定使用以下测试工具实现应用软件系统单元测试和子系统集成测试,以及部分系统平台软件模块的相关测试。

请参考《C++简明手册》

1、C++单机版(支持)

下载路径:

\\\tools\软件测试工具\cpptest__win32_独立版

2、C++插件版(支持VS2010)

下载路径:

\\\tools\软件测试工具\插件版

2.5测试的目录结构

1、各个工程存放测试套件、桩函数文件、测试数据

测试源文件通过导入VC工程,源码以链接方式显示在工作空间

/hncapi/api/hncapi/inc_api

/hncapi/libprj/hncapi/plc

测试套件

桩函数文件

2、以hnc8/trunk/为例:

2.6测试代码的书写规范

2.6.1测试套件/测试用例定义规范

【规则1】在测试套件定义中开始注册测试用CPPTEST_TEST_SUITE(TestSuiteName)

例:

CPPTEST_TEST_SUITE(TestSuite_ActivationGetDayNum);

【规则2】在测试套件定义中结束注册测试用例CPPTEST_TEST_SUITE_END()

【规则3】测试用例注册CPPTEST_TEST(testCaseName)

例:

CPPTEST_TEST(test_ActivationGetDayNum_Ok);

CPPTEST_TEST(test_ActivationGetDayNum_Failed);

【规则4】在测试套件源文件中使用该宏来定义给定的测试套件中的测试所设置的源/头文件。

CPPTEST_CONTEXT(testedFile)

例:

CPPTEST_CONTEXT("../api/");

【规则5】在测试套件源代码中使用该宏来设置某个给定的测试套件将在测试可执行文件构建时被添加到某个源文件后面CPPTEST_TEST_SUITE_INCLUDED_TO(testedSource)

例:

CPPTEST_TEST_SUITE_INCLUDED_TO("../api/");

备注:

下图示例,测试套件TestSuite_ActivationGetDayNum及其测试用例注册

2.6.2测试用例初始化变量书写规范

【规则1】初始化输入参数

例:

/*Pre-conditioninitialization*/

/*Initializingargument1(sn)*/

:

:

Bit8*_sn="6933-E8A4-013L-00C1-FBC6-1C13";

【规则2】初始化全局变量

例:

/*Initializingglobalvariable*/

:

:

=0;

:

:

=0;

:

:

=0;

2.6.3测试用例被测单元函数调用规范

【规则】调用被测单元

例:

/*TestedfunctioncallHNC_ActivationSetSn(Bit8*)*/

:

:

Bit32_return=:

:

HNC_ActivationSetSn(_sn);

2.6.4测试用例验证规范

【规则1】断言两个布尔类型值相等

CPPTEST_ASSERT_BOOL_EQUAL(expected,actual)

例:

CPPTEST_ASSERT_BOOL_EQUAL(0,(_return));

【规则2】断言两个整型值相等

CPPTEST_ASSERT_INTEGER_EQUAL(expected,actual)

例:

CPPTEST_ASSERT_INTEGER_EQUAL(0,(_return));

CPPTEST_ASSERT_INTEGER_EQUAL(66,(:

:

));

【规则3】断言两个指针类型字符串相等

CPPTEST_ASSERT_PTR_EQUAL(expected,actual)

2.6.5完整测试用例实例

2.6.6桩函数书写规范

【规则】查询当前执行的测试用

boolCppTest_IsCurrentTestCase(constchar*id)

例:

voidCppTest_Stub_nc_gettime(:

:

nctime_t*ptime)

{

if(CppTest_IsCurrentTestCase("test_HNC_ActivationSetSn_Ok"))

{

ptime->year=2015;

ptime->month=1;

ptime->day=20;

}

}

2.7测试单元的文件组成及命名规范

每个测试单元由测试代码文件、程序主函数文件和编译运行脚本文件组成,单元测试完成之后还生成一系列测试报告,这些测试报告将与模块单元一起提交。

测试单元包含如下文件及其所处目录位置如下所述:

【规则1】测试套件命名TestSuite_测试单元函数名.cpp

例如:

【规则2】测试用例命名test_测试单元函数名_测试简明标识

例如:

test_HNC_ActivationLoad_Failed

test_HNC_ActivationLoad_Ok

test_HNC_ActivationLoad_Null

【规则3】自定义测试桩命名测试单元函数名

例如:

【规则4】测试文件地址:

C++test工作空间下,对应各工程文件的test文件夹的路径

例如:

\workspace\hncapi\tests\autogenerated\api\

【规则5】自定义测试桩文件地址:

C++test工作空间下,对应各工程文件的stubs文件夹的路径。

例如:

\workspace\hncapi\stubs

2.8单元测试的实施规范

按照单元测试规程进行实施,进行代码审查和动态测试。

【规则1】从服务器下载最新源码,导入项目来创建C++test项目,添加各个工程对应的测试文件到本地。

【规则2】要求静态检查通过后,再开始单元测试。

【规则3】在写测试用例驱动时,所有外部传入参数、全局变量等都需要进行初始化。

【规则4】调用原始定义的桩函数时,该桩函数应该是系统标准函数或者是已通过测试的函数。

【规则5】系统函数作为桩函数时,一般情况采用原始定义,特殊情况可以自定义。

【规则6】在编写或调试测试驱动和桩时,禁止修改源代码进行调试。

【规则7】测试结果输出,要根据具体情况把函数中数据流的值进行验证。

【规则8】测试文件,要求在C++test编译通过并执行通过,才能提交到服务器。

3测试结果提交和验收

参与单元测试的人员,将各自负责测试的模块单元测试后提交服务器,服务器完成工程内的所有测试用例执行,以及测试报告反馈。

开发和测试组长需要查看测试报告,验收单元测试质量,并给出一定的指导意见!

3.1提交的测试产品

1、对于每个被测单元的测试结果提交

每个测试单元测试实现.cpp文件

每个测试单元的相关桩函数实现.cpp

每个测试单元的测试设计文档,请参考《单元测试设计文档》。

2、单元测试总结报告(由服务器完成)

静态检查报告

单元测试执行报告

单元测试任务报告

3.2测试产品提交方式

按照各个工程存放测试套件、桩函数文件、测试数据,以下以hnc8/trunk/hncapi为例:

1、测试套件位置

2、桩函数文件位置

3、测试数据位置/trunk/unit_test/.cpptest/hncapi/unit-data

3.3单元测试工作产品验收规范

每个被测类/被测源文件单元测试通过的准则如下:

1、正确性测试结果文件:

在C++test通过了全部的测试用例,保证测试用例覆盖了单元模块中的所有功能点;

2、代码覆盖率达到要求:

语句覆盖率100%

基本块覆盖率100%

判定覆盖率90%以上

简单条件覆盖率80%以上

3、每一个单元测试Bug清单都处于一个明确的状态,不能改正的必须给出详细的解释说明;

4、单元测试工作产品的验收采用同级评审的方法,由评审组决定测试是否通过,来保证单元测试的质量和软件产品的质量。

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 人文社科 > 法律资料

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2