Issues in OO Testing1

8/8/2019 Issues in OO Testing1

1/42

SD

Testing Object-Oriented Systems:


2/42


3/42

SD

I ssues Related to TestingObject-Oriented Applications

Implications of inheritance New context of usage

Multiple Inheritance True specialization -- reuse of test cases Programming convenience -- must test subclasses and

superclasses


4/42

SD


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


5/42

SD


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


6/42

SD


Integration strategy

Thread-based: All classes needed to respond to certainexternal input

Uses-based: Starts with classes that do not use other classes; then continue with classes that use the firstgroup and so on.

Test process strategy Design a little, code a little, and test a little cycle


7/42

SD

Requirement Definition

Preliminary Design

Detailed Design

Coding

I ntegration Testing

Unit Testing

Systems Testing

The Structured Testing Pyramid


8/42

SD

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 methodwithin a class.


9/42

SD

M ethods for Generating Test CasesFor Unit Testing

Statement coverage

Graph based Branch coverage Condition coverage Path coverage

All unit testing methods are also applicable totesting methods within a class.


10/42

SD

I ntegration 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


11/42

SD

Systems Testing

Performed exclusively in terms of inputs andoutputs of the systemPerformed mostly on the target platformThread-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


12/42

SD

Use Case Analysis

Class Hierarchy Design

M ethod Design

M ethod Coding

Cluster ( I ntegration) Testing

M ethod Testing

Use Case Testing

Class Testing

The OO Testing Pyramid


13/42

SD

M ethod Testing

Tests each individual method

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


14/42

SD

Class Testing

Tests All private and publics methods in a class

Test accessor methods before creator methods tocontrol complexityClass testing is a first level of integration testingMainly black-box testing based on class behavior Must use stubs and drivers to substitute for methods


15/42

SD

Class Testing

M ethod 1:..

.M ethod 2:...

Method 3:..

.


16/42

SD

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 butrun them as part of testing their concrete subclasses.Reuse test cases with different concrete subclasses.


17/42

SD

Ex ample

Patient

I n-patient Out-patient

Register_a_patient

Register_out_patientRegister_in_patient


18/42

SD

WhatM

ethods to Test Within ClassesNew methods: defined in the class under test andnot inherited or overloaded by methods in a

superclass: Complete testingInherited methods: defined in a superclass of theclass under test: Retest only if the methodsinteracts with new or redefined method.

Redefined methods: defined in a superclass of butredefined in the class under test : completeRetest reusing tests from the superclass.


19/42

SD

Class Testing Techniques

In addition to testing methods within a class

(either glass box or black box), the following threetechniques can be used to perform functionaltesting for the class: State-Transition testing

Transaction-Flow testing Exception testing


20/42

SD

State-Transition TestingA state-transition model describes the differentstates 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 theattribute values and objects that the objectcontains.An object may transition from a state to state as aresult of an event , which may yield an action.


21/42

SD

Ex ample

Prospect

Retired-member Life-member

M emberReceive application

E stablish-membership

Receive cancellation

Receive cancellation5-years anniversary


22/42

SD

State-Transition Testing

Create test cases corresponding to each transition

path that represent a full object life cycleMake sure each transition is exercised at leastonce.


23/42

SD

Cluster ( I ntegration) TestingA cluster is a collection of classes (possibly fromdifferent systems) cooperating with each other viamessaging.

A cluster specification should include methods fromeach class that will be accessedCluster testing focuses on the interaction among theinstances of the classes in the cluster It assumes that each class has been tested individuallyCluster testing is considered a second level of integration testing


24/42

SD

Cluster ( I ntegration) Testing:Why is it Different?

Event-Driven execution

No functional decompositionThe sequence of execution is not knownIntegration testing must be driven by how objectwill behave dynamicallyObject composition introduces a new dimension of integration testing


25/42

SD

Types of E rrors Found DuringI ntegration Testing

Messaging errors:

Failure to meet a requirement, i.e., no method to sendor receive a message Incompatible method and message in sender and

receiver Incorrect event timing between object actions Incorrect instantiation or destruction of objects


26/42

SD

Types of E rrors Found DuringI ntegration 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


27/42

SD

M ethods 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 separatelyProject Schedule-based clusteringContract-based clustering


28/42

SD

Techniques for Object-OrientedI ntegration Testing

Message QuiescenceEvent Quiescence


29/42

SD

M essage Quiescence

A method is a single unit of code that performs a

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


30/42

SD

Object 1

Object 2

Object 3

M ethod 1

M ethod 2

Method 3

M ethod 1

M ethod 2

M ethod 1

M ethod 2M ethod 3

An Object Network


31/42

SD

Object 1

Object 2

Object 3

M ethod 1

M ethod 2

Method 3

M ethod 1

M ethod 2

M ethod 1

M ethod 2M ethod 3

MM -Paths


32/42

SD

E vent QuiescenceAn 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 portevent

An input port event followed by a set of MM-Paths, and terminated by an output event is called

Atomic System Function (ASF).


33/42

SD

Object 1

Object 2

Object 3

M ethod 1

M ethod 2

Method 3

M ethod 1

M ethod 2

M ethod 1

M ethod 2M ethod 3

Atomic System Function

1

2

3

I nput port event (A)Output port event (A)

I nput port event (B)

Output port event (B)


34/42

SD

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.


35/42

SD

What Are Use CasesA 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 therequirement phase


36/42

SD

ExampleUse 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#


37/42

S

D

Static Testing and Analysis of Object-Oriented M odels


38/42


39/42

S

D

Ex amples of Analysis and DesignM odels to be Tested (Cont.)

State-Transition Models

State transition diagrams for classes, clusters, andsubsystems

Object network Message sequence between methods in classes

Transaction-Flow Models


40/42

S

D

Testing M odels

Criteria

Correctness Completeness Consistency

Early informal models are tested informally

The criteria should be interpretive in the context of iterative incremental approach


41/42

S

D

M odel Testing Approaches

Testing by comparison

compares each model to its predecessor or to previousforms of the model

Testing by inspection uses checklists to make sure that the model meets

certain criteriaTesting by verification follows certain steps to assure completeness and

consistency of one part of the model with another


42/42

S

D

ConclusionThe OO is not always the best approach to systemdevelopment.

Claimed benefits of the OO approach can only beobtained through: Robust development process Good development practices by individuals

Automated toolsThe OO approach introduces substantialdifficulties to the testing process.

Issues in OO Testing1

Documents

Transcript of Issues in OO Testing1