Browse Prior Art Database

Autonomic testing in on-demand scenario Disclosure Number: IPCOM000031302D
Original Publication Date: 2004-Sep-21
Included in the Prior Art Database: 2004-Sep-21
Document File: 2 page(s) / 42K

Publishing Venue



This article outlines an approach for providing dynamic (On-demand) testing of dynamically deployed and configured applications which are created by use of aggregating Web Services - for example by the use of a process choreographer.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 48% of the total text.

Page 1 of 2

Autonomic testing in on-demand scenario

Currently a lot of work is going on in developing "on-demand computing", where resources and services are combined on demand to provide solutions. While much of the work is centred around deployment, connectivity, runtime, and programming model, the fact remains that the solutions built will have to be tested. In particular, the testing will have to encompass a wide variety of systems. Further, the normal long Quality Assurance and test cycles that are applied to real integration and connectivity projects and solutions will be at odds with the on-demand nature and timeframes for on-demand applications. Typically integration test takes place on complete test systems and using specialised test tools. Often the tests are hand-written, and specific to the infrastructure and/or application. In an on-demand environment, where the components of the application may be distributed across many organisations, such a test system is impractical. Another complicating factor with on-demand is that some or many of the integrated systems will be already running, and often in the control of other organisations. Current testing approaches often assume the whole infrastructure is monolithic and can be tested as one.

    This article addresses the problems of testing on-demand solutions by including in Web Services that form part of the solution features that allow the components to be tested in isolation and used in a test mode within the solution. This approach allows systems to be tested automatically as part of deployment, and allows the actual system to be tested.

The advantages are that
a) it supports integration test of an application on the real system as much as possible
b) it enables periodic testing of the running application with real workloads to test for valid function, response times, etc.
c) it can avoid the need for creating standalone test systems - this is particularly important where the services within the application are brought in as services from third party suppliers (e.g. credit card payment) - this is important to avoid significant cost and to significantly reduce QA cycles.

    There are three aspects to this approach. In this scenario a large scale application is constructed from a number of Web Services. Each Web Service is built to be inherently testable and deployed in this way into the infrastructure.

The infrastructure provides for testing the web service in three possible ways.

    Firstly, the tooling for this environment will generate a "ping" method on the service. The ping method will respond simply to identify the service is running and provide a response time.

    The second test method involves adding a header to the service request message to indicate that the service request is to proceed as normal but in a test-mode, where no actual effects are to happen. This header is added when the application is being run in test mode. The form of the header could be <od:test mode="ncname">, where...