The Test Management Guide Software Test Guide RSS Feed
*
Accessibility

Background

BS7925-2 Annex B - Guidelines for Testing and Test Measurement

State Transition Testing



Annex B   
(informative)

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




© RuleWorks - All Rights Reserved - Policy - - Sitemap