ST UNIT V
ST UNIT V
Introduction
• 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 software
structure, 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
the time being to a person or thing.”
• 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.
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.
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
graph would be the same because it has no notion of time.
• Although the finite state machines model can be elaborated to include notions of time
in addition to sequence, such as time Petri Nets.
O Software implementation
• There is rarely a direct correspondence between programs and the behavior of a
process described as a state graph.
• The state graph represents, the total behavior consisting of the transport, the software,
the executive, the status returns, interrupts, and so on.
• There is no simple correspondence between lines of code and states. The state table
forms the basis.
Important graphs
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.
TransitionBugs-
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.
• Ambiguities are impossible because the program will do something for every input. Even
the 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
the state became unreachable as a result of incorrect transition.
• There are two possibilities for unreachable states:
O There is a bug; that is some transitions are missing.
O 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.
Tool Building
If you build test tools or want to know how they work, sooner or later you will be
implementing or investigating analysis routines based on these methods.
It is hard to build algorithms over visual graphs so the properties or graph matrices
are fundamental to tool building.
• A junction is node with more than one nonzero entry in its column.
• A self loop is an entry along the diagonal.
Cyclomatic Complexity
• The cyclomatic complexity obtained by subtracting 1 from the total number of entries in each row
and ignoring rows with no entries, we obtain the equivalent number of decisions for each row.
Adding these values and then adding 1 to the sum yields the graph’s cyclomatic complexity.
Relations
• A relation is a property that exists between two objects of interest.
• For example,
• “Node a is connected to node b” or aRb where “R” means “is connected to”.
• “a>=b” or aRb where “R” means greater than or equal”.
• A graph consists of set of abstract objects called nodes and a relation R between the nodes.
• If aRb, which is to say that a has the relation R to b, it is denoted by a link from a to b.
• For some relations we can associate properties called as link weights.
Transitive Relations
• A relation is transitive if aRb and bRc implies aRc.
• Most relations used in testing are transitive.
• Examples of transitive relations include: is connected to, is greater than or equal to, is less than or
equal to, is a relative of, is faster than, is slower than, takes more time than, is a subset of,
includes, shadows, is the boss of.
• Examples of intransitive relations include: is acquainted with, is a friend of, is a neighbor of,
is lied to, has a du chain between.
Reflexive Relations
• A relation R is reflexive if, for every a, aRa.
• A reflexive relation is equivalent to a self loop at every node.
• Examples of reflexive relations include: equals, is acquainted with, is a relative of.
• Examples of irreflexive relations include: not equals, is a friend of, is on top of, is under.
Symmetric Relations
• A relation R is symmetric if for every a and b, aRb implies bRa.
• A symmetric relation mean that if there is a link from a to b then there is also a link from b to a.
• A graph whose relations are not symmetric are called directed graph.
• A graph over a symmetric relation is called an undirected graph.
• The matrix of an undirected graph is symmetric (aij=aji) for all i,j)
Antisymmetric Relations
• A relation R is antisymmetric if for every a and b, if aRb and bRa, then a=b, or they are the
same elements.
• Examples of antisymmetric relations: is greater than or equal to, is a subset of, time.
• Examples of nonantisymmetric relations: is connected to, can be reached from, is greater than,
is a relative of, is a friend of
equivalence Relations
• An equivalence relation is a relation that satisfies the reflexive, transitive, and
symmetric properties.
• Equality is the most familiar example of an equivalence relation.
• If a set of objects satisfy an equivalence relation, we say that they form an equivalence class
over that relation.
• The importance of equivalence classes and relations is that any member of the equivalence
class is, with respect to the relation, equivalent to any other member of that class.
• The idea behind partition testing strategies such as domain testing and path testing, is that we can
partition the input space into equivalence classes.
• Testing any member of the equivalence class is as effective as testing them all.
• The square of the matrix represents all path segments two links long.
• The third power represents all path segments three links long.
• n
• aij=Σ aik akj
• k=1
• more generally, given two matrices A and B with entries aik and bkj, respectively, their product
is a new matrix C, whose entries are cij, where:
▪ n
• Cij=Σ aik bkj
Partitioning Algorithm
• Consider any graph over a transitive relation. The graph may have loops.
• We would like to partition the graph by grouping nodes in such a way that every loop is
contained within one group or another.
• Such a graph is partially ordered.
• There are many used for an algorithm that does that:
• We might want to embed the loops within a subroutine so as to have a resulting graph which is
loop free at the top level.
• Many graphs with loops are easy to analyze if you know where to break the loops.
• While you and I can recognize loops, it’s much harder to program a tool to do it unless
you have a solid algorithm on which to base the tool.
Node Reduction Algorithm (General)
• The matrix powers usually tell us more than we want to know about most graphs.
• In the context of testing, we usually interested in establishing a relation between two
nodes-typically the entry and exit nodes.
• In a debugging context it is unlikely that we would want to know the path expression
between every node and every other node.
• The advantage of matrix reduction method is that it is more methodical than the graphical
method called as node by node removal algorithm.
1. Select a node for removal; replace the node by equivalent links that bypass that node and add
those links to the links they parallel.
2. Combine the parallel terms and simplify as you can.
3. Observe loop terms and adjust the out links of every node that had a self loop to account for
the effect of the loop.
4. The result is a matrix whose size has been reduced by 1. Continue until only the two nodes of
interest exist.