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

2023-10-25 08:58
文章标签 test 测试 开发人员 ibm 提速 realtime rational

本文主要是介绍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、RocketMQ？

字节面试：RocketMQ是怎么测试的呢？ 答： 首先保证消息的消费正确、设计逆向用例，在验证消息内容为空等情况时的消费正确性； 推送大批量MQ，通过Admin控制台查看MQ消费的情况，是否出现消费假死、TPS是否正常等等问题。（上述都是临场发挥，但是RocketMQ真正的测试点，还真的需要探讨） 01 先了解RocketMQ 作为测试也是要简单了解RocketMQ。简单来说，就是一个分
阅读更多...
【测试】输入正确用户名和密码，点击登录没有响应的可能性原因

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

目录 一、前端问题 1. 界面交互问题 2. 输入数据校验问题 二、网络问题 1. 网络连接中断 2. 代理设置问题 三、后端问题 1. 服务器故障 2. 数据库问题 3. 权限问题： 四、其他问题 1. 缓存问题 2. 第三方服务问题 3. 配置问题 一、前端问题 1. 界面交互问题 登录按钮的点击事件未正确绑定，导致点击后无法触发登录操作。 页面可能存在
阅读更多...
业务中14个需要进行A/B测试的时刻[信息图]

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

在本指南中，我们将全面了解有关 A/B测试 的所有内容。 我们将介绍不同类型的A/B测试，如何有效地规划和启动测试，如何评估测试是否成功，您应该关注哪些指标，多年来我们发现的常见错误等等。 什么是A/B测试？ A/B测试（有时称为“分割测试”）是一种实验类型，其中您创建两种或多种内容变体——如登录页面、电子邮件或广告——并将它们显示给不同的受众群体，以查看哪一种效果最好。 本质上，A/B测
阅读更多...
论文翻译：ICLR-2024 PROVING TEST SET CONTAMINATION IN BLACK BOX LANGUAGE MODELS

论文翻译：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应用一：安装与图像采集测试

在Verybot上安装OpenCV是很简单的，只需要执行：         sudo apt-get update         sudo apt-get install libopencv-dev         sudo apt-get install python-opencv         下面就对安装好的OpenCV进行一下测试，编写一个通过USB摄像头采
阅读更多...
Golang test编译使用

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 报表的自动化测试

BIRT 报表的自动化测试

来源：http://www.ibm.com/developerworks/cn/opensource/os-cn-ecl-birttest/如何为 BIRT 报表编写自动化测试用例 BIRT 是一项很受欢迎的报表制作工具，但目前对其的测试还是以人工测试为主。本文介绍了如何对 BIRT 报表进行自动化测试，以及在实际项目中的一些测试实践，从而提高了测试的效率和准确性 -------
阅读更多...
可测试，可维护，可移植：上位机软件分层设计的重要性

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

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

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

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

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2