Object Oriented Testing
Object Oriented Testing
Object Oriented Testing
246 305 568 783 742 492 514 482 330 172 82 59 31 10 2
No.
Of
Chains
It is very difficult to understand a given class
in a large OO program if that class depends
on many other classes
Without sufficient insight, a tester may not
know where to start in testing an OO library.
Extremely costly to construct stubs, tester
must understand called fcts, possibly create
and properly initialize certain objects, and
write code to simulate the behaviors and
effects of the called fcts.
Impossible to predict and equally impossible
to test, all possible uses of a template class
Difficult to identify and test the effect of
polymorphism and dynamic binding
Difficult to id change impact in OO
maintenance, since the impact may ripple
throughout the OO program through the
complex dependencies.
STATE BEHAVIOR TESTING
PROBLEM
Objects have states and state dependent behaviors.
So we need an object state diagram and generate
associated tests.
Effect of an operation on an object depends of the
state of the object and may change the state of the
object. Thus the combined effect of the
operations must be tested.
OO state behavior testing can be specification
based or program based. Documentation is either
missing or poor - use a program based approach.
Derive from the source code the state-
dependent behaviors of the objects and
represent this info in an OSD; generate test
cases and test data from the OSD to test the
program and observe the output.
THE TOOL SUPPORT
PROBLEM
CASE tools still in infancy that support OO testing;
sw testing tedious - preparation, execution, analysis
of tens of thousands of cases and test data sets.
could use a spec based approach; derived from
specs; required formal specs so tool can derive test
cases - depends on level of detail of formal spec -
observation of authors formal specs rarely used ( at
least in this country)
tester must manually prepare; does need extensive
tool support
OOTM ENVIRONMENT
math defined test model with three diagrams:
– 1) object relation diagram - std stuff of oo model
– 2) block branch diagram - shows control structure
of a member fct; interfaces to other member fcts;
therefore tester knows which data is used and/or
updated and which other fcts are invoked by the
member fct. BBD diagram helps prepare fct test
cases, structural test cases, test harnesses in
member fct unit testing, derive data dependence
across multiple fcts and objects; and display
statement, branch, and path coverage information.
3) OSD - object state diagram similar to
Statechart - show state behavior of an
object; reduce complexity for each state-
dependent data member of a class; so state
behavior of class is aggregate of the data
members’ state machines so have hierarchy
of state machines -
remember - what does a hierarchy do for
us?
· For maintenance in fixing errors: The
firewall tool automatically identifies changes
and computes the affected classes; displays
the test order for retesting the affected
classes.
So firewall tool used in two different ways:
– before making actual changes to id impact of
changes; estimate effort in terms of test stubs
and test cases needed to retest the affected
classes
– after making changes, a regression tester can
use the tool to identify the actual changes and
their impact. also compute the optimal test
order to retest the affected classes.
OOTM OSD consists of hierarchical,
concurrent, communicating state machines.
Supports inheritance and aggregation
features; concurrent because objects viewed
as concurrent processes and communicating
because objects can send and receive
messages from each other.