SOFT 3406

Software Verification and

Validation
Week XIII
Ahmet Feyzi Ateş

Işık University Faculty of Engineering and Natural Sciences

Department of Computer Science Engineering 
2022-2023 Spring Semester
Object Oriented Testing
Object-Oriented Testing

✧ The shift from traditional to object-oriented

environment involves looking at and reconsidering old
strategies and methods for testing the software.

✧ The traditional programming consists of procedures

operating on data, while the object-oriented paradigm
focuses on objects that are instances of classes.

✧ OO program should be tested at different levels to

uncover all the errors.

3
Levels of Object-Oriented Testing

✧ At the algorithmic level, each module (or method) of every

class in the program should be tested in isolation.
✧ At the class level, every class should be tested as an
individual entity.
✧ As classes are integrated to form a small subsystem,
testing each subsystem individually is necessary.
✧ At this level, focus is on testing the components that
execute concurrently as well as on the interclass
interaction.
✧ Once all the clusters in the system are tested, system level
testing begins. At this level, interactions among
subsystems are tested.

4
Units for Object Oriented Testing

✧ Traditional software has a variety of definitions for “unit.”

✧ Two that pertain to object-oriented software are:
▪ A unit is the smallest software component that can be compiled
and executed.
▪ A unit is a software component that would never be assigned to
more than one designer to develop.
✧ Certain industrial applications have huge classes;
▪ These clearly violate the one-designer, one-class definition.
✧ In such applications, it seems better to define an
object-oriented unit as the work of one person, which
likely ends up as a subset of the class operations.
✧ In an extreme case, an object-oriented unit might be a
subclass of a class that contains only the attributes
needed by a single operation or method,
5
Units for Object Oriented Testing (cont’d)

✧ Mostly, the class-as-unit is accepted as the choice for the

most basic unit.
▪ Smallest testable is (an instance) of a class.

✧ One advantage of this choice is; in a UML context, a class

has an associated StateChart that describes its behavior,
which is extremely helpful in test case identification.
▪ Each method (and constructor) in a class should be tested.
▪ The state behavior (attributes) of the class should be tested by
valid sequence of method calls.

✧ A second advantage is that object-oriented integration

testing has clearer goals, namely, to check the
cooperation of separately tested classes, which echoes
traditional software testing.
6
How does OO make testing different
✧ Testing begins by evaluating the OOA and OOD models.
▪ OOA models requirements and use cases.
▪ OOD models classes and sequence diagrams.
✧ Concept of a “unit” broadens the notion of a class.
▪ Conventional testing focuses on input-process-output.
▪ OO testing focuses on testing on each method, then designing
sequences of methods to exercise states of a class.
✧ Integration testing is scenario driven.

Unit Testing Integration Testing

7
Integration in Object Oriented Testing

✧ Once the unit testing is complete, two

steps must occur:
▪ To integrate operations into a full class
▪ To integrate the class with other classes.
▪ if flattened classes were used, the original class hierarchy must be
restored, and
▪ if test methods were added, they must be removed.

✧ Once we have our “integration test bed,” we need to

identify what needs to be tested. As we with traditional
software integration, static and dynamic choices can be
made.

8
System Testing in OO Testing

✧ System testing is independent of system

implementation.
✧ A system tester does not really need to know if the
implementation is in procedural or object-oriented code.
✧ The primitives of system testing are port input and
output events.
✧ The issue is how to identify threads to be used as test
cases.
✧ Requirements specification models, particularly the
behavioral models, are used as the basis of thread test
case identification.

9
System Testing in OO Testing

✧ In OO system testing, many ideas are inherited from

system testing of traditional software and presume the
system has been defined and refined with the UML
notation.

✧ One emphasis, then, is finding system-level thread test

cases from standard UML models.

✧ At the system level, a UML description is composed of

various levels of use cases, a use case diagram, class
definitions, and class diagrams.

10
Object Oriented Testing:
An Application

✧ A Currency Converter – System Functions

✧ In the first step, the customer/user describes the
application in very general terms.
✧ This might take the form of “user stories,” which are
precursors to use cases.
✧ From these, three types of system functions are
identified:
▪ Evident, obvious ones,
▪ Hidden, might not be discovered immediately,
▪ Frill, the “bells and whistles” that so often occur.

11
A Currency Converter

● Converts US Dollars to:

○ – Brazilian real (R$)
○ – Canadian dollars (C$)
○ – European euros (€)
○ – Japanese yen (¥)
○
● User can revise inputs
● User can perform repeated
conversions

12
Currency Converter System Functions

13
Currency Converter – High Level Use Cases

✧ Several levels of use cases

▪ High Level
▪ Essential
▪ Expanded Essential
▪ Real

✧ The use case development begins with a very high-level

view.

✧ Very few details are provided in a high-level use case; they

are insufficient for test case identification.

✧ The main point of high-level use cases is that they capture a

narrative description of something that happens in the
system to be built.
14
15
Currency Converter – Essential Use Cases

✧ Essential use cases add “actor” and “system” events to

a high-level use case. Actors can be people, devices,
adjacent systems, or abstractions such as time.

✧ Actions / Responses are numbered,

✧ Numbers show approximate sequence in time

✧ The numbering of actor actions (port input events) and

system responses (port output events) shows their
approximate sequences in time.
16
Essential Use Cases

HLUC1 → EUC1

Essential Use Case for HLUC-1

17
Currency Converter – Detailed GUI Definition

✧ Once a set of essential use cases has been identified,

the graphical user interface (GUI) is fleshed out with
design-level detail.
✧ These controls will be referred to in the EEUCs.
✧ Only selected EEUCs will be included.

18
Expanded Essential Use Cases

● Adds:
○ Pre / Post conditions
○ Alternative sequences of events
○ References system functions found earlier

19
Real Use Cases
✧ Real Use Cases are only slightly different from EEUC
✧ Instead of “Enter dollar amount”
▪ “Enter 10 in txtDollar” used, etc.

20
System Test Cases
✧ Finally, system Test Cases can be derived from RUC

21