Guidelines for Testing Techniques and Test Measurement
B.3 State
Transition Testing
Introduction
This black box technique is based upon
an analysis of the specification of the component to model its behaviour by
state transitions. We illustrate the
technique by means of a worked example.
Naturally, the technique is only effective to the extent that the model
captures the specification of the component.
Example
Consider
a component, manage_display_changes,
with the following specification:
The component responds to input requests to change an
externally held display mode for a time display device. The external display mode can be set to one
of four values: Two correspond to displaying either the time or the date, and
the other two correspond to modes used when altering either the time or date.
There are four possible input
requests: 'Change Mode', 'Reset', 'Time
Set' and 'Date Set'. A 'Change Mode'
input request shall cause the display mode to move between the 'display time'
and 'display date' values. If the
display mode is set to 'display time' or 'display date' then a 'Reset' input
request shall cause the display mode to be set to the corresponding 'alter
time' or 'alter date' modes. The 'Time
Set' input request shall cause the display mode to return to 'display time'
from 'alter time' while similarly the 'Date Set' input request shall cause the
display mode to return to 'display date' from 'alter date'.
|
A state model is produced for
the component to identify its states, transitions, and their events and
actions. State transition diagrams
(STD) are commonly used as state models and their notation is briefly
illustrated opposite.
Events are always caused by
input. Similarly, actions are likely
to cause output. The output from an
action may be essential in order to identify the current state of the
component. A transition is determined
by the current state and an event and is normally labelled simply with the
event and action.
|
|
The STD for the component manage_display_changes
is shown in figure B.3.
Figure B.3 STD
for Manage_Display_Changes
Test
cases are initially derived from the state transition diagram to exercise each
of the possible transitions (using the abbreviated STD labels):
|
Test Case
|
1
|
2
|
3
|
4
|
5
|
6
|
|
Start State
|
S1
|
S1
|
S3
|
S2
|
S2
|
S4
|
|
Input
|
CM
|
R
|
TS
|
CM
|
R
|
DS
|
|
Expected Output
|
D
|
AT
|
T
|
T
|
AD
|
D
|
|
Finish State
|
S2
|
S3
|
S1
|
S1
|
S4
|
S2
|
This indicates that for test case 1 the
starting state is DISPLAYING TIME (S1), the input is 'change mode' (CM), the
expected output is 'display date' (D), and the finish state is DISPLAYING DATE
(S2).
This set of six test cases exercises
each of the possible transitions and so achieves 0-switch coverage [Chow]. Tests written to achieve this level of
coverage are limited in their ability to detect some types of faults because
although they will detect the most obvious incorrect transitions and outputs,
they will not detect more subtle faults that are only detectable through
exercising sequences of transitions.
Tests
written to achieve the next level of coverage, 1-switch, exercise all the
possible sequential pairs of transitions, of which there are ten in the manage_display_changes component:
|
Test Case
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
8
|
9
|
10
|
|
Start State
|
S1
|
S1
|
S1
|
S3
|
S3
|
S2
|
S2
|
S2
|
S4
|
S4
|
|
Input
|
CM
|
CM
|
R
|
TS
|
TS
|
CM
|
CM
|
R
|
DS
|
DS
|
|
Exp. Output
|
D
|
D
|
AT
|
T
|
T
|
T
|
T
|
AD
|
D
|
D
|
|
Next State
|
S2
|
S2
|
S3
|
S1
|
S1
|
S1
|
S1
|
S4
|
S2
|
S2
|
|
Input
|
CM
|
R
|
TS
|
CM
|
R
|
CM
|
R
|
DS
|
CM
|
R
|
|
Exp. Output
|
T
|
AD
|
T
|
D
|
AT
|
D
|
AT
|
D
|
T
|
AD
|
|
Finish State
|
S1
|
S4
|
S1
|
S2
|
S3
|
S2
|
S3
|
S2
|
S1
|
S4
|
This indicates that test case 1 comprises two transitions. For the first transition the starting state
is DISPLAYING TIME (S1), the initial input is 'change mode' (CM), the
intermediate expected output is display date (D), and the next state is
DISPLAYING DATE (S2). For the second
transition, the second input is 'change mode' (CM), the final expected output
is display time (T), and the finish state is DISPLAYING TIME (S1).
Note that intermediate states, and the
inputs and outputs for each transition, are explicitly defined.
Longer sequences of transitions can be
tested to achieve higher and higher levels of switch coverage, dependent on the
level of test thoroughness required.
A
limitation of the test cases derived to achieve switch coverage is that they
are designed to exercise only the valid transitions in the component. A more thorough test of the component will also attempt to cause invalid
transitions to occur. The STD only
explicitly shows the valid transitions (all transitions not shown are
considered invalid). A state model that
explicitly shows both valid and invalid transitions is the state table. The notation used for state tables is
briefly described below:
|
|
Input
1
|
Input
2
|
etc.
|
|
Start State 1
|
Entry
A
|
Entry
B
|
etc.
|
|
Start State 2
|
Entry
C
|
Entry
D
|
etc.
|
|
etc.
|
etc.
|
etc.
|
etc.
|
where Entry X = Finish State / Output
for the given start state and input.
The
state table for the manage_display_changes component is shown below:
|
|
CM
|
R
|
TS
|
DS
|
|
S1
|
S2/D
|
S3/AT
|
S1/N
|
S1/N
|
|
S2
|
S1/T
|
S4/AD
|
S2/N
|
S2/N
|
|
S3
|
S3/N
|
S3/N
|
S1/T
|
S3/N
|
|
S4
|
S4/N
|
S4/N
|
S4/N
|
S2/D
|
Any entry where the state remains the same and the output is shown as
null (N) represents a null transition, where any actual transition that can be induced will represent a
failure. It is the testing of these
null transitions that is ignored by test sets designed just to achieve switch
coverage. Thus a more complete test set
will test both possible transitions and null transitions, which means testing
the response of the component to all possible inputs in all possible states. The state table provides an ideal means of
directly deriving this set of test cases.
There are 16 entries in the table above
representing each of the four possible
inputs that can occur in each of the four possible
states, making 16 test cases which can be read from the state table as shown
below:
|
|
CM
|
R
|
TS
|
DS
|
|
S1
|
S2/D
(Test
Case 1)
|
S3/AT
(Test
Case 2)
|
S1/N
(Test
Case 3)
|
S1/N
(Test
Case 4)
|
|
S2
|
S1/T
(Test
Case 5)
|
S4/AD
(Test
Case 6)
|
S2/N
(Test
Case 7)
|
S2/N
(Test
Case 8)
|
|
S3
|
S3/N
(Test
Case 9)
|
S3/N
(Test
Case 10)
|
S1/T
(Test
Case 11)
|
S3/N
(Test
Case 12)
|
|
S4
|
S4/N
(Test
Case 13)
|
S4/N
(Test
Case 14)
|
S4/N
(Test
Case 15)
|
S2/D
(Test
Case 16)
|
which corresponds to:
|
Test Case
|
1
|
2
|
3
|
4
|
5
|
....
|
. .
|
....
|
12
|
13
|
14
|
15
|
16
|
|
Start State
|
S1
|
S1
|
S1
|
S1
|
S2
|
....
|
. .
|
....
|
S3
|
S4
|
S4
|
S4
|
S4
|
|
Input
|
CM
|
R
|
TS
|
DS
|
CM
|
....
|
. .
|
....
|
DS
|
CM
|
R
|
TS
|
DS
|
|
Exp. Output
|
D
|
AT
|
N
|
N
|
T
|
....
|
. .
|
....
|
N
|
N
|
N
|
N
|
D
|
|
Finish State
|
S2
|
S3
|
S1
|
S1
|
S1
|
....
|
. .
|
....
|
S3
|
S4
|
S4
|
S4
|
S2
|
If the above test
cases are compared with those produced to achieve 0-switch coverage then it can
be seen that by also testing the null transitions an extra 10 test cases are
created (3,4,7,8,9,10,12,13,14 and 15).
