Exploring White Box Testing in Software Engineering

White box testing is a software and application testing technique popular in software engineering. The core focus of white box testing is the internal structure (design and code) of an application rather than just its function as is the case for black box testing. White box testing is also referred to as Clear Box testing, Open Box testing, Transparent Box testing, and Code-Based testing. Unlike black box testing which focuses on the functional and behavioral components of an application, white box testing focuses on the structural design of a software entity; hence its alternative name, structural testing.

For a white box test, the person or team tasked with running the tests must have a deep understanding of the internal structures of an application and its source code. A tester can use the detailed knowledge of the internal mechanisms of a system to create test cases, which ensures that the system is complete and the code performs its duties as intended. The test cases focus on specific spots of a software application such as code statements and program branches (program paths).

Focus of White Box Testing

1. Error and fault detection: Analyzing the internal mechanism of an application can help identify programming errors (syntax and logic errors), which result in incorrect program output (for logic errors) and system failure / crash (for syntax errors). These errors can be as a result of typographical errors or incorrect programming assumptions.

2. Security analysis: White box test cases can help identify security vulnerabilities in an application. By analyzing the code blocks, a tester can identify security holes within an application without inputting data into the application.

3. Broken program paths and branches: Poorly structured paths, branches, and statements usually cause unexpected behavior and errors in an application.

4. Incorrect component integrations: Incorrect internal integrations usually lead to logical errors and often system crashes. White box test cases focus on the internal mechanism of an application and identify how data flows through each module of the application.

White Box Testing Techniques

There are various techniques that can help analyze the working flow of a software application to detect issues and errors. Error and fault detection made possible through the comparison of predefined input data against the expected output and the actual output of the whole application, a path within the application, and a branch. White box testing can be done throughout all levels of system developments; however, an emphasis is done at the system, unit, and integration levels.

A. Control Flow / Coverage Testing

Control flow is a fundamental testing technique that focuses on the flow of a program. It is applicable on both small and large programs of varying complexities. The most common coverage is control flow testing are statement coverage, branch coverage, and condition (decision) coverage.

1. Statement Coverage

During testing, statement coverage ensures that each statement within a code block is executed at least once. In other words, statement coverage transverses each line of code at least once. System coverage helps identify lines of code that are faulty or missing from the code.

Consider the PHP script below:

/*PHP SCRIPT 1*/

function number_compare($a, $b){
	$result = '';
	if($a > 0 && $b > 0){
		if($a>$b){
			$result = '{$a} is greater than {$b}';
		}else{
			$result = '{$a} is equal or less than {$b}';
		}
	}else{
		$result = "Either or both = 0";
	}
	
	return $result;
}

The above script can be designed into a flow chart as shown below:

Flowchart of PHP Script 1

In the case of Statement Coverage, every node must be traversed at least once. To achieve 100% statement coverage, a tester can use the test cases a=3 and b=5. In this test case, the program will follow the path highlighted in red and in so doing, the test will have achieved 100% statement coverage.

2. Branch Coverage

Branch coverage focuses on decision points (true/false) in the code, which include all if-else blocks and conditional loops. Test cases are designed so that each branch in all decision points is executed (transversed) at least once. Branch coverage aims to identify any missing branches (decision points) in the code.

Consider the code in PHP SCRIPT 1 above.

To achieve 100% branch coverage, every possible path should be tested independently. Since there are three possible decision paths in the PHP script above; a tester can use the test cases a=5 and b=3, which will execute as shown in flowchart branch A. The tester would then create a second test cabse a=3 and b=5, where branch B will be executed. The third test case can be a=0 and b=4, which will execute as shown in flowchart branch C.

Flowchart of PHP Script 1 (All Possible Decision Paths)

3. Decision coverage (Condition coverage)

During testing, condition coverage ensures that all condition expressions within the code are tested - that is, all possible combinations of true and false conditions. In software engineering, conditional expressions are achieved through the use of if/else/else if statements, switch statements, and loops (while, do while, for statements). A condition is a boolean-valued expression - evaluates to either true or false. Condition coverage is then decomposed to decision coverage, where each possible combination within a decision is tested.

Consider the Javascript code below:

/*Javascript SCRIPT 1*/

function getGrade(score){
	var grade;
	if(score >= 90){
		grade = "A";
	}else if(score >= 80){
		grade = "B";
	}else if(score >= 70){
		grade = "C";
	}else if(score >= 60){
		grade = "D";
	}else{
		grade = "F";
	}
	
	return grade;
}

In this code snippet, the function getGrade() takes a score as input and returns a corresponding letter grade based on certain if/else if/else conditions.

To achieve 100% decision (condition) coverage, a tester needs to test each condition with both true and false scenarios. The tester can design test cases to cover all conditions as:

1. Test Case 1: Score = 95; Expected outcome; A

2. Test Case 2: Score = 87; Expected outcome; B

3. Test Case 3: Score = 70; Expected outcome; C

4. Test Case 4: Score = 63; Expected outcome; D

5. Test Case 5: Score = 25; Expected outcome; F

By applying decision (condition) coverage, the tester ensures that the code has been thoroughly tested for all possible conditions and outcomes, reducing the likelihood of undetected errors or missed scenarios within the decision logic.

B: Basic Path Testing

Basic path testing is a white case testing that focuses on the logical flow of a program by covering all the possible linearly independent paths of the code.

In basic path testing, the following procedure is used:

1. Draw the corresponding control flow graphs (CFG): CFG is a graphical representation of a program that illustrates the control flow of a program from statements, to decision points, to loops. In CFG, each node represents a statement, while each edge represents the flow of control between the statements (nodes).

   
   A Representation of Nodes and Edges

2. Calculate the cyclomatic complexity, V(G): The cyclomatic complexity is derived from the CFG. In software engineering, cyclomatic complexity is a metric that determines the complexity of a program. The formula for cyclomatic complexity is V(G) = E - N + 2, where E is the number of edges and N is the number of nodes.

3. Identify the linearly independent paths: Independent paths represent all possible combinations and scenarios of loops and decisions that are needed to be covered. Therefore, if a program has 10 linearly independent paths, 10 test cases should be created.

4. Finally, test cases are designed for all linearly independent paths, where each test represents each unique path through the code. For each test case, an input should be defined and an expected output determined.

C: Loop Testing

Loop testing focuses on different paths and scenarios within loops in program code. Fundamentally, loop testing ensures that all loops are behaving as expected, from their entry conditions, to iterations, to their exit conditions. Commonly, errors in loops occur near the beginnings and ends of the loop.

There are three main types of loops in software engineering:

1. Simple loops: A nested loops can be represented as follows:

   
   A Simple loop

   These loops are of size m. For simple loops, test cases are designed that:

   1. Skip the loop entirely. This condition is only fulfilled when the conditions of executing the loop are not met.

   2. Only 1 pass through the loop

   3. 2 passes through the loop

   4. n passes through the loop, where n<m

   5. m + 1 and m - 1 passes

2. Nested loops testing: Nested loops can be represented as follows:

   
   Nested Loops

   With all other loops set to the minimum values, start conducting simple loop testing on the innermost loop. Work outwards testing each loop until all loops have been tested.

3. Concatenated loops testing: Concatenated loops can be represented as follows:

   
   Concatenated Loops

   Concatenated but independent loops are tested using the simple loop testing. On the other hand, concatenated but dependent loops are treated as nested loops and the nested loops testing is used.

 

D: Data Flow Testing

Data flow testing focuses on the lifetime of a particular piece of data such as a variable in a program. It is concerned with where and how variables are created, how they are used, and how they are killed (destroyed) in a program.

Data flow testing helps identify:

1. Declared variables that are never used

2. Undeclared variables that have been used in a program

3. Multiple declarations of a variable before it is used.

 

Advantages of White box Testing

1. White box testing is thorough as entire code structures are tested. This comprehensive testing ensures that all potential issues, errors, and defects are identified.

2. Testing is done at an early stage during development enabling any issues, such as coding errors and logic flaws, to be identified before a graphical user interface (GUI) is provided as is required for black box testing. Early detection ensures issues are fixed early on.

3. White box testing can be included within the Software Development Lifecycle (SDLC)

4. White box testing allows for code optimization. Code can be restructured and improved for security and performance during testing.

Disadvantages of White box Testing

1. Testers need to have in-depth knowledge of the programming language used and access to the program’s source code.

2. Familiarity with the inner workings of a program can bring bias during testing

3. For larger and complex programs, the costs associated with testing are usually very high.

4. Testers can focus too much on the internal structures of the program missing the much-significant external structures.

5. Once any changes are made, new test cases need to be redesigned.