Browse Prior Art Database

A framework for testing internal components through knowledge of system structure

IP.com Disclosure Number: IPCOM000028071D
Original Publication Date: 2004-Apr-22
Included in the Prior Art Database: 2004-Apr-22
Document File: 2 page(s) / 48K

Publishing Venue

IBM

Abstract

Verifying that a computer based system, either hardware or software, works as intended is a difficult problem, and significant resources are typically invested in this effort. One of the common means of testing a system is by injecting test-cases and then checking that the verified system works as expected. Test-cases can be written manually, but in many areas (for example process verification), a large majority of the test-cases are automatically generated by a test-generator. Automatically generated test-cases must meet two inherent classes of requirements: -- Tests must be valid; that is, their behavior should be well defined by the specification of the verified system; -- Test-cases should also be of high quality, in the sense that they expand the coverage of the verified system and focus on potential bugs. This invention deals with a method for increasing the quality of test-cases produced by a test-case generator. In many domains, tests are injected to the verified system through the system's interface, but they are aimed at testing some of the system's internal components. Examples may include: -- Testing a function by stimulating the API of the library it is part of. The test-case doesn't call the function directly, but it calls other functions, which call other functions, which eventually call the tested function. -- Testing a part of the interconnect of a hardware system by initiating transactions from the components connected to that interconnect. To improve the quality of test-cases aimed at internal components of the verified system, a test generator would produce tests that stress the tested component. Such stress is achieved by generating tests that require the active participation of the tested component multiple times and in different scenarios. Typically, we would like the tested component to be used multiple times in parallel or in close time proximity. We describe a method for building test generators that have the ability to stress internal components. To date, different test-generators have had different ad-hoc means to improve the quality of the generated tests. We are not aware, however, of a fully-blown framework for achieving this purpose. [ We use to term transaction to denote the basic building block of a test-case. A test-case is therefore comprised of multiple transactions, each with its own characteristics. A transaction defines a set of inputs to the verified system's interface. ].

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

Page 1 of 2

A framework for testing internal components through knowledge of system structure

The invention is based on a function f that accepts as input:

An internal component of the system, c . A transaction T .

As output, f returns 'true' if T stimulates c , and false otherwise.

To stimulate the component c , a test generator generates multiple transactions, in close time proximity, that satisfy the function f . By doing so, it stresses the tested component, therefore increasing the quality of the test-case.

A test-generator that includes the invention accepts, as part of its inputs:

The structure of the verified system, including the set of its components, C . A function f , as described above. A user request, to stimulate the set of components D (D is a subset of C ). An integer w , that denotes the size of the sliding window aimed to stress components from different directions in close time proximity.

An integer n that denotes the total number of transactions to be generated in the test-case.

The test generator operates according to the given algorithm:

We define Q to be a queue of size w, each element of Q is a set of components. We define test_case to be a list of transactions

// * * * * * * * * * * * * * * * * * * * * * * * * * * *

Set Q to the empty queue Set test_case to the empty list

For i = 1 to n

current_window := union(all the set in Q)

if (current_window == empty_set)

current_window = D

End if

t := generate_transaction(f, current_window)

Append t to test_case

if (Q is full)

remove the set at the head of Q

End if

stimulated_components = calc_stimulated(D,f,t)

Add stimulated_components to the tail of Q End for

print "The generated test is: ", test_case

Page 2 of 2

// * * * * * * * * * * * * * * * * * * * * * * * * * * *

Subroutine generate_transaction(function f, set window)

Generate a transaction t such that:

There exist a component c in window, such...