Browse Prior Art Database

Data Flow Manipulation using Relative Data Flow Tagging to support Incremental Advancement toward a target Test Data Flow Sequence.

IP.com Disclosure Number: IPCOM000198586D
Publication Date: 2010-Aug-10
Document File: 3 page(s) / 59K

Publishing Venue

The IP.com Prior Art Database

Abstract

Data Flow Manipulation using Relative Data Flow Tagging to support Incremental Advancement toward a target Test Data Flow Sequence.

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 38% of the total text.

Page 1 of 3

Data Flow Manipulation using Relative Data Flow Tagging to support Incremental Advancement toward a target Test Data Flow Sequence .

Application testing involves driving the system under test with various inputs and observing the resultant behaviour. In the special case of terminal/device related application testing this involves sending inbound data flows to the application under test and observing the returned output data flows.

    Terminal workload simulation tools allow for the simulation of large workloads as would result from multiple users working at multiple terminals.

    In addition to delivering a standard workload, such programs can potentially be used to recreate specific error scenarios, where abnormal device behaviour or critical timing expose a weakness in the application. Such testing could be required in a software service organization where it is necessary to reproduce error scenarios reported by a customer that exposed a defect in the application being serviced, such that any defect fix can be tested. The process of recreating such error situations can require detailed control over specific aspects of the simulation. For example it may be necessary to corrupt the data being sent from the device to the application, or to simulate a hardware error in the device. Alternatively it may be necessary to control the order in which data flows occur, to simulate critical timing situations, or even to cancel certain data flows entirely. This specific control of events is unlikely to be provided by the standard Application Programming Interface (API) of the simulation program, but in a terminal workload simulation tool, the required functionality is available through the use of user exits. However writing a user exit is a complex task requiring detailed product knowledge, the process of writing user exits is consequently time-consuming. User exits are also inflexible, having to be written in advance of the test to perform one specific task.

    Where multiple exits are required the choreography of their actions to achieve the desired overall effect can be so complex as to be impractical. Another restriction of the user exit is that it has no concept of the overall data flow scenario, it can only take actions in response to specific events, or data patterns. The restrictions inherent in user exits, as described, combine to make their powerful functionality inaccessible to all but the most determined, experienced and well resourced test teams.

    The process of precisely reproducing a specific data flow sequence is commonly an incremental one, in that an initial attempt to reproduce the data flow sequence is only partially successful, and a series of further refinements are made to correct deviations from the target data flow sequence. This gradual refinement of the inbound data flow set is not always a series of forward steps towards the target. Some of the attempts to correct deviations from the target data flow may have unwanted conseq...