Browse Prior Art Database

Preprocessing test suites for test execution efficiency Disclosure Number: IPCOM000020393D
Original Publication Date: 2003-Nov-19
Included in the Prior Art Database: 2003-Nov-19
Document File: 5 page(s) / 49K

Publishing Venue



Preprocessing test suites for test execution efficiency

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

Page 1 of 5

Preprocessing test suites for test execution efficiency

When software is tested using a test execution engine, the test execution engine is supplied with a test suite which consists of test cases. Each test case consists of a sequence of stimuli to the system under test, and it's expected response and system state after each stimulus is applied. These test suites are often long and expensive to run in terms of computing resources, and elapsed time.

    This invention involves a first analysis of the test suite to determine the degree of redundancy inherent in the test suite, and then provides a scheme for executing the test suite or portions thereof, in order to reduce the amount of time and resources needed to run the test suite, without compromising the quality of the validation done by the modified test suite execution.

    The invention is applicable to any software application, but it can be used with even greater savings when testing a software application that is equipped with a dump and restart mechanism, or a forking mechanism for spawning two processes concurrently from the same starting position.

    The first analysis phase of the invention scans the test suite and notes any repeated sequences of stimuli and states where a subsequence of two different test cases are identical. This analysis phase can be carried out using well known pattern matching algorithms (e.g. the McCreight Suffix tree construction for identifying common substrings).

    Let S(i) denote the i-th state of the program under test, A(j) the j-th input action allowed by the program under test, and R(k) the k-th response of the program under test to an input action. A test case is thus a sequence of test steps, each step consists of an Action, its Response, and the new program State entered as a result of the action. Each test case starts with an initial state of the program under test, so a typical test case looks like:
Test Case:
S(0) - the initial state of the system A(1)R(1)S(1) - the first step of the test, it's input action, the system response, and the new system state entered. A(2)R(2)S(2) - the second step of the test, etc.

A(3)R(3)S(3) A(4)R(4)S(4) A(5)R(5)S(5)

    If there exist such sequences at the end of two distinct test cases (i.e. both test cases have the same suffix of states and stimuli) then the suffix that is repeated may be omitted by the test execution engine on the second and subsequent occurrences of this suffix.

    An example of this situation is given in the following test cases. Test Case 1:

A(1)R(1)S(1) - step 1 A(2)R(2)S(2) - step 2 A(3)R(3)S(3) - step 3 A(4)R(4)S(4) - step 4 A(5)R(5)S(5) - step 5

Test Case 2:

Page 2 of 5

S(0) A(6)R(6)S(6) - step 1 A(7)R(7)S(7) - step 2 A(8)R(8)S(8) - step 3 A(9)R(9)S(2) - step 4 A(3)R(3)S(3) - step 5 A(4)R(4)S(4) - step 6 A(5)R(5)S(5) - step 7

    Note that test case 2 finishes its step 4 in the same state (S(2)) that test case 1 finished its step 2. Moreover the actions in test case 2 after step 4 are identical...