关于六一儿童节的来历-行政职业能力测试

IBM Rational Test RealTime为开发人员测试提
速
软件项目越来越复杂，由于在开发人员对模块测试不充分，导致在集成测试和系统测试阶段
耗费大量的 时间和人力，甚至导致项目进度的重大延误。因此，为了保证项目质量和进度的
可预见性，就要求开发团 队对自己开发的代码进行充分测试。但在不借助工具的情况下，开
发人员对代码进行完善的测试需要花费 50%左右的时间，而开发人员的主要职责是开发代码，
在面对进度压力时，开发人员进行的测试往往是 留于形式，不能得以切实执行，留下了大量
的质量隐患。IBM Rational Test Rea lTime帮助开发人员创建测试脚本、执行测试用例和生
成测试报告，并提供对被测代码进行静态分析 和运行时分析功能。利用该工具，开发人员可
以大大提高测试的效率。本文通过举例介绍如何利用IBM Rational Test RealTime进行开发
人员测试的过程。
0
评论
IBM,
2004 年 7 月 01 日

内容


在 IBM Bluemix 云平台上开发并部署您的下一个应用。
开始您的试用
1. 引言
软件项目越来越复杂，由于在开发人员对模块测试不充分 ，导致在集成测试和系统测试阶段耗费大量的时间
和人力，甚至导致项目进度的重大延误。因此，为了保 证项目质量和进度的可预见性，就要求开发团队对自
己开发的代码进行充分测试。但在不借助工具的情况 下，开发人员对代码进行完善的测试需要花费50%左右
的时间，而开发人员的主要职责是开发代码，在 面对进度压力时，开发人员进行的测试往往是留于形式，不
能得以切实执行，留下了大量的质量隐患。
IBM Rational Test RealTime帮助开发人员创建测试脚本、执行测试用例和 生成测试报告，并提供对被测代
码进行静态分析和运行时分析功能。利用该工具，开发人员可以大大提高 测试的效率。本文通过举例介绍如
何利用IBM Rational Test RealTime进行开发人员测试的过程。
回页首
2. IBM Rational Test RealTime概述
Test RealTime是IBM Rational提供的代码级测试工具。该工具包含如下特点：
1. 代码静态分析，功能测试和运行时分析相集成。
2. 代码编辑、测试和调试相集成。

3. Test RealTime通过分析源代码，自动生成测试驱动（Test Driver）和桩（Test Stub）模版。
开发人员只需要在该测试脚本的基础上指定测试输入 数据、期望输出数据以及打桩函数的逻
辑。
4. 测试执行后自动生成测试报告和各种运行时 候报告。测试报告展示通过或失败的测试用例，
而运行时分析报告包括代码覆盖分析报告，内存分析报告 、性能分析报告和执行追踪报告。
5. 通过Target Deployment Port技术同时支持开发机和目标机的测试。
回页首
3. 开发人员测试现状分析 假设在c:rtrtsrc目录下具有UmtsCode.c和UmtsCode.h（通过winzip在 c:目录下展开文件）。其
中UmtsCode.c中包含了code_int(int x, 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(int x, char *buffer)进行测试的传统过程：
1. 利用C语言编写测试驱动程序test_code_int.c，该代码包含main函数，并m ain函数利用输入值调用
code_int，然后检查code_int的返回值和期望值是否匹配来 判断测试用例是否通过。
2. 分别编译code_int.c和test_code_int.c，然后连接执行test_code_。
3. 根据test_code_的执行输出，来整理测试报告。
该过程具有如下问题：
1. 利用C语言来编写测试程序，编码工作量大，而且易于出错。测试人员的工作重心不是关注测试用 例的设
计，而是关注如何实现测试用例。
2. 不能对测试程序（test_code_int.c）进行有效的管理，测试执行不方便。
3. 包含测试用例成功与失败的测试报告不能自动化生成，需要手工编写。
4. 不能自动得到代码的覆盖情况，测试完备性以及被测试单元的可靠性不能得到保证。
回页首
4. 利用Test RealTime对code_int(int x, char *buffer)函数进行
测试
4.1 Test RealTime的开发人员测试过程

上图是利用Rational Test RealTime的开发人员测试过程，步骤如下：
1、 编码：开发人员在Test RealTime提供的CC++语言编辑器中进行代码编写。
2、 测试脚本模版自动生成：在被测源代码编译通过后，Test RealTime将通过对源代码进行分析，形成测试脚本模板。
3、 增强测试脚本：开发人员根据设计的测试用例，在测试脚本模板的基础上增加和修改测试用例。
4、 生成测试程序：Test RealTime将根据测试脚本生成C语言测试程序。
5、 执行测试：Test Realtime编译测试程序、被测程序、连接并执行可执行程序。
6、 生成测试报告：Test RealTime将根据测试执行产生的日志文件生成测试报告。
7、 测试结果分析：开发人员根据测试报告判断被测程序质量或测试完备性。
8、 解决错误：如果发现测试用例未通过，来定位错误位置，并修改错误。Test RealTime可以和开发环境的调试器
（如Visual C 6.0的）集成，提高错误定位速度。
9、 增强测试用例：增强测试用例来覆盖前次测试执行没覆盖的代码分支。
4.2 安装配置测试环境
4.2.1 创建相关目录
由于在编码和单元测试阶段中引入Test RealTime， 因此需要对新增加的文件类型，如测试脚本文件、测试
报告文件进行有序的管理。建议参考如下目录结构 ：




scr：被测源代码，包括.c文件和.h文件
scripts: 存储测试脚本
reports: 存储Test RealTime格式的测试报告
html: 存储HTML格式的测试报告
4.2.2 安装配置Microsoft Visual C++ 6.0
安装Microsoft Visual C++ 6.0后，需要配置PATH环境变量，从 而保证在命令行下能执行VC的相关命令。
可以通过在命令行下执行命令进行验证。
4.2.3 安装配置IBM Rational Test RealTime
Test RealTime的安装软件需要联系IBM当地的销售代表获得。详细安装步骤参见《Rational? Test
RealTime Installation Guide》文档。

安装完成后，需设置环境变量ATTOLSTUDIO_VERBOSE=1，这样Test RealTime将显示详细的build信息。
4.2.4 创建Test RealTime Project
一个Test RealTime Project类似于Visual C++ 6 .0的Project，包含了被测试代码，测试脚本等相关信息以
及CC++语言编译、连接等选项。
通过File > New > Project…菜单进入如下Project创建界面：

指定项目的名字和所处位置。Test RealTime将自动在项目所处位置下以项目名创建一个目 录，本例为c:rtrttest，而
且该目录也是项目的当前目录。 选择“Next >”进入如下界面：

不同的开发环境对应不同的Target Deployment Port，由于被测代码UtmsCode.c是C语言，因此选择C Visual 6.0。
选择Finish将创建一个Project. 和VC类似，需要设置相关项目级的相关参数。通过如下界面进入Configuration
Settings界面。

就本例而言，不需修改缺省的C语言编译、连接等选项， 而只需要通过如下两个界面设置report文件所处的目录为
c:rtrtreport（由于当前目 录为c:rtrttest，因此目录值为..reports）。

4.3 对函数code_int(int x, char *buffer) 进行测试
下面以code_int的测试为例详细介绍如何利用Test RealTime进行测试的过程。
4.3.1 根据源代码自动生成测试脚本模版
选择File > New > New Activity > Component Testing菜单，进入Component Testing Wizard界面，通过 按
钮增加被测文件“UtmsCode.c”，并选中“compute static metrics”对被测代码进行静态分析。如下图显示：

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

对于code_int函数，v(g)表示与测试难度相关 的函数复杂度度量。如v(g)=1，表示该函数没有分支。为了控制软件的
可测试性，建议一个函数的 复杂度不超过10。关于v(g)的详细解释，参见Test RealTime帮助。为了对code_int 进
行测试，选中code_int旁边的checkbox，点击“Next >”进入“Test Script Generation Settings”界面。 为了让生成
的测试脚本位于scripts目录，如下图修改“Test script path and file name”参数值为“..”。

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

上述过程实际是通过图形化界面设 置命令attolstartC的相关参数。attolstartC通过分析指定的C代码，形成测试脚本模版，详细信息参考Test RealTime reference manual.
4.3.2 基于测试脚本模版，根据函数的设计规范，编写测试用例

Test RealTime生成的测试脚本模板中包含一个测试用例，该测试用例的相关输入、输出值设置为0或“”。
SERVICE code_int
SERVICE_TYPE extern
-- Tested service parameters declarations
#int x;
#char buffer[200];
ENVIRONMENT ENV_code_int
VAR x,
VAR buffer,


init = 0,
init =


ev = init
ev = init
END ENVIRONMENT -- ENV_code_int
USE ENV_code_int
TEST 1
FAMILY nominal
ELEMENT
#code_int(x, buffer);
END ELEMENT
END TEST -- TEST 1
END SERVICE -- code_int
其中VAR x, init = 0, ev = init语句表示x的初始值为0，期望值等于初始值， VAR buffer, init = 表示
buffer的初始值为“”，期望值也等于初始值。
根据前面code_int 函数的设计规范，形成如下三个测试用例如下：
SERVICE code_int
SERVICE_TYPE extern
-- Tested service parameters declarations
#int x;
#char buffer[200];
ENVIRONMENT ENV_code_int
VAR x,
VAR buffer,


init = 0,
init =


ev = init
ev = init
END ENVIRONMENT -- ENV_code_int
USE ENV_code_int
TEST 1
FAMILY nominal
ELEMENT




VAR x, init = 2,

ev = init
ev = VAR buffer, init =
#code_int(x, buffer);
END ELEMENT
END TEST -- TEST 1
TEST 2
FAMILY nominal
ELEMENT

VAR x, init = 34,

ev = init
ev = VAR buffer, init =
#code_int(x, buffer);
END ELEMENT
END TEST -- TEST 2
TEST 3
FAMILY nominal
ELEMENT




VAR x, init = 56,

ev = init
ev = VAR buffer, init =
#code_int(x, buffer);
END ELEMENT
END TEST -- TEST 3
END SERVICE -- code_int
完整的测试脚本文件参见c:rtrtscripts UtmsCode_。
4.3.3 执行测试
在修改测试脚本后，按如下图选择“Build”执行测试：

在Build过程中，将在“Output Window”中显示build的详细步骤：
1． 执行attolpreproC命令把把测试脚本编译成TTest.c：attolpreproC

2． 对TTest.c进行预处理、编译形成。
3． 对UtmsCode.c进行预处理形成UtmsCode.i： -P
4． attolcc1对UmtsCode.i进行插针形成UmtsCode_aug.c：attolcc1
UmtsCode_aug.c
5． 编译UmtsCode_aug.c形成： -ZI -Yd -GZ -GX -c
Fo
6． 计算被测代码UmtsCode.c的Metric: attolstartC sCode.c-METRICS=。

7． 连接形成： debug subsystem:console machine:I386 pdb:none

out:。其中是Test RealTime提供的库文件。
8． 执行。
9． 形成测试报告。
在执行过程中，Test RealTime将以UML Sequence Diagram的形式显示被测程序的调用关系。

4.3.4 测试结果分析

测试执行完成后，将在Project Browser中显示所有的测试报告文件，这些文件均位于c:rtrtreports目录。
鼠标选中“Results”下的Test, 点击鼠标右键，选择“View Report”，进入测试如下测试报告，该报告将显示测试用例
通过和失败的情况。
虽然UtmsCode函数的三个测试用例都通过，但需要通过代码覆盖情况来分析测试的完备性，因为没有 被测试的代码
很有可能含有错误。 鼠标选中“Results”下的“Code Coverage”, 点击鼠标右键，选择“View Report”，进入测试如下
代码覆盖情况，如下图：

在代码覆盖报告中，绿色的代码表示已经覆盖， 橘红的代码表示部分覆盖，红色的代码表示没有覆盖。 通过对
UmtsCode.c的代码覆盖情况进行分析，发现while ( x!= 0) 语句只是 部分覆盖，该语句一次都不执行这种情况并没执
行，因此需要完善测试用例。关于代码覆盖的详细信息参 考在线帮助。
4.3.5 增强测试脚本
通过对代码覆盖情况进行分析，为了覆盖while ( x!= 0)的所有情况，需要增加如下测试用例：
TEST 4
FAMILY nominal
ELEMENT




VAR x, init = 0,

ev = init
ev = VAR buffer, init =
#code_int(x, buffer);
END ELEMENT
END TEST -- TEST 4
增强后的测试脚本参考c:rtrtscripts UtmsCode_。再次执行测试。测试报告如下图，发现Test 4不通过，
表明UtmsCode.c中有错误。

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