CSE 5324: Software Engineering I

(Analysis, Design, Creation)

Fall 1997

Software Testing

Object Oriented Testing

REMEMBER:

What is the goal of testing?

(Finding errors.)

Assess quality

Uncover errors

Ensure standards are met

Is OO Test different?

(From other methods)

OO models are different

Unit testing is based on classes

Integration is different

OO assumes re-use

The basic goals of testing remain the same

We want to find errors as early as possible

(in process steps: requirements, design, code)

to avoid propagation

Errors made in analysis may:

Lead to errors in classes in design

Make more work in procedures for a bad attribute

(update, inherit, etc.)

Cause extra (or incorrect) subclasses or system

behavior

How are analysis and design "models" tested

Different methodologies (UML, Rumbaugh, Booch, etc)

use different notation

We still want to check that "some" correct syntax was

used

"Experts" in the problem domain can review class definitions

and hierarchy for missing or ambiguous

Do class relationships reflect "the real world"?

Class - Responsibility - Collaboration (CRC) model

classes and relationships may be inconsistent

CRC lists

class name

responsibilities (operations, what it does)

collaborators (other classes needed, sent messages)

and optionally:

class type (like: transaction)

class characteristics (systems related: atomic,

CRC Steps:

Cross check CRC and O-R model

Ensure that a delegated responsibility is actually

done by each (that) collaborator

Ensure each collaborator receives requests from

correct (reasonable) source

Are other classes needed, is work grouped correctly?

Can (should) widely requested services be grouped

(combine responsibilities that always go together)

NOTE: this may be a bad idea - reuse, etc.

OO Unit testing

With encapsulation, smallest testable unit is a

class (or object)

How can we isolate and test?

Class testing - unlike unit test based on algorithms

and data flow -

state behavior of class and encapsulated

operations

Integration testing

What is top-down or bottom-up (with classes)?

Integration often described as:

Thread-based - based on response to an input

or event.

Use-based - test independent classes that use

fewest server classes, then move on to

dependant classes

Cluster testing

collaborating classes are clustered

(by O-R and CRC models)

and exercised

Validation testing

At system level, class connections not

visible

Black Box works here

Test cases may be done from OOA:

Object Behavior, event flow

Test Case Design

Berard

Test case explicitly connected to class

State test purpose

Testing:

Object states

operations, messages

exceptions tested

May be difficult to know the internal state of an object

It might be necessary to build in operations to report

the state

Inheritance requires retesting

Conventional testing (and differences):

Fault based test - high probability of finding an error

where are most likely errors (to be found)?

Derived and Inherited classes - redefined class

tests

Scenario-based testing

What does the user do? (Fault based - what

does software do)

Use Case

Surface structure test - structure visible to user

(commands, etc.)

Deep Structure - examine design and code

Class Testing

Random tests

Partition test - similar to equivalence partition

based on:

attribute

class states

category - functions of operations

Interclass test

Multiple class testing

random testing, partition testing

Behavior model test

based on state transition diagram

(dynamic behavior)

breadth first usually

Reasons not to test:

You didn't know it was policy

Blame someone else's code

(design, etc.)

Good choices:

dead co-workers

children that can't talk

Bad choices:

bosses children

boss

Not on the schedule

We keep finding problems

Too complex

The risks (product liability) not great

Waste of (my) time