Rit 8.5.0 platform training student's guide

IBM Rational Integration Tester
Platform Training Guide

Note
Before using this information and the product it supports, read the information in “Notices”
on page 55.

© Copyright IBM Corporation 2001, 2013.

IBM RATIONAL INTEGRATION TESTER PLATFORM TRAINING GUIDE

OVERVIEW .................................................................................................................................... 3
1

INTEGRATION TESTING AND VIRTUALIZATION .............................................................................. 4
1.1
1.2

2

WHAT IS INTEGRATION TESTING?........................................................................................ 4
SERVICE VIRTUALIZATION .................................................................................................. 5

PREPARATION ......................................................................................................................... 6
2.1
2.2

BEFORE STARTING ............................................................................................................ 7

2.3

THE LIBRARY MANAGER .................................................................................................... 8

2.4
3

RATIONAL INTEGRATION TESTER AND ASSOCIATED TOOLS .................................................... 6

HTTP PROXY ................................................................................................................... 9

RATIONAL INTEGRATION TESTER PROJECT SETUP .................................................................. 10
3.1
3.2

CREATING A NEW PROJECT .............................................................................................. 11

3.3

EXERCISE: CREATING THE TRAINING PROJECT ................................................................... 11

3.4

RATIONAL INTEGRATION TESTER LAYOUT .......................................................................... 16

3.5
4

THE INITIAL SCREEN ....................................................................................................... 10

RATIONAL INTEGRATION TESTER PERSPECTIVES ............................................................... 17

MODELING THE SYSTEM UNDER TEST ...................................................................................... 18
4.1

PERSPECTIVE OVERVIEW ................................................................................................. 18

4.2

WORKING IN MULTIPLE ENVIRONMENTS ............................................................................. 18

4.3

LOGICAL VIEW ................................................................................................................ 19

4.4

EXERCISE: SETTING UP THE LOGICAL VIEW FOR A SIMPLE SYSTEM ...................................... 21

4.5

PHYSICAL VIEW .............................................................................................................. 24

4.6

EXERCISE: SETTING UP PHYSICAL VIEW FOR A SIMPLE SYSTEM .......................................... 24

4.7

ENVIRONMENTS .............................................................................................................. 25

4.8

EXERCISE: CREATING AN ENVIRONMENT ........................................................................... 25

4.9

EXERCISE: SCHEMA LIBRARY ........................................................................................... 26

4.10
5

EXERCISE: THE MESSAGE EXCHANGE PATTERN (MEP) ................................................. 28

REQUIREMENTS LIBRARY ....................................................................................................... 30
5.1
5.2

THE MESSAGE EDITOR ..................................................................................................... 30

5.3

EXERCISE: IMPORTING MESSAGES .................................................................................... 31

5.4

EXERCISE: CREATING MESSAGES FROM A SCHEMA ............................................................ 32

5.5
6

OVERVIEW ..................................................................................................................... 30

ADVANCED EXERCISE ...................................................................................................... 34

RECORDING MESSAGES ......................................................................................................... 35
6.1

THE RECORDING STUDIO................................................................................................. 35

Page 1 of 56 © IBM Corporation 2001, 2013


6.2

RECORDING HTTP TRAFFIC............................................................................................. 37

6.3

EXERCISE: RECORDING HTTP TRAFFIC ............................................................................ 38

7

CREATING TESTS................................................................................................................... 41
7.1

TEST FACTORY ............................................................................................................... 41

7.2

TEST STRUCTURE ........................................................................................................... 42

7.3

BUSINESS VIEW AND TECHNICAL VIEW ............................................................................. 43

7.4

EXERCISE: CREATING A TEST FROM RECORDED MESSAGES ................................................ 43

7.5

THE MEP WIZARDS ......................................................................................................... 44

7.6

EXERCISE: CREATING A TEST FROM MEP ......................................................................... 44

8

TEST EXECUTION ................................................................................................................... 46
8.1

THE TEST LAB ................................................................................................................ 46

8.2

EXERCISE: RUNNING TESTS ............................................................................................. 47

9

TEST AUTOMATION ................................................................................................................ 49
9.1

TEST SUITES................................................................................................................... 49

9.2

EXERCISE: CREATING AND EXECUTING A TEST SUITE .......................................................... 49

9.3

RESULTS GALLERY ......................................................................................................... 51

9.4

EXERCISE: VIEWING RESULTS .......................................................................................... 53

10

LEGAL NOTICES................................................................................................................. 55



Overview

This document serves as a training manual to help familiarize the user with the functionality
present in IBM® Rational® Integration Tester. The training exercises in this document are based
around web services, and it is assumed that the reader has a fair understanding of these.

The main objective of this training course is to present the basic functionality of Rational
Integration Tester. In this course you will:









See how the different components used by Rational Integration Tester can work together
Create projects in Rational Integration Tester
See the various perspectives in Rational Integration Tester and how and when they are used
Observe how Rational Integration Tester can facilitate testing of services in a message
oriented middleware architecture by
o Providing a graphical interfaces for the display and creation of messages
o Automatically comparing a received response with a pre‐programmed one to ensure
they match
o Allowing the running of a test to be repeated over and over with little manual
intervention
o Exposing the details of the process to provide better information from the test team
to the development team, enabling test failures to be examined in detail
Create and run automated tests and test suites
Produce detailed reports on test suites

Before commencing this training course, please make sure you have all the correct files in place.



If you are using a cloud instance, the training files should be located on the desktop
Otherwise, your instructor will let you know where to find any required files.



1 Integration testing and virtualization
1.1 What is integration testing?
In many organizations, testing has traditionally taken two forms: unit testing carried out by
developers, and tests on a more complete system, carried out by a dedicated testing team. However,
as systems become more complex, technical risk increases, and testing techniques need to keep up.
Today, many business systems are not built on a single piece of software, but on a vast array of
components and services that need to interact with each other, and with external business
partners. Testing a single component in isolation does not ensure that it will work together as
specified with other components; unclear or changing requirements, assumptions by others and
complex interactions might cause problems later on. These issues and defects are more complex to
investigate and to fix when addressed later in the delivery cycle.
We can consider an example. If a consumer purchases something online, there are downstream
systems that will check and update their account, perform credit card checks, add shipping and
billing details and so on. Very little of this backend complexity is visible from the level of the GUI. If
the system is not functioning correctly, then the reasons might not be immediately apparent. A
useful metaphor here is to consider the GUI as the tip of the iceberg.

.



As with an iceberg, where you can only see the part that is above the water, testing the user
interface only allows you to see those parts of the system that are exposed to the user. If something
goes wrong within the parts of the system that are out of view, it is quite difficult to investigate and
understand where the problem lies: did one of your services provide the wrong response? Was the
database updated incorrectly? Have you made an incorrect assumption about the response of a
third party system?
With Rational Integration Tester, we can deal with these issues more easily, as it allows us to test at
levels between unit testing and end to end testing. First, we can perform component interface
testing. This can be very useful when you have a business process that does not yet have a user
interface, might not need a user interface, or might be exposed to third parties as a simple service.
Secondly, you can test multiple components as a group to ensure that they work together correctly.
However, the true benefit of this sort of testing is the ability to identify exactly where failures are
occurring. Integration tests driven by Rational Integration Tester provide the capability to watch
messages as they pass through the system, so that testers can see exactly where any issues lie.

1.2 Service virtualization
If you want to test out multiple parts of the system, you might encounter situations where some
part of the system is unavailable. Perhaps it is still under construction, being used by someone else,
or is only available within a production environment. In other situations, perhaps it does not
function in the way that you need it to for a particular test scenario; for example, checking that your
systems can handle erroneous data coming from third parties.
Waiting for components to become available in order to test could leave less time in the
development cycle to resolve any issues that might be uncovered. It is generally accepted that the
later a bug is found, the more expensive it is to fix, so waiting to test a particular scenario is not
ideal.
The solution is to virtualize the missing component or components, creating a stub to handle the
missing functionality that is required by a particular test scenario. Of course, this does not remove
the need to test the real version of that service when it does become available, but allows you to
test the rest of the system, working around the availability or unavailability of individual
components. Once you do introduce the real component, you will have significantly reduced the
risk of its integration into the system by preemptively testing against it using Rational Test
Virtualization Server.
Rational Integration Tester and its associated tools, including Rational Test Virtualization Server,
provide the capability to create virtual services that work with your tests, as well as virtualize
databases that can be used by the system under test. These stubs can then be shared with other
testers, and deployed as required during testing.



2 Preparation
2.1 Rational Integration Tester and associated tools
Before you start using Rational Integration Tester, you will look at how it will be set up, and how it
will interact with the system under test.
Depending on what you want to achieve, you might be using a number of tools. This module
describes the most common:







Rational Integration Tester
Rational Test Control Panel
Rational Test Virtualization Server
Rational Performance Test Server
Rational Integration Tester Platform Pack
Results Database

Rational Integration Tester is the main design and testing tool that you will be using during this
course. It is used to model the system under test, record information from the system under test,
create tests and stubs, run tests, and review results.
Rational Test Virtualization Server and Rational Performance Test Server are required for
executing performance tests and stubs. They can also be used to monitor the performance of
remote computers during testing, and run tests on remote computers.



The Rational Integration Tester Platform Pack includes a variety of tools to help with discovery of
the system under test, recording data from the system, and with stubbing different components of
the system. It provides different tools for different technologies; for example, it provides a proxy
that can be used when recording or stubbing messages passing over HTTP(S) or TCP.
The Rational Test Control Panel is a central command hub for these components. All instances of
Rational Test Virtualization Server, Rational Performance Test Server, and most Rational
Integration Tester Platform Pack components will report back to Rational Test Control Panel, and
receive commands from it. The Rational Test Control Panel can also hold a repository of stubs, and
be used to view historical test results through a web interface.
Finally, a results database should be set up for your projects. This can hold historical results of your
test suites, performance tests, and logs from any stubs that you have created.
Please note that unlike some other Rational tools, test resources are not stored in a database.
Rational Integration Tester and associated tools used in this training course keep all resources on
the file system. A version control system can also be used to hold historical versions of any
resources. Results are the only artifacts stored in the database.

2.2 Before starting
Assuming that you have installed the software above, you will need to do some configuration of
your system before you can get started. This has been done for you in the training environment, but
is outlined here so that you know what needs to be done should you want to do it yourself.







Library Manager
Results database setup
Rational Test Control Panel & Platform Pack / Servers
File Location / Version Control
Quality Management
Change Management

Of these, the Library Manager is mandatory, and will be covered separately in the following section.
A file location is also mandatory. A results database is mandatory if running performance tests, and
recommended otherwise. All other items might or might not be necessary, depending on what you
will be doing within your project.
The results database can be set up by creating a suitable schema in an IBM DB2®, MySQL, MS SQL
or Oracle database. This database holds historical results for your test suites, performance tests,
and stubs. Scripts are provided within the Rational Integration Tester installation to create all
tables and stored procedures required in the results database, and they can be passed on to your
local database administrator for examination before execution. Once it is set up, the database can
be shared across multiple users and multiple projects
If you will be running performance tests, using stubs, or interacting with different transports
through the Rational Integration Tester Platform Pack, you will need to install the appropriate
software, as outlined in the previous section. If you are only looking at performance testing, the
Rational Test Control Panel is optional, but helpful; for the platform pack or the Rational Test
Virtualization Server, it is mandatory. Each of these components should be given the URL for the



Rational Test Control Panel, so that they can poll it for instructions and report back as required. In
those scenarios, the Rational Test Control Panel URL will also be required when creating a project.
When creating test projects, you will need to choose where to store them. Each project will have its
own folder and subfolders on your hard disk, with each resource having its own file within those
folders. Version control can be used to track the history of each project, and is the preferred way of
sharing projects with others. Version control is handled through Eclipse Team Providers, which
provide support for different version control systems. Rational version control systems are
supported in this way, as are a number of open source and external version control systems.
Finally, you might want to interact with other developers or testers from your test tool. To do this,
you can choose to integrate with a quality management or change management tool. This is beyond
the scope of this training course, as each system functions differently. It is, however, a useful tool to
consider before commencing testing.

2.3 The Library Manager
The Library Manager is the main configuration tool for Rational Integration Tester. It provides the
means to enable connectivity to the wide variety of technologies supported by Rational Integration
Tester, and to set up other configuration options as required.
Rational Integration Tester supports a number of technologies out of the box: web services, email,
and a number of databases. However, connectivity to a number of other proprietary technologies
will require external Java™ libraries, which are normally supplied within the installation files of
that software.
If that software is installed on the same computer as Rational Integration Tester, then the Library
Manager can be used to point Rational Integration Tester towards the installed location of the
required libraries. Otherwise, those libraries can be copied across to the local computer, and the
Library Manager used to locate the local copies of those files. If you do not go through this
procedure, you will find that Rational Integration Tester will generate errors when you attempt to
connect using any technologies that have not been set up correctly.
Regardless of the technologies that you plan to test with Rational Integration Tester, you will need
to run the Library Manager once on any computer that has a copy of Rational Integration Tester.
Any changes made in the Library Manager will not take effect until the next time you start Rational
Integration Tester.
Note: If Rational Integration Tester is running while you make changes in the Library Manager,
then you will need to restart Rational Integration Tester.
All of the above also applies for Rational Test Virtualization Server and Rational Performance Test
Server. Each of these has its own Library Manager, which must be run before that server can
connect to anything that uses a technology configured within the Library Manager. The servers also
need to be restarted after any changes are made. This also applies even if the servers are running
on the same computer as Rational Integration Tester.



2.4 HTTP Proxy
During this training course, you will be using web services. For this reason, you will find it helpful
to have the Rational Integration Tester HTTP Proxy set up. This is part of the Rational Integration
Tester Platform Pack, and so it can be installed with that software. It can then be configured to run
as a service on your computer, and HTTP traffic from certain applications can be directed to run
through the proxy. Note that this configuration needs to be handled for each client application
separately.
The proxy will help you to record HTTP traffic during this course; it can also be used to aid in
virtualization scenarios. While there are other methods of capturing or stubbing HTTP services
available to you through Rational Integration Tester, the proxy is the easiest method. For this
reason, it has been installed and configured to run with the software in your training environment.



3 Rational Integration Tester Project Setup
3.1 The Initial Screen
Once configuration of the system is complete, you are ready to launch Rational Integration Tester
and create a new project. Launching Rational Integration Tester will bring up the following screen:

If you are running Rational Integration Tester on your local computer, you will need to make sure
you have a license at this stage; cloud instances should already have a license installed for you.
Once licensing is sorted out, you have several options. From top to bottom:


New Project: allows you to create a project.



Clone Project: creates a copy of any Rational Integration Tester project.



Fetch Project from Source Control: Check out a project from a source control system, and
open it. Note that you will need to configure Rational Integration Tester to communicate
with your source control system before doing this.



Open Link: follows a link taken from the Test Lab perspective to navigate to the results of a
test or test suite.





Open an existing project: opens an existing project, either from the list of recent projects
shown by Rational Integration Tester, or by browsing to a .ghp file.

3.2 Creating a new project
Creating a new project goes through four stages. These are:
1. Setting the project name and location
2. Connecting to external servers
3. Setting up user‐based permissions
4. Setting up change management integration
Only the first step is compulsory; the others are optional, with the settings available to edit later
from within the project. If you need to edit any of these settings after the project has been created,
you can do it through the Project Settings window (found in the Project menu of Rational
Integration Tester).
That said, filling out the server settings listed in the second stage of the project creation process
will normally be very useful, and you will be doing that for the examples used in this course.
The first of these settings is for the results database, which provides the ability to record and view
historical test results. The other server settings available are for Rational Test Control Panel and
the Results Server (legacy users only). Rational Test Control Panel provides the ability to manage
any proxies and agents used by the software; these capabilities can be used while recording and
stubbing. The Results Server setting is used to create links to the reports held on the server, which
should also be connected to your results database; this functionality is now provided by Rational
Test Control Panel, so the Results Server is no longer required, and will not be used in this course.
There is only a single user in your example project, so you do not need to configure user‐based
permissions for the project. It is more useful in other projects where it is necessary to restrict
access to a project to certain individuals, or to allow different access levels to the project for
different users.
Finally, you can configure a connection to change management tools such as JIRA, HP Quality
Center, or any Open Services for Lifecycle Collaboration (OSLC) compliant change management
system, such as IBM Rational Team Concert™. This allows you to link directly into these tools, and
raise defects directly from a test or test suite. As this is a simple introductory project, you do not
need to be concerned with this for now.
At the end of the wizard, a new project folder will be created within your file system. This folder
will hold all resources, including a model of the system under test, along with any tests, stubs or
other resources created for the project. Data files used by your project can also be stored here; this
can help you make your project more portable by including everything in one place.

3.3 Exercise: Creating the training project
You will now create a brand new project, which you will continue to use for the duration of this
course:



1. Launch Rational Integration Tester by double‐clicking the IBM Rational Integration Tester
shortcut on your desktop.
2. Rational Integration Tester will launch, displaying the initial screen. Create a new project by
selecting New Project and clicking OK.

3. We can now give our project a name, using the Project Name field. Call your project
AddNumbers.



4. If desired, modify the Owner and Comments fields (these are saved with the project and
can be modified later).
5. In the Directory field, enter the full path to the directory where the project should be
created, or click Browse to locate the directory. The selected directory cannot contain an
existing Rational Integration Tester project.
6. When you are satisfied with the project details, click Next. If the selected directory does not
exist, you will be prompted to let Rational Integration Tester create it, or you can go back
and select a different directory.
7. The wizard will now display the Server Settings window. At the top of this window, there is
a Results Database section, where we can provide connection details for the results
database, which is used to store all of the test data collected by Rational Integration Tester.
A valid database and working connection are required to store or view any historical results
in Rational Integration Tester.
8. Rational Integration Tester will remember the database details that were used previously; if
you are using a cloud instance, this means that you should already have details entered for
you. Otherwise, you will need to enter details into the Database URL, User Name, and
Password fields. If you need to re‐enter them, the settings for the databases on the cloud
instances are shown below. Otherwise, ask your trainer.



Settings

Value

Database URL

jdbc:db2://localhost:50000/resultdb

User Name

db2inst1

Password

Gr33nhat

9. Click Test Connection. A window should open stating that the connection was successful.
10. Below the database settings, we can connect to the Results Server and Rational Test Control
Panel. We will not be using the Results Server, but Rational Test Control Panel will be
needed later on. Use the following settings to connect:

Settings

Value

RTCP URL

http://localhost:7819/RTCP

Domain

Default



11. When you are satisfied with the details entered on this screen, click Finish. If user‐based
permissions or connections to change management tools were required, you would need to
choose Next, and then set them up on the following screens.
12. The new project will be opened in Rational Integration Tester. By default, it will display the
Logical View in the Architecture School perspective.



3.4 Rational Integration Tester layout

The main window of Rational Integration Tester is a workbench that contains several dockable
windows. These windows are organized in a logical way, providing an intuitive, easy‐to‐use central
workspace.
Information about your current project can be found in the title bar and status bar. At the top of the
screen, the title bar indicates the name of the current project, along with the current environment.
At the bottom of the screen, the status bar indicates the name of the current test cycle, the current
user, and the memory usage. For the purposes of this manual, you will not need to be concerned
with the information in the status bar, though you might find it useful to keep an eye on the title bar
to check which environment is currently active.



3.5 Rational Integration Tester perspectives
In the center of the screen is the main workbench of Rational Integration Tester, showing the
current perspective view. The workbench can be viewed from one of six perspectives
, selected from the Perspectives toolbar:
Perspective

Icon

Description
Defines the architecture of the system under test, including
service components as well as logical and physical resources

Architecture School

Creates requirements that will help other users to create
tests and test data more quickly and more accurately

Requirements Library

Monitors systems and processes to record events that are
captured by Rational Integration Tester

Recording Studio

Test Factory

Creation of tests, test suites, stubs and test data sets

Test Lab

Runs resources that are created in the Test Factory

Results Gallery

Contains historical test data and lets users view various
reports for any stored test run, including performance,
errors, and coverage data

The initial layout of the workbench for each perspective is pre‐determined, and it can be restored at
any time by selecting Window > Reset Current Perspective from the main menu. Many aspects of
the workspace can be customized. Each window can be resized within the workbench by clicking
and dragging on its borders; it can be closed by using the button in the top right corner and can
be set to automatically hide when not in use with or to remain constantly visible with .
Note: If you ever find that a panel within the current perspective is no longer visible (for example, if
it has been closed), then the Reset Current Perspective command will also bring that panel back
into view.



4 Modeling the system under test
4.1 Perspective overview
The Architecture School perspective is the default perspective loaded when Rational Integration
Tester is started. This perspective is used for modeling the system in a simple, graphical fashion.
This model is split into several parts. As the model is split into several parts, the Architecture
School perspective is also split into several different views. In addition to these views, we also use
an environment to bind different parts of the model together.
The views are presented along the bottom of the perspective:


Logical View



Physical View



Synchronisation



Schema Library



Data Models



Rule Cache



Environment Tasks

For the moment, we are going to look at an example of a simple system, which will make use of the
first two views, along with environments, which are used to tie the Logical and Physical views
together. We will then move to the Schema Library to set up message formats.

4.2 Working in multiple environments
As we move through the lifecycle of a project, testing might be carried out over multiple
environments. For example, we might have a development environment, using development data,
and its own infrastructure. As we move into a formal test phase, we might start to use different
infrastructure components, or different data. Finally, in production, a completely new set of
infrastructure components will be used, and real‐world data will be in use.

This is only a simple example, but it serves to illustrate the problem: if we are not careful, we could
create tests or stubs that will need to be rebuilt as we move from environment to environment, or
even worse, resources that are not portable at all. Fortunately, Rational Integration Tester provides
a solution to this, by partitioning the model of the system under test. In order to move our



resources across different environments, we will set up the infrastructure of our system in three
sections: Logical View, Physical View, and the Environment.
The Logical View provides us with an abstract view of the system under test, but does not tie us to
using any particular infrastructure. As an example, it will state that a database is required by our
system, but it will not state any more than that; the database URL, connection details, and even the
type of database provider are not specified at this stage.
The Physical View then defines all of the implementation options; so, for our example, we might
have three separate databases used across all different environments. All three databases would be
listed in the Physical View.
Finally, the Environment binds the logical and physical resources together. At any stage, Rational
Integration Tester can check which environment is being used, and if a reference is found to a
logical infrastructure element, it will use the environment to find the correct physical component.
So, to finish off our example, if we need to access a database within a test or a stub, Rational
Integration Tester will look up the environment to determine which of the three databases should
be accessed. If we then move to another environment, Rational Integration Tester will perform the
lookup again, and select the appropriate database.
Of course, this applies to any infrastructure; not just databases, but also web servers, Java Message
Service (JMS), or any proprietary technologies.

4.3 Logical View
The Logical View provides an abstract model of the system that we are interacting with. We are
going to build a simple model here to demonstrate how this works. This model will be made up of
several different elements:

The first object we will need to create is a Service Component. Service Components act as containers
for all other elements within the Logical View, and can contain other Service Components to build
up more complex structures.

In most cases, we will want to define Operations within a Service Component. Operations define the
functionality of the system. We will be able to create resources based upon the information
provided within each operation.



In order to communicate with the operations available within the system, we will also need a set of
Infrastructure Components. These are named components that can be bound to physical resources.
Remembering that Logical View does not contain any concrete details of these components, they
will serve to tell us that there is a JMS server, database, web server, or another piece of
infrastructure, while the Physical View and Environment will provide more exact information later
on.
All of these elements (service components, operations, and infrastructure components) can be
created by pressing Ctrl+N to create a new component, right‐clicking and using the context menu,
or from the toolbar at the top of the Logical View. In addition, you can use Ctrl+F to find resources
after they have been created.

Finally, we will use Dependencies to link operations to each other, or to infrastructure components.
Outgoing dependencies are displayed in lavender, and incoming dependencies are displayed in
green. Dependencies are only displayed for items in the diagram that are selected. In the example
diagram above, this lets us know the following information:


Operation1 has a dependency on Operation2, meaning that Operation1 might call upon
Operation2 (though it might not do so in all circumstances).



Operation2 has a dependency on the HTTP Connection. This will normally mean that either

we require this HTTP connection to act as the transport for the operation, or that the
operation might need to make use of the HTTP connection itself after it has received a
message.

To create a dependency, we can either draw it using the Add a Dependency button in the
toolbar, or if we are setting up an infrastructure component as the transport, we can do this by
opening up the operation’s properties by double‐clicking on it, and editing the transport
information within the Message Exchange Pattern tab of the properties window that opens.



The toolbar contains a number of other useful tools, on the right:

Add an External Resource: creates a new External Resource, or Synchronization Source,
within the Logical View, and optionally synchronizes with it. We will discuss
synchronization in detail later on.

Add a Dependency: allows you to draw a dependency between two operations, or from
an operation to an infrastructure component.

Edit Filters: filters determine which dependencies will be shown in the Logical View.
They might be necessary in larger, more complex systems.

Selection mode: puts the cursor into selection mode, where you can select and edit
elements of the model. This is the default cursor mode.

Zoom in: zooms into the diagram. This can also be done with Ctrl+MouseWheelUp.
Zoom out: zooms out of the diagram. This can also be done with Ctrl+MouseWheelDown.
Zoom area: zooms to fit an area, drawn with the mouse, onto the screen.
Reset Zoom: sets the zoom back to the default level.
Fit to contents: zooms the screen to fit everything contained in the Logical View.
Pan mode: uses the cursor to pan around the screen.
Layout all nodes: automatically rearranges all elements contained in the Logical View, so
that nothing is obscured.
Grid: switches the grid on or off. The default setting is off.

We will now use the elements described above to start building a model of an example system. This
system will contain a single web service. We can use this same process to build a model of any
service oriented architecture. Later on, we will look at more efficient methods to build the model,
though as these are not available in all environments, we will look at building everything by hand
for this first example.

4.4 Exercise: Setting up the Logical View for a simple system
The first part of modeling the system under test is to build an abstract model in the Logical View. In
this exercise, you will begin to put together a model of a simple web service, which you will add to
in the following exercises.



1. Before starting, we will need to make sure that the web service we are modeling is active.
From the desktop, launch the AddNumbersServer. You should see the following window
open:

2. Click the Start Service button. The Add Numbers Server window should update so that the
Start Service button is disabled, and the Stop Service button is enabled:

3. Minimize this window (do not close it), and return to Rational Integration Tester.
4. From the Architecture School perspective, make sure that you are in Logical View using the
tab at the bottom of the screen.
5. The middle of the screen will be blank, because there is currently nothing in our model. To
add the first component of a system, right‐click and select New > General > Service
Component. When asked for a name, call it AddNumbers. It should then be added to your
workspace:

6. Select AddNumbers by clicking on it. The outline should change to orange, to indicate that it is
selected.
7. Right‐click the AddNumbers component, and select New > General > Operation. Call the
operation Addition. Your service component should now look like the following image:



8. Similarly, add an infrastructure component called AddNumbersPort, by right‐clicking and
selecting New > Web > HTTP Connection
9. The logical description of our basic system is nearly complete. We just need to define the
transport information for the Addition operation by tying it to AddNumbersPort. Double‐
click the Addition operation, and take a look at the Message Exchange Pattern tab.
10. Look for the Transport property, and click the Browse… button next to it to select a
transport.
11. In the window that opens, select AddNumbersPort. Click OK to return to the properties of the
Addition operation.
12. The Binding section of the window will now have been updated to point towards
AddNumbersPort. A set of HTTP settings will also be available now that we have specified a
HTTP transport. We will come back to these settings later. For now, click OK to close the
properties window.
13. You should now be able to see the dependency between the operation and the infrastructure
component. Select the Addition operation by clicking on it, and you should see a purple
arrow going from the operation to AddNumbersPort. This indicates that the Addition
operation is dependent on AddNumbersPort.

14. Try navigating around the logical view using the following controls:
o To navigate around the logical view you can use the horizontal and vertical
scrollbars, or you can click the Pan button and left‐click the screen to drag it
around.
o To adjust the zoom level you can use either the zoom buttons
Ctrl key and use the mouse wheel.

or hold down the



o To move any of the services or components around, ensure the Select Cursor button
is selected, and left click the service or component you want to move, and drag it
to the desired location.
o If you ever want to reset the layout of the services and components, then the Layout
All Nodes button will organize them into an efficient layout.
o To set the zoom level so that the entire diagram fits inside the screen, use the Fit to
Contents button .

4.5 Physical View
On its own, the logical view that we have created is not enough to fully describe our system. As
mentioned previously, it does not contain information about the address of the server we are
talking to, or any connection settings that might be required. We are going to specify this
information separately, in the Physical View.
This view displays available physical resources and their location within the enterprise. Each
resource listed within the Physical View represents a single configuration of an infrastructure
component described in the Logical View.
Resources in this view are organized by subnet and host. If a resource is not associated with a
subnet or host, it will be displayed under Unconnected Resources. We are going to create the
physical resource for the AddNumbers web service: a simple web server.

4.6 Exercise: Setting up Physical View for a simple system
1. Switch to Physical View using the


2. We are going to add a new resource here. Along the top of the perspective, you will see a
toolbar containing options for adding new resources from different categories

3. Choose the Web category, and then choose the Web Server

option .

4. The New Web Server window will open. Set the Host setting to localhost using the Port
setting of 8088.

5. Click the Test Transport button to make sure that you are able to connect properly to the
web service (you might need to scroll down to see the button). Once you are satisfied that it
is working properly, click OK to close the window and save the new resource.



4.7 Environments
Once we have the logical data, which gives us an abstract model of what infrastructure is required
by our system, and the physical data, which specifies the different configurations available for each
infrastructure component, we then need to match these up. Remembering that this could change
between different stages of the lifecycle of the project, we can use a set of environments to
coordinate this process.
A new project starts without an environment, so we will create an initial environment in this
exercise. Other environments could be created subsequently as required. These will allow us to
keep using the same test resources, simply by switching to new environments as they become
available.
Environments do not have their own view; instead, there are a number of options in the Project
menu which allow us to access and edit an environment: Create New Environment , Edit
Environments , and Switch to Environment . If you are using the default settings within
Rational Integration Tester, the title bar will also show the name of the current environment.

4.8 Exercise: Creating an environment
Following the previous exercises, your model of the AddNumbers web service has data in the
Logical View and the Physical View. In this exercise, you will bind the data in these two views using
an environment.
1. Select Project > Create New Environment
2. Give the environment a name; for example, Local (most of the environment we are working
with in this training course will be on the local host).

3. The Environments window opens. On the left, you can select the environment to edit. On
the right, you can see how this environment is configured.
4. On the right, you should be looking at the Properties tab, which will be empty at the
moment. The properties of an environment are expressed as tags, which will be covered
later in the course. For the moment, we are not going to need to set up any properties
ourselves.
5. Switch to the Bindings tab. You should see AddNumbersPort listed here. Note that the
physical connection for it is currently listed as UNBOUND.



6. Click the UNBOUND setting, and a drop down box should become active, containing the option
to bind AddNumbersPort to the HTTP Client at localhost. Select the new physical resource
to tell Rational Integration Tester that any messages sent to AddNumbersPort will be sent to
localhost.

7. Click OK to save your changes and exit the window. You should see that the environment
name is now displayed in the title bar.

Once an environment has been created, we can also view and edit environmental data directly from
the Logical View. To do this, you can right‐click an infrastructure component in Logical View, and
then select either Physical Resource, which will show the related physical resource in the current
environment, or select Set Binding In, which will allow you to set the binding in any environment.
This information can also be seen by opening the infrastructure component by double‐clicking it,
and going to the Bindings tab.

4.9 Exercise: Schema Library
We now have most of the information we would need to create a test or stub for this sample web
service. However, we are still missing information about the format of the messages going to and
from the web service. Most of this information can be provided through the Schema Library.
1. Switch to the Schema Library using the


2. At the top of the perspective, there is a toolbar containing buttons for importing different
types of message schemas.
The New WSDL window will open.

Click the WSDL

button.



3. Click Change to enter the location of our schema definition. The Select Location dialog box
will open.
4. Select the URL tab, and enter the following URL:
http://localhost:8088/addNumbers?wsdl Note that the URL is case‐sensitive. Click OK
to close the Select Location dialog box, and again to close the New WSDL dialog box.
5. You can also view the schema information used by the addNumbers service by going to the
same URL with your web browser.
6. Once the schemas have been imported, you can then view them in Rational Integration
Tester. Select WSDLs on the far left of the screen. You will then be able to see the
addNumbers WSDL displayed on the left. Select this WSDL; the details of the schema should
then be shown on the right. The Source tab will display the text of the original WSDL, as you
saw in your web browser.

Note: If you have mistyped the name of the WSDL, you should receive a warning, and the
right side of the screen will not show the message schemas. If you end up in this situation,
you can fix it in the following manner:



Amend the location of the WSDL by using the Change button next to the WSDL Location at
the top of the screen. Following that, click the Rebuild button to rebuild the schema data.
To complete the process, you might need to select one of the folders above the WSDL in the
center panel, and then select the WSDL again.
7. Go to the Config tab to view each individual message type. You can select each message type
using the Operation drop‐down list just under the tabs along the top of the screen. Use this
to view the three message types: addition__INPUT__addition,
addition__OUTPUT__additionResponse, and addition__FAULT__AdditionException.

4.10 Exercise: The Message Exchange Pattern (MEP)
The final stage of building our system model is to state how the operations will make use of the
message schemas that have been provided. We will do this by building up the Message Exchange
Pattern, or MEP, for each operation. The MEP contains information about the input and output
schemas for the operation, whether the messaging pattern is Request/Reply or Publish/Subscribe,
and how the messages will be sent. When you created a dependency, you set up the transport used
by the operation, stating how messages will be sent to and from the service. To complete the model
of the system under test, we still need to set the rest of the properties of the MEP.
As we will see later on, setting up the MEP correctly now will allow Rational Integration Tester to
aid us in automatically creating resources for each operation.
1. Return to the Logical View.
2. Double‐click the Addition operation to edit it.
3. On the Message Exchange Pattern tab, make sure that the Pattern is set to
Request/Reply.
4. We now need to select the message formats for the request and the reply. On the Request
line, click the Browse button to select a message format.
5. The Select Schema dialog box will open. It is formatted in much the same way as the
Schema Library. Find and select the addition__INPUT__addition schema, and then click
Finish.
6. Do the same for the Reply message, selecting the addition__OUTPUT__additionResponse
schema.
7. You will also see tabs towards the bottom of the screen for HTTP Properties and HTTP
Headers. Under the HTTP Properties tab, set the Resource Name to /addNumbers . This
will be used to build the correct URL when communicating with the web service. In your
case, it will be http://localhost:8088/addNumbers , where the host and port are taken
from the physical resource, and the rest of the URL comes from this resource name setting.



8. Click OK to close the Addition operation.
We now have all the information we might need to work with a very simple web service.



5 Requirements Library
5.1 Overview
In the Requirements Library perspective, the user defines the requirements for an interface in the
form of messages. Example messages can be created from scratch or captured and saved from
Recording Studio. There are several advantages of having these message requirements:


They facilitate the creation of tests by dragging and dropping these messages onto a
messaging action within a test.



They help keep tests consistent across multiple users, as each user can share this repository
of defined message structures for various components under test. In essence, they are acting
as a message catalogue.



They provide examples of how the data should appear when working with a given interface.

5.2 The message editor
Within the Requirements Library, you will also come across the message editor for the first time.
You will later see the same editor being used to work with messages in other perspectives within
Rational Integration Tester. The Message Editor formats all message types supported by Rational
Integration Tester into a tree structure. It will also export messages from that same tree structure
into the appropriate format when sending that message over a transport.

Depending on the context, the message editor will have a number of tabs. We will look at these in
more detail as we come to use them, but you will see the following tabs when using the message
editor:





Config: Provides main configuration information, including information about the transport.
Also shows an overview of how the message body will be handled. This might be configured,
but by default, this overview reflects the content of the Value/Asset tab.



Value/Assert: Provides values to send for each field, or expected values for those fields if
receiving a message.



Filter: Allows the user to filter messages based on their contents



Store: Saves data for later use

Note that the body of the message will be visible in all tabs, but the Config tab only contains a short
summary of some of the details contained in the message header. All other tabs contain more
details of any message headers.

5.3 Exercise: Importing messages
As a first example of using the Requirements Library, you will now import an existing XML
document into Rational Integration Tester. You will then see how it is represented within the
message editor.
1. As an example, we are going to use the simple example provided in the Data Files folder on
your desktop: additionInput.xml. Open this file in a text editor to take a look at it. You will
see a simple XML message. Do not open the file in your web browser, as it will reformat the
message by inserting extra characters.
2. Select the XML text, and copy it using Ctrl + C.
3. Switch back to Rational Integration Tester, and make sure you are in the Requirements
Library perspective. Remember that you can select this with the Requirements Library
button from the Perspectives Toolbar, or by pressing F8.
4. On the left, you will see a tree structure describing all of the logical elements we saw earlier
in the Architecture School. The tree structure will map directly to the structure of the
different components in the Logical View. Find the Addition operation in the tree, then
right‐click it, and choose New > Message. Call it example_from_file.

5. The right side will now be partly populated. You should see a simple tree structure for your
new message, with a Text (Message) above a text (String). Right‐click the text
(String), and choose to paste the XML data we copied earlier. You should end up with a
message that looks like the following:



6. If an error occurs, go back to the XML document in your text editor, and make sure that you
have copied all of the XML content before attempting to paste it into Rational Integration
Tester again.
7. Compare the original XML document with the tree structure generated in Rational
Integration Tester, and then click Save.

5.4 Exercise: Creating messages from a schema
While we can import messages by copying and pasting, there will also be times when we want to
work by entering values into the structure provided by the message schema.
1. Right‐click the Addition operation in the tree on the left, and choose New > Message to
create a second message. Call it example_from_schema.
2. You should see a message which simply has a top level message node containing a single text
string, as we had in the previous exercise. Right‐click the text (String) node, and select
Schema…
3. The Select Schema dialog box will open. On the far left, select WSDLs. You should then see
the addNumbers WSDL shown in the middle of the dialog box; click it to select it.
4. On the right side, you should get a preview of the message types available in the schema.
This might be partially hidden by the Binding Properties section. To control what is
currently hidden or displayed, you can use the arrow buttons ( ). Click the down arrow to
hide the Binding Properties section.
5. In the Operation drop down, we can choose which message type we would like to use; for
this example, we will be generating a message based on addition__INPUT__addition, so
select that.



6. Click Next. You will now see a set of options that will sometimes be useful when applying
schemas to a message. In particular, there will be circumstances where the option to include
optional fields will be needed. For this message schema, however, there are no optional
fields, so we can simply click Finish.

7. You should now see the message formatted using the input message schema for the
addNumbers service. Notice that as the message is based on the WSDL, rather than a file, it
contains information that you did not see in the previous example. For example, under the
Message Headers section, you can see that both the HTTP Properties and HTTP Headers
have been filled in.
8. Using a schema also provides you with a way of checking that your message conforms with
the specifications of an acceptable message. In this example, an input message must contain
two numbers, under the elements arg0 and arg1. We will now see what happens when the



message is modified so that one of these is missing. To do this, select the arg1 (Element)
node, and press the Delete key. Rational Integration Tester will ask for confirmation; click
Yes to respond to this.

9. The message structure will be updated, and you will see orange and red x symbols to inform
you that there is an error somewhere in the message. You can hover your mouse over these
symbols to get more information, but in general, an orange x symbol indicates that there is
an error somewhere further down that branch of the tree, while a red x symbol indicates
that there is an error inside that specific node. Hover over the red x; you should see that the
schema indicates that the addition element should have an arg1 element inside it.
10. To add the element back to the schema, right‐click the tns:addition (Element) node, and
select Add Child > arg1 (Element). The message will be updated, and as the message now
conforms to the schema, the error markers will disappear.
11. As we still have null values for each of the arguments, edit the Text nodes for arg0 and
arg1, and enter a number for each one.
12. Save and close the message.

You have now seen how to import example messages by copying and pasting the data into Rational
Integration Tester. You have also created an example message by applying a message schema and
entering the data manually. As you will see in following sections, is it also possible to record
messages from the live system, and to save them as requirements for later use.

5.5 Advanced exercise
There are a few more things to observe in the Requirements Library.
1. First, look at what happens when you right‐click the Addition operation in the
Requirements Library Tree, and then select New > Request Message or New > Reply
Message.
2. Next, take a look at the other tabs: Value, Store, and Documentation. Notice that you can
see more information taken from the message headers.
3. On the Value tab, change the value of one of the arguments. What happens on the Config tab
if you do this?



6 Recording messages
6.1 The Recording Studio
Rational Integration Tester and the platform pack provide us with the capability to record events
(messages or database interactions) from the system under test. The Recording Studio allows us to
control what parts of the system we want to record, whether it might be specific parts of the system
infrastructure, or specific services using that infrastructure. Traffic over a number of different
transports can be recorded:


HTTP and HTTPS



TCP/IP



IBM WebSphere MQ



Tibco BusinessWorks, EMS and Rendezvous



webMethods Integration Server



SAP IDOC



JDBC (IBM DB2, Oracle, MySQL, MS SQL)



IBM CICS® Transaction Gateway & CICS DPL



IMS Connect



FIX



Java method calls



JMS (subscription only)

Different configurations will be required for each of the different technologies. In this training
course, you will see examples of recording HTTP and IBM WebSphere MQ. For information on
recording events from other transports, refer to the Rational Integration Tester documentation.
This training course will discuss the required configuration for each transport as it is required.
Once the system under test has been set up to allow recording, you can choose what you want to
record within the Recording Studio. This can be done by selecting Event Monitors that specify what
you want to record. A single event monitor can be used to record interactions with a particular
operation, or everything that happens over a particular transport. As some transports might have a
lot of information, you can choose to ignore some events entirely before you even start recording.
For example, Rational Integration Tester will ignore any WebSphere MQ administration messages
being sent over that transport by default; such filters can be added, edited or removed within the
Logical View settings for the transport.
Once you have decided what to record, you can then begin recording. As events are recorded, they
are displayed within the Events View. If desired, Event Monitors can be added or removed as you
record. You can also filter what events are shown in the Events View by selecting different monitors
within the Event Monitors panel. As events of interest are recorded, you can view more details for



these events by selecting them within the Events View; further details will then be shown in the
Event Details panel below.

It is important to note that recording these events does not interfere with the operation of the
system under test. Events will still be dealt with in the same way that they usually would be; the
only difference is that those events will be accessible through Rational Integration Tester.
Following recording, events can be re‐used in a variety of ways. The simplest thing we can do is
export the recorded events to disk, so that they can be imported back into the Recording Studio at
another point in time. Otherwise, events can be used to build the following resources:


Operations



Triggers



Requirements



Data sets



Tests



Stubs

If we do not have a complete model of the system under test, then events recorded from the
transports within the system can be used as a basis for building new operations within our system
model.



Events can be re‐used in the form of triggers; a trigger allows us to stimulate the system under test
directly from Rational Integration Tester. We can then record what happens in response. Note that
this will not necessarily be the same as what happened when we originally created the trigger, and
we will not be performing any validation on any events recorded in response to the trigger. This
means that we can send events to the system without going through the GUI layer (or any other
layer of the system that we might prefer to bypass), allowing us to understand how the system
reacts to various inputs.
In other cases, we might want to save a message for later on, without specifying how it will be used.
It can be saved in the form of a requirement, giving us an example message that we can view in the
Requirements Library. Those requirements can later be imported into other resources. Data from
messages can also be saved into a data set in the form of a CSV file that you can use later for data
driving your tests or stubs.
We can also use recorded groups of events to create tests or stubs. The data within the events can
be hard‐coded into the test or stub; it can also be entered into a data set such as a CSV file, or a data
model, which maps the relationships between the data in the system.

6.2 Recording HTTP traffic
As we are currently using a web service, we will be looking at recording messages sent over HTTP.
There are two ways of accomplishing this: using the HTTP proxy included in the Rational
Integration Tester platform pack, or using packet capture.
The simplest method in terms of configuration is packet capture. This method captures the raw
HTTP traffic being sent over the network from your local computer to other computers. You might
need to perform minimal configuration in the Library Manager to select the network interface that
you would like to record, but once you have done this, you can start recording anything that flows
through your computer. There are a few disadvantages to this, however: first, the packet capture
feature requires administrative privileges, and secondly, some network administrators might not
approve of any packet capture software running on their network.
Recording via a proxy has more initial setup, as it requires the Rational Test Control Panel and one
or more proxies to be configured, but it also offers more power and flexibility. Once a set of proxies
has been set up, recording can capture not only messages from the local computer, but also
messages from other computers. Using a proxy also allows you the option of recording HTTPS
traffic, although that requires more configuration, and is beyond the scope of this course.
As recording through a proxy is a more complex system, consider what needs to happen in that
initial proxy configuration. You will need to have the Rational Test Control Panel set up and running
first; once that is ready, you can install the Rational Integration Tester platform pack. The
installation process asks for the URL of the Rational Test Control Panel, so that the proxy knows
where to get instructions from. Once the proxy is installed, configured and running, your
application then needs to be configured to use the proxy for its HTTP traffic:



This means that each HTTP request the client makes will then go through the proxy. The proxy will
then make that request on behalf of the client application, and send the results back to the client.
The configuration needs to be set up for each client; as details will vary from client to client, we will
not cover the details in this manual. The proxy has already been set up for the Tomcat server in the
training example. However, if you want to know more, there are several examples covered in the
Rational Integration Tester documentation.
By default, this system will not interfere with anything going on in the system. It is simply acting as
an intermediary, passing messages between the client application and the target web service. When
you start recording, however, the proxy starts to interact with other parts of the system in addition
to the client and the web service:

After you ask Rational Integration Tester to record using one or more HTTP or HTTPS event
monitors, it tells Rational Test Control Panel that those event monitors should be recorded. When
each proxy checks Rational Test Control Panel for new instructions, it is told to send a copy of any
relevant messages to the copy of Rational Integration Tester that started the recording. While
messages will still pass between the client and the web service, so the proxy is not changing how
the system functions, the proxy will copy any messages required.
You might be wondering why Rational Integration Tester does not talk directly to the proxy (or
proxies) itself. The first reason is that there might be multiple proxies, and these might be shared
between multiple users. By passing commands through Rational Test Control Panel, there is only
one piece of infrastructure to configure within the Rational Integration Tester project, and proxies
can be added or removed at any time.

6.3 Exercise: Recording HTTP traffic
We will now take a look at an example of using a HTTP proxy to record traffic for the addNumbers
Server.
1. First, you will need to launch a client for the AddNumbers server; you will find the
AddNumbersClient on your desktop. Launch this; you will see a new window open.



2. Next, return to Rational Integration Tester and make sure you are using the correct
recording method. This is set up in the Architecture School, so return to that perspective
and enter the Physical View.
3. Locate the physical instance of your web server, and double‐click it to open it.
4. In the dialog box that opens, switch to the Recording tab.
5. Select External Proxy Server as your Recording Method.
6. Click OK to close the physical resource.
7. Switch to the Recording Studio perspective.
8. Click the Add Event Monitor button to add a new event monitor
9. From the dialog box that opens, select the Addition operation.
10. A new event monitor should be shown in the Event Monitors panel. If not, check that the
previous steps have been completed. Once you are ready, click the Record button in the
Events View toolbar.
11. Switch to the AddNumbersClient window, enter two numbers, and add them together. You
should see a result in that window.
12. Return to the Recording Studio. You should now see two messages in the Events View.

13. Select the first message. You will notice that it has an icon next to it, to indicate that it is a
Request message.
14. In the message details section below, the message itself will be shown, formatted into the
same tree structure you were using previously. You can also select the second message to



view that as well. Here, you should see the same result that you saw in the
AddNumbersClient.
15. Click the Pause button to pause the recording.



7 Creating tests
7.1 Test Factory
You are now ready to start creating some basic tests for the AddNumbers web service. In this
module, you will start to use the Test Factory perspective, and create tests using two simple
methods. You will be reusing the information you have put together previously in the Architecture
School, Requirements Library, and Recording Studio to do this.
Before starting, though, we will take a look at the Test Factory perspective, as well as how each test
is structured.

The perspective itself is fairly simple, and is made up of two parts: the Test Factory Tree and the
Editing Panel. You will recognize the tree from your work with the Requirements Gallery. The tree
is used to hold all of your resources, and as you will have noticed earlier, is directly based on the
structure of the Logical View. All resources are organized beneath their respective operations or
service components. Further organization is carried out by the type of resource; extra folders can
also be added by the user.



The Editing Panel changes depending on the type of resource that is currently being edited. You will
use it in this module to create and edit tests. Later in this course, you will see how to use it to work
with your test data, test suites, and stubs.
There are four main ways to create tests in Rational Integration Tester:


Creating a new blank test



Creating a test from recorded events



Creating a test, or a group of tests, using the MEP wizards



Creating a test from a template

Creating a test from recorded events can be done from the Recording Studio perspective; all other
options are handled in the Test Factory.
We will create our first test from recorded events. We will then take a closer look at how that test is
put together, and how we can edit it. We will also look at creating a test using the MEP. Later
modules will make use of the other methods for creating tests.

7.2 Test structure
The main structure of a test is put together using a set of test actions; there is no scripting required
in Rational Integration Tester. Instead, Rational Integration Tester will determine what it is
required to do by analyzing the sequence of these pre‐configured actions.
At a top level view, the actions within a test will
be split into three phases: Initialise, Test Steps,
and Tear‐down. These sections are treated
differently depending on the type of test being
run. For normal functional tests, as in this
training course, these three sections will
generally be executed in sequence. However, for
performance tests and stubs, where the test
actions will be repeated multiple times, only the
Test Steps section will be repeated; Initialise and
Tear‐down steps will be run once only. Similarly,
certain test actions (such as the Pass and Fail
actions) will skip any further test actions within
the Test Steps, and go straight to any actions
within the Tear‐down phase. For this reason, it is
suggested that the Initialise and Tear‐down
phases are used for setup and clean‐up, such as
clearing database tables or moving files.
The test actions themselves are generally executed in sequence, though logic can be added to the
test to allow for branching and looping.



7.3 Business View and Technical View
Rational Integration Tester provides two different views of Test Actions. The first of these is the
Technical View, which is the default view generated by Rational Integration Tester. This displays
each action using information taken from its configuration:

The Business View provides a user‐editable view. By default, it is exactly the same as the Technical
View, but it can be edited by the user to add a description of the action. In the example below, the
two messaging actions have been edited to add a description; the rest of the test has been left alone:

Switching between Technical View and Business View can be done by using the Technical View
and Business View buttons on the main toolbar at the top of the Rational Integration Tester
window.
Once you are looking at the Business View, action descriptions can be edited in a couple of ways:


Click once on the action to select it, then once again to edit the description.



Select the action, and then press F2.

Right‐click the action, and choose Rename.

7.4 Exercise: Creating a test from recorded messages
1. Make sure you are still in the Recording Studio perspective and that the two messages you
recorded in the previous example are still visible in the Events View. If not, you will need to
record them again.
2. Select both messages in the Events View. If you have recorded more than a single addition,
just select a pair of messages. Remember to use the Request and Reply icons to
identify a request and the corresponding response.



3. Click the Save button to start the Save Recorded Events Wizard.
4. On the first screen, select the option for Unit Test.
5. You can then click the Next button to go through the wizard until you reach the Summary
page. You will explore the other pages of the wizard later on.
6. On the Summary page, give the test the name testFromRecording. When you finish the
wizard, the new test should be open for you in the Test Factory.

7.5 The MEP wizards
The MEP wizards provide us with another way of creating tests. Rational Integration Tester will
take the information that you have supplied as part of the operation under test in the Logical View,
and use that to generate a basic test or set of tests. You will recall that we looked at the MEP (or
Message Exchange Pattern) earlier. It contained information about the message schemas used by
the operation, along with transport details for that operation.
The Test using MEP and Tests using MEP wizards will read that information from the MEP, and
use it to generate input and output messages for the operation. For an operation with a
Request/Reply MEP, this will create a test with a Send Request and a Receive Reply action; both
test actions will take their schema and transport information from the MEP. The main difference
between the two is that creating a single test using the MEP will create a Send Request step where
the fields within the message are all blank; creating multiple tests will fill in the input messages
with random or constant data, as selected within the wizard. In both cases, the Receive Reply action
will contain a message using the appropriate schema, but all fields will be blank, as Rational
Integration Tester does not know how the system is meant to respond to the first message. You can
either edit this test action, or leave it till later to repair in the Test Lab; we will make use of this
second option later.

7.6 Exercise: Creating a test from MEP
1. To use the MEP wizard, right‐click the Addition operation in the Test Factory Tree, and
select New > Test using MEP. Note that there is also an option to create multiple tests from
MEP; you will be using that later on. For now, you will just be creating a single test.
2. You will be asked to give the test a name. Call it testFromMEP, and click OK.
3. As with the previous example, you will be given a new test with two actions in it: a Send
Request, and a Receive Reply.



4. Double‐click the Send Request action to view it. Note that, as with the requirements you
created earlier from the addNumbers schema, the test action contains a message structure,
but the values within that structure have not been filled in. It is possible to fill those in, as
you did for your requirements, but instead you will be taking a different approach here.
Close the Send Request action.
5. You are going to reuse the data contained in the example_from_schema requirement to fill in
the data within the Send Request action. In order to make sure there are not any problems
with this, check that you have saved and closed that requirement.
6. Drag the example_from_schema requirement from the Test Factory Tree onto the Send
Request action in testFromMEP.
7. A dialog box will open, asking what you would like to do with the requirement. It is possible
to copy or to link the requirement. Select Update this action with a copy of the
requirement, and make sure that the checkbox labeled Remember my decision is cleared.

8. Click OK.

9. Open the Send Request action again. You should see that the data contained in the
requirement has been copied into the test action.
10. Check the two numbers specified within the message, and add them together. You will need
this number in a moment.
11. Close the Send Request action, and open the Receive Reply action.
12. You should see a message containing a blank return value. Fill this in with the value that you
calculated in step 10.
13. Click OK to close the Receive Reply action.
14. Save the testFromMEP.



8 Test execution
8.1 The Test Lab
To run tests, you will be using the Test Lab perspective. This is made up of three parts: the Test
Execution Tree, the Task Monitor and the Console.

The Test Execution Tree is used to browse through the test resources. Select a test here; it can be
run in one of three different ways. Right‐click the test and choose Run, double‐click the test in the
tree, or press F5. Further options can be chosen by right‐clicking and choosing Run… from the
context menu. You will see some of these options later in the course.
Once a test has been run, each instance will be shown as a separate line in the Task Monitor. A
progress bar will be displayed on each line. Once the test run is complete, the progress bar will
indicate the status of that text run. By default, it will be green if the test passes, and red if it fails.
Selecting a single test run in the Task Monitor will display further details in the console. Details will
be logged in the console as the test runs; each step will be displayed, documenting the progress of
the test. You can use this to review each test. When a test fails, this will be where you can come to
figure out why the test failed.
If you have documented your tests using the Business View within the Test Factory, you might want
to use that same information in the console. This will allow you a much clearer picture of longer,



more complex tests. While the default is to show the Technical View data, you can easily switch to
the Business View data by modifying the Action Prefix setting in the Console tab of the software’s
Preferences.

8.2 Exercise: Running tests
You will now use the Test Lab to run the tests you created earlier against the AddNumbers web
service.
1. Switch to the Test Lab perspective.
2. Find the testFromRecording test, and select it.
3. Click the Run button.
4. You should see a test run for testFromRecording displayed in the Task Monitor. You will
probably also see more detail shown in the console. If not, select testFromRecording where
it is visible in the Task Monitor.
5. Both the Task Monitor and the Console should indicate that the test has passed.

6. Follow the same procedure for the testFromMEP test; this should also pass.
7. Switch to the Test Factory, and edit the Receive Reply action in testFromRecording.
8. Change the return value given in this message so that it is incorrect.
9. Click OK to close the Receive Reply action, and then Save the test.
10. Run the test again. It should fail.
11. Edit the test again to correct it, and Save the test.



9 Test automation
9.1 Test suites
So far, we have run all of our tests and stubs manually. This is fine while we are developing these
resources, but when we want to run large numbers of tests, this will not scale very well. We will
now look at automating our tests, which will involve two tasks: the automation itself, as well as
reporting the results of these automated tests.
A test suite is a resource type providing a method of aggregating tests and/or other test suites,
which can be run in series or in parallel. Each test suite is made up of one or more scenarios; each
scenario can contain tests, performance tests, test suites, and other scenarios.
Each scenario provides configuration information for the resources inside it: which environment to
use, the timing of the tests (in parallel, or spaced out), and what stubs should be executing while the
scenario is active. For more advanced test suites, scenarios also provide the ability to data drive the
tests within them, and to use probes (where a performance test license is available).
In addition, scenarios can choose to terminate or continue when a resource fails. This allows smoke
tests to be carried out where necessary, but also for larger test suites to continue when all test
results are required.

9.2 Exercise: Creating and executing a test suite
1. Switch to the Test Factory perspective.
2. Right‐click the Addition operation and select New > Tests > Test Suite.
3. You will then need to provide a suitable name for the suite. Call it AdditionSuite and click
OK to proceed.

4. The new suite appears with a new scenario, which is opened in its own tab in the Test
Factory. Double‐click the scenario icon.



5. You can now view the scenario settings. You should notice that the Environment setting is
<Undefined>. This means it will use the current environment. Click OK to close the scenario
settings.
6. Add the two tests that you created earlier. Note that for this example, the order of the tests
should not matter. You can add the tests through either of the following procedures:
o Dragging them from the Tests virtual folder under the Addition operation and
dropping them under the new scenario
o Clicking the Add Tests button on the toolbar above the new scenario and selecting
the tests that were just created

7. Save the new suite by selecting File > Save, or clicking the Save button in the main toolbar
of Rational Integration Tester.
8. Run the suite by clicking Run in the main toolbar of Rational Integration Tester or by right‐
clicking the suite and selecting Run from the context menu
9. The suite is opened and run in the Test Lab. A graphical summary of the execution is
displayed in the Task Monitor, and a detailed report of each item in the suite can be found
in the Console, in the lower portion of the window.



9.3 Results Gallery
When a test suite is run, results will be recorded into the results database, provided one has been
set up previously. These results can then be viewed from within the Results Gallery.



Results are viewed for each resource. The resource type and name can be selected along the top of
the perspective, along with the instance to be displayed (for a test suite only). The instances are
sorted by the time and date of execution of the test suite, and are named. The default name is the
environment it was run in, but this can be changed, as we will see later.
Below that, we can see an execution summary for the currently selected test resource; for a test
suite, this means the status of each test inside the suite. For a single test, this will display a
summary of every time that the test was run and recorded into the database, remembering that test
results are only recorded into the results database as part of a test suite or test cycle.
At the bottom of the perspective, we will see the various reports that are available. Different
reports will be available, depending on the resource that is selected above, and the configuration of
the system under test:


The Reports tab displays a summarized report for the selected test or test suite.



The Console tab displays the console output for the selected test.



The Notes tab allows you to annotate results, updating the results database.



The SCA Coverage, Tibco BW Coverage, and webMethods Coverage tabs supply coverage
reports for test suites run against environments with an Oracle SCA Domain, Tibco
BusinessWorks, or webMethods Integration Server.


Rit 8.5.0 platform training student's guide

Rit 8.5.0 platform training student's guide

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (15)

Similar a Rit 8.5.0 platform training student's guide

Similar a Rit 8.5.0 platform training student's guide (20)

Más de Darrel Rader

Más de Darrel Rader (7)

Rit 8.5.0 platform training student's guide