PATHS – CODE COMPLEXITY TESTING
ADDITIONAL WHITE BOX TESTING
APPROACHED
EVALUATING TEST ADEQUACY CRITERIA
Paths: Their Role in White Box-Based Test Design
• The role of a control flow graph generate control flow
graphs.
• These tools typically calculate a value for a software attribute
called McCabe‘s Cyclomatic Complexity V(G) from a flow
graph.
• The cyclomatic complexity attribute is very useful to a tester.
• The complexity value is usually calculated from the control
flow graph (G) by the formula
• The cyclomatic complexity value of a module is useful to the tester in several ways.
• Provide an approximation of the number of test cases needed for branch
coverage in a module of structured code.
• If the testability of a piece of software is defined in terms of the number of test
cases required to adequately test it, then McCabes‘ cyclomatic complexity
provides an approximation of the testability of a module.
• The tester can use the value of V(G) along with past project data to approximate
the testing time and resources required to test a software module.
• In addition, the cyclomatic complexity value and the control flow graph give the
tester another tool for developing white box test cases using the concept of a path
PATH
• A path is a sequence of control flow nodes usually
beginning from the entry node of a graph through to
the exit node.
• A path may go through a given segment of the control
flow graph one or more times.
• We usually designate a path by the sequence of nodes
it encompasses.
1-2-3-4-5-7-4-8
1-2-3-4-8
Set of independent paths starting
(i) 1-2-3-4-8
(ii) 1-2-3-4-5-6-7-4-8
(iii) 1-2-3-4-5-7-4-8
The number of independent paths in a basis set is
equal to the cyclomatic complexity of the graph.
• Cyclomatic complexity is a measure of the
number of so-called in-dependent paths in the
graph.
• An independent path is a special kind of path in
the flow graph.
• A set of independent paths for a graph is
sometimes called a basis set.
• For most software modules it may be possible to
derive a number of basis sets.
CODE COMPLEXITY TESTING
• Code complexity testing can be achieved by calculating cyclomatic complexity of a flow
graph.
• A flow graph is a representation of a program. A flow graph consists of nodes and
edges.
• In order to convert a standard flow chart into a flow graph to compute cyclomatic
complexity, the following steps to be taken
– Identify the predicates or decision points in the program
– Ensure that the predicates are simple
– Combine all sequential statements into a single node.
– When a set of sequential statements are followed by a simple predicate, combine all the sequential
statements and the predicate check into one node and have two edges emanating from this one
node. Such nodes with two edges emanating from them are called predicate nodes
– Make sure that all the edges terminate at some node; add a node to represent all the sets of
sequential statements at the end of the program.
Evaluating Test Adequacy Criteria
• Most of the white box testing approaches we have discussed so
far are associated with application of an adequacy criterion.
• Testers are often faced with the decision of which criterion to
apply to a given item under test given the nature of the item and
the constraints of the test environment (time, costs, resources)
• One source of information the tester can use to select an
appropriate criterion is the test adequacy criterion hierarchy
which describes a subsumes relationship among the criteria
Achieving all definition-use (def-use) path adequacy means
the tester has also achieved both branch and statement
adequacy.
• Weyuker presents a set of axioms that allow
testers to formalize properties which should be
satisfied by any good program-based test data
adequacy criterion.
Applicability Property
• For every program there exists an adequate test set.
• For all programs we should be able to design an adequate test set that
properly tests it.
• The test set may be very large so the tester will want to select
representable points of the specification domain to test it.
• If we test on all representable points, that is called an exhaustive test set.
• The exhaustive test set will surely be adequate since there will be no other
test data that we can generate.
5. Anti extensionality Property
• There are programs P and Q such that P is equivalent to Q, and T is adequate for P, but T
is not adequate for Q.
• We can interpret this axiom as saying that just because two programs are semantically
equivalent (they may perform the same function) does not mean we should test them
the same way.
• Their implementations (code structure) may be very different. The reader should note
that if programs have equivalent specifications then their test sets may coincide using
black box testing techniques, but this axiom applies to program-based testing and it
is the differences that may occur in program code that make it necessary to test P and Q
