Test virtualization accelerates mainframe testing
Automate mainframe testing and simplify complex tests
Test virtualization helps mainframe testing
Today's applications are complex. They spread across multiple systems and have many interdependent parts. Complex applications require complex tests, which need time and resources to set up. Test teams that work on different parts of an application have to coordinate test efforts. One solution to these limitations is to provide virtualization for parts of the application.
For example, for a mobile application that calls a web service, you can virtualize the responses of the web service, so that you can develop your mobile, front-end system without the need of the back-end system, at least for the early testing. The same principle is true for any boundary in an application, where you can split the application into a reasonable set of defined responses. With the application divided at the boundaries, the teams can build their application changes and test them, even though they do not have access to the entire application. This division makes it possible for test teams to work for a longer percentage of the development cycle. This suggestion can be particularly helpful with mainframe application testing where access to test resources is generally limited and where separate components need to interact with each other. Test virtualization works by identifying appropriate boundaries at which the technology can be applied. In the context of mainframe testing, this is typically from component to component.
But how do you virtualize parts of an application? Software engineers are familiar with test stubs, which are programs that simulate the behavior of software components that the module under test, depends on. Test stubs make it possible to perform tests earlier in the cycle, at reduced cost. However, when the system under test grows large and complex, stubs quickly become too difficult to create and to manage. The IBM test virtualization solution uses the stub concept and provides comprehensive functions that create, use, and share virtual services (also called stubs). To create a virtual service, you record it in a real system or you analyze the service interface definition. A team server then manages the services, which can be deployed to multiple test environments. The solution accelerates the delivery of complex test environments and makes it possible for development teams to do tests earlier and more frequently in the project lifecycle.
Test virtualization has many benefits for an enterprise system that includes mobile or web channels, mainframe transaction managers, such as IBM® CICS®, IBM® IMS™, and mainframe message servers and databases. It makes it possible to:
- Set up multiple test environments in minutes, rather than weeks
- Test multiplatform applications that produce and consume COBOL copybooks and data files and interact with IBM® WebSphere® MQ, IBM® DB2®, and other systems by use of virtualized, complex dependencies
- Improve coverage for integration and negative test scenarios
- Improve coverage for latency tests by simulating application behavior that takes too long to respond
- Perform early performance tests to ensure the robustness of the system under test
- Develop, in parallel, different parts of an application or system by use of virtualized dependencies
- Reduce competition for critical mainframe resources
This article describes different test virtualization scenarios in the mainframe and steps through a sample of how to virtualize a CICS program. The approach used in the sample also applies to other middleware and service protocols.
Mainframe test virtualization scenarios
Different types of test virtualization are possible for the mainframe environment. The scenarios in this article focus on specific, mainframe connectivity options and are not an exhaustive list of virtualization possibilities.
CICS virtualization: Mainframe or distributed app calls CICS program
In Scenario 1, a mainframe or distributed application calls a CICS program by using the HTTP or HTTPS protocol, as shown in Figure 1.
This virtualization takes advantage of CICS support for web services, which makes it possible for a CICS program to be exposed as a web service with a minimum amount of programming effort. Such CICS services can be virtualized, regardless of the client-side technology.
Figure 1. Scenario 1: Mainframe or distributed app calls CICS program with HTTP
CICS virtualization: Distributed Java app calls CICS program
In Scenario 2, a distributed Java application calls a CICS program through the IBM CICS Transaction Gateway, as shown in Figure 2.
CICS Transaction Gateway serves as a connector for enterprise modernization of CICS assets. A CICS program can be virtualized if it is accessed through CICS Transaction Gateway by another application.
Figure 2. Distributed application calls CICS program through CICS Transaction Gateway
CICS virtualization: CICS application calls a web service
In Scenario 3, a CICS application calls a web service by using the
INVOKE WEBSERVICE command, as shown in Figure 3.
The downstream web service can be virtualized using the same technology as in scenario 1.
Figure 3. CICS program calls a web service with INVOKE WEBSERVICE calls
Scenarios 1, 2, and 3 are examples of inter-mainframe virtualization because the dependent system is usually in another platform or another IBM® z/OS® system.
CICS virtualization: CICS program calls another CICS program
In Scenario 4, a CICS program calls another CICS program by use of the distributed program link (DPL), as shown in Figure 4.
In CICS, DPL makes it possible for a CICS program to pass control to a second CICS program to run a function. The two programs can be in the same CICS region or in different regions. In this scenario, the linked-to program can be virtualized and call latency and ABENDs in the linked-to program can be simulated to assist with development or test scenarios that are typically difficult to achieve.
Because the application under test and its dependent application are in the same z/OS instance, this scenario is described as intra-mainframe virtualization. It allows mainframe development and quality assurance teams to use test virtualization technology within a large mainframe application.
Figure 4. CICS program calls another CICS program with distributed program link
DB2 database virtualization
Access to host-based DB2 databases through Java database connectivity (JDBC) can be virtualized. The virtual database can run on a separate DB2 instance on z/OS or on the distributed platform, as shown in Figure 5. This setup makes it possible for you to create virtual databases that do not require z/OS to run. You can work with isolated copies of data that can be manipulated independently to achieve test goals.
Figure 5. DB2 database virtualization
An IMS application can be virtualized if the application is called by a client, by using the IMS Connect protocol, as shown in Figure 6. You can record IMS type 1 and type 2 messages and use them to construct virtual program responses. Type 1 messages are generated from applications deployed on IBM® WebSphere® Application Server that are configured with the IBM® IMS™ Transaction Manager resource adapter. Type 2 messages are generated from user-written applications that use the IBM® IMS™ Enterprise Suite Connect API.
Figure 6. IMS virtualization
WebSphere MQ virtualization
Programs that interact with message queuing services provided by WebSphere MQ (both z/OS and the distributed version) can be virtualized, as shown in Figure 7. In addition to the normal running of stubs, IBM® Rational® Test Workbench provides the sift and pass-through capability that makes it possible for you to run both real and virtual services at the same time and seamlessly filter a subset of messages to either the real or virtual services. Previously, only a real service or a virtual service could be up at one time, because simultaneous usage results in contention for the messages being used. The benefits are obvious. You can focus on a subset of messages (among millions of messages) to simulate and test, and let the other messages go to the live system.
Figure 7. WebSphere MQ virtualization
Example of CICS DPL virtualization
In this example, see how a mainframe team uses CICS DPL virtualization to help them remove the dependency on other modules so that they can test early. You can apply a similar approach to any other scenario where test virtualization is supported.
A fictitious company JKE Banking is currently implementing a number of
modernization programs across their application portfolio. The company
wants to improve the user experience of the loan query function of their
mobile application to use geolocation data to obtain a list of providers.
The company is also changing the
Calculate Mortgage module
that serves both the main, green-screen mortgage application and the
Get Companies module used in the loan query function. Figure
8 shows how the modules and services are organized across CICS
Figure 8. Architecture of mortgage application
Because the team that makes the changes to
Get Companies needs
to iterate fast to stay aligned with the mobile development team, they
choose to use test virtualization to avoid impact and dependency on the
Mortgage Calculation module. Another way to avoid the
dependency is to replicate the program in another region, but that option
requires more time, because it depends on the availability of
How to record interactions
Before you can record DPL calls, you need to install the IBM®
Rational® Integration Tester and the IBM® CICS® Transaction
Server agent and configure them in the CICS region that is to make the DPL
requests. After the agent is installed, run the
transaction to start it, as shown in Figure 9.
Figure 9. Start the CICS Transaction Server agent in the Rational Integration Tester
A test engineer on the team then uses Rational Integration Tester to record interactions and to create and edit the stub. As shown in Figure 10, the test engineer models a logical CICS region in Rational Integration Tester to represent the region from which to record and creates a corresponding physical resource that specifies the SYSID and APPLID to correctly identify the particular region.
Figure 10. Create logical CICS region in Rational Integration Tester
The logical resource then becomes added to the list of event monitors in the Recording Studio perspective of Rational Integration Tester. To start the recording, the tester clicks the red circle button as shown in Figure 11 to instruct the agent to capture all the DPL requests in the CICS region.
Figure 11. Record stubs in Rational Integration Tester
Because both the
Get Company service and the existing,
green-screen CICS mortgage application make calls to the
Calculate Mortgage module, you can use either of them to
achieve the recording. In this example, the tester decides to use the
green-screen application, a CICS transaction called JKEP, to do the
recording because it is the simplest.
The tester logs into CICS and runs the JKEP transaction, inputs the loan amount, the years, and the interest rate, and presses Enter to tell the application to calculate the monthly payment. The screen shows the calculation result in the Monthly Payment field, as shown in Figure 12.
Figure 12. Mortgage 3270 interface
After this series of actions, two events appear in the Rational Integration
Tester recording view, as shown in Figure 13. They are the request and
response of the DPL call to the
Calculate Mortgage module.
The data fields in the request and response represent the
COMMAREA, the CICS communication area in which data is passed
to the program being invoked. To adapt them from their raw form, apply a
copybook schema that is imported into Rational Integration Tester. After
the schema is applied, the request and response data is then shown in a
structured manner, which is easier for the tester to read and edit.
Figure 13. Events recorded in Rational Integration Tester
The test engineer then selects the pair of events and saves them as a simple stub, as shown in Figure 14. A stub can contain many event pairs that represent the different requests to be supported. When the stub is run and a DPL call comes in, it tries to match the request against the configured messages. If a match is found (you can apply a number of different matching rules that pick up matches that are not exact), the recorded response is sent back.
Figure 14. Save the stub in Rational Integration Tester
As shown in Figure 15, to test the new stub, the engineer runs it within the workbench element of Rational Integration Tester, where the tester can make additional changes and add other scenarios. Because this is a design environment, the stub has limited throughput and can run for a limited time.
Figure 15. Run the stub in Rational Integration Tester
A stub can contain complex logic or a simple pre-built response. The stub
has settings and properties that control its behavior. The response time
property makes it possible for the test engineer to simulate the latency
of the real-world service to confirm that the
program behaves correctly in this scenario. As shown in Figure 16, the
response time is configured to vary between 20 and 50ms with a Gaussian
distribution. This method to test performance against a long response-time
setting is much easier than using real services to perform similar
Figure 16. Stub properties define the response times
The test engineer can configure the behavior for requests that are not handled. This is known as sift-and-pass-through, and is another powerful stub behavior that you can easily configure. Logic is added to a stub to help it determine whether it should respond to a received request (known as sifting) or, when possible, to send the traffic for onward processing to the real system (known as pass-through.) Sift-and-pass-through is supported for MQ and CICS and other transports. In this example, the tester chooses to simulate an error, as shown in Figure 17.
Figure 17. Define the pass-through configuration
After these tasks are complete and the stub is tested and ready to use, it is then published to Rational Test Control Panel for other shared use.
Manage stubs in Rational Test Control Panel
Rational Test Control Panel is a team server you can use to manage virtual services and the agents that provide the infrastructure. You publish stubs from Rational Integration Tester to Rational Test Control Panel when they are ready to be used, as shown in Figure 18.
Figure 18. Publish stub to Rational Test Control Panel
As shown in Figure 19, in a view in Rational Test Control Panel the test engineer is able to see the elements of the system under test, organized into domains and environments. From there the tester can launch and see the status of the stubs and the statistics of requests that are handled by the stub. From the test control panel, you can search logs and results and view the status of agents.
Figure 19. Rational Test Control Panel VIE view
Continuous testing with UrbanCode Deploy
Many development teams have moved toward automated environment management and automated deployment as part of their build cycle. You can include virtual services as part of the test environment and as part of the deployment process. In the JKE Banking example, the bank uses IBM® UrbanCode® Deploy, a leading deployment automation product, to deploy their mobile and mainframe application to a test environment to run their regression tests. UrbanCode Deploy includes a plug-in to work with the virtual services created by Rational Integration Tester.
As shown in Figure 20, an UrbanCode Deploy test process is enhanced to use a virtual service. The Start Stub and Stop Stub steps in the process diagram communicate with a Rational Test Control Panel server to ensure the required stubs can be used for this test scenario.
Figure 20. Deploy stubs with UrbanCode Deploy
Rational Test Control Panel also provides integration APIs in the form of REST services, custom ANT tasks, and a command line client to make it possible for other test and deployment automation tools to use the test virtualization capabilities.
Use Rational Development and Test to prepare test environment
IBM® Rational® Development and Test Environment for System z® is an environment for mainframe application development and testing where the operating systems, middleware, and software can run on Intel and Intel-compatible platforms without the need for System z mainframe hardware. With this test environment, developers and testers are able to work independently of each other and use test virtualization technology to prepare an environment for a mainframe project much faster then before. Development can iterate on this environment using virtual third-party services until the time they need to integrate with the real sub-systems.
This article describes the types of test virtualization scenarios that are supported in z/OS. It includes a sample of how to create a virtual service for a CICS program and use it in a team environment. Test virtualization and Rational Development and Test work together to simplify z/OS test environment preparation. For more information about continuous integration, deployment, and testing in mainframe environments, see the continuous integration for System z series of articles.