RTRT单元测试方法.docx

RTRT单元测试方法.docx

《RTRT单元测试方法.docx》由会员分享，可在线阅读，更多相关《RTRT单元测试方法.docx（17页珍藏版）》请在冰豆网上搜索。

RTRT单元测试方法

IBMRationalTestRealTime为开发人员测试提速

软件项目越来越复杂，由于在开发人员对模块测试不充分，导致在集成测试和系统测试阶段耗费大量的时间和人力，甚至导致项目进度的重大延误。

因此，为了保证项目质量和进度的可预见性，就要求开发团队对自己开发的代码进行充分测试。

但在不借助工具的情况下，开发人员对代码进行完善的测试需要花费50%左右的时间，而开发人员的主要职责是开发代码，在面对进度压力时，开发人员进行的测试往往是留于形式，不能得以切实执行，留下了大量的质量隐患。

IBMRationalTestRealTime帮助开发人员创建测试脚本、执行测试用例和生成测试报告，并提供对被测代码进行静态分析和运行时分析功能。

利用该工具，开发人员可以大大提高测试的效率。

本文通过举例介绍如何利用IBMRationalTestRealTime进行开发人员测试的过程。

 评论

IBM,

2004年7月01日

∙

内容

在IBMBluemix云平台上开发并部署您的下一个应用。

1.引言

软件项目越来越复杂，由于在开发人员对模块测试不充分，导致在集成测试和系统测试阶段耗费大量的时间和人力，甚至导致项目进度的重大延误。

因此，为了保证项目质量和进度的可预见性，就要求开发团队对自己开发的代码进行充分测试。

但在不借助工具的情况下，开发人员对代码进行完善的测试需要花费50%左右的时间，而开发人员的主要职责是开发代码，在面对进度压力时，开发人员进行的测试往往是留于形式，不能得以切实执行，留下了大量的质量隐患。

IBMRationalTestRealTime帮助开发人员创建测试脚本、执行测试用例和生成测试报告，并提供对被测代码进行静态分析和运行时分析功能。

利用该工具，开发人员可以大大提高测试的效率。

本文通过举例介绍如何利用IBMRationalTestRealTime进行开发人员测试的过程。

回页首

2.IBMRationalTestRealTime概述

TestRealTime是IBMRational提供的代码级测试工具。

该工具包含如下特点：

1.代码静态分析，功能测试和运行时分析相集成。

2.代码编辑、测试和调试相集成。

3.TestRealTime通过分析源代码，自动生成测试驱动（TestDriver）和桩（TestStub）模版。

开发人员只需要在该测试脚本的基础上指定测试输入数据、期望输出数据以及打桩函数的逻辑。

4.测试执行后自动生成测试报告和各种运行时候报告。

测试报告展示通过或失败的测试用例，而运行时分析报告包括代码覆盖分析报告，内存分析报告、性能分析报告和执行追踪报告。

5.通过TargetDeploymentPort技术同时支持开发机和目标机的测试。

回页首

3.开发人员测试现状分析

假设在c:

\rtrt\src目录下具有UmtsCode.c和UmtsCode.h（通过winzip在c:

\目录下展开rtrt.zip文件）。

其中UmtsCode.c中包含了code_int（intx,char*buffer）函数的实现，该函数的设计规范如下：

1、完成对整数x的编码，并把编码的输出值返回到buffer中。

2、编码规则为：

输入值

输出值

x=2,buffer=“”

Buffer“I12”,/*其中I表示整数编码，1为整数串的长度，2表示整数串*/

x=34,buffer=“”

Buffer“I243”,/*其中I表示整数编码，2为整数串的长度，43表示整数串，对进行倒序编码*/

x=56,buffer=“I243”

Buffer“I243I265”

对code_int（intx,char*buffer）进行测试的传统过程：

1.利用C语言编写测试驱动程序test_code_int.c，该代码包含main函数，并main函数利用输入值调用code_int，然后检查code_int的返回值和期望值是否匹配来判断测试用例是否通过。

2.分别编译code_int.c和test_code_int.c，然后连接执行test_code_int.exe。

3.根据test_code_int.exe的执行输出，来整理测试报告。

该过程具有如下问题：

1.利用C语言来编写测试程序，编码工作量大，而且易于出错。

测试人员的工作重心不是关注测试用例的设计，而是关注如何实现测试用例。

2.不能对测试程序（test_code_int.c）进行有效的管理，测试执行不方便。

3.包含测试用例成功与失败的测试报告不能自动化生成，需要手工编写。

4.不能自动得到代码的覆盖情况，测试完备性以及被测试单元的可靠性不能得到保证。

回页首

4.利用TestRealTime对code_int（intx,char*buffer）函数进行测试

4.1TestRealTime的开发人员测试过程

上图是利用RationalTestRealTime的开发人员测试过程，步骤如下：

1、编码：

开发人员在TestRealTime提供的C/C++语言编辑器中进行代码编写。

2、测试脚本模版自动生成：

在被测源代码编译通过后，TestRealTime将通过对源代码进行分析，形成测试脚本模板。

3、增强测试脚本：

开发人员根据设计的测试用例，在测试脚本模板的基础上增加和修改测试用例。

4、生成测试程序：

TestRealTime将根据测试脚本生成C语言测试程序。

5、执行测试：

TestRealtime编译测试程序、被测程序、连接并执行可执行程序。

6、生成测试报告：

TestRealTime将根据测试执行产生的日志文件生成测试报告。

7、测试结果分析：

开发人员根据测试报告判断被测程序质量或测试完备性。

8、解决错误：

如果发现测试用例未通过，来定位错误位置，并修改错误。

TestRealTime可以和开发环境的调试器（如VisualC6.0的msdev.exe）集成，提高错误定位速度。

9、增强测试用例：

增强测试用例来覆盖前次测试执行没覆盖的代码分支。

4.2安装配置测试环境

4.2.1创建相关目录

由于在编码和单元测试阶段中引入TestRealTime，因此需要对新增加的文件类型，如测试脚本文件、测试报告文件进行有序的管理。

建议参考如下目录结构：

∙scr：

被测源代码，包括.c文件和.h文件

∙scripts:

存储测试脚本

∙reports:

存储TestRealTime格式的测试报告

∙html:

存储HTML格式的测试报告

4.2.2安装配置MicrosoftVisualC++6.0

安装MicrosoftVisualC++6.0后，需要配置PATH环境变量，从而保证在命令行下能执行VC的相关命令。

可以通过在命令行下执行cl.exe命令进行验证。

4.2.3安装配置IBMRationalTestRealTime

TestRealTime的安装软件需要联系IBM当地的销售代表获得。

详细安装步骤参见《Rational?

TestRealTimeInstallationGuide》文档。

安装完成后，需设置环境变量ATTOLSTUDIO_VERBOSE=1，这样TestRealTime将显示详细的build信息。

4.2.4创建TestRealTimeProject

一个TestRealTimeProject类似于VisualC++6.0的Project，包含了被测试代码，测试脚本等相关信息以及C/C++语言编译、连接等选项。

通过File>New>Project…菜单进入如下Project创建界面：

指定项目的名字和所处位置。

TestRealTime将自动在项目所处位置下以项目名创建一个目录，本例为c:

\rtrt\test，而且该目录也是项目的当前目录。

选择“Next>”进入如下界面：

不同的开发环境对应不同的TargetDeploymentPort，由于被测代码UtmsCode.c是C语言，因此选择CVisual6.0。

选择Finish将创建一个Project.和VC类似，需要设置相关项目级的相关参数。

通过如下界面进入ConfigurationSettings界面。

就本例而言，不需修改缺省的C语言编译、连接等选项，而只需要通过如下两个界面设置report文件所处的目录为c:

\rtrt\report（由于当前目录为c:

\rtrt\test，因此目录值为..\reports）。

4.3对函数code_int（intx,char*buffer）进行测试

下面以code_int的测试为例详细介绍如何利用TestRealTime进行测试的过程。

4.3.1根据源代码自动生成测试脚本模版

选择File>New>NewActivity>ComponentTesting菜单，进入ComponentTestingWizard界面，通过按钮增加被测文件“UtmsCode.c”，并选中“computestaticmetrics”对被测代码进行静态分析。

如下图显示：

选择“Next>”按钮进入如下“ComponentUnderTest”界面选择被测函数：

对于code_int函数，v（g）表示与测试难度相关的函数复杂度度量。

如v（g）=1，表示该函数没有分支。

为了控制软件的可测试性，建议一个函数的复杂度不超过10。

关于v（g）的详细解释，参见TestRealTime帮助。

为了对code_int进行测试，选中code_int旁边的checkbox，点击“Next>”进入“TestScriptGenerationSettings”界面。

为了让生成的测试脚本位于scripts目录，如下图修改“Testscriptpathand”参数值为“..\scripts\UmtsCode.ptu”。

选择“Next>”按钮,然后“Finish”按钮，进入如下界面：

上述过程实际是通过图形化界面设置命令attolstartC的相关参数。

attolstartC通过分析指定的C代码，形成测试脚本模版，详细信息参考TestRealTimereferencemanual.

4.3.2基于测试脚本模版，根据函数的设计规范，编写测试用例

TestRealTime生成的测试脚本模板中包含一个测试用例，该测试用例的相关输入、输出值设置为0或“”。

SERVICEcode_int

SERVICE_TYPEextern

--Testedserviceparametersdeclarations

#intx;

#charbuffer[200];

ENVIRONMENTENV_code_int

VARx,init=0,ev=init

VARbuffer,init="",ev=init

ENDENVIRONMENT--ENV_code_int

USEENV_code_int

TEST1

FAMILYnominal

ELEMENT

#code_int（x,buffer）;

ENDELEMENT

ENDTEST--TEST1

ENDSERVICE--code_int

其中VARx,init=0,ev=init语句表示x的初始值为0，期望值等于初始值，VARbuffer,init="",ev=init表示buffer的初始值为“”，期望值也等于初始值。

根据前面code_int函数的设计规范，形成如下三个测试用例如下：

SERVICEcode_int

SERVICE_TYPEextern

--Testedserviceparametersdeclarations

#intx;

#charbuffer[200];

ENVIRONMENTENV_code_int

VARx,init=0,ev=init

VARbuffer,init="",ev=init

ENDENVIRONMENT--ENV_code_int

USEENV_code_int

TEST1

FAMILYnominal

ELEMENT

VARx,init=2,ev=init

VARbuffer,init="",ev="I12"

#code_int（x,buffer）;

ENDELEMENT

ENDTEST--TEST1

TEST2

FAMILYnominal

ELEMENT

VARx,init=34,ev=init

VARbuffer,init="",ev="I243"

#code_int（x,buffer）;

ENDELEMENT

ENDTEST--TEST2

TEST3

FAMILYnominal

ELEMENT

VARx,init=56,ev=init

VARbuffer,init="I243",ev="I243I265"

#code_int（x,buffer）;

ENDELEMENT

ENDTEST--TEST3

ENDSERVICE--code_int

完整的测试脚本文件参见c:

\rtrt\scripts\UtmsCode_new1.ptu。

4.3.3执行测试

在修改UtmsCode.put测试脚本后，按如下图选择“Build”执行测试：

在Build过程中，将在“OutputWindow”中显示build的详细步骤：

1．执行attolpreproC命令把把测试脚本UtmsCode.put编译成TTest.c：

attolpreproC"C:

\rtrt\scripts\UmtsCode.ptu""cvisual6\TTest.c"

2．对TTest.c进行预处理、编译形成TTest.obj。

3．对UtmsCode.c进行预处理形成UtmsCode.i：

cl.exe-P"C:

\rtrt\src\UmtsCode.c""-I..\src

4．attolcc1对UmtsCode.i进行插针形成UmtsCode_aug.c：

\attolcc1"cvisual6\UmtsCode.i""cvisual6\UmtsCode_aug.c"atct.def…

5．cl.exe编译UmtsCode_aug.c形成UmtsCode.obj：

cl.exe-ZI-Yd-GZ-GX-c"cvisual6\UmtsCode_aug.c"-Fo"cvisual6\UmtsCode.obj""-I..\src"

6．计算被测代码UmtsCode.c的Metric:

attolstartC"C:

\rtrt\src\UmtsCode.c"…-METRICS="../reports"。

7．连接形成Test.exe：

link.exe/debug/subsystem:

console/machine:

I386/pdb:

none"C:

\rtrt\test\cvisual6\TTest.obj""C:

\rtrt\test\cvisual6\UmtsCode.obj""cvisual6\TP.obj"ws2_32.lib/out:

".\cvisual6\Test.exe"。

其中TP.obj是TestRealTime提供的库文件。

8．执行Test.exe。

9．形成测试报告。

在执行过程中，TestRealTime将以UMLSequenceDiagram的形式显示被测程序的调用关系。

4.3.4测试结果分析

测试执行完成后，将在ProjectBrowser中显示所有的测试报告文件，这些文件均位于c:

\rtrt\reports目录。

鼠标选中“Results”下的Test,点击鼠标右键，选择“ViewReport”，进入测试如下测试报告，该报告将显示测试用例通过和失败的情况。

虽然UtmsCode函数的三个测试用例都通过，但需要通过代码覆盖情况来分析测试的完备性，因为没有被测试的代码很有可能含有错误。

鼠标选中“Results”下的“CodeCoverage”,点击鼠标右键，选择“ViewReport”，进入测试如下代码覆盖情况，如下图：

在代码覆盖报告中，绿色的代码表示已经覆盖，橘红的代码表示部分覆盖，红色的代码表示没有覆盖。

通过对UmtsCode.c的代码覆盖情况进行分析，发现while（x!

=0）语句只是部分覆盖，该语句一次都不执行这种情况并没执行，因此需要完善测试用例。

关于代码覆盖的详细信息参考在线帮助。

4.3.5增强测试脚本UtmsCode.ptu

通过对代码覆盖情况进行分析，为了覆盖while（x!

=0）的所有情况，需要增加如下测试用例：

TEST4

FAMILYnominal

ELEMENT

VARx,init=0,ev=init

VARbuffer,init="A",ev="AI10"

#code_int（x,buffer）;

ENDELEMENT

ENDTEST--TEST4

增强后的测试脚本参考c:

\rtrt\scripts\UtmsCode_new2.ptu。

再次执行测试。

测试报告如下图，发现Test4不通过，表明UtmsCode.c中有错误。

4.3.6修改测试脚本UtmsCode.c

如附件UtmsCode_new.c的内容修改UtmsCode.c，然后重新执行测试，将发现测试报告中的所有测试用例都通过，同时所有的代码均已被执行。