Software Testing and

Quality Assurance

Chapter 5: Structural (White Box) Testing

1
 Brainstorming Questions
 What are the key principles of structural testing?
 How does structural testing differ from functional
testing?
 How can control flow graphs be used to analyze program
complexity?
 How can data flow analysis be used to identify potential
errors in data usage?
 What are the different types of data flow anomalies and
how can they be detected

2
 What is Structural Testing?
 Testing the internal structure and logic of a software
application.
 Key Techniques:
 Control Flow Testing: Analysing all possible execution paths.
 Data Flow Testing: Tracking data from origin to destination.
 Benefits:
 Design and Code Defects: Identifying logical errors.
 Control Flow Issues: Detecting missing or incorrect branches,
loops.
 Initialization Problems: Uncovering initial state errors.
 Data Flow Errors: Pinpointing data manipulation issues.

Figure5.1 White-box testing 3

 What is Structural Testing?
Types of White Box Testing
 Basis Path Testing
 Flow Graph Notation
 Cyclomatic Complexity
 Coverage Testing
 Statement Coverage
 Branch Coverage
 Condition Coverage
 Data Flow Testing

4
 Control Flow Testing
 A white-box testing technique that analyses a
program's control flow to identify potential bugs.
 Key Steps:
 Control Flow Analysis:
• Examines the program's control structure
• Identifies all possible execution paths
 Test Case Design:
• Develops test cases to cover all paths
• Focuses on testing logic and decision-making

5
 Basis Path Testing
 What is a Path?
 A sequence of nodes and edges in a control flow graph.
 Starts from the initial node and ends at a terminal node.
 Basis Set
 Minimal set of paths that covers every statement in the program.
 Executing these paths ensures maximum code coverage.
 Basis Path Testing
 White-box testing technique.
 Focuses on the internal structure of the code.
 Identifies and tests critical code segments.

6
 Continued…
To Implement Basis Path Testing:
1. Create a control flow graph (CFG): Visual representation
of the program's control flow.
2. Determine the cyclomatic complexity: Measure of the
number of independent paths in the CFG.
3. Identify a basis set of paths: A minimal set of paths that
covers every statement and edge in the CFG.
4. Design test cases: Create test cases to execute each path in
the basis set.
5. Execute test cases: Run the test cases and analyse the
results
7
 Continued…
Path Coverage Testing
 Path coverage is a testing technique that aims to execute
every possible path through a program's control flow.
 While exhaustive testing is often impractical, focusing on
linearly independent paths provides a more efficient and
effective approach.
Linearly Independent Paths
 Unique paths through the program's control flow graph
(CFG).
 Introduce at least one new edge or node not covered by
other paths.
 Balance between test coverage and effort.
8
 1. Control Flow Graph (CFG)

 Visual representation of a program's execution paths.

 Nodes: Represent individual statements or groups of
statements.
 Edges: Indicate the flow of control between statements.
 Regions: Enclose code blocks or decision points.
 Purpose:
 Understand program logic and structure.
 Identify potential optimization opportunities.
 Analyze program complexity and performance.
 Aid in code testing and debugging.

9
 Constructing CFGs
1. Sequence:
 A linear flow of control from one statement to the next.
 Represented by a sequence of nodes connected by edges.
2. Selection (if-else):
 Two possible paths based on a condition.
 Represented by a node for the condition, with two edges
leading to the true and false branches.
3. Iteration (while):
 Repeated execution of a block of statements as long as a
condition is true.
 Represented by a loop structure with an edge from the
last statement back to the condition node.
 Using these basic ideas, the CFG of Euclid’s GCD
computation algorithm can be drawn as shown in fig. 5.3.

10
 Continued…
 Sequence:
 a=5;
 b = a*2-1;

Fig. 5.2 (a): CFG for sequence constructs

 Selection:
• if (a>b)
• c = 3;
• else
• c =5;
• c=c*c;
Fig. 5.2 (b): CFG for selection constructs

11
 Continued…
 Iteration :
• while (a>b)
• {
• b=b -1;
• b=b*a;
• }
• c = a+b;
Fig. 5.2 (c): CFG for and iteration type of constructs
 EUCLID’S GCD Computation Algorithm

12
 Continued…

Fig. 5.3: Control flow diagram

13
 2. Cyclomatic Complexity
 A metric quantifying a program's logical complexity.
 Determines the number of independent paths through the code.
 Why is it important?
 Helps assess software maintainability, testability, and potential for
defects.
 Guides testing efforts by identifying complex areas.
 Control Flow Graph (CFG) Method:
 Count edges (E) and nodes (N).
 Complexity = E - N + 2
 Region Method:
 Count the number of regions in the CFG.
 Complexity = Number of regions
 Decision Points Method:
 Count decision points (if, while, for).
14
 Complexity = Decision points + 1
 Continued…
 For the CFG of example shown in fig. 5.3, E=7
and N=6. Therefore, the cyclomatic complexity =
7-6+2 = 3.
 To measure cyclomatic complexity Region, R = 4
 Number of Nodes = 8
 Number of edges = 10
 Number of Predicate Nodes = 3
 Cyclomatic Complexity V(G) =R= 4 Or V(G) =
Predicate Nodes + 1 = 3 + 1 = 4 Or V(G) = E – N
+ 2 = 10 – 8 + 2 = 4
 As set of independent paths for flow graph
 Path 1: 1-2-4-7-8
 Path 2: 1-2-3-5-7-8
 Path 3: 1-2-3-6-7-8
 Path 4: 1-2-4-7-2-4…..-7-8

15
 Statement Coverage
 A software testing technique that ensures every line of code is
executed at least once.
 If a statement isn't executed, potential errors within it can't be
detected.
1. Identify Statements: Locate individual statements in the code.
2. Design Test Cases: Create test cases to execute each statement.
3. Measure Coverage: Calculate the percentage of executed
statements.
 Limitations of Statement Coverage
• Limited Error Detection: May miss errors in logical conditions
or complex data flows.
• False Sense of Security: 100% coverage doesn't guarantee bug-
free code.
 SC = No of statements Executed/Total no of statements in the source
code * 100
16
 Continued…
 Example: Consider the
 To achieve 100% statement
Euclid’s GCD computation
algorithm: coverage, we can use the
following test cases:
 int compute_gcd(int x, int y)
{ •Test Case 1: (x = 3, y = 3)
•Test Case 2: (x = 4, y = 3)
 while (x != y) {
•Test Case 3: (x = 3, y = 4)
 if (x > y) {
 By executing these test
 x = x - y; cases, we ensure that every
 } else { statement in the function is
 y = y - x; executed at least once.
 }
 }
 return x;
}
17
 Example Scenario 1:
If a = 5, b = 4
input (int a, int b) print (int a, int b) {
{ int sum = a+b;
sum = a+b if (sum>0)
If (sum>0) print ("This is a positive result")
{ else
Print (This is positive result) } print ("This is negative result")
}
else { SC = 5/7*100 = 500/7 = 71%
Print (This is negative result) print (int a, int b) {
} int sum = a+b;
if (sum>0)
}
print ("This is a positive result")
else
print ("This is negative result")
}
SC = 6/7*100 = 600/7 = 85%
18
 Branch Coverage
 A testing technique that ensures every possible branch in
a program's control flow graph is executed at least once.
 Also known as Edge Testing.
 Why is it important?
 Stronger Coverage: It implicitly covers statement
coverage.
 Enhanced Fault Detection: It helps identify defects that
might be missed by other testing techniques.
 How it works
 Identify Branches: Determine all decision points in the
code.
 Design Test Cases: Create test cases to execute each
branch at least once, both true and false.
19
 Continued…
 Execute Test Cases: Run the test cases to cover all
branches.
 Analyze Results: Identify any defects or errors revealed
by the testing process.
 Example: Euclid's GCD Algorithm
 Test Cases:
(x=3, y=3): Both branches are taken.
(x=3, y=2): One branch is taken.
(x=4, y=3): One branch is taken.
(x=3, y=4): One branch is taken

20
 Condition Coverage
 Ensure all possible outcomes of a condition are tested.
 Problem: Exponential growth of test cases with increasing
complexity.
 Solution: Branch Testing
 Focus: Test each branch of a decision statement (e.g., if-then-
else).
 Benefit: Simpler and more practical than full condition
coverage.
 Strength of Testing Strategies
 Condition Coverage: More rigorous, but less practical for
complex conditions.
 Branch Coverage: Balanced approach, ensuring all branches
are executed.

21
 Data Flow-Based Testing
 Focus: Data flow through a program
 Goal: Ensure correct variable definition and usage
 Key Concepts:
 Definition (DEF): Assigning a value to a variable
 Use (USE): Accessing a variable's value
 Live Definition: A valid definition for later use
 DU Chain: A sequence from definition to use
 Testing Strategy:
 DU Chain Coverage: Execute every DU chain
 Test Path Selection: Prioritize paths covering multiple DU chains
 Benefits:
 Improved Code Quality
 Enhanced Test Coverage
22
 Reduced Debugging Time
 Example

23
 Reaching Definitions
 A definition can reach multiple nodes.
 A node can be reached by multiple definitions.
 The concept of reaching definitions is crucial for data flow
analysis and optimization techniques in compilers.

24
 Def-use Pairs
 A DU pair (n1, n2) represents a definition-use
relationship for a variable x. This means:
1. Definition at n1: Variable x is defined (assigned a value)
at node n1.
2. Use at n2: Variable x is used (its value is accessed) at
node n2.
3. No Intervening Definition: There's a path from n1 to n2
that doesn't contain any other definitions of x. This
ensures that the value defined at n1 is the one used at
n2.
• Identifying DU Pairs in the Given CFG
• Based on the provided CFG and the DEF and USE sets
for each node, we can identify the following DU pairs:
25
 For variable s: Continued…
 (1, 7): The definition of s at node  (4, 6): The definition of x at node
1 is used at node 7. 4 is used at node 6.
 (1, 8): The definition of s at node  (4, 7): The definition of x at node
1 is used at node 8. 4 is used at node 7.
 (7, 9): The definition of s at node  (4, 8): The definition of x at node
7 is used at node 9. 4 is used at node 8.
 (8, 9): The definition of s at node  For variable y:
8 is used at node 9.  (5, 3): The definition of y at node 5
is used at node 3.
 For variable x:
 (5, 6): The definition of y at node 5
 (2, 3): The definition of x at node is used at node 6.
2 is used at node 3.
 (5, 7): The definition of y at node 5
 (2, 4): The definition of x at node is used at node 7.
2 is used at node 4.  (5, 8): The definition of y at node
 (4, 3): The definition of x at node 5 is used at node 8.
4 is used at node 3.

26
Examples of Def-Use Pairs

27
 Test Case Generation Strategies
 All-DU-Paths
 Generate test cases for every possible path between a
definition and a use of a variable.
 All-Uses
 Generate at least one test case for each use of a variable,
ensuring coverage of a path from its definition.
 All-Definitions
 Generate at least one test case for each definition of a
variable, ensuring coverage of a path to one of its uses.
 Note: These strategies can be combined or modified to
suit specific testing needs and project constraints.

28
 Data-flow anomalies
 It represent the patterns of data usage which may lead to
an incorrect execution of the code.
Examples of data flow anomaly
a) It is an abnormal situation to successively assign two
values to a variable without using the first value==>
Defined and then defined again
b) It is abnormal to use a value of a variable before assigning
a value to the variable ==> Undefined but referenced
c) Another abnormal situation is to generate a data value
and never use it ==> Defined but not referenced

29
 Continued…
 After detecting a data flow anomaly The programmers must
analyse the causes of data flow anomalies and eliminate
them.
 Investigate the cause of the anomaly.
 To fix an anomaly, write new code or modify the
existing code.
 The presence of a data flow anomaly in a program does
not necessarily mean that execution of the program will
result in a failure.
 A data flow anomaly simply means that the program
may fail, and therefore the programmer must investigate
the cause of the anomaly.

30
 Mutation Testing
 A technique to assess the quality and effectiveness of a
test suite.
 Involves introducing small, deliberate changes
(mutations) to the source code.
 The goal is to determine if the existing test suite can
detect these faults.
 The Mutation Testing Process:
1. Initial Testing:
• Execute the original software with the existing test suite.
2. Mutation:
• Create mutant versions of the software by applying
mutation operators.
31
 Continued…
 Common operators:
• Arithmetic operator replacement
• Constant value modification
• Data type alteration
• Control flow changes
3. Test Suite Execution:
• Run each mutant against the existing test suite.
4. Mutant Killing:
• A mutant is "killed" if a test case detects the introduced
fault.
• Surviving mutants indicate weaknesses in the test suite.
5. Test Suite Enhancement:
• Develop new test cases to target the uncovered code32
paths.
 Continued…
 Why Use Mutation Testing?
 Identify Test Suite Weaknesses: Uncover gaps in your test
coverage.
 Estimate Residual Defect Density (RDD): Measure the number
of potential defects remaining.
 How Mutation Testing Works
1. Mutate Code: Introduce small changes to the source code.
2. Re-run Tests: Execute the test suite against the mutated code.
3. Analyze Results: If a mutation goes undetected, it indicates a
test coverage gap.
 You can improve the quality and reliability of your software.

33
Thank you!
Questions?

34