Object-oriented Testing

processroguishSoftware and s/w Development

Nov 18, 2013 (3 years and 8 months ago)

56 views

Object
-
oriented
Testing

SIM3302

Objectives


To cover the strategies and tools
associated with object oriented testing


Analysis and Design Testing


Class Tests


Integration Tests


Validation Tests


System Tests

Object
-
oriented Testing


When should testing begin?


Analysis and Design:


Testing begins by evaluating the OOA and OOD models


How do we test OOA models (requirements and use cases)?


How do we test OOD models (class and sequence diagrams)?


Structured walk
-
throughs, prototypes


Formal reviews of correctness, completeness and consistency


Programming:


How does OO make testing different from procedural programming?


Concept of a ‘unit’ broadens due to class encapsulation


Integration focuses on
classes

and their context of a use case scenario

or their execution across a thread


Validation may still use conventional black box methods


Testing Analysis

and Design


Syntactic correctness:


Are UML and ADT notation used correctly?


Semantic correctness:


Does the model reflect the real world problem?


Is UML used as intended by its designers?


Is the ADT design complete (capturing all the classes and
operations in UML diagram) and understandable?


Testing for consistency:


An inconsistent model has representations in one part that are
not reflected in other portions of the model


Testing the Class Model

1.
Revisit the Use Cases, CRC cards and UML class model.

Check that all collaborations are properly represented.

Inspect the description of each CRC index card to make sure a
delegated responsibility is part of the collaborator’s definition.


Example: in a point of sale system.


A
read credit card

responsibility of a
credit sale

class is accomplished if
satisfied by a
credit card

collaborator

2.
Invert connections to ensure that each collaborator asked for a
service is receiving requests from a reasonable source


Example: a credit card being asked for a purchase amount


Have you tested your analysis and design?


If not, who will do it?


Testing OO Code

Class tests

System

tests

Integration

tests

Validation

tests

Object
-
oriented Testing
Strategies(1)


Unit Testing


Smallest testable unit is the encapsulated class or object


Test each operation as part of a class hierarchy

because its class hierarchy defines its context of use


Driven by class operations and state behavior, not algorithmic detail and data
flow across module interface


Approach:


Test each method (and constructor) within a class


Test the state behavior (attributes) of the class between methods


Complete test coverage of a class involves


Testing all operations


Setting and
interrogating

all object attributes


Exercising the object in all possible state


Test sequences are designed to ensure that relevant operations are exercised


State of the class is examined to determine if errors exist


Object
-
oriented Testing
Strategies(2)


Unit Testing …


How is class testing different from
conventional testing?


Conventional testing focuses on input
-
process
-
output,

whereas class testing focuses on each
method, then designing sequences of
methods to exercise states of a class


But white
-
box testing can still be applied

Object
-
oriented Testing
Strategies(3)


Integration Testing


OO does not have a hierarchical control structure so conventional top
-
down and bottom
-
up integration tests have little meaning


Focuses on
groups of classes

that collaborate in some manner


Integration of operations one at a time into a class is often meaningless


Because of direct and indirect interaction of components


Thread
-
based testing


Testing/integrate the set of classes required to respond to one input or event


Use
-
based testing (
integrates classes required by one use cas


Begins by testing independent classes that use very few of server classes


Next layer of classes (dependent classes) that use the independent classes are
tested next


Cluster testing


Groups of collaborating classes are tested for interaction errors


Regression testing is important as each thread, cluster or subsystem is
added to the system


Object
-
oriented Testing
Strategies(4)


Validation Testing


Are we building the right product?


Validation succeeds when software functions in a manner that
can be reasonably expected by the customer.


Focuses on visible user actions and user recognizable
outputs


Validation tests are based on the use
-
case scenarios, the
object behavior model, and the event flow diagram


Apply:


Use
-
case scenarios from the software requirements spec


Black
-
box testing to create a deficiency list


Acceptance tests through alpha (at developer’s site) and beta (at
customer’s site) testing with actual customers


Object
-
oriented Testing
Strategies(5)


Software may be part of a larger system. This often leads to “finger
pointing” by other system dev teams


Finger pointing defence:

1.
Design error
-
handling paths that test external information

2.
Conduct a series of tests that simulate bad data

3.
Record the results of tests to use as evidence


Types of System Testing:


Recovery testing: how well and quickly does the system recover from
faults


Security testing: verify that protection mechanisms built into the system
will protect from unauthorized access (hackers, disgruntled employees,
fraudsters)


Stress testing: place abnormal load on the system


Performance testing: investigate the run
-
time performance within the
context of an integrated system


Test Case Design(1)


Each test case should be uniquely identified and be explicitly
associated with a class to be tested


the purpose of the test should be stated


A list of testing steps should be developed for each test and
contains:


A list of specified states for the object that is to be tested


A list of messages and operations that will be exercised as a
consequence of the test


A list of exceptions that may occur as the object is tested


A list of external conditions needed to be changed for the test


Supplementary information required to understand or implement
the test


OO testing focuses on designing appropriate sequences of
operations

Testing Methods


at the Class Level(1)


Random Testing : requires large number of
data permutation and combination


Identify operations applicable to a class


Define constraints on their use


e.g. the class must always
be initialized first


Identify a minimum test sequence


an operation sequence
that defines the minimum life history of the class


Generate a variety of random test sequences


this
exercises more complex class instance life histories


Testing Methods


at the Class Level(2)


Example of Random Testing


1) consider an
account

class that has the
following operations:


open, setup, deposit, withdrawal, balance,
summarize, credit Limit, close



2)

The account must be opened first and closed
on completion

Testing Methods


at the Class Level(3)


Example of Random Testing


3) a variety of behaviors may occur:


open

setup

deposit

[
deposit

|
withdrawal

|
balance
|
summarize

|
credit

limit
]
n

withdrawal

close




4)

different operation sequences can be generated randomly:



test case #1:
open

setup

deposit

deposit


balance


summarize




withdrawal

close


test case #2:
open

setup

deposit

withdrawal


deposit


balance



credit limit

withdrawal

close

Testing Methods


at the Class Level(4)


Partition Testing : reduces the number of test cases required to test a
class (remember ECP)


Input and output are categorized


Deriving partitioning categories:


State
-
based partitioning


Categorizes class operations based on their ability to change the state
of the class


Tests designed in way so that operations that cause state changes are
tested separately from those that do not


Example:


Test case #sp1:
open

獥瑵p

摥d潳楴

摥d潳楴


w楴i摲慷慬


withdrawal

捬c獥


Test case #sp2:
open

獥瑵p

摥d潳楴

summarize

捲敤楴c汩浩l




withdrawal

c汯獥

Testing Methods


at the Class Level(5)


Deriving partitioning categories:


Attribute
-
based partitioning


Categorizes class operations based on the attributes that they use and
modify


Tests designed in way so that operations that use or modify attributes
are tested separately from those that do not use or modify attributes


Example:


for the
account class
, the attributes
balance

and
credit limit

can be used
to define operations. Operations are divided into three partitions:


1) operations that
use

credit limit


2)

operations that
modify

credit limit


3)

operations that do not use of modify

credit limit

Testing Methods


at the Class Level(6)


Deriving partitioning categories:


Category
-
based partitioning


Categorizes class operations based on the generic function that each
performs such as initialization, computation, query, termination


Example:


operations in the
account class

can be categorized as:


1) initialization
(open, setup)


2) computation
(deposit, withdraw)


3)

queries
(balance, summarize, credit limit)


4)

termination
(close)

Interclass

Test Case Design(1)


Test case design becomes more
complicated as integration of the OO
system begins


testing of collaboration
between classes


Refer to diagram

Interclass

Test Case Design(2)


Multiple class testing


For each client class, use the list of class operators to generate a
series of random test sequences that send messages to other
server classes


For each message generated, determine the collaborator class
and the corresponding operator in the server object


For each operator in the server object (invoked by a client object
message), determine the message that it transmits


For each of the message, determine the next level of operators
that are invoked and incorporate these into the test sequence.

Interclass

Test Case Design(3)


Multiple class testing : example

Consider a sequence of operations for the
bank

class relative to an
ATM

class:

verifyAcct

verifyPin

[[
verifyPolicy

withdrawReq
] |
depositReq

|
AcctInfoReq
]
n


A random test case for the bank class might be

Test case #r3:
verifyAcct

verifyPin


depositReq



The collaborators invoked for the above test case are
ValidationInfo

to execute
verifyAcct

and
verifyPin
. Collaborate with
Account

to execute
depositReq


Thus a new test case is

Test case #r4

:
verifyAcct
Bank
[
validAcct
ValidationInfo
]

verifyPin
Bank

[
ValidPin
ValidationInfo

depositR
eq

[
deposit
Account
]

Interclass

Test Case Design(4)


Test derived from behavior models


Use the state transition diagram as a model


Test cases must cover all states


Breadth first traversal of the state model can be used (test one transition
at a time and only make use of previously tested transitions when
testing a new transition


Testing Methods

Applicable at Interclass Level(1)


Cluster Testing


Concerned with
integrating and testing clusters

of cooperating
objects


Identify clusters
using knowledge of the operation of objects and
the system features

that are implemented by these clusters


Approaches to cluster testing


Use
-
case or scenario testing


Testing is based on a user interactions with the system


Has the advantage that it tests systems features as experienced by users


Thread testing



tests the systems response to events as processing
threads through the system


Object interaction testing



test sequences of object interactions that
stop when an object operation does not call on services from another
object


Testing Methods

Applicable at Interclass Level(2)


Use Case/Scenario
-
based Testing


Based on


Use cases


Corresponding sequence diagrams


Identify scenarios from use
-
case and supplement these with
interaction diagrams that show the objects involved in the
scenario


Concentrates on functional requirements


Every use case


Every fully expanded (<<extend>>) combination


Every fully expanded (<<uses>>) combination


Tests normal as well as exceptional behavior


OO Test Design Issues


White
-
box testing methods can be applied to testing the
code used to implement operations


Black
-
box testing methods are appropriate for testing
OO systems


OO programming brings additional testing concerns


Classes may contain operations that are inherited from
superclass


Subclasses may contain operations that were redefined rather
than inherited


All classes derived from a previously tested base class need to
be thoroughly tested.

Summary


One strategy is a bottom
-
up approach


class, integration, validation and system
level testing