20CS6PE34-STM UNIT-4

UNIT IV
State, State Graphs and Transition testing: state graphs, good & bad state graphs, state
testing, Testability tips

Introduction
 State is a condition or situation during which an object undergoes throughout its life
time.
 The finite state machine is as fundamental to software engineering as boolean
algebra to logic.
 State testing strategies are based on the use of finite state machine models for
softwarestructure, software behavior, or specifications of software behavior.
 Finite state machines can also be implemented as table-driven software, in which
case they are a powerful design option.

State Graphs
 A state is defined as: “A combination of circumstances or attributes belonging for
thetime being to a person or thing.”
 A state graph consists of a set of states in order to represent the behavior of the system
 For example, a moving automobile whose engine is running can have the following
states with respect to its transmission.
Reverse gear
Neutral gear
First gear
Second gear
Third gear
Fourth gear

State graph - Example

 For example, a program that detects the character sequence “ZCZC” can be in the
following states.
 Neither ZCZC nor any part of it has been detected.
Z has been detected.
ZC has been detected.
ZCZ has been detected.
ZCZC has been detected.

M Srimathi, Assistant Professor, CSE Dept, TKREC 1

 20CS6PE34-STM UNIT-4

 States are represented by Nodes. State are numbered or may identified by wordsor
whatever else is convenient.

Inputs and Transitions

 Whatever is being modeled is subjected to inputs. As a result of those inputs, the
statechanges, or is said to have made a Transition.
 Transitions are denoted by links that join the states.
 The input that causes the transition are marked on the link; that is, the inputs are
linkweights.
 There is one out link from every state for every input.
 If several inputs in a state cause a transition to the same subsequent state, instead of
drawing a bunch of parallel links we can abbreviate the notation by listing the several
inputs as in: “input1, input2, input3………”.

Finite State Machine

 A finite state machine is an abstract device that can be represented by a state
graphhaving a finite number of states and a finite number of transitions between
states.
Outputs
 An output can be associated with any link.
 Out puts are denoted by letters or words and are separated from inputs by a
slash as follows: “input/output”.
 As always, output denotes anything of interest that’s observable and is not
restricted to explicit outputs by devices.
 Outputs are also link weights.
 If every input associated with a transition causes the same output, then denoted it as:
 “input1, input2, input3… ............................./output”

State Tables
 Big state graphs are cluttered and hard to follow.
 It’s more convenient to represent the state graph as a table (the state table or state
transition table) that specifies the states, the inputs, the transitions and the outputs.
 The following conventions are used:
 Each row of the table corresponds to a state.
 Each column corresponds to an input condition.
 The box at the intersection of a row and a column specifies the next state (the
transition) and the output, if any.

M Srimathi, Assistant Professor, CSE Dept, TKREC 2

 20CS6PE34-STM UNIT-4

State Table-Example

Time versus Sequence

 State graphs don’t represent time-they represent sequence.
 A transition might take microseconds or centuries;
 A system could be in one state for milliseconds and another for years- the state
graphwould be the same because it has no notion of time.
 Although the finite state machines model can be elaborated to include notions of
time inaddition to sequence, such as time Petri Nets.

Software implementation
 There is rarely a direct correspondence between programs and the behavior of a
processdescribed as a state graph.
 The state graph represents, the total behavior consisting of the transport, the software,
theexecutive, the status returns, interrupts, and so on.
 There is no simple correspondence between lines of code and states. The state table
formsthe basis.

Good State Graphs and Bad

 What constitutes a good or a bad state graph is to some extent biased by the kinds of
stategraphs that are likely to be used in a software test design context.
 Here are some principles for judging.
 The total number of states is equal to the product of the possibilities of factors that
make up the state.
 For every state and input there is exactly one transition specified to exactly one,
possibly the same, state.
M Srimathi, Assistant Professor, CSE Dept, TKREC 3
 20CS6PE34-STM UNIT-4

 For every transition there is one output action specified. The output could be
trivial, but at least one output does something sensible.
 For every state there is a sequence of inputs that will drive the system back to the
same state.

Important graphs

State Bugs-Number of States

 The number of states in a state graph is the number of states we choose to

recognize ormodel.
 The state is directly or indirectly recorded as a combination of values of variables that
appear in the data base.
 For example, the state could be composed of the value of a counter whose possible
valuesranged from 0 to 9, combined with the setting of two bit flags, leading to a total
of 2*2*10=40 states.
 The number of states can be computed as follows:
1. Identify all the component factors of the state.
2. Identify all the allowable values for each factor.
3. The number of states is the product of the number of allowable values of all the
factors.
 Before you do anything else, before you consider one test case, discuss the number of
states you think there are with the number of states the programmer thinks there are.
 There is no point in designing tests intended to check the system’s behavior in various
states if there’s no agreement on how many states there are.
1. Impossible States
M Srimathi, Assistant Professor, CSE Dept, TKREC 4
 20CS6PE34-STM UNIT-4

 Some times some combinations of factors may appear to be impossible.

 The discrepancy between the programmer’s state count and the tester’s state count is
often due to a difference of opinion concerning “impossible states”.
 A robust piece of software will not ignore impossible states but will recognize them
and invoke an illogical condition handler when they appear to have occurred.

Equivalent States
 Two states are Equivalent if every sequence of inputs starting from one state produces
exactly the same sequence of outputs when started from the other state. This notion
can also be extended to set of states.

Merging of Equivalent States

Recognizing Equivalent States

 Equivalent states can be recognized by the following procedures:
 The rows corresponding to the two states are identical with respect to
input/output/next state but the name of the next state could differ.
 There are two sets of rows which, except for the state names, have identical state
graphswith respect to transitions and outputs. The two sets can be merged.

Transition Bugs
Unspecified and contradictory Transitions
 Every input-state combination must have a specified transition.
 If the transition is impossible, then there must be a mechanism that prevents the
input from occurring in that state.
 Exactly one transition must be specified for every combination of input and state.
 A program can’t have contradictions or ambiguities.

M Srimathi, Assistant Professor, CSE Dept, TKREC 5

 20CS6PE34-STM UNIT-4

 Ambiguities are impossible because the program will do something for every input.
Eventhe state does not change, by definition this is a transition to the same state.

Unreachable States
 An unreachable state is like unreachable code.
 A state that no input sequence can reach.
 An unreachable state is not impossible, just as unreachable code is not impossible
 There may be transitions from unreachable state to other states; there usually because
thestate became unreachable as a result of incorrect transition.
 There are two possibilities for unreachable states:
 There is a bug; that is some transitions are missing.
 The transitions are there, but you don’t know about it.

Dead States
 A dead state is a state that once entered cannot be left.
 This is not necessarily a bug but it is suspicious.

Output Errors
 The states, transitions, and the inputs could be correct, there could be no dead or
unreachable states, but the output for the transition could be incorrect.
 Output actions must be verified independently of states and transitions.
 State Testing
 Impact of Bugs
 If a routine is specified as a state graph that has been verified as correct in all
details. Program code or table or a combination of both must still be implemented.
 A bug can manifest itself as one of the following symptoms:
 Wrong number of states.
 Wrong transitions for a given state-input combination.
 Wrong output for a given transition.
 Pairs of states or sets of states that are inadvertently made equivalent.
 States or set of states that are split to create in equivalent duplicates.
 States or sets of states that have become dead.
 States or sets of states that have become unreachable.

Principles of State Testing

 The strategy for state testing is analogous to that used for path testing flow graphs.
 Just as it’s impractical to go through every possible path in a flow graph, it’s
impracticalto go through every path in a state graph.
 The notion of coverage is identical to that used for flow graphs.
 Even though more state testing is done as a single case in a grand tour, it’s
impractical to do it that way for several reasons.
 In the early phases of testing, you will never complete the grand tour because of bugs.
 Later, in maintenance, testing objectives are understood, and only a few of the states
andtransitions have to be tested. A grand tour is waste of time.
 Theirs is no much history in a long test sequence and so much has happened
that verification is difficult.
M Srimathi, Assistant Professor, CSE Dept, TKREC 6
 20CS6PE34-STM UNIT-4

Starting point of state testing

 Define a set of covering input sequences that get back to the initial state when
starting from the initial state.
 For each step in each input sequence, define the expected next state, the expected
transition, and the expected output code.
 A set of tests, then, consists of three sets of sequences:
 Input sequences
 Corresponding transitions or next-state names
 Output sequences

Limitations and Extensions

 State transition coverage in a state graph model does not guarantee complete testing.
 How defines a hierarchy of paths and methods for combining paths to produce
covers ofstate graphs.
 The simplest is called a “0 switch” which corresponds to testing each transition
individually.
 The next level consists of testing transitions sequences consisting of two
transitions called “1 switches”.
 The maximum length switch is “n-1 switch” where there are n numbers of states.
 Situations at which state testing is useful
 Any processing where the output is based on the occurrence of one or more sequences
of events, such as detection of specified input sequences, sequential format validation,
parsing, and other situations in which the order of inputs is important.
 Most protocols between systems, between humans and machines, between
components ofa system.
 Device drivers such as for tapes and discs that have complicated retry and recovery
procedures if the action depends on the state.

Whenever a feature is directly and explicitly implemented as one or more state transition
tables.

M Srimathi, Assistant Professor, CSE Dept, TKREC 7