Application Server

Digg This!

Page 1 of 2   next page »

This article describes how the Open Source tool OpenSTA facilitated the system integration testing of a middleware solution based on IBM WebSphere Application Server and the Websphere Branch Transformation Toolkit (BTT).

OpenSTA automation improved test execution accuracy and reproducibility while preserving the project's tight test budget. With the benefit of the lessons learned and the key OpenSTA workarounds documented here, you may want to consider OpenSTA for your own distributed application testing strategy.

Why an Open Source Test Tool?
A recent project for a financial institution delivered a middleware infrastructure to support an Interactive Financial Exchange (IFX) messaging interface between line-of-business applications and the business's core financial systems. Figure 1 illustrates the middleware architecture, with the components in bold representing the initial release and future components in grey.

The project team had to devise a method for testing the integrity of the transactions passing through the middleware to satisfy both the system integration testing criteria and the demands of the corporate audit department. The project sponsor wanted the testing approach selected to be repeatable and extensible for testing future additions in the middleware's transaction inventory. Besides these challenges, the project had no budget for buying commercial testing tools. Without a test tool to structure, automate, and report on test case execution, it would be very hard to provide reproducible results and meet the testing deadline for the hundreds of test cases defined for the project.

With a tight budget, a looming deadline, and no test automation tool, it was clear this was a chance to explore what Open Source had to offer.

Selecting OpenSTA
Research on the available Open Source testing tools revealed that OpenSTA would give the team a no-cost testing platform with a rich set of features to support the middleware system integration testing requirements. OpenSTA was originally developed as a commercial product but has since been open sourced. Because of its commercial heritage, OpenSTA offers a more polished user interface than other Open Source tools, comprehensive help, and an online reference for its proprietary Script Control Language.

For this particular project, a key feature of OpenSTA was its Script Control Language, which let the team execute a number of routines that were reusable for each test case. This feature, combined with OpenSTA's ability to report on test case results including the IFX-encoded response, helped the test team meet its testing schedule. Unfortunately no tool could reduce the work involved in collecting test data for the hundreds of test cases defined for the project.

Designing the Test Scripts
The object of the system integration test was to ensure that the middleware and legacy system interoperated and that IFX-encoded requests and the resulting IFX-encoded responses accurately reflected the results of the legacy system's transactions. The system integration test cases specified the request message content and expected response message content for a variety of business scenarios and test case conditions. The OpenSTA test scripts were designed to meet these test case criteria.

To support the test case execution, a set of IFX-encoded requests was prepared with test data from the legacy system's test region. A complementary set of IFX-encoded responses, one each for the expected results of the IFX-encoded requests, was also developed. So each test case was represented by a request/response pair. It should be noted that the design and implementation of these messages was completely independent of the test tool.

OpenSTA scripts were then developed so each test case would:

• read the IFX-encoded request
• read the expected test results in the form of an IFX-encoded response (referred to as a model response)
• generate a unique message identifier (RqUID) as required by MQ per the project's IFX specification and update both the IFX-encoded request and IFX-encoded model response with the identifier
• submit the IFX-encoded request to the middleware for processing
• capture the actual IFX-encoded response from the middleware
• depending on the test case, remove the time-sensitive elements (timestamps) from the actual IFX-encoded response and the IFX-encoded model response
• compare the actual response with the model response: if identical, flag the test case as passed; otherwise, flag the test case as failed

Since much of this test script logic was common to all the test scripts, it was decided that the test scripts would be written in a modular format in a basic mainline script calling OpenSTA's built-in commands and custom subroutines as required.

A Modular Approach
OpenSTA provided the architecture to design modular scripts so that common logic could be reused for each test case category. After some experimentation, a scripting approach was developed using four script elements:

• a single test script template slightly customized for each test script
• a set of common subroutines referenced by each test script as required
• an IFX-encoded request message for each test script
• an IFX-encoded model response message for each test script

Figure 2 illustrates how these elements interrelate.

In this project's OpenSTA deployment, each test script referenced two executable components: the customized script template that acts as the scripting mainline function and the common subroutines script file that provides common logic across test cases. When executed, the test script reads the IFX-encoded request and model response messages specified in the customized script template, sends the IFX-encoded request to the middleware, captures the response, compares it to the model response, and flags the test script execution as having passed or failed. A link to the script template and common sub-routine files used in this project can be found with this article, see source.html).

The following sections describe the details behind the design of each test script component, including insight on how to avoid some of OpenSTA's quirks and limitations.

Test Script Templates (Sort Of)
The test script templates referenced above are more conceptual than physical, since OpenSTA doesn't support a script template mechanism. The test team defined a "template" by defining a generic set of steps that each test script would need to execute based on the test case criteria specified by the project and then "cut, pasted, and modified" specific test scripts several hundred times. This may sound tedious, but the effort was quite small compared to the benefits of having a common test script pattern and automated test script execution. The specific test script modifications are described in the section "Customizing the Test Script Template" (in part 2 of this article, which will run in WebSphere Journal Vol: 4, Iss: 9).

Test Script Example
Figure 3 illustrates a test script for a specific test case that follows this test script template approach. The script is displayed in the OpenSTA Script Modeler editor.

Page 1 of 2   next page »