CITS5501 Software Testing and Quality Assurance
Graph-based testing
Unit coordinator: Arran Stewart
1 / 25
Overview
Graph-based testing – we identify inputs which will exercise
particular paths through a graph representing the software in
some way.
The graph could represent
control flow through a program
data flow between variables
an activity diagram, showing the workflow when a user interacts
with the system
a state diagram, showing states of a system and transitions
between them
2 / 25
Graph definition
A graph consists of:
A set N of nodes
A set E of edges, each edge being an “arrow” from one node
to another
3 / 25
Graph-based testing
We will start by considering control flow. Our approach is:
1 Use the source code (or pseudocode) to produce a control flow
graph.
2 Using the graph produce a set of tests for the given program.
4 / 25
Constructing the graph
In a control flow graph, nodes represent points in the program
control flow can go “from” or “to”
Loops, thrown exceptions and gotos (in languages that have
them) are locations control flow can go from – statements
representing these spots are “sources”
Locations control flow can go to are “sinks”
5 / 25
Sequence control flow graphs
The flow graph for a sequence of statements is
s1
s2
6 / 25
if-then control flow graphs
given pseudocode like
if c then:
s1
s2
we get the following graph
c true
false
s1
s2
7 / 25
if-then-else control flow graphs
if c then:
s1
else:
s2
s3
true c false
s1 s2
s3
8 / 25
What about loops?
Edges will obviously go “backward” in the graph (usually,
towards the “top”)
9 / 25
while-do control flow graphs
while c do:
s1
s2
c false
true
s1
s2
10 / 25
other structures
Most other control flow structures can be written into one of
these forms (including “case” statements, breaking out of
loops, “for” loops, etc)
11 / 25
other structures – example
A “case” statement:
case x of:
val1: s1; break
val2: s2; break
default: s3
s4
12 / 25
other structures – example (2)
Can be written as nested if-else
if x == v1:
s1
else:
if x == v2:
s2
else:
s3
s4
13 / 25
Using the graph
To find a new test, examine the graph edges that haven’t been
exercised yet, and try to devise a test that exercises it
In general, we’d actually like to find a test that exercises as few
edges as possible
why?
14 / 25
Using the graph
To find a new test, examine the graph edges that haven’t been
exercised yet, and try to devise a test that exercises it
In general, we’d actually like to find a test that exercises as few
edges as possible
why?
Tests that exercise a large number of edges usually represent
“common” scenarios – we’d actually like to find less common
cases (i.e. get more “value” out of the test)
Ideally, we want tests to be small and independent, so that
when something goes wrong, we can localize the fault.
15 / 25
Example – sorting algorithm
S1 i = 2
C1 while (i <= n):
S2 j = i - 1
C2 while j >= 1 and A[j] >= A[j+1]:
S3 temp = A[j]
S4 A[j] = A[j+1]
S5 A[j+1] = temp
S6 j = j-1
S7 i = i + 1
16 / 25
Example – sorting algorithm (2)
17 / 25
Example – binary search
Inputs
n, the length of the following array.
A, an integer array with entries A[1], ..., A[n] such that
A[i] < A[i+1] for i between 1 and n-1
(i.e., it’s sorted in ascending order, and 1-based)
key, an integer to search for (the “needle”)
Outputs
index, an integer between 0 and n such that:
if index = 0 then key does not equal any entry of the array A
if index is between 1 and n then A[index] = key
18 / 25
Example – binary search (2)
found = false
low = 1
high = n
while ((low <= high) and not found):
medium = floor((low + high)/2)
if A[medium] == key:
index = medium
found = true
else:
if A[medium] < key then
low = medium + 1
else:
high = medium - 1
if not found:
index := 0
19 / 25
Graph-based testing criteria
Graph-based testing criteria
20 / 25
Graph-based testing criteria
Graph-based testing criteria
Some possible criteria include:
node coverage - our test set traverses every node
(if using program control flow: statement coverage is similar,
but coarser)
edge coverage - we traverse every edge
egde-pair coverage - we traverse every possible pair of edges
We might use the informal heuristic of executing each loop 0
times, once, more than once (sometimes called “loop
coverage”)
21 / 25
Graph-based testing criteria
Prime paths
Definitions:
Simple Path: A path from node ni to nj is simple if no node
appears more than once, except possibly the first and last
nodes are the same
No internal loops in our path
A loop is a simple path
22 / 25
Graph-based testing criteria
Prime paths
Definitions:
Simple Path: A path from node ni to nj is simple if no node
appears more than once, except possibly the first and last
nodes are the same
No internal loops in our path
A loop is a simple path
Prime Path : A simple path that does not appear as a proper
subpath of any other simple path
23 / 25
Graph-based testing criteria
Prime path coverage
Prime Path Coverage (PPC): Every prime path in the graph is
visited.
It subsumes node and edge coverage
But not edge-pair coverage – we code have nodes (m,n), where
m loops to itself, and edge pair coverage requires the path
(m,m,n) to be exercised.
when it comes to devising tests, some tests may end up
exercising multiple prime paths. But that’s okay – as long as
all prime paths are visited, we’ve satisfied the criterion.
24 / 25
Graph-based testing criteria
Control flow graphs
In a control flow graph, different graph coverage criteria will
correspond to:
Node coverage: Execute every statement
(in fact, node coverage is stronger, since one statement may
expand to multiple nodes)
Edge coverage: Execute every branch
Note that complex boolean conditions in branches are still treated as
a single node. (Effectively, the boolean condition is a “black box”.)
Logic coverage conditions (used, for instance, in avionics) look at
these conditions in finer-grained detail.
25 / 25
