Software Testing Techniques

OBJECT-ORIENTED
SOFTWARE ENGINEERING
UNIT 07 : Software Testing Techniques
© 2018, PRAMOD PARAJULI

OOSE UNIT 07 – Software Testing Techniques 2
Disclaimer
These slides are part of teaching materials for Object Oriented
Software Engineering (OOSE). These slides do not cover all
aspect of learning OOSE, nor are these be taken as primary
source of information. As the core textbooks and reference books
for learning the subject has already been specified and provided
to the students, students are encouraged to learn from the original
sources.
Contents in these slides are copyrighted to the instructor and
authors of original texts where applicable.

SOFTWARE TESTING

Process of executing a program with the intent of
finding an error

Good test case has high probability of finding an as-
yet undiscovered error

A successful test is one that uncovers an as-yet
undiscovered error

TESTING PRINCIPLE

All test should be traceable to customer requirements

Test should be planned long before testing begins

Pareto principle applies to S/W testing

Testing should begin ‘in the small’ and progress
towards testing ‘in large’

Exhaustive testing is not possible

TESTING TYPES

Unit/component/defect testing

Mutation testing

Integration testing

System testing
●
Alpha testing
●
Beta testing
●
Acceptance testing
Compone
nt
te
sting
Syste
m
te
sting
Softwa
rede
ve
lope
r Inde
pe
nde
nt te
sting te
a
m

TESTING PRIORITIES

Only exhaustive testing can show a program is free from
defects. However, exhaustive testing is impossible

Tests should exercise a system's capabilities rather than its
components

Testing old capabilities is more important than testing new
capabilities

Testing typical situations is more important than boundary
value cases

TEST DATA AND TEST CASES

Test data Inputs which have been devised to test
the system

Test cases Inputs to test the system and the
predicted outputs from these inputs if the system
operates according to its specification

DEFECT (UNIT) TESTING PROCESS
De
sign te
st
ca
se
s
Pre
pa
r ete
st
data
R
un pr ogra
m
with te
st da ta
Compa
r ere
sults
to te
st ca
se
s
T
e
st
ca
se
s
T
e
st
data
T
e
st
re
sults
T
e
st
re
por ts

BLACK-BOX TESTING

An approach to testing where the program is considered as a
‘black-box’

The program test cases are based on the system specification

Test planning can begin early in the software process
1. Equivalence class partitioning
2. Boundary value analysis

EQUIVALENCE CLASS PARTITIONING

Input data and output results often
fall into different classes where
all members of a class are related

Each of these classes is an
equivalence partition where the
program behaves in an
equivalent way for each class
member

Test cases should be chosen from
each partition
Syste
m
Outputs
Inva
lid inputs V
a
lid inputs

EQUIVALENCE CLASS PARTITIONING

Partition system inputs and outputs into ‘equivalence sets’
If input is a 5-digit integer
between 10,000 and 99,999,
equivalence partitions are
<10,000, 10,000-99, 999 and
> 10, 000

Choose test cases at the boundary of these sets
00000, 09999, 10000, 99999, 10001
Be
twe
e
n 1 0000 a
nd 99999
Le
ss tha
n 1 0000 Moretha
n 99999
9999
10000 50000
100000
99999
Input va
lue
s
Be
twe
e
n 4 a
nd 1 0
Le
ss tha
n 4 Moretha
n 1 0
3
4 7
11
10
Numbe
r of input va
lue
s

EXAMPLE: SEARCH ROUTINE

STRUCTURAL TESTING

Sometime called white-box
testing (glass-box testing)

Derivation of test cases
according to program
structure. Knowledge of the
program is used to identify
additional test cases

Objective is to exercise all
program statements (not all
path combinations)
1)statement coverage
2)branch coverage
3)condition coverage
4)path coverage

PATH TESTING

The objective of path
testing is to ensure
that the set of test
cases is such that
each path through
the program is
executed at least
once
1
2
3
4
6
5
7
while bottom <= top
if (elemArray [mid] == key
(if (elemArray [mid]< key
8
9
bottom > top

INTEGRATION TESTING

Tests complete systems or subsystems
composed of integrated components

Integration testing should be black-box testing
with tests derived from the specification

Main difficulty is localising errors

Incremental integration testing reduces this
problem

INTEGRATION TESTING
T3
T2
T1
T4
T5
A
B
C
D
T2
T1
T3
T4
A
B
C
T1
T2
T3
A
B
T
e
st se
que
nce1 T
e
st se
que
nce2 T
e
st se
que
nce3

APPROACHES TO INTEGRATION TESTING

Big-bang integration testing

Top-down testing
●
Start with high-level system and integrate from the top-
down replacing individual components by stubs where
appropriate

Bottom-up testing
●
Integrate individual components in levels until the
complete system is created

In practice, most integration involves a combination
of these strategies

TOP-DOWN APPROACH
Level 2
Level 2
Level 2
Level 2
Level 1 Level 1
Testing
sequence
Level 2
stubs
Level 3
stubs
. . .

BOTTOM-UP APPROACH
Level N
Level N
Level N
Level N
Level N
Level N–1 Level N–1
Level N–1
Testing
sequence
Test
drivers
Test
drivers

TESTING APPROACHES

Architectural validation
●
Top-down integration testing is better at discovering errors
in the system architecture

System demonstration
●
Top-down integration testing allows a limited
demonstration at an early stage in the development

Test implementation
●
Often easier with bottom-up integration testing

Test observation

Problems with both approaches. Extra code may be
required to observe tests

SYSTEM TESTING

Alpha testing – test carried by test team within the
organization

Beta testing – testing performed by a selected group
of friendly customers

Acceptance testing – performed by customer to
determine whether or not to accept the delivery of
the system

Stress testing – test systems beyond its maximum
design load

TESTING WORKBENCHES
Dyna
mic
a
na
l yse
r
Progra
m
be
ing te
ste
d
T
e
st r e
sults
T
e
st
pre
dictions
File
compa
ra
tor
Exe
cution
re
por t
Sim
ulator
Source
code
T
e
st
ma
na ge
r
T
e
st da ta Ora
cle
T
e
st da ta
ge
ne
r ator
Spe
cification
Re
por t
ge
ne
r ator
T
e
st re
sults
re
por t

OBJECT-ORIENTED TESTING

The components to be tested are object classes that are
instantiated as objects

Larger grain than individual functions so approaches
to white-box testing have to be extended

No obvious ‘top’ to the system for top-down
integration and testing

OOT LEVELS

Testing operations associated with objects

Testing object classes

Testing clusters of cooperating objects

Testing the complete OO system

OBJECT CLASS TESTING

Complete test coverage of a class involves
●
Testing all operations associated with an object
●
Setting and interrogating all object attributes
●
Exercising the object in all possible states

Inheritance makes it more difficult to design
object class tests as the information to be
tested is not localised

INTERFACE TESTING

Takes place when modules or
sub-systems are integrated to
create larger systems

Objectives are to detect faults due
to interface errors or invalid
assumptions about interfaces

Particularly important for object-
oriented development as objects
are defined by their interface
B
C
T
e
st
ca
se
s
A

INTERFACE TYPES

Parameter interfaces
●
Data passed from one procedure to another

Shared memory interfaces
●
Block of memory is shared between procedures

Procedural interfaces
●
Sub-system encapsulates a set of procedures to be called by
other sub-systems

Message passing interfaces
●
Sub-systems request services from other sub-systems

INTERFACE ERRORS

Interface misuse
●
A calling component calls another component and makes an
error in its use of its interface e.g. parameters in the wrong
order

Interface misunderstanding
●
A calling component embeds assumptions about the behaviour of
the called component which are incorrect

Timing errors
●
The called and the calling component operate at different speeds
and out-of-date information is accessed

INTERFACE TESTING GUIDELINES

Design tests so that parameters to a called procedure are at
the extreme ends of their ranges

Always test pointer parameters with null pointers

Design tests which cause the component to fail

Use stress testing in message passing systems

In shared memory systems, vary the order in which
components are activated

WEATHER STATION INTERFACE

Use a state model to
identify state transitions
for testing

Examples of testing
sequences
●
Shutdown -> Waiting -> Shutdown
●
Waiting -> Calibrating -> Testing -> Transmitting -
> Waiting
●
Waiting -> Collecting -> Waiting -> Summarising -
> Transmitting -> Waiting
ide
ntifie
r
re
por tWe
a
the
r ()
ca
libra
te(instrume
nts)
te
st ()
sta
rtup (instrume
nts)
shutdown (instrume
nts)
WeatherStation

OBJECT INTEGRATION

Levels of integration are less distinct in object-
oriented systems

Cluster testing is 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 system features as
experienced by users

Thread testing
●
Tests the systems response to events as processing threads
through the system

Object interaction testing
●
Tests sequences of object interactions that stop when an
object operation does not call on services from another
object

SCENARIO-BASED TESTING

Identify scenarios from use-cases and
supplement these with interaction diagrams
that show the objects involved in the scenario

Consider the scenario in the weather station
system where a report is generated

SCENARIO-BASED TESTING - EXAMPLE
:CommsController
request (report)
acknowledge ()
report ()
summarise ()
reply (report)
acknowledge ()
send (report)
:WeatherStation :WeatherData

SCENARIO-BASED TESTING - EXAMPLE

Thread of methods executed
●
CommsController:request -> WeatherStation:report ->
WeatherData:summarise

Inputs and outputs
●
Input of report request with associated acknowledge and a
final output of a report
●
Can be tested by creating raw data and ensuring that it is
summarised properly
●
Use the same raw data to test the WeatherData object

End of Unit 07 : Software Testing Techniques

Software Testing Techniques

More Related Content

What's hot (19)

Similar to Software Testing Techniques (20)

More from Pramod Parajuli (9)

Recently uploaded (20)

Software Testing Techniques