RTRT单元测试方法.docx
- 文档编号:6508880
- 上传时间:2023-01-07
- 格式:DOCX
- 页数:17
- 大小:326.21KB
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,然后重新执行测试,将发现测试报告中的所有测试用例都通过,同时所有的代码均已被执行。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- RTRT 单元测试 方法
![提示](https://static.bdocx.com/images/bang_tan.gif)