Ibm rtw rtvs_implementation_guide_v4_0_2_public_release

© IBM Corporation 2016
U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA
ADP Schedule Contract with IBM Corp.
Rational Test Workbench
And
Rational Test Virtualization Server
Implementation Guide
Guidelines and suggested best practices for users of
IBM® Rational® Test Workbench
And
Rational Test Virtualization Server
Version 4.0.2

IBM RTW RTVS Implementation Guide v4.0.2-Public-Release.doc Page 2 of 64
Revision History
Date Version
28 Nov 2012 0.1
09 May 2012 1.0
31 May 2012 2.0
03 Feb 2014 3.0
28 May 2015 4.0 first public draft
02 Jul 2015 4.0.1 Public Release
15 Feb 2016 4.0.2, added
“Debugging what is
happening in RIT”

Contents
1 Introduction.............................................................................................................................. 5
1.1 Package Contents ............................................................................................................. 5
2 Service Virtualization and Software Testing – Concepts......................................................... 7
2.1 Tests and Virtual Services................................................................................................ 8
2.2 Consumer-centric vs Provider-centric.............................................................................. 8
2.3 General Testing Guidelines when using the product ..................................................... 11
2.4 Test Types and Phases.................................................................................................... 12
3 Rational Integration Tester..................................................................................................... 17
3.1 Learning about the System Under Test (SUT)............................................................... 17
3.2 Building Tests, Virtual Services, and related assets....................................................... 22
4 Rational Test Control Panel ................................................................................................... 24
4.1 Domains and Environments ........................................................................................... 24
4.2 Publishing versions of a stub.......................................................................................... 25
5 Rational Test Virtualization Server........................................................................................ 26
5.1 Roles of Rational Test Virtualization Server ................................................................. 26
5.2 Running Multiple Versions of Virtual Services Concurrently....................................... 26
6 Developer’s Guide.................................................................................................................. 29
6.1 Project Environments revisited ...................................................................................... 29
6.2 Default Project Structure................................................................................................ 30
6.3 Naming Conventions...................................................................................................... 30
6.4 Rational Integration Tester Perspectives........................................................................ 33
6.5 Version Control and Sharing projects............................................................................ 37
7 Thoughts on Project Methods ................................................................................................ 38
7.1 Summary of Phases........................................................................................................ 38
7.2 Phase 1 - Discovery........................................................................................................ 39
7.3 Phase 2 - Configure........................................................................................................ 44
7.4 Phase 3 - Virtualize (record) .......................................................................................... 45
7.5 Phase 4 - Model.............................................................................................................. 46
7.6 Phase 5 - Deploy ............................................................................................................ 46
7.7 Phase 6 - Execute ........................................................................................................... 47
8 A brief discussion of Governance (Organizational models) .................................................. 48

8.1 Cost-Effective Division of Labor................................................................................... 48
8.2 To CoE or not to CoE?................................................................................................... 51
Appendix A. Special Note on Contracts - WSDL .................................................................... 52
Appendix B. Special Note on Contracts - XSD........................................................................ 53
Appendix C. Virtual Service Complexity................................................................................. 54
Appendix D. Bottlenecks (queueing model discussion)........................................................... 56
Appendix E. Software Versions ............................................................................................... 57
Appendix F. Software Support Subscriptions.......................................................................... 58
Appendix G. License Keys and Support................................................................................... 59
Notices .......................................................................................................................................... 61
Table of Figures
Figure 1 Tests and Virtual Services - points of interception .......................................................... 8
Figure 2 Summary of Test Types and progression ....................................................................... 12
Figure 3 Timed Sections in Performance Tests ............................................................................ 16
Figure 4 (From RTW KC) Methods of creating assets................................................................. 17
Figure 5 MQ Queue Manager physical transport stubbing settings ............................................. 20
Figure 6 MQ Queue Manager physical transport recording settings............................................ 21
Figure 7 Publishing Virtual Services - versions ........................................................................... 25
Figure 8 Project Environments ..................................................................................................... 29
Figure 9 Default project structure................................................................................................. 30
Figure 10 Suggested folder structure ............................................................................................ 30
Figure 11 Business View (vs Technical View)............................................................................. 33
Figure 12 Role relationships......................................................................................................... 49
Figure 13 Bottlenecks and the queueing model, or “why are tests running slowly?” .................. 56
Figure 14 “View installed packages” from menu......................................................................... 57
Figure 15 Example of installed packages listing .......................................................................... 57
Figure 16 Browse for a product on the IBM support web site ..................................................... 58
Figure 17 Successfully Subscribed ............................................................................................... 58

1 Introduction
This document presents guidelines and suggested best practices for users of IBM Rational Test
Workbench and Rational Test Virtualization Server, the IBM products that support Automated
Integration Testing and Service Virtualization. A key component of Rational Test Workbench is
Rational Integration Tester, the target of much of this document, but other components are given
treatment as well.
Automated Integration Testing (also known as Sub-GUI testing) enables the injection of requests
to interfaces or services, via the same technologies used by other consumers of that interface.
The automation of this level of testing is a very strong accelerator for software testing – and at
the same time provides a terrific opportunity to increase the quality of software applications.
Service Virtualization is a technology and approach that can replace a live service with a
software ‘responder’, which consumes a tiny fraction of the resources that most live services
would require. At the same time, this Virtual Service should be indistinguishable in operation
from the live service for the test scenarios that the Virtual Service was designed to manage.
Before starting, there’s one overarching concept that should be addressed first. The System
Under Test (SUT) is the program or function that must be tested. You never want to pretend to
be (to 'virtualize away') the actual function you are testing - the code you have produced – or you
would never find all the bugs - this is a core idea that will be revisited throughout this guide.
Please note that while these are peer-reviewed best practices, some are necessarily a bit arbitrary.
Your decisions will be more informed after reviewing this document, but your decisions are your
own.
Lastly, the footnote URLs that are “shortened” in this document all refer to IBM web sites. All
other URLs are full URLs, in consideration for those who are sensitive to security.
 Feedback on any part of this early draft document is welcome; please send email to
hudacek@us.ibm.com.
1.1 Package Contents
Rational Test Workbench includes:
 Rational Integration Tester
 Rational Performance Tester
 Rational Functional Tester
 Rational Test Control Panel
 Rational Test Workbench Mobile Client
This component enables mobile UI testing and Selenium based browser testing.
Rational Test Virtualization Server, the deployment-time software, includes:
 Rational Test Control Panel
 Rational Integration Tester Agent
 Rational Performance Test Server
 Probes (to obtain & save metrics during Performance Testing)

Rational Test Control Panel is included in both packages. Rational Test Control Panel is the
web-based dashboard and controls the array of technologies that enable recording and playback
(in the case of Virtual Services).
Note: There are no installable packages with the names Rational Performance Test Server and
Probes; these are simply options when installing from the Rational Integration Tester Agent
installation package.
 Rational Integration Tester Performance Tests can be run using Rational Test
Virtualization Server, but there are differences between Performance Testing in
Rational Integration Tester and Rational Performance Tester: Rational Performance
Tester does not use Rational Performance Test Server; instead, it uses its own
Performance Test agents. Rational Performance Tester is not addressed in this
document.

2 Service Virtualization and Software Testing – Concepts
Rational Integration Tester can be used much earlier in the Software Development Life-Cycle
(SDLC) than is possible with traditional Functional and Integration Testing tools. Developers
can use the product to test software immediately upon starting work on a project, phase, sprint,
feature, etc. This section gives some recommendations regardless of test cycle, but also attempts
to address specific types of testing using the product.
There are traditionally three approaches to defining, building, and working with Integration Tests
and Virtual Services:
1. Create from the message specification – ‘contract’
This is usually in the form of WSDL and XSD for web services, but could also be other
specifications such as COBOL Copybooks. If you are building Tests before or during
development there may not be a live system to record, so this capability can be very valuable.
2. Record the data sent to a service (and associated response)
From the recording, it is possible to create a ‘sub-GUI’ test that drives the back-end service,
or to create a virtual service1
that will respond instead of the live service. Sub-GUI Tests are
usually more fine-grained than typical end-to-end (UI Automation) testing tools can provide.
3. Do the work yourself.
If you do not have contracts, or you are working with a message format that does not use
contracts, and you cannot record requests and responses, then you will need to create Tests
and Virtual Services manually. This may involve use of ‘payloads’ – example requests and
responses – to quickly configure a Test or Virtual Service. Alternatively, you can build up a
Test or Virtual Service with no data, and no contracts, and later reconcile your Tests/Virtual
Services with actual systems as they come into existence.
1
Virtual Services may also be referred to as ‘stubs’ throughout this document, and the product
uses the term ‘stub’ throughout its graphical user interface.

2.1 Tests and Virtual Services
When working with interfaces, there’s one important concept that should be established right
away: work with the tool in front of an interface/service to create Tests, and behind a system to
create a Virtual Service (stub). A test is something that is created to exercise a service/interface.
A virtual service (stub) is something that simulates all, or a subset, of services/interfaces needed
by the SUT.
Figure 1 Tests and Virtual Services - points of interception2
When you run a test, you are testing the System Under Test (SUT). When you record a Virtual
Service, you do so behind the SUT (you are recording its interactions with its back-end systems).
As you can see, the SUT is a relative thing. When you record Tests or Virtual Services at
multiple layers in your IT environment, you have multiple SUTs – one for each such targeted
component, application, system, etc.
Some may envision an application where there is a GUI simply calling a back-end. If you are
testing that ‘back-end’, it is your SUT, and you are creating Tests to exercise that back-end. If
you are recording the interactions from the GUI to that back-end, you are creating Virtual
Services for your GUI. Such might be the case if you are using a mobile application that makes
RESTful calls to its back-end services.
 You might hear vendors, business partners, or other users refer to “virtualizing inputs”
to describe recording in front of an SUT (for example, an asynchronous stream of
messages that is to be ‘replayed’). This is the same as a ‘test’. IBM considers
“virtualized inputs” to be confusing and less than precise.
2.2 Consumer-centric vs Provider-centric
In traditional IT Environments, there are providers of services, and each of those has its own set
of consumers. Thus, an enterprise service that performs customer Master Data Management
2
See https://ibm.biz/BdEFBm for the full blog entry.

(MDM) is a provider of that service, and all applications that make calls upon the MDM service
make up the list of consumers of that service.
This section discusses the trade-offs in choosing consumers or providers as the focal point for
Service Virtualization.
Table 1. Key issues for consumers and providers
Issues Faced Impacts
Consumers?
Impacts
Providers?
“Critical path” dependencies delay testing X X
Back-end outages impact testing X X
Test Environment won’t scale X X
Back-end services not built/ready X X
Lost time coding and testing stubs/mocks X X
Must provide multiple versions of a service X
Can’t test in parallel (shared resource conflicts) X
Pre-test configuration difficult X
Test environments too costly X X
Table 1 shows that consumers and providers of services and interfaces have similar problems
during software development. Some customers have focused on the provider of services when
considering how to adopt Service Virtualization. There are important consequences to this
choice. While it may be appropriate for some, you may find that you are not maximizing the
benefits or minimizing the costs.
Virtual Services can be created by recording behind a SUT, in other words requests sent from the
SUT. Thus, Virtual Services are of most interest to consumers of a back-end interface. This has
ramifications that are perhaps not immediately obvious, so let’s explore this topic in a bit more
depth.
Costs: Imagine you are the provider of a service, with a few dozen applications across the
enterprise that consume your service. Each application development group would like a virtual
version of your service, but with tailored test data for their Integration/Regression/Performance
Tests. You may wish to have one Virtual Service for each group of applications, with each using
custom test data. However, realistically, each application team wants to have multiple Virtual
Services (whether different or the same version), each instance having specific test data loaded &
available. Each of those groups also has multiple test environments, and likely wants a stub for
each environment (possibly with each of those available in multiple versions).
You as the provider already provide the service. If you also own the ‘privilege’ of providing the
virtual service, then you are taking on a not-inconsiderable workload. If a dozen teams each
have five test environments and they have four different versions simultaneously in use in their
test environments, then that’s 12 * 5 * 4 = 240 stubs – for one consumer and the corresponding
interface that you wish to virtualize. Some back-end service providers manage 1,000 interfaces
(e.g., Web Service “operations” or MQ-based messaging interfaces). It’s not a manageable task
for any provider, and if one team cannot scale this way, it’s clearly not feasible as an enterprise-
wide approach.

Benefits: Now, who benefits most from the use of virtual services? The consumers – end of
argument. However, placing responsibility and ownership with the provider means the provider
invests, but the consumer benefits. As should be clear by now, this is an unbalanced model.
Nevertheless, let’s talk a bit more about why this is true.
Rather than accelerating development and testing by freeing consumers of the hard dependencies
on providers, this would actually be increasing the level of dependency. Coordination between
projects would still be critical. The same fragile “wait for breaking changes” phenomenon that
is such a serious issue today would still be present. In other words, the critical path is still
critical. Nothing has been done to change the game.
This is why the focus is on the consumer. When consumers manage their own back-end
dependencies, it’s possible to virtualize all of a SUT’s back-end interfaces and not inform even
one of those back-end service providers. For back-ends that don’t exist yet, consumers can
create Tests and Virtual Services that enable full-function automated Integration/Performance
Testing without waiting for the provider to provision the infrastructure and complete installation
and/or configuration of the back-end service.
Now, imagine being a service provider and having to create Virtual Services before being
permitted to allocate actual resources and create the real-world service, which might be called
“deliver before actually delivering”.
[This ignores, of course, the case where there is no intention to ever create a physical service
running on a real virtual or native “computer” – because you have SV as a solution. Discussions
around this sometimes are labeled “test environment virtualization” because when you create all
the back-end services for an application, it’s possible to complete testing without ever having a
real live back-end server].
Each ‘consumer’ or ‘consumer group’ can share Virtual Services (e.g., at the level of a domain,
as discussed elsewhere in this document), if the consumers decide it is worth doing. But forcing
consumers to clump together and forcing SV development to be done by the same provider that
already can’t meet deadlines for real services…….is not a recipe for success.
 Note that a provider can still also automate their own Integration Testing, since they can
create Tests by recording in front of their system, and they can still use SV. Having
the discussion around SV with a service provider makes their system the SUT; they
most likely have their own set of dependencies, after all.
This also implies that, once the perspective shifts to the provider’s system, the
consumers of that provider are no longer part of the (new) conversation about testing
and Virtual Services.
This is a subtle point: as you work within an enterprise, your discussions with various
groups will each focus on a different SUT, whether large or small.
One final thought: note that if the provider records requests and responses, that recording may
not be useful to the consumer, who would rather make their own recording behind their own
SUT. This means that a provider-centric model now requires even more communication and
shared management – as the consumer may have to supply human resources and make their own
test environment available so that they can execute Tests to drive traffic to the provider’s
environment. Why slow down both parties, again, when a consumer-centric model enables every
consumer to proceed without consulting any of their providers?

Having said all this… there are always exceptions to the rule. You might still use a provider-
centric model – if a provider only has a single consumer. This might be true for a vertical
application, where the different architectural tiers belong to the same IT
department/organization. It may also work for small or very homogeneous organizations.
2.3 General Testing Guidelines when using the product
When incorporating automated integration testing and service virtualization into any testing
method, please consider these recommendations:
 Do not wait for the UI to automate your Tests.
These tools are designed for automated Integration Testing. They do not require a user
interface to be in place for your SUT. Traditionally, substantial time may pass before a UI
is in place (or has been updated).
 Test early and often.
Testing earlier in the lifecycle means that defects are less expensive to resolve. Plan to run
automated Integration Tests often.
 Don’t forget that the product is designed to work with popular Continuous Integration tools
like Jenkins, enabling further automation.
 Plan for flexibility by stubbing strategically.
If the impact of risky or unreliable back-ends unavailable in a given test environment is
high, then customers should plan to create Virtual Services to replace those back-end(s)
before they become unavailable. This means that when the inevitable happens, testing can
continue. Note that it’s possible to use Virtual Services from other test environments, and
in some cases, even the data from those other environments.
 The best approaches to testing are risk-based.
Identify the most important risks faced in testing each application. Do not create Virtual
Services for low-risk interfaces that are stable, responsive, and accurate. Instead, aim for
‘low-hanging fruit’, the sources of the most pain in development and test.
 Define your own reality.
You have control over all physical properties of the stub you create. In the real world, you
cannot turn off a mainframe or cause it to respond more slowly. A stub can be instructed
never to reply to a specific request – or to wait for longer than the SUT application’s
timeout settings. A stub can even provide a completely corrupt response (aka “fuzz
testing”). The product enables excellent negative testing, which is often not possible using
other test tools.
 Use Test Suites to group Tests.
Rational Integration Tester provides Test Suites to execute Tests in sequence or in parallel.
In such cases, it might be necessary to pass Tags (which is the product term for variables)
between Tests. The KnowledgeCenter documents the mechanics of Tags3
. Tags should be
correctly designated as input or output in individual Tests, so that the output values of one
test can be used as an input value to another test within a suite.
3
“Tag Data Store” – See https://ibm.biz/BdXqsr

 Make your projects portable.
Some of the test resources you work with will be URLs or URIs. These types of test
resources need to be “reachable” by all those with whom you share projects. If those
resources are not available to all, compensate for this fact by including local versions of the
resources; this helps, for example, when working with IBM Technical Support.
The term ‘portable’ here means that any time you have file-based assets or resources,
always store them inside the project directory on disk, or users on other computers may get
errors because the files will not be present on those computers.
 On the other hand, if you have simple ‘reference information’ that developers use, such
as design documents or data dictionaries, do not store those in your project – they will
be transferred as part of the project every time you publish and deploy! This can greatly
slow down operations and some customers have exhausted disk space because they
did not know that it was happening.
2.4 Test Types and Phases
Figure 2 Summary of Test Types and progression
Note that in the figure above, Functional Integration Testing and Performance Testing are
possible during the full lifecycle of software development. This reflects the use of the product(s)
described in this document.
The job roles involved in this new world of testing might be as shown in Table 2 below.
Table 2 Job roles and testing
Type of Test Creator Executor/User
Unit Dev Dev
Integration Dev, Tester Dev, Tester
Performance Dev, Tester Dev, Tester
2.4.1 Static Testing (Compliance Testing)
Compliance testing ensures that the software is compliant with industry or governmental
standards such as those published by W3C and others. Rational Integration Tester supports
compliance testing through validation of the contracts that define services (in those cases where
WSDL or XML Schema are used), including WS-I Policy validation4
.
4
“Compliance testing before running tests” - See https://ibm.biz/BdXqsZ

2.4.2 Unit Testing
The goal of Unit Testing is to validate individual components, whether those components make
calls to one or more back-end services or not. When developers perform Unit Testing using the
product for Tests and/or Virtual Services:
 Use simple test data; if you record, you can simply use that data for Tests or Virtual
Services; there is usually little need to create intelligence or add heuristics to generated
assets as the test or stub often will not be shared.
 It’s a productivity gain (whether or not you choose to record) to create Tests from
resources – e.g., Using Discovery or through schemas (WSDLs, Copybooks, WADL,
protocol buffers, etc.).
 Recording and executing the ‘Save Events’ wizard is generally the quickest way to produce
Tests or Virtual Services.
 Use the product to create simple, individual Tests for a SUT with some or all back-end
service providers stubbed out.
 Tests can be grouped into Test Suites (e.g., based on related application function); Test
Suites can then execute the Tests sequentially or in parallel.
 Do not forget negative testing.
 Generate a report for Unit Tests – even if the testing is minimal – by configuring a results
database and creating Test Suites.
2.4.3 Integration Testing
The goal of Integration Testing is to validate interfaces between multiple components/systems.
Virtual Services can be used in place of ‘live’ back-ends as described elsewhere in this
document, but as live services become available, they can also be used in Integration Tests run
by the product. Unit Tests should still be run, even after creation of Integration Tests.
 Developers (or Testers) can reuse existing test assets to build (suites of) Integration Tests.
 Recording traffic and executing the ‘Save Events’ wizard is generally the quickest way to
produce new Integration Test assets, but this document also discusses ways to create Tests
without having a back-end service available.
 You should export recorded data immediately, as the events will be lost once you exit
Rational Integration Tester; see Section 3.1.3.1 on page 18 for more info.
 If you use the Recording Studio wizard to create an Integration Test using a Simple Data
Set, the data is put into a spreadsheet – which you can later edit to add boundary test cases
and negative test cases.
2.4.4 System Testing
System Testing tests the entire system – whether it is a single web application or a cluster of
systems that cooperatively provide a ‘business process’. As Unit and Integration (Sub-GUI)
Testing are now used to perform exhaustive testing, including negative testing, of components,
System Testing can concentrate on verification of correct function.

 Data-driven Tests can be used to drive coverage requirements.
 Tests can concentrate on validating all possible paths in a business process.
 Once Tests are successful, group all Tests of a business process into one or more Test
Suites; this produces a verified, automated regression test.
2.4.5 System Integration Testing
The goal of system integration testing is to verify functionality of an end-to-end business process
that spans multiple systems. The testing should cover business logic, sequencing, exception
handling, and process decomposition (including service and process reuse) that spans multiple
systems.
 All end-to-end business processes along with all paths of execution should be validated
(building on the test assets used in System Testing).
 Different Tests should be created for each logic path (including exception handling) and
then grouped into Test Suites.
2.4.6 Performance Testing
There are many types of Performance Testing. While load testing of an entire site at production
levels is important, and there are tools to accomplish this, stress testing of individual components
can also be very useful, where the physical size of the system/environment is not as critical.
Rational Performance Test Server is very capable at this type of testing. During early
Integration-related activities, Stress Testing brings to the surface any issues related to the design
of a component, but also to the ‘glue’ – the points of integration found in every distributed
application system.
 Stress testing does not have goals like concurrency levels or response times; rather,
the goal is to force a failure to occur, to determine the resilience and flexibility of a
component. An application whose components and integration points have been
stress-tested is much less likely to encounter issues during system Performance
Testing at scale.
A few other types of Performance Testing include:
 Endurance ("Soak") Testing
Can the application sustain a continuous expected load? During endurance tests, memory
utilization is monitored to detect potential leaks. Look for performance degradation.
Important: idle periods must be included.
 Spike Testing
This involves ‘spiking’ the number of users suddenly, to characterize an application's
handling of dramatic changes in load.
 Scalability Testing
This helps forecast the capability of the system to scale up or scale out. The goal is to
mitigate bottlenecks that can impede scalability of the application.
 Volume Testing

This form of testing uses realistically-sized data. Whether it's a database with 500,000
records stored, or the size of an input (or output), the goal is to assess the impact of
handling "realistic" data.
These types of test are not usually performed on smaller components, but rather on entire
applications or systems (comprised of multiple applications). Of these types of test, Rational
Performance Test Server is perhaps best positioned to perform Volume Testing, but all are
possible.
To summarize:
 Rational Performance Test Server can drive Performance Tests of components, and Virtual
Services can be used to support Performance Testing
 Note that you can tune Virtual Services for Performance Testing.5,6
 As with Functional Testing, run Performance Tests early and often
 Sub-GUI Stress Tests are most useful to developers, but formal testing environments may
also find them valuable for testing groups of related components
 Leverage existing Functional Tests to create Performance Tests
 Use Probes on target systems to collect performance-related resource metrics
 Use the Log Measurement Action to obtain additional information from servers
 Be aware that for a single test data set distributed among multiple Rational
Performance Test Server agents, each agent processes the entire test data set. In rare
cases where the input data must be unique for every request by each agent, this is
possible using a special technique (there is a TechNote7
describing one approach).
2.4.6.1 Customer story – how Virtual Services helped performance of functional tests
One customer runs IBM Security AppScan® to perform security vulnerability analysis and certify
a system’s compliance. The AppScan test runs for over 30 hours, and because of the nature of a
“vulnerability scan”, it does not run a “test script”. Instead, similar to how a web crawler works,
it is pointed at the home page and discovers (and Tests) all resources available via navigation.
The customer found that in a PoC, 100 requests to a specific live back-end service provider were
completed in roughly 110 seconds – almost two minutes. Those same 100 requests were
completed using a stub in 10 seconds (a reduction of 90.9%). The target duration for an
AppScan run at this customer is envisioned to be three hours when the work is complete (the
customer is adopting the product as this document is being published).
2.4.6.2 Note on Small-scale Performance Testing
When running small-scale Performance Tests, it is helpful to track the response times of
individual transactions. If a transaction response time exceeds tolerances the issue can be
5
“Disable Performance Optimizations” – See https://ibm.biz/BdXqsY
6
“Dedicated Engines” - See https://ibm.biz/BdXqsz
7
“Sharing Data Sets” - See http://www-01.ibm.com/support/docview.wss?uid=swg21649977

remedied quickly, as it is likely the developer is working directly with the component that is
exhibiting the failure. Note that these timings are not active during Functional Testing, only
during Performance Testing.
Figure 3 Timed Sections in Performance Tests

3 Rational Integration Tester
Rational Integration Tester separates learning about the SUT from building and executing Tests
and Virtual Services. Learning takes place in either the Architectural School perspective or the
Recording Studio perspective. [For an eloquent and interesting description of the philosophy
behind the Architecture School perspective, see Dennis Schultz’ blog entry8
. Note that Dennis
has several excellent blog entries on the same theme.]
3.1 Learning about the System Under Test (SUT)
Figure 4 (From RTW KC) Methods of creating assets9
Architecture School’s Logical View is used to build graphical models of the application(s) that
are part of the SUT, along with their dependent back-end interfaces/systems. This logical model
helps understand and validate relationships and dependencies among application components,
infrastructure components, and the communication interfaces that link them.
The logical model does not contain enough information to be directly testable; for example,
infrastructure components do not include physical characteristics. Instead, Project Environments
link infrastructure components to actual physical resources. By keeping all physical settings for
a single actual Test Environment in a single Rational Integration Tester Project Environment, it
is possible to switch quickly between those Test Environments (e.g., DEV, SIT, UAT) by
switching the current Project Environment. You can publish Virtual Services to your DEV and
SIT environments in one step, effectively providing Virtual Services for both test environments
at the same time.
Within a project, there are service components, which contain operations, and infrastructure
components, which can be inside or outside of any service component.
This logical model can be built via topology discovery, synchronization, recording (in Recording
Studio perspective), or manually.
3.1.1 Topology Discovery
3.1.2 Synchronization
Rational Integration Tester can synchronize with many different types of resources. The product
can perform large-scale synchronization with supported platforms such as:
8
Blog – See https://dennisschultz.wordpress.com/2013/11/24/the-rational-integration-tester-
model/
9
“Options for creating test resources” - See https://ibm.biz/BdXbcs

 WebSphere Application Server
 WebSphere Message Broker (now IBM Integration Bus)
 TIBCO (BusinessWorks or Design Time Library)
 Software AG webMethods Integration Server
 SAP PI
The product can also synchronize specific resources, such as these for web services:
 Remote web services that support “?WSDL” or “?wsdl” appended to web service
invocation URL (please see Appendix A and Appendix B starting on page 52)
 WebSphere Service Registry and Repository
 Local WSDL and XSD (XML Schema Definition) files
 Universal Description, Discovery and Integration (UDDI) Directories
3.1.3 Recording
The specific mechanisms used to record are heavily dependent on the transport, and to a lesser
extent, on the message format of the relevant interfaces. Let’s just talk about some interesting
aspects of recording, rather than going through an exhaustive list.
3.1.3.1 Recording Studio – the first thing you should do after recording…
…is to save that data! Rational Integration Tester can save a Recording Studio History (RSH)
file that includes some or all of the recorded events. You can save to a file or to Rational Test
Control Panel. If you save to a file, make sure that the file is stored under the project
directory. This enables anyone that opens the project to load those events, and thus they don’t
need live access to the systems involved at the time you made the recording.
 An RSH file is XML, as are all project assets; it contains XML that includes identifiers for
the logical and/or physical assets from the project. As such, an RSH file is only useful
with the same project. So don’t save an RSH file and expect someone who has a
different project to import it – it won’t work (even if they created exactly the same logical
and physical component, their IDs will be different).
3.1.3.2 MQ Recording
MQ recording is among the easiest – and yet the most sophisticated – of capabilities the product
brings to the table. Note that there is initial setup required; the MQ Exit must be installed in the
Queue Manager. You might create a WebSphere® MQ Queue Manager infrastructure
component in Logical View manually, or you might synchronize with WebSphere Application
Server. If you’ve manually added MQ, you might record the transport to create operations,
which you can then use to record. If you have synchronized with the application server, you
likely have operations already defined.
 There is tremendous benefit to use of the MQ exit for recording and playing back – the
MQ Exit is thousands of times faster than a human is, and eliminates the possibility of
human error. Two other very important benefits are that it’s not necessary to stop or
reconfigure the consumer or the live back-end system, and the Exit enables Sift & Pass-
Through (more on S&PT in a bit...)

There are six different ways to record MQ traffic:
 Queue browsing (applicable for all versions of WebSphere MQ)
 Proxy queues (applicable for all versions of WebSphere MQ)
 Mirror queues (WebSphere MQ 7.0 or later)
 Dynamic mirror queues (WebSphere MQ 7.0 or later)
 Queue aliasing (WebSphere MQ 7.0 or later)
 Record-The-Transport (WebSphere MQ 7.0 or later)
Of these, the most flexible and capable is Dynamic Mirror Queues, which should work in almost
any situation where you have the Rational Integration Tester MQ Exit installed on the target
queue manager.
Rather than duplicate information that is present in the KnowledgeCenter, let’s instead explore
the impact of using the MQ User Exit to record and playback traffic, especially using Dynamic
Mirror Queues.
Record the transport happens when you add an event monitor for the MQ infrastructure
component, instead of an operation that depends on that MQ transport. When you do this, all
queues on the queue manager will be recorded. This is most useful as a discovery mechanism, to
learn what traffic is passing through a given Queue Manager (e.g., during a test of a little-
understood application).
One customer had scheduled an impending sunset of a set of applications after a consolidation
project (a common IT initiative). When the product was installed and they performed discovery
via recording the transport, the customer was surprised to find that there was active application
traffic where they had been confident they’d found and migrated all such interfaces. Recording
the transport can be very valuable to learn exactly what’s happening within your environment!
 Record the transport without filtering is not recommended on a busy shared server.
For example, a customer has a Queue Manager with over 100,000 queues configured –
recording the transport there would likely result in a large CPU spike, potentially slowing
the overall throughput of the MQ Queue Manager, or even causing resource
exhaustion.
But note that even here, there is a safety net! You can wildcard the queues on the
Recording Studio tab of the Logical resource, i.e., if you know you want to record all
queues starting BIZ_* then you can do this and still record the transport without getting
messages from all 100,000 queues. The MQ exit will still ‘fire’ on each PUT but it won’t
do very much work for queues that do not match the filter.
If you suspect the queue manager is very large, very busy, or both, use wildcard queue
names.
Recording with Dynamic Mirror Queues: during recording, the MQ Exit places a copy of the
incoming message on another queue for Rational Integration Tester to pick up. Since the MQ
Exit also places a copy on the live request queue, there is roughly twice the amount of work
being done within the Queue Manager as when not recording – for each queue being recorded.
The same treatment is given to the response, once it is received.

Of course, recording even a dozen queues during a Functional Test should not substantially
increase the load on the QM server, but keep in mind performance characteristics. For example,
a dozen queues all being exercised by a stress test means the doubling of the work performed
may have a relatively larger impact on the MQ Queue Manager.
Playback with Dynamic Mirror Queues: the MQ Exit places a copy of the incoming message
on a separate queue for Rational Integration Tester to pick up, and if “Sift and Pass-Through” is
enabled, there’s a second message placed on a separate (“divert”) queue.
 If the stub handles the incoming message, it places the resulting reply message in a separate
queue, and the MQ Exit then puts it on the live reply queue; the message on the divert
queue is deleted
 If the stub does not handle the message, the request message is taken from the divert queue
and placed on the live queue for the live back-end to handle
The performance impact of running an MQ stub will usually be minimal, whether it responds or
the request is passed to the live back-end.
3.1.3.3 Sift and Pass-Through
Sift and Pass-Through (SPT) enables a Virtual Service to be able to release requests to the live
back-end service/interface. It’s applicable to some but not all VS technologies – for instance, it’s
not possible with JDBC (“Virtual DBs”).
If you use this capability with MQ messaging, you need to create something called a “namelist”
in the MQ Queue Manager. The namelist you need to create is rit.divert.rules. Details are
available in the KnowledgeCenter10
.
3.1.3.4 MQ recording wrap-up
To summarize, the sweet spot for MQ recording using the Exit is Dynamic Mirror Queues with
Sift & Pass-Through enabled. Figure 5 below shows the Physical Resource Stubbing settings for
an MQ Queue Manager, and Figure 6 shows the Recording settings tab.
Figure 5 MQ Queue Manager physical transport stubbing settings
10
“MQ diverted queue rules namelist” – See https://ibm.biz/BdXqsS

Figure 6 MQ Queue Manager physical transport recording settings
 One last note: Dynamic Mirror Queues support a single stub for an MQ queue. If you
would like to use multiple Virtual Services (i.e., to increase throughput), then consider
“Use Sift & Pass-Through with Fixed Queues”. More details are available in the
Knowledge Center11
.
3.1.4 Building a model by hand
Manually building logical models may be necessary where synchronization or recording is not
possible or there are no service components when synchronized.
Rational Integration Tester supports a number of different types of assets while building the
logical model, including Service Components, Infrastructure Components, Operations, Physical
Resources, and Dependencies.
As an example, in the Logical View of Architecture School, this set of steps might be used:
1. Create a new service component and within it, create associated operations and
infrastructure components
2. Define a Rational Integration Tester Project Environment, if not done already
3. For each infrastructure component, bind to a physical definition (e.g., using context
menu, choose “Set Binding In… > your environment >” then choose an existing physical
resource or choose ‘New…’ to create one)
4. Add dependencies between operations and infrastructure components or between two
operations
Note that some ‘manual’ activities are more like semi-automatic synchronization. For example,
if you have a WSDL contract for a web service, you can paste the URL (i.e., the Web Service
URL with ?wsdl as a suffix) into the Logical View and a Service Component, Operations,
Infrastructure Components, and Dependencies will all be created and associated for you by
Rational Integration Tester. The same is true if you synchronize with WSRR.
11
“Fixed mode (Sift & Pass-Through)” – See https://ibm.biz/BdXqsK

3.2 Building Tests, Virtual Services, and related assets
3.2.1 Test Asset Creation
There are a number of ways to create Tests. The most often-used method is to record events to
create your assets. Another option is to create Message Requirements (Messages in 8.7 and later
versions) and link them to your Tests. Message Requirements are discussed further below. MEPs
are yet another powerful way to generate many Tests from a contract for an interface.
In testing an application, you may often create similar Tests. You can copy and paste a test, or
copy and paste a message from one test to another, or even fragments of messages between
Tests.
3.2.1.1 Message Exchange Pattern (MEP)
Tests can be created using the Message Exchange Pattern of an operation. A Message Exchange
Pattern (MEP) describes the interaction type (i.e., Publish, Subscribe, Pub/Sub, or
Request/Reply) used by the operation’s transport.
In many cases, message contracts contain enumerations (lists of valid values). For example, the
schema may prescribe that a certain field can only contain “Male” or “Female”. If field A were
of type enumeration, with 20 valid values, creating 20 Tests would be time-consuming and
tedious. The product can automatically create multiple Tests from enumerations. Choosing the
‘Create Tests > ‘Using MEP...’ will start a wizard that will guide you through the process.
If you decide to use MEP to create your test assets, you usually want to select ‘Minimum
Number of Combinations’ to avoid generating a large number of redundant Tests.
3.2.2 Using Message Requirements
Recorded messages can be saved as Requirements in the Requirements Library. These messages
can be dragged and dropped onto message actions such as Publishers, Subscribers. This
minimizes the impact of schema changes in your Tests. It is a best practice to create
requirements, which can be linked to Tests to validate incoming messages or publish outgoing
ones. When linking requirements to Tests/Virtual Services, a change in the requirement will
propagate the changes automatically into your Tests/Virtual Services.
 Note that as of 8.7 Requirements are called Messages and there is no longer a
Requirements perspective. Instead, Messages appear in the Test Factory and Test Lab
perspectives under their corresponding parents in the tree view.
3.2.3 Recording vs manual creation - Trade-offs
If you record interactions, you will need to determine the key data in the request and response.
This can’t be overemphasized. But if you choose not to record the behavior of the system, then
you must also learn much more about the interface itself.
For example, if the Automated Test you run during recording already includes negative business
test cases, then recording those interactions will automatically provide an understanding of some
of the Negative Tests for the specific interface/system. If you manually construct Tests/Virtual
Services or build from MEP (see Section 3.2.1.1 on page 22), then you must either thoroughly
understand the business architecture of the SUT, or have the full participation of a development

lead or architect for the applications involved. If you do not, the Tests you create manually may
not provide full coverage – which is a risk most testing tries to minimize.
This is why the recommended method is to use recording as the basis of creating Tests and
Virtual Services. But this is not an absolute statement:
 If there are no sophisticated/mature Automated Tests to be run against the SUT, then
recording (obviously) won’t be of much help; some customers do only manual testing, for
example
 If code coverage is not a concern, but instead “happy path” Functional Testing is the goal,
then there should be no need to consider business or technical negative testing, and
recording may not be as important
3.2.4 Stateful Virtual Services
A stateful Virtual Service is one that needs to know something about its prior execution. For
example, tracking the list of GUIDs used in a test run, so message IDs in responses are never
repeated. Another example, seen at a customer, was a use case where a user self-registers, and
then attempts to do so again – the user should be given a business error message (“you are
already registered”). This can be a non-trivial problem, but fortunately, there is a capability in
Rational Integration Tester that serves this need quite well: the Data Model. When used with
Sessions, it is quite powerful. The KnowledgeCenter has a page that might be a good starting
point to explore this further12
.
3.2.5 Debugging what is happening in RIT
RIT has a “console window” – this is where JVM output appears. It can be found via Help ->
About and then choosing the button that opens the console. However, using these steps, the
window that opens is “modal”; it’s not possible to work in the RIT application until you close
this window.
However, it’s much easier if you open the JVM console window using the shortcut key Control-
Shift-J. Once you have it open, you can alt-tab or just click in the RIT window and continue
working there, without closing the console.
As an example of the usefulness of the console window, sometimes it’s a struggle to configure a
secure (TLS) connection to a back-end server. If you type Ctrl-Shift-J, right-click to clear the
console, then press ‘Test Connection’ in the physical resource for an infrastructure component in
the Logical View of Architecture School, the console will provide useful info. If you add
“-Djavax.net.debug=ssl” or “-Djavax.net.debug=all” to the RIT start-up arguments using Library
Manager (you’ll have to restart RIT), the console will contain a lot of information, hopefully
some of it useful.
Another situation where the console can be useful is when you are trying to configure recording
of JDBC calls on a database.
In general, most situations where Java might output messages (such as stack traces), the
information will be sent to the JVM Console.
12
“Data Model” and “Session” introduction – see https://ibm.biz/BdXqse

4 Rational Test Control Panel
Virtual Services designed in Rational Integration Tester are published to Rational Test Control
Panel, which holds them in a repository. From there, they can be deployed to one or more
Rational Integration Tester-Agents. Rational Test Control Panel also enables you to schedule
single or recurring execution of Test Suites, and assets like messages created in the Recording
Studio perspective.
 Published Virtual Services will be stored on the computer where Rational Test Control
Panel is installed, so long-term disk space requirements will depend on the size and number
of published Virtual Services
 Rational Test Control Panel contains state information about deployed Virtual Services;
use of Domains and Environments is critical to the ability to quickly understand the overall
status of your team’s Virtual Services
 Use of clear names and proper versioning of Virtual Services will make life easier for
everyone
4.1 Domains and Environments
A domain represents a logical grouping of related systems that are part of a real business project
and it is the basic unit of management within the product. A domain in Rational Test Control
Panel is a means of grouping and managing Tests, Virtual Services, and supporting assets (like
environments).
It is usual for a service or other endpoint to appear in more than one domain because it is reused
by different business projects in different contexts. Thus, different business groups within an
organization may also want to manage Virtual Services they consume independently from other
groups/domains.
A domain can contain one or more environments. Each project should be associated with a
domain, e.g. Billing or Customer Relationship Management, and will target environments
defined within that domain. Only the smallest of deployments should proceed without use of
domains for isolation of Tests, Virtual Services, etc.
4.1.1 Use of Scenarios
Before running Tests, you may require several Virtual Services to start in your environment. In
Rational Test Control Panel, selecting individual Virtual Services to start takes time, and could
induce race conditions where an application hits a mix of live back-ends and Virtual Services.
Scenarios can be used in Rational Test Control Panel to start all Virtual Services at
approximately the same time, but can also be used in Test Suites to start Virtual Services, and
then run Tests.
Creating a scenario is very easy – start the Virtual Services you want to have in the scenario in a
given Domain and Environment, then, in Rational Test Control Panel, click the create scenario
button. The scenario is then available in Rational Test Control Panel and in Rational Integration
Tester.
An alternative to scenarios can accomplish the same goal: using Ant to drive a test can start
many stubs in an automated fashion.

4.2 Publishing versions of a stub
During stub development and testing, you will require multiple versions of a stub. Note that this
section describes publishing, not execution of multiple versions of Virtual Services, which is
addressed below (in Section 5.2 on page 26).
 When deploying a stub, increment the stub version on the Publish Virtual Services
Window. A new version being published is denoted by the blue arrow
 Make it a required standard in your organization to always increment the version number in
a stub when publishing
It’s a best practice never to publish a stub at the same version. Rational Integration Tester 8.7,
the current release, attempts to provide assistance by detecting version number collisions.
Figure 7 Publishing Virtual Services - versions

5 Rational Test Virtualization Server
5.1 Roles of Rational Test Virtualization Server
Rational Test Virtualization Server is a run-time component that represents the deployment
environment for Virtual Services. It is capable of executing both Tests and Virtual Services, on
demand, or on a schedule, via any of these methods:
 The Rational Integration Tester GUI (which issues commands to Rational Test Control
Panel)
 Issuing RESTful commands to Rational Test Control Panel
 Command-line execution
 Ant build file
 HP Quality Center or Rational Quality Manager ‘plug-in’
Rational Test Virtualization Server has multiple modes of operation. In addition to running
Tests and Virtual Services, when running Performance Tests, the product functions as Rational
Performance Test Server. Probes are used to obtain system metrics during Performance Tests
for later analysis.
5.2 Running Multiple Versions of Virtual Services Concurrently
Just as with ‘live’ services, it is possible to run multiple versions of Virtual Services (at the same
time). The manner in which this can be done depends on the transport characteristics. This
section will discuss some noteworthy scenarios.
Note that it’s possible to change a DataSource name in an application, or change the host and/or
port for a web service, or the send/receive queue names for an MQ client application to point at
any one of several versions of a stub. However, that’s not desirable. It’s better to maintain
transparency, convenience, and productivity. This is not always possible, due to the properties of
the particular ‘transport’. The following sections discuss some important concepts.
5.2.1 Web Service Virtual Services
 A stub, any stub, must live within the same technology constraints as the live interface it
is simulating.
Making multiple versions of a web service stub available should not require changing the
consumer application. However, this depends on how customers choose to version their web
services. There are multiple ways of doing so, and those same methods can be used for their
virtual counterparts.
One approach is Message Versioning, i.e. version the message definitions (XSDs). This does not
enable a ‘message router’ (proxy or stub) to identify a web service except by checking the
versions of all the message definitions for a given web service request. It’s rather more complex
and it’s slower.
Contract versioning applies to the WSDL definition itself. There are several variations of this,
but a preferred method uses URI versioning – you should be happy if you already use this
approach. It means the Rational Test Control Panel HTTP proxy rules can be used to route to a

specific stub, rather than having the stub perform inspection of the request itself. This is the
highest-performing implementation choice.
For example, here is a web service that is available in two versions using URI-based contract
versioning:
 http://example.com:8080/ws/com/acme/shipping/1.0/TrackingService/
 http://example.com:8080/ws/com/acme/shipping/2.0/TrackingService/
The product suite readily supports URL-based versioning such as the above. This can replace
the old approach of changing host name and/or the port. This versioning approach makes it very
easy to deploy a web service stub for different versions of the live service, and run them
concurrently.
Note that the versioning mentioned here is not the stub version! Stub versioning is independent
of the version of the live back-end; you might develop a stub at version 2.1 for a v1.0 back-end,
and version 3.3 for a v1.1 back-end. Of course, it’s possible to try to match the major version of
a stub and its relevant live back-end service, but that’s a style choice, rather than a best practice.
Admittedly, that would make it easier for humans to correlate Virtual Services with live back-
ends, but it would probably be difficult to keep the two synchronized, as they change for
different reasons.
Where URL versioning is not used, extra work must be done in designing a stub. For example,
XML versioning in general is usually done in one of these ways:
 Namespaces
 Extension Elements
 Custom version attributes
These all require additional work in a stub to inspect the headers or body of a request. There is a
performance difference when routing happens in a stub rather than in proxy rule processing.
When UDDI is added in to this mix, the complexity rises, but it’s similar to XML versioning
approaches (e.g., tModel -> tModelInstanceInfo -> instanceDetails is extensible).
5.2.2 MQ Messaging-based Virtual Services
For MQ, the same queue pair obviously cannot be used for two versions of an MQ stub without
inspection of request contents. The versioning method is different from that used for web
services because the transport protocol is different.
A customer may choose to use different queue pairs for different versions of the back-end
service provider, perhaps for reasons other than using SV. In that case, the product can easily
work with the various versions of the live back-end.
However, if a customer wishes, it’s possible to use the same queue(s), and to inspect incoming
messages in a routing stub that then calls either the proper version of a stub, or the live back-end.
As with some kinds of web service versioning, this means extra work. In the case of MQ
carrying an XML payload, XML versioning techniques can be used, as described above for web
services.
And, just as with web services, if you decide to augment your request by including an additional
XML element intended to be processed by a Virtual Service, it does require a change to

consumer applications – but only ‘on demand’; you only need to make this change to
applications as and when they need to use virtual MQ interfaces.
Important: This is not a flag to express your intent to hit a Virtual Service (i.e., true/false), as
then transparency is lost (the consumer now ‘knows’ whether it is invoking a stub or not), but
instead should be something static like “SV_Enabled=1”. This is a holistic solution that ensures
smooth integration of the consumer, the live back-end, and the Virtual Service itself.
 Note that if you do this - add a ‘consumer application SV ID’ as a new element in a
request message, you are asking for trouble – imagine editing a stub every time a new
consumer ‘registers’ its willingness to use a stubbed interface.
If you do adopt this practice, perhaps for logging and future trend analysis), you could
avoid the higher maintenance by checking only for the presence of such a field.
5.2.3 JDBC/Database Virtual Services
For virtual DB Virtual Services, the transport is JDBC. The product hooks its java-based JDBC
proxy into the consuming application and makes decisions based on the JDBC URI and the user
ID. Thus, to have multiple versions, you could change the JDBC URI and/or the user ID.
This URI + user ID does not need to be valid in the real world. However, this can be tricky;
make sure that pair does not identify a real, live database (it would likely be an ugly coincidence
and might cause serious issues). This approach might be useful where, e.g., a DEV database will
take two weeks to be created, but you want to start developing immediately. The fastest way to
achieve this is to record from an existing DB interaction, then customize the virtual/stub DB to
reflect the request/response behavior needed by the new (version of the) SUT application that is
being developed.
 Where there is no real back-end database, the stub must always be running! Thus, this
technique may be most useful early in the development cycle.
It may be easiest to deploy different versions of database Virtual Services to different
environments – which is a nice way of saying a different JDBC URI. This approach has the
benefit that it maintains a relationship with a real, live physical resource. Thus, a JDBC stub
might be targeted at SIT, and also customized and deployed for use in DEV. Now, consumers
can point at any of the available Virtual databases that have been created for that consumer.

6 Developer’s Guide
This section is dedicated to those who are hands-on users of the tools. Consider the suggestions
documented here to be a good jumping-off point.
6.1 Project Environments revisited
For a given project or application team, their test environments are typically fixed. Create
Project Environments in Rational Integration Tester that map to real development or test
environments. Each Project Environment binds the logical infrastructure components in the
product to the deployment units found in the corresponding physical environment, including
actual physical specifications (IP addresses, ports, protocols, etc.). Figure 8 below shows an
example list of Project Environments.
The important point about Project Environments – and their containers, which are called
Domains – is that there should be a finite list. The list should be centrally managed – and should
not grow except as new groups participate in SV.
The Project Environment name is used in Rational Test Control Panel when publishing Virtual
Services; if the Project Environment does not exist under the Domain, it will be created.
 Do not let your team create ‘DEV1’ through ‘DEV99’, or SV development and test
leadership will have a hard time understanding what they are seeing in the Rational
Test Control Panel dashboard – and have an even harder time finding specific
resources in Rational Test Control Panel (like checking if a particular stub is running to
support a test this morning for a specific Test Environment…).
The exception is where you are intentionally creating a ‘virtual test lab’, in which, for
example, you are assembling a new ‘place’ to run Tests and Virtual Services, by pulling
some assets from a DEV environment and some others from a SIT environment. In this
case, you’re creating a “virtual test environment” with no corresponding physical
environment.
Figure 8 Project Environments

6.2 Default Project Structure
When a project is created for the first time, the following project folder structure is created on
disk:
Figure 9 Default project structure
The product supports creation of additional folders. Creating folders for assets gives you the
ability to break down a large project into smaller, more easily-understood chunks.
This is chiefly the case for Tests and test data; Virtual Services are often built to be multi-
environment (i.e., a stub can be published and deployed into DEV, SIT, and UAT as part of the
same publish/deploy task). This means using an environment in a stub name could lead to
deploying a ‘DEV’ stub into SIT – which can be confusing.
It is possible, of course, to have simpler Virtual
Services for development situations (like Unit Tests)
and more-complex Virtual Services for higher testing
environments, so using folders for Virtual Services
works well when there is a division among
environments and the Virtual Services that are
deployed differ among the environments.
When implementing Tests and Virtual Services in
Rational Integration Tester, supporting resources such
as schemas, WSDLs, Ant scripts, and executables (e.g.
psftp.exe for file transfers) are often needed by the
project. All these resources should be stored
somewhere under the project root directory; one approach to using folders is shown in Figure 10.
Note that common ECMAScript functions can be placed into “library files” and those could be
placed in a “Common Functions” folder, if desired.
6.3 Naming Conventions
The goal here is to enable quick recognition and understanding of context for assets within the
Test Factory or Test Lab. It is also a good way of being able to denote assets that vary only
slightly in functionality.
Figure 10 Suggested folder structure

The following notation will be used in this section:
 {…} indicates a mandatory parameter
 For example {Service}
 […] indicates an optional parameter
 For example [Component]
 | indicates that one of multiple parameters is applicable
 For example [Name | Surname] means that (optionally) either name or surname
could be provided
These types of testing have been identified in this document:
 Unit Testing (and limited integration)
 Integration Testing
 System Testing
 Performance Testing
 In the naming conventions below, ‘HC’ means ‘Hard-Coded’ and “SDS” means ‘Simple
Data Set’.
Note that customers or even specific projects may have different interpretations of the terms
Unit, Integration, and System testing.
 Unit Test Cases{ServiceName|OperationName}_{Pos|Neg}_UT_{HC|SDS}
 E.g., Enrich_Pos_U_HC
 Component Integration Test Cases
 {ProcessName}_{Pos|Neg}_{IT}_{HC|SDS}
 E.g., CheckEnrichProcess_Neg_IT_SDS
 System Test Cases
 {EndToEndBusinessProcessName}_{Pos|Neg}_ST_{HC|SDS}
 E.g., EnrichProcess_Pos_ST_SDS
 Performance Test Cases
 {ProcessName}_{Perf}
 E.g., EnrichProcess_Perf
 Project Name
 {ProjectName}
 E.g., CustomerManagement
 Service Component Name
 {ServiceComponentName}
 E.g., CustomerManagement

 Operation Name (e.g., when it’s not explicitly named in the request payload)
 {OperationName|Functionality}
 E.g., Enrich, Validate
 Test Data Name (common sense dictates the name match the test name)
 {TestName}_{sourceType}
 Remember, TestName is of the form {name}_{Pos|Neg}_{UT|IT|ST}_{HC|SDS})
 E.g., EnrichProcess_Pos_ST_SDS_Excel
 Test Suite Name
 {Functionality}_TS
 E.g., EnrichValidation_TS
 Scenario Name
 {ProcessName|SubProcessName}_S
 E.g., CheckEnrichProcess_S
 Test Template Name
 {TestName}_T
 Remember, TestName is of the form {name}_{Pos|Neg}_{UT|IT|ST}_{HC|SDS})
 E.g., EnrichProcess_Pos_ST_SDS_T
 Requirement Message Name
 {OperationName}_{Req|Res}_R
 E.g., Enrich_Req_R, Enrich_Res_R
 Trigger Name
 {OperationName}_TR
 E.g., Enrich_TR
 Stub Name
 {OperationName}_Stub_{HC|SDS}
 E.g., Enrich_Stub_SDS
Note: If you are not a fan of underscores, then using camel case works equally well, but the
longer the names become, TheLongerTheyAreTheHarderTheyBecomeToRead; acronyms also
don’t always look good in Camel Case, but you could instead adopt
CheckEnrichProcessNegItSds.
Inevitably, especially in early projects or PoCs or pilots, SV developers end up creating copies of
assets, to explore different approaches or methods. Appending a number such as “_07” should
make it clear that the very similar assets are all based on the same ‘parent’. The quick
numbering in suffixes is both easy to do and makes later clean-up much more simple/quick (you
don’t want all those half-developed assets around after you find the best solution, do you?). In
addition, the documentation tab, and the ‘business view’ both allow annotations to be made,
which means the names don’t need to be overloaded (used to provide detailed information).
Simple clear names should be used for most things.

One note that complements ‘naming’ standards nicely is that you can enable ‘business view’,
which will enable a capability that lets you nicely annotate things in Test Factory.
Figure 11 Business View (vs Technical View)
 There are SV practitioners who testify that they use business view 99% of the time, and
that it greatly increases readability of the resulting project.
6.4 Rational Integration Tester Perspectives
This section includes a few notes about some of the perspectives available in the product.
6.4.1 Architecture School
6.4.1.1 Environments Revisited
You will likely need to run your Tests in different environments (e.g. DEV, Sandbox, SIT, and
UAT). Changing the current environment should not require you to change test assets.
 It’s possible to define environment tags for information that is environment-specific, in
other words varies between the different environments where your Tests/Virtual Services
will run
 Operations reference transports; transport-related settings (user names, URLs, queue
names) could be placed into environment tags if desired
6.4.1.2 Schemas
 Copy any schemas used (XSDs, etc.) into a specific folder within the project folder, rather
than referencing them as files elsewhere on the local machine. It makes things easier to
debug should things go wrong. From the user's perspective, this also means that moving
the project is easier. Disregard this if the schemas are located by URL
 Be aware that referencing WSDL by URI will import the WSDL into the Schema Library,
but XSD’s referenced by that WSDL will not be imported (as of version 8.6.0.3). This
means anyone who opens the project in Rational Integration Tester must have the
same online access to the XSD schemaLocation (usually a URI) as the original
developer of the project). This may change in a future release (where the XSD files will
be populated on disk, somewhere under the project folder hierarchy).

 If using DFDL schemas, the schemas must be included somewhere in the project folder if
you want to use those schemas in a deployed stub or test.
6.4.2 Test Factory
6.4.2.1 Implementing Tests
Automated Tests can become large or complicated, making them more difficult to debug.
 Design and develop Tests to be as generic as possible
 Create smaller Functional Tests that can be called by parent Tests using the “Run Test”
action
 Use the “comment” action to describe complex/non-intuitive steps in a test
 Use the documentation tab of the test to describe the functionality of the test

Tests are always comprised of three basic activities: Initialize, Test Steps and Tear-down.
 The Initialize activity should be restricted to executing commands that start or configure
plugins, servers, or target resources
This activity may be used for other kinds of test preparation (for example, overriding
environment tags); note that if these tags are overwritten in the test, they will not be
restored to their original values.
 The Test Steps activity contains the actions performed during a test
If the test is repeatedly executed (e.g., as part of a Test Suite, or as part of a Performance
Test), the Test Steps activity is the only one that will be executed for each iteration.
 The Teardown activity is executed after Test Steps are complete (and is only executed in
the last test iteration when Test Steps are repeated).
6.4.2.2 Test Data
 When creating data in spreadsheets, add a column to your spreadsheet with the test
case/name/id (e.g., a defect number from a change management system)
 Remember, do not edit the ‘grouping’ column unless you really understand its intent and
usage – it’s needed by the product
 Remember that Lookup Test Data, Iterate Test Data, and Fetch Test Data actions will
automatically map tags to data columns that have the same names (it can make life much
easier if you consistently do this).
6.4.2.3 Creating Test Suites
Test suites are used mainly to construct reusable, packaged Regression Tests that can be run
across multiple environments, or repeatedly within the same environment.
 If you have dependencies on Virtual Services (to be running before running the Test Suite),
make sure they have been included in the References tab of the Scenario editor (see the
KnowledgeCenter for more details about Scenario References13
)
 Make sure the Test Suite is repeatable; if necessary, add Environment Tasks at the start of
the Test Suite, or Tests at the start or end, to clean up databases, (re)initialize components,
etc.
6.4.2.4 Running Tests and Test Suites
You may decide to run Tests individually or create a Test Suite and add your Tests in the suite
13
“Scenario Reference Settings” – See https://ibm.biz/BdXqsg

 Always check your environment settings before running a test or Test Suite
 Include Log actions in your Tests to write to the console or disk files – and you can, of
course, use tags for the file path
 Test suites have some advantages over individual Tests – for example, the results of Test
Suite execution are saved to the Results DB, while individual test results are not (unless
you are testing while in a Test Cycle)
If you prefer to run your Test Suite as part of a Continuous Integration (CI) Build Process, then
it’s possible to use Ant scripts to run your Tests:
 You can use the product to generate Ant scripts for each Test Suite you wish to run during
CI and save them in a folder within the project.
 In the Ant script, change the hardcoded values to Ant variables that can be substituted at
run-time. Place those variables in a .properties file – see the KnowledgeCenter for more
information14
.
 You can use a build server to pass in such a properties file to Ant automatically.
 Be aware that Ant consumes a license when running Tests; for this reason, one global CTP
always recommends a customer should have floating licenses for interactive users and
fixed licenses for any build servers.
6.4.2.5 Implementing Virtual Services
This is generic information about Virtual Services, not tied to any specific transport.
 Create data-driven Virtual Services where possible.
 Sift and pass-through – When testers want to access the live system, Virtual Services can
Pass Through non-matching traffic to the live system. This allows the Virtual Service to be
run in parallel with Tests against the live system.
6.4.2.6 Virtual Service performance
Performance depends on the proximity of the Virtual Services and SUT, which should be a
consideration during installation and deployment. Tests should get good response times from
Virtual Services and while it’s usually desirable to avoid timeouts, negative testing has never
been easier than using the tools and technologies in the product.
 In the Logging tab of the Virtual Service, set the logging level to “None” to minimize
interaction of the Virtual Service with the project database (this is now the default when
running from RTCP)
 Smaller, simpler Virtual Services are preferable to large complex Virtual Services
 Virtual Services with hundreds of ‘events’ require conditional tests that increase
response time, and, if one of the most-popular events is near the end of the list,
performance will be dramatically different than you might expect!
14
“Ant Tasks” – See https://ibm.biz/BdXqsJ

You can also tune Virtual Services for
 Capacity
 Parallelism
 Think time (whether to match production response times, use one of the available statistical
models available, or reduce to zero think-time for Performance Testing)
6.5 Version Control and Sharing projects
Projects can be shared using Software Configuration Management, sometimes called Source
Control Management (SCM)15
. As you start your journey using the product, it’s best to avoid
merge conflicts altogether - dedicate a project to a single SV developer at a time. Keep projects
small, simple, and dedicated to related activities. After you are comfortable with Rational
Integration Tester, and have some expertise regarding the mechanisms of the product, you can
take a more sophisticated approach to your concurrent development efforts.
Where projects become more complex, there are a few rules that can minimize the risk of
conflicts. Here are some thoughts on how to approach shared SV development in Rational
Integration Tester.
 SV Developers may edit the same project if they are only creating or modifying test/Virtual
Service assets
 Only one person at a time should be creating/deleting the all-important "shared resources"
(shared resources are mainly found in the Architecture School perspective, e.g., transports,
environments, logical components and operations, and physical assets)
 Once you have completed a round of changes, validate the project by re-running Test
Suites
 Make sure to include check-in details – build a culture that values comments about
changes, defect numbers, etc.
 As always, whether in Rational Integration Tester or in any other software development
tool, check in often
15
See “Integrating with source control management tools” at https://ibm.biz/BdXqxW

7 Thoughts on Project Methods
This section presents method-related guidance that should be complementary to any project
method.
 Though there are references to ‘phases’ in this material, there is no requirement for a
specific number of phases. The phases were chosen only to provide a structure to
distinguish the various activities and tasks. These activities can be incorporated in
whole or in part into any project method.
Agile project methods are particularly well-suited to use of this technology; remember
that these ‘phases’ will usually be days or weeks in duration.
At their simplest, these notes may reflect best practices around execution of tasks, but they may
also be useful in sharing a philosophy, one that encourages optimal use of this advanced
technology.
7.1 Summary of Phases
This is a brief introduction to the phases; in subsequent sections, we discuss each in more detail.
1. Discover
 Perform activities that aim to find pain points (in software development and/or testing)
where SV can help.
2. Configure
 The goal here is to try to figure out, ahead of time, what must be done in preparation for
active test/virtual service development. We want to prepare and plan for the work, while at
the same time being as efficient as possible (more on this in a bit).
3. Virtualize
 Execute automated test cases, record service behaviors.
 Create virtual services or tests using contracts (for non-existent or broken back-ends).
4. Model
 Modeling is making 'recordings' more flexible, to be able to respond to different requests
than those recorded; this can be simple or complex, and depends on many factors.
5. Deploy
 Running virtual services on one's desktop is not the best way to share or reuse, whether the
sharing takes place on the same team or with others outside the team.
 Operationalize virtual services and automated/scheduled tests. Ensure logging and results
reporting are in place and executing correctly.
6. Execute
 Use Virtual Services for test cases that depend on problematic "live system" counterparts,
measure and report on Tests and Virtual Services, and use SV to help realize Continuous
Testing as part of DevOps.

7.2 Phase 1 - Discovery
7.2.1 "System Under Test" (SUT) Revisited
The SUT could be a component, a module, a runtime library… an Enterprise Application
(EAR)… or an entire web site. It might be easiest for a SUT with any complexity to have a
System Context diagram, focused on the SUT and showing external interfaces, direction of
data/control flow(s), etc. Simple SUTs might use a spreadsheet that identifies type & direction
of each interface.
In order to virtualize an interface, there must be context –the SUT is an anchor, enabling
identification of those back-ends upon which the SUT directly depends. Thus, the focus is on
interfaces/services needed by the core functionality that the team will be constructing,
maintaining, testing, etc.; the goal is to identify upstream or downstream systems as separate
from the SUT.
Note that in later stages of development, such as System Integration or System Test, the SUT
expands; testing how an application functions with all its pieces developed and deployed means
not virtualizing services provided by one part of the SUT to another. However, earlier, in
development, it may be worth it, for example, to virtualize a web service call from one part of an
application to another part (where, for example, the service has not yet been developed &
promoted/deployed).
7.2.2 Identify relevant testing pain points
Some examples of pain points are:
 Back-end service does not exist yet
 Back-end service does not provide trustworthy responses (availability, dirty data, conflicts
between consumers, etc.)
 Back-end service does not scale (perhaps it’s already overcommitted or has too little
capacity, or any/all Performance Testing is problematic)
 The back-end is an external service that is not available 7x24 or for which a per-transaction
cost happens (even during testing)
It’s not good enough just to identify the SUT and all its back-end interfaces; it’s best to virtualize
those that have a reasonable justification for doing so. You do not want to virtualize interfaces
that are stable and robust --- a.k.a., “If it ain’t broke, don’t fix it”.
Note that if your organization is using advanced Collaborative Lifecycle Management (CLM)
technologies such as Rational Team Concert™, then you can and should take advantage by
creating a record of ‘pain points’ in the tooling. It will be an excellent enhancement to your
existing CLM tool usage model16
.
16
“Continuous Improvement Tracking” – (requires account login) See
https://jazz.net/wiki/bin/view/Main/ContinuousImprovementTracking

7.2.3 Prioritize testing pain points
Prioritize testing pain points based on criteria like risk, business criticality, or short-term/long-
term need for the Virtual Service. In addition to these typical models of risk, feasibility is
important in selecting back-end interfaces to virtualize; here are some considerations relevant to
SV:
 The more layers of processing (moving parts) there are behind an interface/service you
wish to virtualize, the more likely that the Virtual Service will need to change – whether
it’s the message format or the underlying data
 Understanding and characterizing data dependencies among back-end systems – especially
when only some of them are to be virtualized
 Understanding and characterizing data synchronization issues among back-end systems –
especially when only some of them are to be virtualized (note that this and the previous
bullet are closely related)
There is a recurring theme here: data stability is important. Some interfaces that see frequent
changes to the message formats (contracts) might require re-recording (or Virtual Service model
changes) too often to make them worth the effort of maintenance. Other (live) interfaces might
have side effects due to shared state; there is a point beyond which SV may become an
unacceptable burden for an SV developer or Center of Excellence (CoE, see Section 8.2 on page
51).
7.2.4 Defining use case and test cases
For all the identified pain points, it’s important to identify (or define) use cases that include the
best test cases to use. The most important thing here is to focus on the test cases, but the usual
way of finding those test cases is via the corresponding use cases. A “use case” is broader than a
test case, so elaborating the test cases for a use case usually identifies the best test cases that
target the specific back-end interfaces. This can be done well before the actual recording of
interfaces, and reduces risk when executing recording in a setting with multiple participants.
Two caveats here:
 You might need to add more back-end interfaces once you start recording, usually from an
incomplete understanding of the SUT; guard against this by documenting relevant use
cases and test cases even for back-end interfaces not yet in-scope for your SV activities
 It’s possible that you will remove some of the interfaces identified in this activity
(discussed in Section 7.2.6 on page 42), but the work you will have done will be useful in
the future, too
7.2.4.1 Importance of this activity
The reasons for most of the best practices in this document are intended to be clear. However,
the importance of use cases and test cases is one that may require a bit more detail. Here’s a
parable - a synthesis of multiple past customer experiences.
ZetaBank meets to attempt their first session using the product to record interactions for their
enterprise application “ZetaAndYou”, an HR application. All the players are in the room: a PM,
the ZetaAndYou lead developer, a senior QA leader, along with an SV architect and an SV
developer. All the SV prep work has been done already (install, configure intercept points,
smoke test recording, etc.). Now it’s time to put ZetaAndYou through its paces.

Note: Always try to use Automated Tests, no matter how they are executed – manual execution
of Tests too often results in different data being used over several iterations, or differences in the
steps being executed in different iterations, or both. The ZetaBank QA folks will run the
Automated Tests, of course.
ZetaBank wants to record the interaction between ZetaAndYou and its back-end
interfaces/services. In the session, they ask the QA folks which test cases to execute to cause
requests to all the relevant back-end service providers. The QA folks do not think about use
cases, they think about test cases – but test cases are driven into an SUT, not out of it. QA
cannot be expected to know happens in ZetaAndYou for any given test case. If the ZetaAndYou
lead developer knows the use cases, the test cases, and the architecture of ZetaAndYou, she
might be able to help identify the test cases. As it turns out, the lead developer knows some of
the test cases, but not all. The team is reduced to executing various Tests, and checking to see if
any data was recorded. This goes on for an hour or two, after which they decide to abort the
session and reconvene a few days later (when the ZetaAndYou Application Architect will be
back in town).
If they had identified the test cases ahead of the session, they would have completed their work.
Now, there is a bit of a blemish on the reputation of the SV team, because the perception will be
that it was hard to do, or that they were not prepared (though there’s an element of truth to the
latter).
7.2.5 Documenting dependencies between test cases
Identify test cases that depend on other test cases and/or test cases that “belong together” (in an
SV sense). Identify use/test cases that must be completed before others to minimize the number
of back-end interfaces to be virtualized.
Example 1: Your team’s shopping cart test scenario (composed of 15 test cases) involves
searching for products, selecting one, adding it to a shopping cart, showing the cart, changing
quantity, and finally making a purchase; there is a natural order and ‘add to shopping cart’ might
depend on the ‘selecting product’ use case (just as one example). “Depends” in this case might
mean that those two functions both depend on the same (non-existent) back-end Web Service; if
so, then several things can be inferred:
 It may be possible to test ‘add to shopping cart’ before completing the ‘search for product’
Web Service call, by creating a virtual service for the ‘search for product’ function;
 If the ‘select product’ test case has its “product catalog” and “inventory” back-end
interfaces virtualized, maybe the ‘add to shopping cart’ test case can utilize one or more of
the same Virtual Services (reuse is a good thing with virtual services);
 This could sometimes mean avoiding virtualizing one or more back-end calls; if, for
instance, a virtual service is created in front of a service broker, then the services called by
that broker might not need to be virtualized;
 It’s also likely that the Web Service operation called during ‘search for product’ will be
different from the operation that needs to retrieve specific product details; in this case,
creating virtual services for calls to both ‘show product details’ and ‘add to shopping cart’
back-end interfaces provides consistent responses (even if ‘live’ product details change), so
that testing can continue.

The above example shows how to approach dependency analysis during the Discovery phase.
Other kinds of dependencies can trip you up –one more scenario might help to highlight stateful
behavior.
Example 2: Suppose a test case where two “consumers” in the SUT use different interfaces to
the same ‘live’ back-end system and your testing will call on both of those interfaces. If you
only virtualize one of those interfaces, you might find that your test case fails when using Virtual
Services. This usually happens when you expect to get different results from one 'live'
interaction due to the state change brought about by the other interaction; such interfaces should
be virtualized together, or not at all.
Virtualizing in the more general case of two or more separate back-end systems that
cooperatively manage shared state works the same way. Do them together – or don’t virtualize
them at all.
7.2.6 Finalizing in-scope services to be virtualized in this iteration
Confirm / reach consensus on those test cases that will involve virtualization of back-end service
providers. For Agile methods, in-scope interfaces to be virtualized go on iteration backlog,
while out-of-scope interfaces might go on the product backlog, or are simply ignored/dropped (to
possibly be reconsidered later, i.e., if they would not provide enough value to virtualize “at this
time”).
Try to predict the full SV development and testing work required during the current iteration, and
do rough planning for subsequent iterations. Current iteration planning should also estimate the
size of the work.
If this is not done (or not done well), there will be a loss of velocity by failing to achieve goals,
and if a product backlog or other tracking mechanism is not kept for upcoming iterations, the
team might have to repeat some part of the current iteration analysis in a future iteration.
7.2.7 Reviewing existing Virtual Services for reuse
Do this to avoid redundant virtualization of services that are possibly very similar. There are two
cost considerations here – creating/harvesting and re-using:
 In the face of more redundancy (entropy) in the list of published Virtual Services, it
becomes harder to create reusable assets (Create a new Virtual Service, or replace an
existing Virtual Service? If so, replace which Virtual Service? There are so many!)
 It becomes increasingly difficult to know which Virtual Service is the best choice when
attempting to reuse
Discussion: There is a more basic consideration here: whether a Virtual Service should be
developer-centric, team-centric, project-centric, program-centric, or enterprise-wide. Given that
the unique identifying characteristic of a Virtual Service is the pair (Consumer, Provider), along
with the pair (Transport and Message Format), the easiest choice is to be very specific
(developer- or team-centric focus on sharing). The message format may be the most important
consideration – two Virtual Services may use the same message format (e.g., a specific WSDL)
but each may choose to filter on different data elements (one might key on first and last name,
while another performs a lookup based on an ID field). Note that there may be one more
dimension, as there may be multiple Test Cases, though these differences are only in data. We
discuss the use of sets of data in a business context in Section 2.2 on page 8.

Ibm rtw rtvs_implementation_guide_v4_0_2_public_release

Ibm rtw rtvs_implementation_guide_v4_0_2_public_release

Recommended

Recommended

More Related Content

Similar to Ibm rtw rtvs_implementation_guide_v4_0_2_public_release

Similar to Ibm rtw rtvs_implementation_guide_v4_0_2_public_release (20)

Recently uploaded

Recently uploaded (20)

Ibm rtw rtvs_implementation_guide_v4_0_2_public_release