WhiteBox Testing

WhiteBox Testing

White box testing techniques analyze the internal structures of the software, including the used data structures, interior design, and code structure, rather than just the functionality as in black box testing. It is also called glass box testing, transparent box testing, or structural testing. Another name for white box testing is OK testing or open box testing.

Working process of white box testing:

Input: Requirements, Functional specifications, design documents, source code.

Processing: Performing risk analysis to guide through the entire process.

Proper test planning involves designing test cases to cover the whole code and executing rinse-repeat until error-free software is achieved. The results are also communicated.

Output: Preparing the final report of the testing process as a whole.

Testing techniques:

Statement coverage: In this technique, the aim is to traverse all statements at least once. Hence, each line of code is tested. In the case of a flowchart, every node must be crossed at least once. Since all lines of code are covered, it helps point out faulty code.

Statement Coverage Example

Branch coverage: This technique involves designing test cases so that each branch from all decision points is traversed at least once. Similarly, all edges in a flowchart must be crossed at least once.
Branch Coverage
Condition Coverage: In this technique, all individual conditions must be covered, as shown in the following example:

READ X, Y
IF(X == 0 || Y == 0)
PRINT ‘0’
#TC1 – X = 0, Y = 55
#TC2 – X = 5, Y = 0

Multiple Condition Coverage: In this technique, all possible combinations of possible condition outcomes are tested at least once. Let’s consider the following example:

READ X, Y
IF(X == 0 || Y == 0)
PRINT ‘0’
#TC1: X = 0, Y = 0
#TC2: X = 0, Y = 5
#TC3: X = 55, Y = 0
#TC4: X = 55, Y = 5

Basis Path Testing: In this technique, control flow graphs are made from code or flowchart, and then Cyclomatic complexity is calculated, which defines the number of independent paths so that the minimal Number of test cases can be designed for each separate path. Steps:
Make the corresponding control flow graph.
Calculate the cyclomatic complexity.
Find the independent paths.
Design test cases corresponding to each independent path
V(G) = P + 1, where P is the Number of predicate nodes in the flow graph
V(G) = E – N + 2, where E is the Number of edges and N is the total number of nodes
V(G) = Number of non-overlapping regions in the graph
#P1: 1 – 2 – 4 – 7 – 8
#P2: 1 – 2 – 3 – 5 – 7 – 8
#P3: 1 – 2 – 3 – 6 – 7 – 8
#P4: 1 – 2 – 4 – 7 – 1 – . . . – 7 – 8

Loop Testing: Loops are widely used and fundamental to many algorithms; hence, their testing is essential. Errors often occur at the beginnings and ends of loops.

  • Simple loops: For simple loops of size n, test cases are designed that:
    Skip the loop entirely.
    Only one pass through the loop
    Two passes
    m passes, where m < n
    n-1 ans n+1 passes
  • Nested loops: For nested loops, all the loops are set to their minimum count, and we start from the innermost loop. Simple loop tests are conducted for the innermost loop, which is worked outwards until all the loops have been tested.
  • Concatenated loops: Independent loops, one after another. Simple loop tests are applied for each. If they’re not independent, treat them like nesting.