object, including its construction, state changes, and
destruction. Object state testing involves five important
issues: 1) constructing a suitable object state test
model, 2) verifying a test model, 3) selecting object
state test strategies, 4) defining and selecting object
state test criteria, and 5) generating test cases.
This paper proposes an object state test model,
called the object state diagram (OSD), to capture
state-dependent behavior of the objects in an 00 program.
We then present a method to construct an OSD
for a class object based on its design specification. U 5
ing the OSD as our object test model, test strategies
and test criteria are discussed. In addition, different
test generation methods are also described. Unlike the
&sting object models in OOA and OOD, the OSD
model is defined for testing rather than modeling in
mind. It is defined to facilitate a tester to understand
the state-dependent behavior of different parts in an
object class, to generate state test cases, and to evaluate
the test results.
The organization of this paper is as follows. Section
2 briefly reviews the existing work in traditional state
testing, and discusses new issues in object state testing.
Section 3 introduces our state test model OSD.
Section 4 briefly discusses the construction of an OSD
fiom a class specification. Section 5 is devoted to OSD
testing, including OSD test criteria. Then test strate
gies and test generation methods are illustrated in section
6. Finally, conclusions and future work are presented.
2 Related Work
In the past two decades, finite state machines
(FSM) have been used as test models to verify the
behavior of traditional software[l][lO]. Tsun S. Chow
in [lo] proposed a distinguished approach to testing
the behavior of a program. In his approach, a finite
state machine is used to model the program execution
process in terms of stimuli and operations. Stimuli is
input from the outside world and operations are exe