Browse Prior Art Database

A pattern for system testing messaging and other network based products

IP.com Disclosure Number: IPCOM000182078D
Original Publication Date: 2009-Apr-24
Included in the Prior Art Database: 2009-Apr-24
Document File: 4 page(s) / 119K

Publishing Venue

IBM

Abstract

In Enterprise integration the problems have been around integration of products or components and when instances are spread across multiple system. For example, network issues cause software failure and FDCs. With automation being the applied to all testing that is done, these scenarios usually get missed out due to complexity of testing and automation. In general, the problem is around causing multiple events on a distributed test environment. The impact is seen more while testing messaging software and network based software more as these test enviroments spread across multiple systems. From a user perspective, a test framework is needed for testing large deployments over multiple machines and also to recreate real scenarios where lot of parallel events occur at the same time. The manual intervention in a test environments like these is hard as the complexity increases. A real scenario: When testing Lotus expeditor micro broker (http://publib.boulder.ibm.com/infocenter/ledoc/v6r1/topic/com.ibm.rcp.tools.doc.appdev/ovr10020.html), small messaging server, there were problems in testing communication with WebSphere MQ (http://www.ibm.com/software/ts/mqseries/). Most of the problems were around network issues, restarting WebSphere MQ, problems like listener going down, message loss due to some problems in environment, etc. There were also problems in running the test script as it needed a lot of manual intervention. More to add the problem is with test configuration. Usually complex test like these either use properties file for reading test configuration or test scripts themself embed the configuration. But that didn't seem very workable as deployment itself needed lot of effort in condition where the test involved lots of softwares and machines The other best practice that has been observed in the recent testing frameworks has been that the test code has to machine and enviroment independent as much as possible. This enables easier testing on a platform or a new environment.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 53% of the total text.

Page 1 of 4

A pattern for system testing messaging and other network based products

Authors

Neeraj Krishna, Vijay R Kalangumvathakkal

Solution is built over the following principles:
1. The test script need not have any knowledge of test machine that run different instances of software
2.

No manual intervention for the execution of test

3. Ability to cause multiple events on different test machines at the same time (Asynchronous)

Advantages:

1. Easier automation of complex tests involving multiple machines
2. If MQTT is used for Publish/Subscribe the subscribers can run on any system and hence will allow small devices also to become a part of the test easily
3. Decouple Test code from the test infrastructure
4. Improve change and extensibility in test infrastructure with minimal changes to the test code and environment

Claims:

1. This is a pattern based on pub/sub paradigm for testing
2. Decoupling of test scripts and test machines
3. Ability to cause parallel events on multiple test machines
4. Topics representing components of test like MQINSTANCE, BROKERINSTANCE, etc

Existing Technology:

STAF: Software Testing Automation Framework (STAF) is a open source utility that is

popularly used. But didn't help in solving the problem described above as it required knowledge

of the machine that runs the different software. For example, to restart MQ running on a remote system. We had to connect to that system and then perform that action. The test scripts hence required lot of configuration. Also STAF designed more to be a synchronous set of operations and hard to cause mutiple events at the same time.

1

Page 2 of 4

Components of the solution:

Test script runner: Let's call this the test script publisher (Can even be outside the firewall). It can be connected to the broker and will be publisher and will be run on any one machine of convenience

2. A publish/subscribe engine: Its a very small broker that runs on a central system (can be a Lotus Expeditor micro broker). Can also called as test controller

3. Subscribers running on the test machines: The subscribers that is connected to the broker will be on every test system and depending on software instance on the test system it will subscribe to the broker on a particular topic

2

[This...