Unit II - White-box testing | Software Testing

📌 Syllabus Topics Covered

7 Hrs Weightage

2.1 Introduction (Need of white box testing, Testing types, Test adequacy criteria, Static testing by humans)
2.2 Structural testing (logic coverage criteria, Basis path testing)
2.3 Graph metrics
2.4 Loop Testing
2.5 Data flow testing
2.5 Mutation Testing
2.6 Design of test cases
2.7 Testing of Object oriented systems
2.8 Challenges in White box testing

📖 Comprehensive Theoretical Notes

Exam-Oriented Theory

2.1 & 2.2 White-Box Testing & Logic Coverage Criteria

White-Box Testing (Glass-Box / Structural / Clear-Box Testing): A testing methodology where the internal logic, source code structure, control flow graphs, and data paths of an application are fully visible and examined by the tester.

Logic Coverage Hierarchy:

Statement Coverage: Ensures every executable code statement is executed at least once: $$\text{Statement Coverage} = \frac{\text{Number of executed statements}}{\text{Total statements}} \times 100\%$$
Branch / Decision Coverage: Ensures every decision point (e.g., if/else, switch) evaluates to both TRUE and FALSE at least once.
Condition Coverage: Evaluates every individual boolean sub-condition in compound expressions (e.g., in if (A && B), test $A=\text{T/F}$ and $B=\text{T/F}$).
Multiple Condition Coverage (MCC): Tests all $2^n$ possible truth-table combinations of boolean conditions.
Path Coverage: Tests every independent executable path through the program from start to end (strongest coverage).

2.2.2 & 2.3 Basis Path Testing & Cyclomatic Complexity (McCabe)

Basis Path Testing (Tom McCabe): Identifies the set of linearly independent execution paths that span all possible program executions.

Control Flow Graph (CFG): Represents code flow using Nodes (sequential statements) and Edges (transfer of control/branches).

Cyclomatic Complexity $V(G)$ Calculation (3 Equivalent Methods):

Formula 1 (Edges & Nodes): $V(G) = E - N + 2P$ (where $E$ = edges, $N$ = nodes, $P$ = connected components, usually 1).
Formula 2 (Predicate Nodes): $V(G) = P_n + 1$ (where $P_n$ is the number of binary decision/predicate nodes).
Formula 3 (Enclosed Regions): $V(G) = \text{Number of closed regions} + 1 \text{ (outer region)}$.

2.4 - 2.8 Loop Testing, Data Flow, Mutation Testing, and OO Testing

Loop Testing: Focuses specifically on loop constructs (Simple, Nested, Concatenated, Unstructured). For simple loops of max count $n$: test bypass loop ($0$), exactly $1$ iteration, $2$ iterations, typical $m < n$ iterations, $n-1$, $n$, and $n+1$ iterations.

Data Flow Testing: Tracks variable lifecycles across Define ($d$), Use ($u$ - computation or predicate), and Kill ($k$) states (DU-paths).

Mutation Testing: Fault-based testing where intentional artificial bugs (mutants) are injected into source code (e.g., changing + to -). A test suite is high quality if its test cases 'kill' (detect) all mutants: $$\text{Mutation Score} = \frac{\text{Killed Mutants}}{\text{Total Mutants} - \text{Equivalent Mutants}} \times 100\%$$

Testing Object-Oriented Systems: Challenges arise from Encapsulation (hidden state), Inheritance (re-testing inherited methods in new contexts), and Polymorphism (dynamic binding requires combinatorial testing across all concrete subclasses).

🔑 Key Concepts & Examination Keywords

Quick Terminology

Cyclomatic Complexity

A quantitative software metric measuring the number of linearly independent paths through a program's source code.

Control Flow Graph (CFG)

A directed graph representing all paths that might be traversed through a program during its execution.

Basis Path Testing

A white-box testing technique that derives test cases to guarantee that every independent execution path is executed at least once.

Mutation Testing

A technique where mutants (modified code with artificial bugs) are evaluated against test suites to measure test adequacy.

🎯 High-Yield Important Examination Questions

8–10 Descriptive Points Each

Q1. Explain Cyclomatic Complexity in detail: define Control Flow Graphs (CFG), state the 3 mathematical formulas, and demonstrate with a complete numerical code example.

10 MarksCyclomatic ComplexityCore

▼

📝 Detailed Examination Answer (10-Point Model):

Definition of Cyclomatic Complexity: Developed by Thomas McCabe in 1976, Cyclomatic Complexity $V(G)$ is a structural metric measuring the logical complexity and number of independent basis paths in a software program.
Control Flow Graph (CFG) Construction: Constructed from source code where Nodes represent sequential basic statement blocks and directed Edges represent conditional/unconditional jumps.
Predicate Nodes Concept: A node containing a conditional branching decision (e.g., `if`, `while`, `for`, `case`) that splits control into two or more outgoing edges.
Calculation Method 1 (Edges and Nodes): Formula: $V(G) = E - N + 2P$, where $E$ is the number of directed edges, $N$ is the number of nodes, and $P$ is connected components (typically $P=1$).
Calculation Method 2 (Predicate Nodes): Formula: $V(G) = P + 1$, where $P$ is the total count of binary predicate decision points in the graph.
Calculation Method 3 (Bounded Regions): Formula: $V(G) = R$, where $R$ is the total number of enclosed planar regions plus the single unbounded external region in the CFG.
Numerical Code Demonstration: Given code: `if (A > 0) { if (B > 0) x=1; else x=2; } else x=3;`: Nodes $N=6$, Edges $E=7$, Predicates $P=2$. Complexity $V(G) = 7 - 6 + 2(1) = 3$.
Deriving Linearly Independent Paths: Path 1: $1-2-3-5-6$ (A>0, B>0); Path 2: $1-2-4-5-6$ (A>0, B<=0); Path 3: $1-5-6$ (A<=0). Exactly 3 test cases required for 100% basis path coverage.
Software Risk Thresholds: $V(G) 1-10$: Low risk, simple program; $11-20$: Moderate risk, more complex; $21-50$: High risk, refactoring required; $>50$: Untestable, unstable code.
Benefits in Test Case Design: Provides an exact mathematical upper bound on the minimum number of white-box test cases necessary to guarantee full branch coverage.

Q2. Explain the Logic Coverage Criteria in White-Box Testing: Statement Coverage, Branch/Decision Coverage, Condition Coverage, and Path Coverage.

10 MarksLogic Coverage Criteria

▼

📝 Detailed Examination Answer (10-Point Model):

Concept of Structural Logic Coverage: A quantitative measurement framework evaluating the thoroughness of a test suite in exercising internal source code constructs.
1. Statement Coverage Definition: Measures the percentage of executable code statements executed by the test suite: $\frac{\text{Executed Statements}}{\text{Total Statements}} \times 100\%$.
Weakness of Statement Coverage: Weakest coverage criterion; 100% statement coverage can completely miss critical `else` branches in single-branch `if` statements without throwing errors.
2. Branch / Decision Coverage: Requires that every decision point evaluates to both `TRUE` and `FALSE` at least once: $\frac{\text{Executed Decision Outcomes}}{\text{Total Decision Outcomes}} \times 100\%$.
Branch Coverage Subsumption: 100% Branch Coverage guarantees 100% Statement Coverage, but 100% Statement Coverage does NOT guarantee 100% Branch Coverage.
3. Condition Coverage: Requires that each individual boolean sub-clause in a compound condition evaluates to both true and false independently (e.g., for `A || B`, testing $A$ and $B$).
Condition / Decision Coverage (C/DC): Combines branch and condition coverage, requiring every condition and every overall decision outcome to evaluate to true and false.
Modified Condition / Decision Coverage (MC/DC): Mandated by FAA for aviation software; proves that each individual condition can independently affect the decision outcome while holding other conditions fixed ($N+1$ tests).
4. Complete Path Coverage: The strongest coverage metric; tests every possible execution path from entry to exit, but practically impossible in loops due to infinite path explosion.
Practical University Exam Hierarchy: Path Coverage (Strongest) > MC/DC > Multiple Condition > Branch/Decision > Statement Coverage (Weakest).

Q3. Describe Mutation Testing, Loop Testing, and the specific challenges encountered in testing Object-Oriented software systems.

10 MarksAdvanced White-Box Testing

▼

📝 Detailed Examination Answer (10-Point Model):

Mutation Testing Core Concept: A fault-based white-box technique where synthetic defects (mutations) are introduced into the source code to assess the effectiveness of existing test suites.
Mutation Operators: Syntactic rules that modify code: Arithmetic Operator Replacement ($+$ to $-$), Relational Replacement ($>$ to $>=$), Logical Connector Replacement ($&&$ to $||$).
Killing Mutants vs Live Mutants: If a test case fails when run on the mutated code, the mutant is 'Killed'; if all tests pass, the mutant is 'Live' (indicating a gap in test coverage).
Equivalent Mutants Challenge: Mutations that alter syntax but produce identical semantic output to the original program (e.g., `i = i + 0`); cannot be killed by any test case.
Mutation Score Formula: Calculated as: $\text{Mutation Score} = \frac{\text{Killed Mutants}}{\text{Total Mutants} - \text{Equivalent Mutants}} \times 100\%$.
Loop Testing Methodology: Focuses on loop validation: Simple loops tested at boundaries ($0, 1, 2, m < n, n-1, n, n+1$ iterations); Nested loops tested from innermost outward.
OO Challenge: Encapsulation & Information Hiding: Private variables cannot be directly inspected by test drivers, requiring indirect state observation via public methods or reflection.
OO Challenge: Inheritance Complexities: Inherited methods operate in new subclass contexts and interact with overridden fields, necessitating re-testing of inherited code in each derived class.
OO Challenge: Polymorphism & Dynamic Binding: A polymorphic method invocation (`shape.draw()`) can resolve to hundreds of derived classes at runtime, creating combinatorial test explosion.
OO Challenge: State-Dependent Object Behavior: Object method execution depends on internal object state, requiring state-based testing (testing sequences of method invocations).

⚖️ Comprehensive Comparison & Difference Tables

8+ Comparison Criteria

📊 White-Box Testing vs Black-Box Testing

Comparison Parameter	White-Box Testing	Black-Box Testing
Knowledge of Code	Requires full access and in-depth knowledge of internal source code.	Zero knowledge of internal source code; tests strictly against specifications.
Testing Level	Primarily applied at Unit Testing and Integration Testing levels.	Applied at System Testing, Acceptance Testing (UAT), and Functional Testing.
Performed By	Software developers, unit testers, and test automation engineers.	Dedicated QA testers, business analysts, and end-users.
Basis of Test Design	Control flow graphs, statement logic, data paths, code structure.	SRS requirements, functional specifications, use cases, user stories.
Primary Techniques	Basis Path Testing, Statement/Branch Coverage, Mutation Testing.	Equivalence Class Partitioning, Boundary Value Analysis, Decision Tables.
Programming Skill	Requires expert programming and algorithmic knowledge.	Does not require programming knowledge (for manual execution).
Scope of Defects	Finds algorithmic flaws, memory leaks, unhandled branches, dead code.	Finds missing functional requirements, UI defects, usability issues.
Exhaustive Execution	Complex paths make exhaustive path testing impossible for large systems.	Large input domains make exhaustive input testing impossible.

📊 Statement Coverage vs Branch Coverage vs Path Coverage

Comparison Parameter	Statement Coverage	Branch / Decision Coverage	Path Coverage
Coverage Objective	Every executable line of code executed at least once.	Every decision branch evaluates to TRUE and FALSE.	Every independent path from entry to exit executed.
Rigor / Strength	Weakest structural coverage metric.	Moderate structural coverage metric.	Strongest structural coverage metric.
Missing Logic Detection	Fails to detect missing `else` branches.	Detects missing `else` conditions and branch branches.	Detects all complex multi-branch combinatorial failures.
Test Case Count	Requires the minimum number of test cases.	Requires more test cases than statement coverage.	Requires the largest number of test cases ($O(2^N)$).
Subsumption Rule	Subsumed by Branch and Path coverage.	Subsumes Statement coverage; subsumed by Path coverage.	Subsumes both Statement and Branch coverage.
Formula	$\frac{\text{Executed Statements}}{\text{Total Statements}} \times 100\%$	$\frac{\text{Executed Branches}}{\text{Total Branches}} \times 100\%$	$\frac{\text{Executed Paths}}{\text{Total Independent Paths}} \times 100\%$
Industry Requirement	Standard minimum baseline for unit tests (80%).	Standard requirement for enterprise applications.	Required for critical safety systems (avionics / medical).
Feasibility in Loops	Easily achievable even in presence of loops.	Easily achievable in loops.	Practically impossible with unbounded loops.

⚡ Quick Pre-Exam Revision Summary

5-Minute Recap

💡 Core Takeaways & High-Yield Summary

White-box testing examines internal source code logic and control flow paths.
Coverage hierarchy: Statement < Branch/Decision < Condition < MC/DC < Path Coverage.
Cyclomatic Complexity $V(G) = E - N + 2P = P_n + 1 = \text{Regions}$; defines independent basis paths.
Loop testing verifies boundary conditions: $0, 1, 2, m, n-1, n, n+1$ iterations.
Mutation testing evaluates test suite quality by measuring how many synthetic mutants are killed.
OO testing challenges: Encapsulation (hidden state), Inheritance (re-testing context), Polymorphism (dynamic binding explosion).