Browse Prior Art Database

Modelling software defects using a intercepting layer

IP.com Disclosure Number: IPCOM000185631D
Original Publication Date: 2009-Jul-29
Included in the Prior Art Database: 2009-Jul-29
Document File: 2 page(s) / 55K

Publishing Venue

IBM

Abstract

When software testing it is sometimes necessary to temporarily 'code around' errors due to defects. The problem with this is that the 'code arounds' tend to get lost in the large amount of test code and the problem then gets 'lost'. By writing an intercepting layer all knowledge of errors is kept in one place and easily managed.

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

Page 1 of 2

Modelling software defects using a intercepting layer

When using automated test tools or code, particularly model based testing, it becomes difficult to cope when the software under test has problems or defects. A single problem can break hundreds of test scripts or the majority of results in model testing. This prevents testing of other function and possibly produces 'floods' of results produced by a single error.

    The normal solution is to modify the test scripts or models oracle code to work around the problems by building the expected wrong responses into the tests or alternatively disable collections of tests. Over an extended period the number of these 'fixes' gradually builds up until the models or test scripts become unmanageable. The test results stop indicating the existence of the problems, and the 'fixes' get forgotten as do the defects.

    When the problems in the tested software are cured it can be difficult to find the fixes and reinstate the default behaviour, depending how diligent testers have been about marking, commenting and tracking the fixes.

    When the code under test is unfinished and incomplete it may not be testable and produce errors for some function calls or data but it may be desired to continue with testing despite the problems to obtain what results are possible.

    This disclosure covers a solution to the problem of managing fixes to problems or defects during software testing by any automated software testing tools.

    A 'layer' of software intercepts the calls and data going to the software under test, possibly stores some state and data,then passes data back to the testing system. The data returned to the testing system mimics the 'normal' behaviour of the software under test. Optionally the intercepting layer may also pass the calls on to the system under test if required.

    The layer of software has an interface (Application Programmers Interface or 'API') that exactly matches (is copied from) the interface under test. Initially the intercepting layer simply passes on any calls to it's API functions to the API of the software under test unchanged. The initial empty intercepting layer can be created automatically from Javadoc*, by introspection, or by 'cut an paste' from the software under test.

    The intercepting layer contains functions which replace those affected by the problems in the tested system. Each time the intercepting layer is called it logs data about the defect either to the normal test log or a dedicated log of problems detected during testing. When a defect is found or a part of the software is modelled code' is added to the intercepting layer. The relevant API call(s) and data are intercepted, passed to the new code, and results from the new code are passed back to the calling test script or model. The API call may also be passed on to the code under test and it's returned results may be handled in the intercepting layer code. In this way the intercep...