IBM Rational Test RealTime为开发人员测试提速

2023-10-25 08:58

本文主要是介绍IBM Rational Test RealTime为开发人员测试提速,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

http://www.ibm.com/developerworks/cn/rational/r-realtest/

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

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:/rtrt/src目录下具有UmtsCode.c和UmtsCode.h(通过winzip在c:/目录下展开rtrt.zip文件)。其中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函数,并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. 利用Test RealTime对code_int(int x, char *buffer)函数进行测试

4.1 Test RealTime的开发人员测试过程


上图是利用Rational Test RealTime的开发人员测试过程,步骤如下:

1、 编码:开发人员在Test RealTime提供的C/C++语言编辑器中进行代码编写。

2、 测试脚本模版自动生成:在被测源代码编译通过后,Test RealTime将通过对源代码进行分析,形成测试脚本模板。

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

4、 生成测试程序:Test RealTime将根据测试脚本生成C语言测试程序。

5、 执行测试:Test Realtime编译测试程序、被测程序、连接并执行可执行程序。

6、 生成测试报告:Test RealTime将根据测试执行产生的日志文件生成测试报告。

7、 测试结果分析:开发人员根据测试报告判断被测程序质量或测试完备性。

8、 解决错误:如果发现测试用例未通过,来定位错误位置,并修改错误。Test RealTime可以和开发环境的调试器(如Visual C 6.0的msdev.exe)集成,提高错误定位速度。

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的相关命令。可以通过在命令行下执行cl.exe命令进行验证。

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,包含了被测试代码,测试脚本等相关信息以及C/C++语言编译、连接等选项。

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


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


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


就本例而言,不需修改缺省的C语言编译、连接等选项,而只需要通过如下两个界面设置report文件所处的目录为c:/rtrt/report(由于当前目录为c:/rtrt/test,因此目录值为../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”参数值为“../scripts/UmtsCode.ptu”。


选择“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,		init = 0,		ev = init
VAR buffer,		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 = "", ev = 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,		init = 0,		ev = init
VAR buffer,		init = "",		ev = init
END ENVIRONMENT -- ENV_code_int
USE ENV_code_int
TEST 1
FAMILY nominal
ELEMENT
VAR x,		init = 2,		ev = init
VAR buffer,		init = "",		ev = "I12"
#code_int(x, buffer);
END ELEMENT
END TEST -- TEST 1
TEST 2
FAMILY nominal
ELEMENT
VAR x,		init = 34,		ev = init
VAR buffer,		init = "",		ev = "I243"
#code_int(x, buffer);
END ELEMENT
END TEST -- TEST 2
TEST 3
FAMILY nominal
ELEMENT
VAR x,		init = 56,		ev = init
VAR buffer,		init = "I243",		ev = "I243I265"
#code_int(x, buffer);
END ELEMENT
END TEST -- TEST 3
END SERVICE -- code_int

 

完整的测试脚本文件参见c:/rtrt/scripts/ UtmsCode_new1.ptu。

4.3.3 执行测试

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


在Build过程中,将在“Output Window”中显示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是Test RealTime提供的库文件。

8. 执行Test.exe。

9. 形成测试报告。

在执行过程中,Test RealTime将以UML Sequence Diagram的形式显示被测程序的调用关系。


4.3.4 测试结果分析


测试执行完成后,将在Project Browser中显示所有的测试报告文件,这些文件均位于c:/rtrt/reports目录。

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


虽然UtmsCode函数的三个测试用例都通过,但需要通过代码覆盖情况来分析测试的完备性,因为没有被测试的代码很有可能含有错误。鼠标选中“Results”下的“Code Coverage”, 点击鼠标右键,选择“View Report”,进入测试如下代码覆盖情况,如下图:


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

4.3.5 增强测试脚本UtmsCode.ptu

通过对代码覆盖情况进行分析,为了覆盖while ( x!= 0)的所有情况,需要增加如下测试用例:

    TEST 4
FAMILY nominal
ELEMENT
VAR x,		init = 0,		ev = init
VAR buffer,		init = "A",		ev = "AI10"
#code_int(x, buffer);
END ELEMENT
END TEST -- TEST 4

 

增强后的测试脚本参考c:/rtrt/scripts/ UtmsCode_new2.ptu。再次执行测试。测试报告如下图,发现Test 4不通过,表明UtmsCode.c中有错误。


4.3.6 修改测试脚本UtmsCode.c

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

 




回页首

 

5. 小结

IBM Rational Test RealTime除了支持C语言外,还支持C++和Java语言,并支持基于消息的测试。开发人员利用该工具,实现了编码、测试和调试的有机集成,使得边开发边测试或测试驱动的开发得以切实执行。

 

参考资料

  • IBM Rational Test RealTime手册:ftp://ftp.software.ibm.com/software/rational/docs/documentation/manuals/testing.htm
  • IBM Rational Test RealTime技术支持:http://www-306.ibm.com/software/awdtools/test/realtime/support/

 

关于作者

IBM has authored this article

这篇关于IBM Rational Test RealTime为开发人员测试提速的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/281447

相关文章

性能测试介绍

性能测试是一种测试方法,旨在评估系统、应用程序或组件在现实场景中的性能表现和可靠性。它通常用于衡量系统在不同负载条件下的响应时间、吞吐量、资源利用率、稳定性和可扩展性等关键指标。 为什么要进行性能测试 通过性能测试,可以确定系统是否能够满足预期的性能要求,找出性能瓶颈和潜在的问题,并进行优化和调整。 发现性能瓶颈:性能测试可以帮助发现系统的性能瓶颈,即系统在高负载或高并发情况下可能出现的问题

字节面试 | 如何测试RocketMQ、RocketMQ?

字节面试:RocketMQ是怎么测试的呢? 答: 首先保证消息的消费正确、设计逆向用例,在验证消息内容为空等情况时的消费正确性; 推送大批量MQ,通过Admin控制台查看MQ消费的情况,是否出现消费假死、TPS是否正常等等问题。(上述都是临场发挥,但是RocketMQ真正的测试点,还真的需要探讨) 01 先了解RocketMQ 作为测试也是要简单了解RocketMQ。简单来说,就是一个分

【测试】输入正确用户名和密码,点击登录没有响应的可能性原因

目录 一、前端问题 1. 界面交互问题 2. 输入数据校验问题 二、网络问题 1. 网络连接中断 2. 代理设置问题 三、后端问题 1. 服务器故障 2. 数据库问题 3. 权限问题: 四、其他问题 1. 缓存问题 2. 第三方服务问题 3. 配置问题 一、前端问题 1. 界面交互问题 登录按钮的点击事件未正确绑定,导致点击后无法触发登录操作。 页面可能存在

业务中14个需要进行A/B测试的时刻[信息图]

在本指南中,我们将全面了解有关 A/B测试 的所有内容。 我们将介绍不同类型的A/B测试,如何有效地规划和启动测试,如何评估测试是否成功,您应该关注哪些指标,多年来我们发现的常见错误等等。 什么是A/B测试? A/B测试(有时称为“分割测试”)是一种实验类型,其中您创建两种或多种内容变体——如登录页面、电子邮件或广告——并将它们显示给不同的受众群体,以查看哪一种效果最好。 本质上,A/B测

论文翻译:ICLR-2024 PROVING TEST SET CONTAMINATION IN BLACK BOX LANGUAGE MODELS

PROVING TEST SET CONTAMINATION IN BLACK BOX LANGUAGE MODELS https://openreview.net/forum?id=KS8mIvetg2 验证测试集污染在黑盒语言模型中 文章目录 验证测试集污染在黑盒语言模型中摘要1 引言 摘要 大型语言模型是在大量互联网数据上训练的,这引发了人们的担忧和猜测,即它们可能已

Verybot之OpenCV应用一:安装与图像采集测试

在Verybot上安装OpenCV是很简单的,只需要执行:         sudo apt-get update         sudo apt-get install libopencv-dev         sudo apt-get install python-opencv         下面就对安装好的OpenCV进行一下测试,编写一个通过USB摄像头采

Golang test编译使用

创建文件my_test.go package testsimport "testing"func TestMy(t *testing.T) {t.Log("TestMy")} 通常用法: $ go test -v -run TestMy my_test.go=== RUN TestMyTestMy: my_test.go:6: TestMy--- PASS: TestMy (0.

BIRT 报表的自动化测试

来源:http://www.ibm.com/developerworks/cn/opensource/os-cn-ecl-birttest/如何为 BIRT 报表编写自动化测试用例 BIRT 是一项很受欢迎的报表制作工具,但目前对其的测试还是以人工测试为主。本文介绍了如何对 BIRT 报表进行自动化测试,以及在实际项目中的一些测试实践,从而提高了测试的效率和准确性 -------

可测试,可维护,可移植:上位机软件分层设计的重要性

互联网中,软件工程师岗位会分前端工程师,后端工程师。这是由于互联网软件规模庞大,从业人员众多。前后端分别根据各自需求发展不一样的技术栈。那么上位机软件呢?它规模小,通常一个人就能开发一个项目。它还有必要分前后端吗? 有必要。本文从三个方面论述。分别是可测试,可维护,可移植。 可测试 软件黑盒测试更普遍,但很难覆盖所有应用场景。于是有了接口测试、模块化测试以及单元测试。都是通过降低测试对象

JavaScript正则表达式六大利器:`test`、`exec`、`match`、`matchAll`、`search`与`replace`详解及对比

在JavaScript中,正则表达式(Regular Expression)是一种用于文本搜索、替换、匹配和验证的强大工具。本文将深入解析与正则表达式相关的几个主要执行方法:test、exec、match、matchAll、search和replace,并对它们进行对比,帮助开发者更好地理解这些方法的使用场景和差异。 正则表达式基础 在深入解析方法之前,先简要回顾一下正则表达式的基础知识。正则