Download - 9904 - OO Testing Part 2
-
8/7/2019 9904 - OO Testing Part 2
1/42
SOFTWARE DIMENSIONS, 1998www.softdim.com OOTest-1S D
Dr. Magdy S. Hanna
International Institute for Software Testing
Software Dimensions
University of St. Thomas
(651)306-1387, [email protected]
Testing Object-Oriented Systems:Part 2
-
8/7/2019 9904 - OO Testing Part 2
2/42
SOFTWARE DIMENSIONS, 1998www.softdim.com OOTest-2S D
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
-
8/7/2019 9904 - OO Testing Part 2
3/42
SOFTWARE DIMENSIONS, 1998www.softdim.com OOTest-3S D
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
-
8/7/2019 9904 - OO Testing Part 2
4/42
SOFTWARE DIMENSIONS, 1998www.softdim.com OOTest-4S D
Issues Related to Testing
Object-Oriented Applications
Implications of encapsulation
Makes reporting on state difficult
Correctness proofmay help but difficult
Implications of Polymorphism
Each
po
ssible binding requires separate test Makes integration more difficult
-
8/7/2019 9904 - OO Testing Part 2
5/42
SOFTWARE DIMENSIONS, 1998www.softdim.com OOTest-5S D
Issues Related to Testing
Object-Oriented Applications
White-box testing
Appropriate only formethods not forclasses
Control graph testing is not applicable tomethods
Black-box testing
Applicable toclasses
The distance between OO specification and
implementation is small compared toconventional
systems.
-
8/7/2019 9904 - OO Testing Part 2
6/42
SOFTWARE DIMENSIONS, 1998www.softdim.com OOTest-6 S D
Issues Related to Testing
Object-Oriented Applications
Integration strategy
Thread-based: All classes needed to respond tocertainexternal input
Uses-based: Starts withclasses that do not use other
classes; then continue withclasses that use the first
group and soon.
Test process strategy
Design a little, code a little, and test a little cycle
-
8/7/2019 9904 - OO Testing Part 2
7/42
SOFTWARE DIMENSIONS, 1998www.softdim.com OOTest-7 S D
Requirement Definition
Preliminary Design
Detailed Design
Coding
Integration Testing
Unit Testing
Systems Testing
The Structured Testing Pyramid
-
8/7/2019 9904 - OO Testing Part 2
8/42
SOFTWARE DIMENSIONS, 1998www.softdim.com OOTest-8S D
Unit Test
What is a unit?
A single, cohesive function? A function whose code fits on one page?
The amount ofcode that can be written in 4 to 40
hours?
Code that is assigned toone person? In object-oriented programs, a unit is a method
within a class.
-
8/7/2019 9904 - OO Testing Part 2
9/42
SOFTWARE DIMENSIONS, 1998www.softdim.com OOTest-9S D
Methods for Generating Test Cases
For Unit Testing
Statement coverage
Graph based Branchcoverage
Condition coverage
Pathcoverage
All unit testing methods are also applicable to
testing methods within a class.
-
8/7/2019 9904 - OO Testing Part 2
10/42
SOFTWARE DIMENSIONS, 1998www.softdim.com OOTest-10S D
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
-
8/7/2019 9904 - OO Testing Part 2
11/42
SOFTWARE DIMENSIONS, 1998www.softdim.com OOTest-11S D
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) andoutputs (responses)
A sequence of transitions in a state machine model of
the system
-
8/7/2019 9904 - OO Testing Part 2
12/42
SOFTWARE DIMENSIONS, 1998www.softdim.com OOTest-12S D
Use Case Analysis
Class Hierarchy Design
Method Design
Method Coding
Cluster (Integration) Testing
Method Testing
Use Case Testing
Class Testing
The OO Testing Pyramid
-
8/7/2019 9904 - OO Testing Part 2
13/42
SOFTWARE DIMENSIONS, 1998www.softdim.com OOTest-13S D
Method Testing
Tests each individual method
Performed by the programmer Glass box using method code
Statement Coverage
Decision Coverage
Path Coverage
-
8/7/2019 9904 - OO Testing Part 2
14/42
SOFTWARE DIMENSIONS, 1998www.softdim.com OOTest-14S D
Class Testing
Tests All private and publics methods in a class
Test accessormethods before creatormethods tocontrol 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
-
8/7/2019 9904 - OO Testing Part 2
15/42
SOFTWARE DIMENSIONS, 1998www.softdim.com OOTest-15S D
Class Testing
Method 1:
..
.
Method 2:
..
.
Method 3:
..
.
-
8/7/2019 9904 - OO Testing Part 2
16/42
SOFTWARE DIMENSIONS, 1998www.softdim.com OOTest-16 S D
Abstract Vs Concrete Classes
Abstract classes are those that can not be instantiated
They cant be tested directly but as part of testingconcrete classes.
Write test cases for abstract classes separately but
run them as part of testing theirconcrete subclasses.
Reuse test cases with different concrete subclasses.
-
8/7/2019 9904 - OO Testing Part 2
17/42
SOFTWARE DIMENSIONS, 1998www.softdim.com OOTest-17 S D
Example
Patient
In-patient Out-patient
Register_a_patient
Register_out_patientRegister_in_patient
-
8/7/2019 9904 - OO Testing Part 2
18/42
SOFTWARE DIMENSIONS, 1998www.softdim.com OOTest-18S D
WhatM
ethods to Test Within Classes New methods: defined in the class under test and
not inherited oroverloaded by methods in a
superclass: C
omplete 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 butredefined in the class under test : complete
Retest reusing tests from the superclass.
-
8/7/2019 9904 - OO Testing Part 2
19/42
SOFTWARE DIMENSIONS, 1998www.softdim.com OOTest-19S D
Class Testing Techniques
In addition to testing methods within a class
(eith
er glass bo
xo
r black b
ox), t
he f
oll
owing t
hree
techniques can be used to perform functional
testing for the class:
State-Transition testing
Transaction-Flow testing Exception testing
-
8/7/2019 9904 - OO Testing Part 2
20/42
SOFTWARE DIMENSIONS, 1998www.softdim.com OOTest-20S D
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, whichmay yield an action.
-
8/7/2019 9904 - OO Testing Part 2
21/42
SOFTWARE DIMENSIONS, 1998www.softdim.com OOTest-21S D
Example
Prospect
Retired-member Life-member
MemberReceive application
Establish-membership
Receive cancellation
Receive cancellation5-years anniversary
-
8/7/2019 9904 - OO Testing Part 2
22/42
SOFTWARE DIMENSIONS, 1998www.softdim.com OOTest-22S D
State-Transition Testing
Create test cases corresponding to each transition
path
th
at represent a fullo
bject life
cy
cle
Make sure each transition is exercised at least
once.
-
8/7/2019 9904 - OO Testing Part 2
23/42
SOFTWARE DIMENSIONS, 1998www.softdim.com OOTest-23S D
Cluster (Integration) Testing
A cluster is a collection ofclasses (possibly from
different systems) cooperating with eachother via
messaging.
A cluster specification should include methods fromeachclass that will be accessed
Cluster testing focuses on the interaction among the
instances of the classes in the cluster
It assumes that eachclass has been tested individually
Cluster testing is considered a second level of
integration testing
-
8/7/2019 9904 - OO Testing Part 2
24/42
SOFTWARE DIMENSIONS, 1998www.softdim.com OOTest-24S D
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
-
8/7/2019 9904 - OO Testing Part 2
25/42
SOFTWARE DIMENSIONS, 1998www.softdim.com OOTest-25S D
Types ofErrors Found During
Integration Testing
Messaging errors:
Failure tomeet a requirement, i.e., nomethod to sendor receive a message
Incompatible method and message in sender and
receiver
Incorrect event timing between object actions
Incorrect instantiation or destruction ofobjects
-
8/7/2019 9904 - OO Testing Part 2
26/42
SOFTWARE DIMENSIONS, 1998www.softdim.com OOTest-26 S D
Types ofErrors Found During
Integration Testing (cont.)
User interface errors:
A given sequence of user actions does not have theexpected effect on the component.
The timing of events received from the user results in
incorrect functioning of the component
-
8/7/2019 9904 - OO Testing Part 2
27/42
SOFTWARE DIMENSIONS, 1998www.softdim.com OOTest-27 S D
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
-
8/7/2019 9904 - OO Testing Part 2
28/42
SOFTWARE DIMENSIONS, 1998www.softdim.com OOTest-28S D
Techniques for Object-Oriented
Integration Testing
Message Quiesc
enc
e Event Quiescence
-
8/7/2019 9904 - OO Testing Part 2
29/42
SOFTWARE DIMENSIONS, 1998www.softdim.com OOTest-29S D
Message Quiescence
A method is a single unit ofcode that performs a
singlecoh
esive functi
on.
A Method/Message path (MM-Path) is a sequence
ofmethod executions linked by messages.
An MM-Path starts with a method and ends when
it reaches a method that does not issue a messageof its own, i.e., reaches a message Quiescence.
-
8/7/2019 9904 - OO Testing Part 2
30/42
SOFTWARE DIMENSIONS, 1998www.softdim.com OOTest-30S D
Object 1
Object 2
Object 3
Method 1
Method 2
Method 3
Method 1
Method 2
Method 1
Method 2
Method 3
An Object Network
-
8/7/2019 9904 - OO Testing Part 2
31/42
SOFTWARE DIMENSIONS, 1998www.softdim.com OOTest-31S D
Object 1
Object 2
Object 3
Method 1
Method 2
Method 3
Method 1
Method 2
Method 1
Method 2
Method 3
MM-Paths
-
8/7/2019 9904 - OO Testing Part 2
32/42
SOFTWARE DIMENSIONS, 1998www.softdim.com OOTest-32S D
Event Quiescence
An MM Path is triggered by a system-level port
input eventand 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).
-
8/7/2019 9904 - OO Testing Part 2
33/42
SOFTWARE DIMENSIONS, 1998www.softdim.com OOTest-33S D
Object 1
Object 2
Object 3
Method 1
Method 2
Method 3
Method 1
Method 2
Method 1
Method 2
Method 3
Atomic System Function
1
2
3
Input port event (A)
Output port event (A)
Input port event (B)
Output port event (B)
-
8/7/2019 9904 - OO Testing Part 2
34/42
SOFTWARE DIMENSIONS, 1998www.softdim.com OOTest-34S D
System Testing
All rules and methods of traditional systems
testing are also
applicable appli
cable t
oo
bject-
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.
-
8/7/2019 9904 - OO Testing Part 2
35/42
SOFTWARE DIMENSIONS, 1998www.softdim.com OOTest-35S D
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 userclass
Different actions and corresponding system responses
Estimated frequency of use
Very useful for deriving test cases early in the
requirement phase
-
8/7/2019 9904 - OO Testing Part 2
36/42
SOFTWARE DIMENSIONS, 1998www.softdim.com OOTest-36 S D
Example
Use Case # 1 of the Telephone Banking System:
Task: Making a balance transfer
User Class: Current customer
Frequency: one per week percustomer
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#
-
8/7/2019 9904 - OO Testing Part 2
37/42
SOFTWARE DIMENSIONS, 1998www.softdim.com OOTest-37 S D
Static Testing and Analysis of
Object-Oriented Models
-
8/7/2019 9904 - OO Testing Part 2
38/42
SOFTWARE DIMENSIONS, 1998www.softdim.com OOTest-38S D
Examples of Analysis and Design
Models to be Tested
CRC cards
English text descriptions of a single class, its
responsibilities, and it collaborators withotherclasses
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
-
8/7/2019 9904 - OO Testing Part 2
39/42
SOFTWARE DIMENSIONS, 1998www.softdim.com OOTest-39S D
Examples of Analysis and Design
Models to be Tested (Cont.)
State-Transition Models
State transitio
n diagram
s fo
rclasses,
clusters, andsubsystems
Object network
Message sequence between methods in classes
Transaction-Flow Models
-
8/7/2019 9904 - OO Testing Part 2
40/42
SOFTWARE DIMENSIONS, 1998www.softdim.com OOTest-40S D
TestingModels
Criteria
Co
rrectness
Completeness
Consistency
Early informal models are tested informally
The criteria should be interpretive in the context ofiterative incremental approach
-
8/7/2019 9904 - OO Testing Part 2
41/42
SOFTWARE DIMENSIONS, 1998www.softdim.com OOTest-41S D
Model Testing Approaches
Testing by comparison
com
pares each
mo
del to
its predecess
or
or t
oprevi
ousforms of the model
Testing by inspection
uses checklists tomake sure that the model meets
certain
criteria
Testing by verification
follows certain steps to assure completeness and
consistency ofone part of the model with another
-
8/7/2019 9904 - OO Testing Part 2
42/42
SOFTWARE DIMENSIONS, 1998www.softdim.com OOTest-42S D
Conclusion The OO is not always the best approach to system
development.
Claimed benefits of the OO approachcan only beobtained through:
Robust development process
Good development practices by individuals
Automated tools
The OO approach introduces substantial
difficulties to the testing process.