White Box Testing

WHITE-BOX TESTING [Structural Testing]

White box testing is a way of testing the external functionality of the code by examining and testing the program code that realizes the external functionality.
This is also known as clear box, or glass box, or open-box testing. White box testing takes into account the program code, code structure, and internal design flow.
White box testing is classified into static and structural testing.

White-box testing, sometimes called Glass-Box Testing, is a test case design method that uses the control structure of the procedural design to derive test cases.
Using white-box testing methods, the software engineer can derive test cases that

Guarantee that all independent paths within a module have been exercised at least once,
Exercise all logical decisions on their true and false sides,
Execute all loops at their boundaries and within their operational bounds, and
Exercise internal data structures to ensure their validity.

Advantages

It concentrates on the examination of coding.
It uncovers typographical errors.
Detects design errors.

Disadvantages

Do not full fill all testing goals since it only focuses on the examination of code.
Many other system problems may be left out
Test case needs to be changed for implementation of changes

Methods

Basis path testing

Flow graph notation
Independent program paths
Deriving test cases
Graph matrices

Control structure testing

Conditions Testing
Loop Testing
Testing of Simple Loops
Testing of Nested Loops

Testing of Concatenated Loops
Testing of Unstructured Loops

Basis Path testing

Referring to the figure, each circle, called a flow graph node, represents one or more procedural statements. A sequence of process boxes and a decision diamond can map into a single node.

Flow chart (a) Flow graph (b)

The arrows on the flow graph, called edges or links, represent the flow of control. An edge must terminate at a node, even if the node does not represent any procedural statements (e.g., see the symbol for the if-then-else construct).

Areas bounded by edges and nodes are called regions. When counting regions, we include the area outside the graph as a region. Each node that contains a condition is called a predicate node and is characterized by two or more edges emanating from it.

Independent program paths

An independent program path is any program that introduces at least one new set of processing statement or a new condition.

For example: paths illustrated in figure

Path 1: 1 – 11
Path 2: 1 – 2 – 3 – 4 – 5 – 10 – 1 – 11
Path 3: 1 – 2 – 3 – 6 – 8 – 9 – 10 – 1 – 11
Path 4: 1- 2 – 3 – 6 – 7 – 9 – 10 – 1 – 11

How many paths to look for can be counted by using cyclomatic complexity?

Cyclomatic complexity is software metric that provides a quantitative measure of the logical complexity of a program.

Three ways to identify cyclomatic complexity:

The number of regions 1. V (G) =E – N + 2
Where E= number of edges in a flow graph and N = number of nodes in a flow graph 2. V (G) =P + 1
Where, P= Predicate nodes in a flow graph

Deriving test cases

Steps to derive test cases:

Draw a corresponding flow graph
Determine cyclomatic complexity
The number of regions E.g. 4
V (G) =E – N + 2 E.g. : V(G)=11 – 9 + 2 =4
V (G) =P + 1 E.g. V(G) = 3 +1 =4

Determine a basis set of linearly independent paths

Path 1 : 1 – 11
Path 2: 1 – 2 – 3 – 4 – 5 – 10 – 1-…
Path 3: 1 – 2 – 3 – 6 – 8 – 9 – 10 – 1-…
Path 4 : 1- 2 – 3 – 6 – 7 – 9 – 10 – 1 -…
(…) indicates that any path through the remainder of the control structure is acceptable.

Graph matrices

In graph matrix based testing, we convert our flow graph into a square matrix with one row and one column for every node in the graph. If the size of graph increases, it becomes difficult to do path tracing manually.

A graph matrix is a square matrix whose size is equal to the number of nodes on the flow graph. It is the tabular representation of a flow graph and use to develop tool that assist in basis path testing.

Control structure testing

Condition testing

Condition testing aims to exercise all logical conditions in a program module. Logical conditions may be complex or simple. Logical conditions may be nested with many relational operations.
Relational expression: (E1 op E2), where E1 and E2 are arithmetic expressions.
For example, (x+y) – (s/t), where x, y, s and t are variables.
Simple condition: Boolean variable or relational expression, possibly proceeded by a NOT operator.
Compound condition: composed of two or more simple conditions, Boolean operators and parentheses along with relational operators.
Boolean expression: Condition without relational expressions

Loop testing

➢ Loops are fundamental to many algorithms. Loops can be categorized as, define loops as simple, concatenated, nested, and unstructured. Loops can be defined in many ways.

Testing simple loop

Skip the loop entirely
Only one passes through the loop
Two passes through the loop
M passes through the loop, where m < n
n –1, n, n + 1 passes through the loop ‘n’ is the maximum number of allowable passes through the loop

Testing Nested loop

Start at the innermost loop; set all other loops to minimum values
Conduct simple loop tests for the innermost loop while holding the outer loops at their minimum iteration parameter values; add other tests for out-of-range or excluded values
Work outward, conducting tests for the next loop, but keeping all other outer loops at minimum values and other nested loops to “typical” values.
Continue until all loops have been tested

Testing concatenated loop

For independent loops, use the same approach as for simple loops
Otherwise, use the approach applied for nested loops

Testing unstructured loop

Redesign the code to reflect the use of structured programming practices
Depending on the resultant design, apply testing for simple loops, nested loops, or concatenated loops