?


  
 


|
 ?

  



  

‡ 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

|
 ¦


  ?


  


‡ Implications of inheritance
± New context of usage
± Multiple Inheritance
± True specialization -- reuse of test cases
± Programming convenience -- must test subclasses and
superclasses

|
 ¦


  ?


  


‡ 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

|
 ¦


  ?


  


‡ 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.

|
 ¦


  ?


  


‡ 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

|
 ? 
 ?

     
 
?


 
 ¦ ?


  
 !?


 

|
 !?


‡ 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.

|
  
"  ?
 


#!?

‡ Statement coverage
‡ Graph based
± Branch coverage
± Condition coverage
± Path coverage
‡ All unit testing methods are also applicable to
testing methods within a class.

|
 ¦ ?


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

|
 
 
?

‡ 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
|
 ? ?

!
 


!
 
?



 %¦ &?




$ 





?


  
   ?


    

|
   ?


‡ Tests each individual method

‡ Performed by the programmer
‡ Glass box using method code
± Statement Coverage
± Decision Coverage
± Path Coverage

|
 

?


‡ 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

|
 

?


  '
(((())
(((()

  *
(((())
(((()

  +
(((())
(((()

|
 

,
 
   

‡ 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.

|
 Π
 

 
 -- 

¦   

 
 --   
 -- 

|
  
?
 



‡ 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.
|
 

?
?


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

|
  ?
?

‡ A state-transition model describes the different
states and transitions of a class in the context of its
position in the inheritance hierarchy.
r

 
‡ The  of an object is the combination of all the
attribute values and objects that the object
contains.
‡ An object may    from a state to state as a
result of an , which may yield an 
 
|
 Π



 
/ 
   

Œ

  


0 
/ 


/ 



     .   

/ 



|
  ?
?


‡ Create test cases corresponding to each transition

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

|
 
 %¦ &?

‡ 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
|
 
 %¦ &?


  
‡ 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

|
 ?
Œ
# 
¦ ?

‡ 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

|
 ?
Œ
# 
¦ ?
%
)&
‡ 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

|
  
# 
 

‡ 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
|
 ?


  
¦ ?


‡ Message Quiescence
‡ Event Quiescence

|
 

 1



‡ 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  

.

|
 
2 34

+

'

  *
  '

  '
  *
  +

*

  '

  +

  *

|
 

+

'

  *
  '

  '
  *
  +

*

  '

  +

  *

|
 Œ/ 1



‡ An MM Path is triggered by a   

and end with a   

‡ 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


 r
|
 

 #

¦ / %& 
+
 / %&

'

  *
  '
'
  '
  *
  +

*

  '  / %5&

*
  +
¦ / %5& +

  *

|
 
 ?


‡ 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.
|
  !
 


‡ 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
|
 Π
Use Case # 1 of the   :
Task: Making a balance transfer
User Class: Current customer
Frequency: one per week per customer


   

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#

|
 
?
 



   

|
 Π


 

 
 ?

‡ 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
|
 Π


 

 
 ?
 % )&
‡ State-Transition Models
± State transition diagrams for classes, clusters, and
subsystems
‡ Object network
± Message sequence between methods in classes
‡ Transaction-Flow Models

|
 ?
 

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

|
  ?



‡ 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
|
 


‡ 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.
|