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


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


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




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




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



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


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


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


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


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


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


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


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


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


Class Testing

Method 1:

..

.

Method 2:

..

.

Method 3:

..

.

8/7/2019 9904 - OO Testing Part 2

16/42


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


Example

Patient

In-patient Out-patient

Register_a_patient

Register_out_patientRegister_in_patient

8/7/2019 9904 - OO Testing Part 2

18/42


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


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


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


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


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


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


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


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


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


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


Techniques for Object-Oriented

Integration Testing

Message Quiesc

enc

e Event Quiescence

8/7/2019 9904 - OO Testing Part 2

29/42


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


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


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


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


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


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


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


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


Static Testing and Analysis of

Object-Oriented Models

8/7/2019 9904 - OO Testing Part 2

38/42


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


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


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


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


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.

9904 - oo testing part 2

Documents