Testing Object-Oriented Systems:

Part 2

Dr. Magdy S. Hanna

International Institute for Software Testing

Software Dimensions
University of St. Thomas

(651)306-1387, [email protected]

S
DSoftware Dimensions, 1998 www.softdim.com OOTest-1
 Testing Object-Oriented Applications:
Why is it Different?

• No sequential procedural executions

• No functional decomposition
• No structure charts to design integration testing
• Iterative O-O development and its impact on
testing and integration strategies

S
DSoftware Dimensions, 1998 www.softdim.com OOTest-2
 Issues Related to Testing
Object-Oriented Applications
• Implications of inheritance
– New context of usage
– Multiple Inheritance
– True specialization -- reuse of test cases
– Programming convenience -- must test subclasses and
superclasses

S
DSoftware Dimensions, 1998 www.softdim.com OOTest-3
 Issues Related to Testing
Object-Oriented Applications

• Implications of encapsulation
– Makes reporting on state difficult
– Correctness proof may help but difficult
• Implications of Polymorphism
– Each possible binding requires separate test
– Makes integration more difficult

S
DSoftware Dimensions, 1998 www.softdim.com OOTest-4
 Issues Related to Testing
Object-Oriented Applications
• White-box testing
– Appropriate only for methods not for classes
– Control graph testing is not applicable to methods
• Black-box testing
– Applicable to classes
– The distance between OO specification and
implementation is small compared to conventional
systems.

S
DSoftware Dimensions, 1998 www.softdim.com OOTest-5
 Issues Related to Testing
Object-Oriented Applications
• Integration strategy
– Thread-based: All classes needed to respond to certain
external input
– Uses-based: Starts with classes that do not use other
classes; then continue with classes that use the first
group and so on.
• Test process strategy
– Design a little, code a little, and test a little cycle

S
DSoftware Dimensions, 1998 www.softdim.com OOTest-6
 The Structured Testing Pyramid
Requirement Definition Systems Testing

Preliminary Design Integration Testing

Detailed Design Unit Testing

Coding

S
DSoftware Dimensions, 1998 www.softdim.com OOTest-7
 Unit Test

• What is a unit?
– A single, cohesive function?
– A function whose code fits on one page?
– The amount of code that can be written in 4 to 40
hours?
– Code that is assigned to one person?
• In object-oriented programs, a unit is a method
within a class.

S
DSoftware Dimensions, 1998 www.softdim.com OOTest-8
 Methods for Generating Test Cases
For Unit Testing
• Statement coverage
• Graph based
– Branch coverage
– Condition coverage
– Path coverage
• All unit testing methods are also applicable to
testing methods within a class.

S
DSoftware Dimensions, 1998 www.softdim.com OOTest-9
 Integration Testing

• Strategies:
– Bottom-up guided by functional decomposition tree
– Top-down guided by functional decomposition tree
– Big bang
– Pairwise
• All focus on structure and interface

S
DSoftware Dimensions, 1998 www.softdim.com OOTest-10
 Systems Testing
• Performed exclusively in terms of inputs and
outputs of the system
• Performed mostly on the target platform
• Thread-based:
– The behavior that results from a system level input
– An interleaved sequence of system inputs (stimuli) and
outputs (responses)
– A sequence of transitions in a state machine model of
the system
S
DSoftware Dimensions, 1998 www.softdim.com OOTest-11
 The OO Testing Pyramid
Use Case Analysis Use Case Testing

Cluster (Integration) Testing

Class Hierarchy Design

Class Testing

Method Design Method Testing

Method Coding

S
DSoftware Dimensions, 1998 www.softdim.com OOTest-12
 Method Testing

• Tests each individual method

• Performed by the programmer
• Glass box using method code
– Statement Coverage
– Decision Coverage
– Path Coverage

S
DSoftware Dimensions, 1998 www.softdim.com OOTest-13
 Class Testing

• Tests All private and publics methods in a class

• Test accessor methods before creator methods to
control complexity
• Class testing is a first level of integration testing
• Mainly black-box testing based on class behavior
• Must use stubs and drivers to substitute for
methods

S
DSoftware Dimensions, 1998 www.softdim.com OOTest-14
 Class Testing

Method 1:
…………..
………….

Method 2:
…………..
………….

Method 3:
…………..
………….

S
DSoftware Dimensions, 1998 www.softdim.com OOTest-15
 Abstract Vs Concrete Classes

• Abstract classes are those that can not be instantiated

• They can’t be tested directly but as part of testing
concrete classes.
• Write test cases for abstract classes separately but
run them as part of testing their concrete subclasses.
• Reuse test cases with different concrete subclasses.

S
DSoftware Dimensions, 1998 www.softdim.com OOTest-16
 Example
Patient

Register_a_patient

In-patient Out-patient

Register_in_patient Register_out_patient

S
DSoftware Dimensions, 1998 www.softdim.com OOTest-17
 What Methods to Test Within Classes
• New methods: defined in the class under test and
not inherited or overloaded by methods in a
superclass: Complete testing
• Inherited methods: defined in a superclass of the
class under test: Retest only if the methods
interacts with new or redefined method.
• Redefined methods: defined in a superclass of but
redefined in the class under test : complete
Retest reusing tests from the superclass.
S
DSoftware Dimensions, 1998 www.softdim.com OOTest-18
 Class Testing Techniques

In addition to testing methods within a class

(either glass box or black box), the following three
techniques can be used to perform functional
testing for the class:
– State-Transition testing
– Transaction-Flow testing
– Exception testing

S
DSoftware Dimensions, 1998 www.softdim.com OOTest-19
 State-Transition Testing
• A state-transition model describes the different
states and transitions of a class in the context of its
position in the inheritance hierarchy.
(OMT dynamic model)
• The state of an object is the combination of all the
attribute values and objects that the object contains.
• An object may transition from a state to state as a
result of an event, which may yield an action.

S
DSoftware Dimensions, 1998 www.softdim.com OOTest-20
 Example

Prospect Receive application Member

Establish-membership

5-years anniversary
Receive cancellation

Retired-member Life-member
Receive cancellation

S
DSoftware Dimensions, 1998 www.softdim.com OOTest-21
 State-Transition Testing

• Create test cases corresponding to each transition

path that represent a full object life cycle
• Make sure each transition is exercised at least
once.

S
DSoftware Dimensions, 1998 www.softdim.com OOTest-22
 Cluster (Integration) Testing
• A cluster is a collection of classes (possibly from different
systems) cooperating with each other via messaging.
• A cluster specification should include methods from each
class that will be accessed
• Cluster testing focuses on the interaction among the
instances of the classes in the cluster
• It assumes that each class has been tested individually
• Cluster testing is considered a second level of integration
testing

S
DSoftware Dimensions, 1998 www.softdim.com OOTest-23
 Cluster (Integration) Testing:
Why is it Different?
• Event-Driven execution
• No functional decomposition
• The sequence of execution is not known
• Integration testing must be driven by how object
will behave dynamically
• Object composition introduces a new dimension of
integration testing

S
DSoftware Dimensions, 1998 www.softdim.com OOTest-24
 Types of Errors Found During
Integration Testing
• Messaging errors:
– Failure to meet a requirement, i.e., no method to send
or receive a message
– Incompatible method and message in sender and
receiver
– Incorrect event timing between object actions
– Incorrect instantiation or destruction of objects

S
DSoftware Dimensions, 1998 www.softdim.com OOTest-25
 Types of Errors Found During
Integration Testing (cont.)
• User interface errors:
– A given sequence of user actions does not have the
expected effect on the component.
– The timing of events received from the user results in
incorrect functioning of the component

S
DSoftware Dimensions, 1998 www.softdim.com OOTest-26
 Methods for Forming Clusters

• Function-based clustering
– Based on requirements and use cases
– Difficult to perform if requirements were not available
during the design phase
• Subject-based clustering
– Based on subject areas that need to test separately
• Project Schedule-based clustering
• Contract-based clustering
S
DSoftware Dimensions, 1998 www.softdim.com OOTest-27
 Techniques for Object-Oriented
Integration Testing

• Message Quiescence
• Event Quiescence

S
DSoftware Dimensions, 1998 www.softdim.com OOTest-28
 Message Quiescence

• A method is a single unit of code that performs a

single cohesive function.
• A Method/Message path (MM-Path) is a sequence
of method executions linked by messages.
• An MM-Path starts with a method and ends when
it reaches a method that does not issue a message
of its own, i.e., reaches a message Quiescence.

S
DSoftware Dimensions, 1998 www.softdim.com OOTest-29
 An Object Network
Object 3
Object 1

Method 2
Method 1

Method 1
Method 2
Method 3
Object 2

Method 1

Method 3

Method 2

S
DSoftware Dimensions, 1998 www.softdim.com OOTest-30
 MM-Paths Object 3
Object 1

Method 2
Method 1

Method 1
Method 2
Method 3
Object 2

Method 1

Method 3

Method 2

S
DSoftware Dimensions, 1998 www.softdim.com OOTest-31
 Event Quiescence
• An MM Path is triggered by a system-level port
input event and end with a system-level port output
event
• When this port output event is reached, the system
becomes quiescent and waits for another port
event
• An input port event followed by a set of MM-
Paths, and terminated by an output event is called
Atomic System Function (ASF).
S
DSoftware Dimensions, 1998 www.softdim.com OOTest-32
 Atomic System Function
Input port event (A) Object 3
Output port event (A)
Object 1

Method 2
Method 1
1
Method 1
Method 2
Method 3
Object 2

Method 1 Output port event (B)

2
Method 3
Input port event (B) 3

Method 2

S
DSoftware Dimensions, 1998 www.softdim.com OOTest-33
 System Testing

• All rules and methods of traditional systems

testing are also applicable applicable to object-
oriented.
• A thread can be “re-defined” as a sequence of
method executions linked by messages in the
object network.
• Use cases provide a more precise mechanism for
writing test cases.
S
DSoftware Dimensions, 1998 www.softdim.com OOTest-34
 What Are Use Cases
• A Use Case describes a scenario in which a user
interacts with the system to accomplish a particular task.
• Each Use Case specifies:
– The task to be performed
– The user class
– Different actions and corresponding system responses
– Estimated frequency of use
• Very useful for deriving test cases early in the
requirement phase

S
DSoftware Dimensions, 1998 www.softdim.com OOTest-35
 Example
Use Case # 1 of the Telephone Banking System:
Task: Making a balance transfer
User Class: Current customer
Frequency: one per week per customer

User Action System Response

User dials the number System plays greeting and ask for account number

User enters invalid account number System informs user and ask for account number
again

User enter a valid account number System asks for PIN#

S
DSoftware Dimensions, 1998 www.softdim.com OOTest-36
 Static Testing and Analysis of
Object-Oriented Models

S
DSoftware Dimensions, 1998 www.softdim.com OOTest-37
 Examples of Analysis and Design
Models to be Tested
• CRC cards
– English text descriptions of a single class, its
responsibilities, and it collaborators with other classes
• Class specifications
– Complete specification of a class including its data
structure, method names, number and type of
parameters, return values, pre- and post-conditions.
• Use cases
– A representation of the systems usage
S
DSoftware Dimensions, 1998 www.softdim.com OOTest-38
 Examples of Analysis and Design
Models to be Tested (Cont.)
• State-Transition Models
– State transition diagrams for classes, clusters, and
subsystems
• Object network
– Message sequence between methods in classes
• Transaction-Flow Models

S
DSoftware Dimensions, 1998 www.softdim.com OOTest-39
 Testing Models

• Criteria
– Correctness
– Completeness
– Consistency
• Early informal models are tested informally
• The criteria should be interpretive in the context of
iterative incremental approach

S
DSoftware Dimensions, 1998 www.softdim.com OOTest-40
 Model Testing Approaches

• Testing by comparison
– compares each model to its predecessor or to previous
forms of the model
• Testing by inspection
– uses checklists to make sure that the model meets
certain criteria
• Testing by verification
– follows certain steps to assure completeness and
consistency of one part of the model with another
S
DSoftware Dimensions, 1998 www.softdim.com OOTest-41
 Conclusion
• The OO is not always the best approach to system
development.
• Claimed benefits of the OO approach can only be
obtained through:
– Robust development process
– Good development practices by individuals
– Automated tools
• The OO approach introduces substantial
difficulties to the testing process.
S
DSoftware Dimensions, 1998 www.softdim.com OOTest-42