Rational Test Workbench 基础: 初识 Rational Test Workbench

为了实现全面自动化测试的目标,IBM 推出了Rational Test Workbench(简称 RTW)统一测试工具集,包括自动化功能测试,性能测试,接口集成测试,手机移动 App 自动化测试以及服务虚拟化等模块,满足客户多种类型的自动化测试需求。我们将通过系列文章,结合具体的应用,和大家一起分析如何使用 RTW 完成手机自动化测试,接口集成测试,以及通过服务虚拟化实现测试环境的仿真,从而展示 RTW 全面的自动化测试能力,方便大家了解 RTW 并在您的实际工作中应用 RTW。

程 燕宾, 客户技术专家, IBM

程燕宾,IBM Rational 客户技术专家。主要专注于项目管理、软件过程管理、软件配置管理、软件测试等方面的研究。



唐 思臣, 客户技术专家, IBM

唐思臣,IBM 中国有限公司软件部客户技术专家。专注方向为软件自动化测试,软件部署自动化等领域。为国内多家电信、银行客户提供软件过程管理的咨询、技术和产品实施服务工作。当前的主要研究方向有软件持续交付、服务虚拟化、移动测试等。



2013 年 7 月 23 日

前言

随着软件技术的发展和软件不断应用,我们的生活,日常工作也无时不刻被软件所影响和改变。

出门打车,有“嘀嘀打车”来叫车,上车后手机可以收发邮件处理工作,间或看看 Weibo,用微信给朋友发个消息。哦,接到老板电话,要出差了?好的,打开手机上的国航 App, 预订机票,信用卡支付,然后预占位置。

这些软件系统带给用户方便,而为了保证这些系统的功能稳定,高效运行,众多的 IT 信息中心和软件研发企业也面临着更大的挑战。

一个大的企业,往往有多个软件系统,这些系统协同工作才可以保证企业的日常工作和运行;而系统之间的关联性,耦合性越来越强;很多时候,一个貌似简单的业务应用,后面往往贯穿了多个不同的软件系统,如手机预订机票,会访问机票预订系统,银行卡 / 信用卡支付系统,航空公司常旅客管理系统等。

传统的软件测试,更多集中在 GUI 界面的功能测试和性能测试,往往是“重测试,轻定位”。在测试这类分布式复杂应用系统时,如果按照传统基于图形用户界面的方式来测试,往往难以找出系统问题的根本原因。这类系统“简单”的用户操作界面下面往往是复杂的子系统、业务模块的调用,任何一个环节(接口通信)出现了问题都会导致测试失败。

图 1. GUI 界面只是冰山一角,业务由多个系统共同实现
图 1. GUI 界面只是冰山一角,业务由多个系统共同实现

如上图,“冰山”上的 GUI 界面的一个输入请求的输出出现了错误,这个错误是“冰山”下多个服务交互的反应,这些服务可能来自于不同的子系统,我们必须对这些服务的接口进行测试,才能定位出问题的根源。

这就需要超越界面测试,更深入到后台的接口测试,把不同接口测试的测试用例整合在一起,并和传统的功能测试,性能测试结合,共同实现全面的自动化回归测试。同时,由于越来越多的应用是基于手机客户端的,我们的测试工作也必须把针对手机 App 的自动化测试纳入重点。

也正是为了实现全面自动化测试的目标, IBM 推出了 Rational Test Workbench (简称 RTW)统一测试工具集,包括自动化功能测试,性能测试,接口集成测试,手机移动 App 自动化测试以及服务虚拟化等模块,满足客户多种类型的自动化测试需求。我们将通过系列文章,结合具体的应用,和大家一起分析如何使用 RTW 完成手机自动化测试,接口集成测试,以及通过服务虚拟化实现测试环境的仿真,从而展示 RTW 全面的自动化测试能力,方便大家了解 RTW 并在您的实际工作中应用 RTW。


SOA 架构,对测试工作带来新的挑战

计算机技术发展到今天,越来越多的客户开始采用基于 SOA 的分布式体系架构来构建关键企业应用,无论是对旧有信息系统的改造,还是对企业新 IT 架构的设计,分布式、面向服务的体系结构都往往成为了首选的方案。

这种流行的趋势其实是若干因素共同促进的结果。一方面,历经多年软件工程发展所积累的经验、方法和各种架构模式,比如 OO/MDD/MDA,需要新的想法来促进更加快捷的工程组织模式,以应对飞速发展变化的商业模式;另一方面,互联网的多年发展带来了前所未有的分布式系统的交互能力,这成为了实施进一步标准化需求的基础。

图 2. 复杂的 SOA 系统
图 2. 复杂的 SOA 系统

SOA 架构提高了企业对系统的复用程度,以一种松耦合的方式将不同的系统联系到一起,用户会以 PC 联入系统,也可能以移动设备(如智能手机或 Pad)联入系统,这类系统的特性在于:

  • 系统间基于“消息”进行通信。消息格式复杂多样,包括 HTTP、XML、SOAP、File、JSON、REST、二进制、JMS、Base64 等。针对特定的行业还会有 HL7、FIX、SWIFT 等。
  • 体系结构复杂,采用多种技术。如 Web Service、FTP、SCA、SDO、BPEL、ESB、BPM、消息中间件等。
  • 系统间依赖关系复杂,接口众多,难以关联和调试。

传统意义上,测试人员通常会基于开发好的 PC 用户界面做功能测试和性能测试,并使用自动化测试工具进行相应的自动化测试。但是许多项目组发现,针对 SOA 开发使他们比较头疼的是集成测试,因为在集成测试时候会出现大量缺陷。为什么会有这种情况?我们来看一下 SOA 系统集成测试带来的新问题。


复杂系统集成测试的困惑

集成测试,也叫组装测试或联合测试。在单元测试的基础上,将所有模块按照设计要求组装成子系统或系统,进行集成测试。实践表明,一些模块虽然能够单独地工作,但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题,在全局上很可能暴露出来,影响功能的实现。而针对 SOA 和分布式复杂应用系统的集成测试,往往会碰到如下的一些困惑:

无图形用户界面

与传统的基于 GUI 的测试方式不同,SOA 类系统的测试主要是围绕着系统底层各个组件和模块之间的接口来进行的,通过消息的 Schema 来判定接口之间的通信是否正确。这些接口通常没有图形用户界面,无法采用传统的基于图形用户界面的录制方式来进行测试。

消息格式复杂,缺乏统一的测试手段

如图一所述,分布式复杂应用系统的各个模块之间通信和消息格式复杂多样,常见的包括 HTTP、XML、SOAP、File、JSON、REST、二进制、JMS、Base64 等。这就要求测试人员必须要熟悉系统中每一种消息的格式和测试方法,必须针对每一种消息构建独立的测试脚本。这将导致测试工作复杂,难以以统一的方式有效的执行和管理。

单元测试和集成测试的“鸿沟”

我们前面提到,项目组在集成测试时感到头疼,在做分布式复杂应用系统的测试过程中,往往会碰到这样的问题:各个子系统和模块在独立开发和单元测试阶段都进行的十分顺利,软件的质量也不错。一旦进行到集成测试阶段,由于各个模块和组件之间的消息契约十分复杂,依赖关系众多,系统与系统之间在做联调测试的时候容易出现各种各样的问题,导致集成之后的软件系统质量底下,运行期间持续暴露各种各样的缺陷。

图 3. 到了集成测试阶段,质量突然下降
图 3. 到了集成测试阶段,质量突然下降

图三中,我们看到软件质量在“Big Bang”后有个下降期,这是因为在单元测试阶段没有考虑集成测试的问题。举个例子,组件 A 依赖组件 B 和 C,组件 ABC 分别由不同的小组开发,每个小组都会进行单位测试,保证自己小组开发的组件没有问题。但当某一时刻,组件 ABC 都开发好后一集成,问题就出来了。这是我们所说的单元测试和集成测试的“鸿沟”,如果将集成测试介入到单元测试中,出现问题的几率就会大大降低。

测试环境构建费时费力,难以平衡质量和进度

分布式复杂应用系统采用技术种类众多,包含各种类型的操作系统、中间件、数据库、通信协议等等。为了测试一个端到端的业务场景,往往需要耗费大量的人力、物力和时间来重复搭建测试环境(如应用服务器配置、测试数据准备、消息队列初始化等),并且十分容易出错。据统计,测试环境搭建平均耗费掉测试周期 30% 到 50% 的时间。

另外,有时需要定制和额外的软件支撑来满足种种约束(例如,第三方软件可用性,安全,等等),可能仍然不足以反映目标运行环境,或者针对特定条件的测试(第三方组件新的版本等等)。为满足业务目标,系统所需要的开发和测试频率,由于测试环节低下的生产率和覆盖率而被大大地限制了。更长的测试周期增加了应用交付的风险,系统的质量也难以得到保证。

后台性能瓶颈难捕获

对传统的应用系统做性能测试时,通常的做法是采用性能测试工具通过录制用户界面操作生成测试脚本的方式来进行。但分布式复杂系统的性能瓶颈往往不在 Web 前端界面,界面上一个简单的操作往往对应着后台大量的子系统、模块接口的消息调用,任何一个接口的消息处理性能瓶颈都会影响到整体系统的性能。此外,通过传统基于界面操作录制的方式也无法灵活地模拟多个接口直接的串联和并发调用的场景。而且,传统的性能测试工具,如 Load runner、RPT 等,录制的是第一层客户端(经常是浏览器)发送给第一个服务器(经常是 web 服务器)的请求,而服务器发送给后台的请求是捕获不到的,而后台的服务器设置往往是性能优化的关键。


移动终端应用为测试带来的挑战

从目前软件开发来看,越来越多的企业认识到其业务应用的用户已开始从个人计算机(如台式机和笔记本电脑)转向移动设备(如智能手机和平板电脑)来访问 Internet 并获取所需的信息。用户使用移动设备作为访问 Internet 获取信息和请求服务的主要途径,因为无论去哪里人们都能随身携带移动设备,并且移动设备更加直观易用。这种用户行为的重大转变促使企业为现有的应用开发移动版本,随着移动应用市场的成熟,相应的移动软件开发测试问题呈现到人们的视野之中。

移动应用开发面临巨大挑战的一个领域是测试。移动应用测试在复杂度和成本方面比传统应用有了重大的飞跃。与传统 PC 和 Web 应用不同,支持移动设备和版本级别的范围可能非常庞大。移动项目测试动辄包含数百种设备,移动操作系统、网络运营商、区域设置和设备方向组合的情况相当普遍。连接不同的运营商网络时,同一型号的设备功能可能也会略有不同。此外,网络连接的质量对于移动应用的表现也会产生深远的影响。

绝大部分移动应用具有多层的架构,设备处于“前端”,对中间层和“后端”数据进行访问。有效的移动应用测试涉及到各应用层,而不只是测试移动设备上的程序。中间层和后端服务有可能会为移动应用测试带来极高的成本和复杂性挑战。

许多移动项目会使用手工测试方式,这是一种快速开始测试的有效方式。但团队必须购买应用支持的各种移动设备,测试人员按照已编写好的脚本说明执行测试。这种手工测试代价大,效率低。但是在应用可用性的信息反馈方面,手工测试确实能发挥很大作用。

除了依靠实际的移动设备,还可以使用移动设备模拟器和仿真器来执行测试。借助这种方法,在桌面工作站上运行的软件程序能够代替实际的设备来完成测试。运用模拟器和仿真器开展移动应用测试对于开发人员单元测试等任务十分有效。因此,无论是手工测试还是自动测试,在实际的移动设备上执行某种形式的测试往往十分必要。

有些移动应用测试解决方案依赖于在设备上运行代理程序,可用自动执行的方式与测试脚本进行交互,这种方法能够灵活地运用实际物理设备或仿真器开展测试,并可通过自动化技术提高效率。


Rational 测试工作台解决方案

针对传统应用的测试和新型系统类型的测试,IBM 提供了 Rational 测试工作台解决方案。该方案作为 Rational 软件质量保证的核心组成部分,为企业分布式复杂应用系统和移动应用系统等提供了强有力的测试支持。

图 4. Rational Test Workbench 架构图
图 4. Rational Test Workbench 架构图

Rational Test Workbench

图四中,黑色方框内是 Rational Test Workbench(Rational 测试工作台),该测试工作台提供了广泛的测试能力,包含 GUI 的功能测试、消息接口的功能测试、GUI 性能测试脚本的编写、消息接口的性能测试脚本的编写、消息接口的桩的脚本的编写和移动应用的测试等,具体包括以下四个组件:

  • Rational Integration Tester(简称 RIT)
  • Rational Functional Tester(简称 RFT)
  • Rational Performance Tester(简称 RPT)
  • RTW Mobile Client

并且 RTW 其可以和性能测试服务器(Rational Performance Test Server)/ 服务虚拟化服务器(Rational Test Virtualization Server)协同工作,共同完成大规模,多团队的服务测试,性能测试,服务虚拟化仿真等 .

集成测试组件 RIT

Rational Integration Tester(以下简称 RIT)定位是用于测试分布式复杂应用系统的自动化测试工具,优势是支持复杂系统的多种类型的接口的自动化测试,可以把不同类型的接口测试组合起来,按照业务流程形成一个完整的测试过程。

其可以应用于传统的系统(例如文件, FTP,中间件)和新建应用(SOA、XML、JMS、ESB、BPM、CEP、Cloud 等)。通常这类系统没有用户界面,RIT 提供了基于 UI 的测试能力,也能够被集成到客户现有的产品中。 RIT 为复杂环境的客户提供了完整的集成测试能力。具体特性包括:

  • 无需编码的测试

传统的自动化测试工具需要用户编写测试脚本。RIT 使用一系列可配置的测试步骤来构建测试脚本模型并且使其与测试者的活动更紧密。例如,“发送消息”、“与预期的消息比较”、“查询数据库”、“在日志文件中查找错误”、“检查文件的一致性”等等,都无需测试人员手动编写测试脚本。由于无需手动编写测试脚本,测试人员将关注于与工具向导的交互,例如通过 Schema 和消息交换模式来生成测试、修复损坏的测试等。通过消除手工的、重复的、耗时的操作,RIT 可以让测试人员的精力关注在更有价值的活动上。

  • 产品架构

RIT 提供了图形用户界面来管理测试资产,用于交互执行和优化测试用例。测试用例也可以通过命令行、ANT、Maven、或者其它测试管理工具执行。RIT 是一种基于 OSGI 的应用,使用了 Eclipse 框架的元素。

  • 报告功能

测试结果被写入可定制的报告,可以通过 Web 浏览器或者产品本身来查看。报告可以被导出为 PDF 或者 HTML,也可以导入到 Word 或者打包通过邮件自动发送。

  • 丰富的可扩展性

RIT 提供了丰富的可扩展性,例如定制数据转化、验证、数据传输和接收、数据格式化等。

  • 持续测试和验证

RIT 能够很好的与持续构建服务器集成在一起,以调度的方式执行测试并报告结果。RIT 还可用于持续的验证服务,包含语义检查,响应时间违规报告。

  • 测试和缺陷管理

RIT 具有和测试管理和缺陷跟踪系统集成的能力,例如 IBM Rational Quality Manager。允许从测试管理工具中执行测试并收集结果。支持集成 JIRA 和 IBM Rational Team Concert 作为缺陷跟踪系统。并且,能够在缺陷中包含上下文信息,以帮助开发人员快速修复。

  • 多协议支持

RIT 提供了大量的协议支持能力,并且还在不断更新。涵盖了常见厂商的产品和技术,提供了强大的行业特定协议的支持,例如医疗、金融、交通等。如图五所示:

图 5. RIT 支持的协议
图 5. RIT 支持的协议

GUI 功能测试组件 RFT

试想,一个网上在线商场系统,需要考虑用户的不同使用习惯,主流的用户可能使用 Windows2003,,WindowsXP,Windows 7 等不同操作系统,使用 IE,FireFox 等不同浏览器;那么在线商场系统是否在不同操作系统 / 不同浏览器的组合情况下,,都可以正常工作呢?这就需要针对这不同测试环境分别进行测试,即针对测试环境的覆盖率测试。而自动化回归测试工具的“一次录制,多次(不同环境)运行”就可以完全满足这种需求,提高测试覆盖率。

功能测试工具的技术特点是“一次录制,多次运行”,测试人员在第一次测试时候录制标准答案,以后在应用发生了修改以后,或者需要覆盖更多测试环境情况下,调出第一次录制的脚本,让自动化功能测试工具自动运行,得出测试结果。

图 6. 自动化回归测试测试环境覆盖率
图 6. 自动化回归测试测试环境覆盖率

自动化功能测试主要围绕界面进行测试,通过自动录制形成测试脚本实现自动化的功能 / 回归测试。Rational Functional Tester(以下简称 RFT)就定位帮助测试人员完成 PC 应用自动化功能测试。RFT 支持对浏览器、Java Application 应用、SAP、Siebel 应用以及 .Net 界面应用的功能测试自动化,其测试脚本语言采用 Java 或 Microsoft VB .NET,并可和 Eclipse 或 Microsoft Visual Studio .NET 集成。由于采用标准的测试脚本语言,测试人员无须学习特定语言的语法和 API,同时通过和开发环境集成,大大降低了工具学习成本,甚至开发人员也可以迅速掌握该工具,积极参与到自动化测试脚本的开发过程中。

RFT 提供了标准的脚本录制功能,并在无需编程的情况下,快速实现测试数据的参数化,提高测试脚本的开发效率。

此外,在测试脚本的开发方式上,测试人员使用 RFT 可从最初的基于录制和数据驱动技术,逐步过渡到基于测试框架的脚本开发技术。

RFT 具体特性包括:

  • 支持多种 IDE:为 Java、Web、SAP 和 Siebel 和 Microsoft Visual Studio.Net 程序
  • 定制生成 Java 或 Visual Basic.Net 语言的测试脚本
  • 为高级测试人员提供原汁原味的 Java 和 VB.NET 编辑器和调试器
  • 通过 ScriptAssure 技术,支持“按照属性的优先级”来设置对象识别,从而灵活的应对频繁的用户界面变更,如测试多语言系统时候,把语言相关的属性设置低优先级,从而使测试环境做到和系统语言无关。
  • 多点验证,支持正则表达式的模式匹配自动化的数据关联和数据驱动测试,消除手工编码的需要
  • 先进的对象映射维护能力
  • 可用于测试 3270/5250/VT100 终端应用程序

GUI 性能测试组件 RPT

一个大型的应用系统,在多个人访问的情况下是否还可以稳定,高效的运行,如火车票购买网站,是否支持在春运的时候,多个人同时访问,进行正常的火车票查询和预定?这就需要通过性能测试来检验。

性能测试是为描述测试对象与性能相关的特征,并对其进行评价而实施和执行的一类测试,如描述和评价测试对象的响应时间、吞吐量,以及操作的可靠性和限制等特征。一般可以使用被测系统的动态监测报告、响应时间及吞吐量报告、百分位图报告和各种性能比较报告,对被测对象进行性能评测。

性能测试可以有效地帮助测试人员和性能工程师验证系统的性能,识别和解决各种性能问题。它适用于性能测试人员和性能优化人员,用于开发团队在部署大型应用程序前,验证其可扩展性、性能和可靠性。

性能测试方案的系统架构如图所示,性能测试工具安装在 Master 主机上,控制脚本运行和整个负载加载过程。根据负载模型的要求,首先将测试脚本下载到 Agent 机器,然后在 Agent 机器运行脚本,模拟多个虚拟用户,分别加载到服务器。同时在整个测试过程自动收集测试数据,由测试主机统一处理,生成测试报告及各种报表。

图 7. 性能测试工具工作图
图 7. 性能测试工具工作图

Rational Performance Tester(以下简称 RPT):RPT 能支持 HTTP/ HTTPS、SAP、Siebel、Citrix 和 TCP Socket 协议,同时客户可利用 RPT 提供的协议开发工具包(Protocol SDK),自主开发特殊协议的适配器,从而实现对其它协议的支持。RPT 基于 Eclipse 平台,并基于 Java 脚本语言,能快速开发性能测试脚本、建立性能测试负载模型、灵活运行性能测试并生成各种性能测试报告,具有易用性和开放性等特点。此外,RPT 能实现对服务器资源的实时监控,并建立资源使用状况和服务器响应状况的关联,从而帮助快速定位在操作系统层面的性能问题。对 J2EE 应用,RPT 还能进行性能深层次分析,更准确定位应用代码中的性能问题。在执行性能测试时,支持配合 Rational Performance Test Server 使用。

RPT 具体特性包括:

  • Web、SAP、Siebel 和 Citrix 应用程序的性能测试
  • 可视化编辑器同时提供测试的高层视图和详细视图
  • 不同用户群的灵活建模与仿真
  • 运行时的报告能够立即识别性能问题
  • 自动识别和支持动态服务器响应
  • 测试中用户负载动态变化
  • 服务器资源数据的收集与可视化展现
  • 采用浏览器样式显示测试中的每一张网页
  • 能对服务器资源进行监控
  • 能对 J2EE 应用性能问题进行深层分析

移动应用测试组件 RTW Mobile Client

“移动改变生活”,如今,如果你使用的不是智能手机,那么真的有可能是 Outman/out woman 了,我们出门打车,察看天气,移动交流,微博微信,这些都已经渗透在我们的生活中。众所周知,移动应用已经在我们的工作生活中广泛使用,电影票,机票,打车,银行转帐,购物都可以通过 App 来解决;而移动 App 的开发测试也面临着很多的挑战,重要的是作为移动终端,类型多样化,技术多样化。如 Android 操作系统的版本众多(Android 2.2 到目前最新的 4.2),这些都会让移动 App 的开发者面临着这样的疑问:我们开发的 App 是否可以支持这些名目繁多的手机 / 系统 / 版本?如何测试呢,针对没有手机终端或者模拟终端进行手工安装,跑功能测试?

这就是自动化的移动测试要解决的问题。

RTW Mobile Client 是 Rational 测试工作台在 V8.5 以后新增的功能,主要针对移动应用系统提供相应的测试解决方案。其采用录制 - 回放 - 检查结果的过程,完成手机应用的自动化测试。

具体特性包括:

  • 提供简洁的 IDE 和终端程序来修改测试脚本、执行测试案例和生产测试报告
  • 自然语言描述操作步骤及可视化的编辑测试脚本
  • 支持运行在 Android 和 iOS 上 native 和 hybrid 类型的应用
  • 融合了移动和 Selenium 的多流程的 Web 界面测试
  • 集成 RQM(Rational Quality Manager)增强测试计划和图形展示能力
  • 集成 IBM 移动开发平台
图 8. 移动自动化测试过程
图 8. 移动自动化测试过程

我们后续会在《使用 IBM Rational Test Workbench 测试 Android App 应用》中详细介绍使用 RTW 来测试移动应用程序。

Rational Performance Test Server

通常我们希望在系统上线之前就可以找到 SOA 应用或者基于“消息”的系统的性能瓶颈,与传统的独立应用系统性能测试不同,这类应用的性能往往涉及到很多层面:多端点、多主机、极限消息传输率、极限消息大小、消息延迟等等。作为 Rational Integration Tester 的扩展,Rational Performance Test Server(以下简称 RPTS)为分布式复杂环境和 SOA 的性能测试带来了便利。这允许用户重用任何消息接口的功能测试脚本(RIT 脚本)作为性能测试的基础,混合不同类型的交互来测试应用对服务器实际负载的影响。有点类似传统的性能测试工具中的混合测试?对,的确是的,但请注意的,在这里混合的协议很多是后台服务器要使用到的协议,而不仅仅是第一层客户端发送给后台的协议数据包。

作为 RIT 的性能测试扩展,用户通过 RIT Performance Controller 定义性能测试的场景,测试负载通过 RPTS 可以在多台服务器上通过代理(Agent)生成。通过采用探针的方式,操作系统和特定消息数据可以被捕获并返回结果,同时用户能够通过图形化的界面(RIT Client)来进行分析而无需进行编程。此外,还能够通过并行执行多个消息端口的测试来充分模拟实际的业务场景。

在性能测试过程中,仅仅收集简单的 CPU 和内存的信息是远远不能够满足分布式复杂系统和 SOA 应用的需求的。RPTS 通过探针(Probe)技术来助力挖掘出性能测试期间各分布式组件的底层详细信息。RPTS 涉足分布式复杂系统监控领域已经超过 10 年,知道哪些性能指标是最重要的并且能够轻易获取。通过一个简单的配置接口就能够访问数百种关于 TIBCO,Sonic,IBM,BEA 等中间件的性能度量指标。

图 9. RPTS 性能测试架构图
图 9. RPTS 性能测试架构图

只有获取了详细的性能监控指标运行结果的性能测试才是一个有效的测试,RIT 的性能监控图表引擎可以在测试执行阶段或者结束阶段,从海量的性能指标数据中提取我们最需要的信息。并且能够导出成各种形式的报告,以各种我们希望的图表形式体现。我们可以:

  • 通过单击,实现跨多台机器的消息汇总分析;
  • 定义与多台测试机相关的性能指标;
  • 通过探针捕获测试执行期间的性能测试指标;
  • 捕获受测试影响的基础架构的性能指标;
  • 通过灵活的图表,在测试执行期间或者结束后进行性能指标分析;
  • 通过回归测试比较不同的测试结果;
  • 与团队成员共享测试结果;
  • 通过模版,快速进行通用负载测试场景分析;
  • 通过 RIT 报告性能测试问题

Rational Test Virtualization Server

介绍

Rational Test Virtualization Server (以下简称 RTVS)。RTVS 能够在多种场景下使用,进行服务的虚拟,不仅仅局限于在测试环境供 RIT 执行。作为能够独立运行的模块,RTVS 同样能够在各种测试场景或开发环境中为手工测试人员和开发人员带来便利。并能够与 RIT 无缝集成:

  • 测试人员往被测系统发送一条消息,被测系统将执行业务操作并调用相关虚拟服务。
  • 虚拟服务接到被测系统发送过来的请求,并验证消息的正确性。
  • 虚拟服务决定如何响应消息(例如,错误处理、查询请求、超时等)。
  • 响应通过虚拟服务发送回被测系统,RIT 将验证响应是否正确。
图 10. 服务虚拟化解决方案
图 10. 服务虚拟化解决方案

方案的价值

Rational 测试工作台解决方案能够为客户带来如下的价值:

  1. 构建强大的测试团队

虚拟服务通过中央存储区进行集中存储,方便团队开发和测试成员进行访问。团队成员随时查看虚拟集成环境的配置,并在浏览器中根据不同的测试场景快速简洁地进行修改。RTVS 的虚拟服务能力,包括:

  • 预制的:用户使用任意的输入,始终返回预制的响应,并且是可控的。
  • 参数化:虚拟服务使用一个数据集,通过表单、数据库或文件返回大量不同类型的数据。同时还支持将数据反持久化到响应的数据源中。
  • 带状态的:基于早期数据返回响应,例如,在一次会话中。
  • 模型驱动:RTVS 提供了丰富的应用行为库,比如持久化、数据供给、B2B、甚至是交易环境等。
  • RTVS 提供了功能强大的向导工具以通过记录的方式创建虚拟服务、数据库、 SWIFT、HL7、IATA、JMS、Web Services、SOAP、REST、TCP/IP 等。
  1. 完美的敏捷开发支持

RTVS 为敏捷团队进行持续测试提供了良好的支持。由于应用是虚拟的,团队无需在开发环境和测试环境中切换配置,并且任何人对虚拟环境的修改都不会影响到实际的系统环境。开发人员和测试人员将采用完全相同的测试环境,以更好支持并行开发 / 测试。

  1. 更快、更低成本的测试

项目团队可以通过在不同场景下使用 RTVS 而获取价值:

  • 通过模拟外部系统,使得集成测试环境相对独立,避免了潜在的风险。
  • 虚拟服务提供的通用响应能力能够将当前测试与即将进行的测试继续比较,以更好地复用测试。
  • 通过可重复、可复用、非人工的方式加速 BPM 应用的测试。

简言之,服务虚拟化可以帮助我们:

  • 通过虚拟化来加速软件交付质量,提升开发和测试速率。
  • 跨团队的测试环境共享,实现并行开发。
  • 跨组织团队实现追踪和基于上下文的协作。
  • 虚拟化系统的服务,提供 24x7 的测试能力。
  • 降低搭建传统测试环境基础架构的支出。
  • 跨越对软硬件,云环境的依赖,交付更快的,端到端的持续集成测试。

我们后续将会在《使用 RTW 对 Web service 进行接口测试和虚拟化仿真》,《扩充虚拟化,实现灵活的服务虚拟化》等文章进一步展开服务虚拟化,结合具体的案例,和大家一起学习讨论。


小结

通过本文,希望读者能对 Rational 测试工作台有一个初步的了解,在后续的文章中,我们会对 Rational 测试工作台的各个组件进行专题的介绍,使 Rational 测试工作台可以应用到读者的生产和工作之中。

参考资料

学习

获得产品和技术

  • 下载更多免费的 IBM Rational 试用版软件,了解 IBM Rational 软件的最新特性。
  • 获取更多 IBM 试用版软件,并熟练掌握来自 DB2®、Lotus®、Tivoli®,以及 WebSphere® 的开发工具和中间件产品,用这些试用版软件开发您的下一个项目。这些试用版软件可以免费直接从 developerWorks 下载。

讨论

  • 加入 developerWorks 中文社区,developerWorks 社区是一个面向全球 IT 专业人员,可以提供博客、书签、wiki、群组、联系、共享和协作等社区功能的专业社交网络社区。
  • 访问 developerWorks 社区上的 敏捷开发小组,在那里您将有机会与更多的开发人员一起交流敏捷开发最佳实践。
  • 加入 IBM 软件下载与技术交流群组,参与在线交流。

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=938333
ArticleTitle=Rational Test Workbench 基础: 初识 Rational Test Workbench
publish-date=07232013