White Box Testing

White Box Testing is software testing technique in which internal structure, design and coding
of software are tested to verify flow of input-output and to improve design, usability and
security. In white box testing, code is visible to testers so it is also called Clear box testing, Open
box testing, Transparent box testing, Code-based testing and Glass box testing.

It is one of two parts of the Box Testing approach to software testing. Its counterpart, Blackbox
testing, involves testing from an external or end-user type perspective. On the other hand, White
box testing in software engineering is based on the inner workings of an application and revolves
around internal testing.

The term "WhiteBox" was used because of the see-through box concept. The clear box or
WhiteBox name symbolizes the ability to see through the software's outer shell (or "box") into its
inner workings. Likewise, the "black box" in "Black Box Testing" symbolizes not being able to
see the inner workings of the software so that only the end-user experience can be tested.

What do you verify in White Box Testing?

White box testing involves the testing of the software code for the following:

 Internal security holes

 Broken or poorly structured paths in the coding processes
 The flow of specific inputs through the code
 Expected output
 The functionality of conditional loops
 Testing of each statement, object, and function on an individual basis

The testing can be done at system, integration and unit levels of software development. One of
the basic goals of whitebox testing is to verify a working flow for an application. It involves
testing a series of predefined inputs against expected or desired outputs so that when a specific
input does not result in the expected output, you have encountered a bug.

How do you perform White Box Testing?

To give you a simplified explanation of white box testing, we have divided it into two basic
steps. This is what testers do when testing an application using the white box testing technique:

STEP 1) UNDERSTAND THE SOURCE CODE

The first thing a tester will often do is learn and understand the source code of the application.
Since white box testing involves the testing of the inner workings of an application, the tester
must be very knowledgeable in the programming languages used in the applications they are
testing. Also, the testing person must be highly aware of secure coding practices. Security is
often one of the primary objectives of testing software. The tester should be able to find security
issues and prevent attacks from hackers and naive users who might inject malicious code into the
application either knowingly or unknowingly.

Step 2) CREATE TEST CASES AND EXECUTE

The second basic step to white box testing involves testing the application's source code for
proper flow and structure. One way is by writing more code to test the application's source code.
The tester will develop little tests for each process or series of processes in the application.
This method requires that the tester must have intimate knowledge of the code and is often done
by the developer.

White Box Testing Techniques

A major White box testing technique is Code Coverage analysis. Code Coverage analysis
eliminates gaps in a Test Case suite. It identifies areas of a program that are not exercised by a
set of test cases. Once gaps are identified, you create test cases to verify untested parts of the
code, thereby increasing the quality of the software product

There are automated tools available to perform Code coverage analysis. Below are a few
coverage analysis techniques a box tester can use:

Statement Coverage:- This technique requires every possible statement in the code to be tested
at least once during the testing process of software engineering.

Branch Coverage - This technique checks every possible path (if-else and other conditional
loops) of a software application.

Apart from above, there are numerous coverage types such as Condition Coverage, Multiple
Condition Coverage, Path Coverage, Function Coverage etc. Each technique has its own merits
and attempts to test (cover) all parts of software code. Using Statement and Branch coverage
you generally attain 80-90% code coverage which is sufficient.

Following are important WhiteBox Testing Techniques:

 Statement Coverage
 Decision Coverage
 Branch Coverage
 Condition Coverage
 Multiple Condition Coverage
 Finite State Machine Coverage
 Path Coverage
 Control flow testing
 Data flow testing
What is Path Testing?

Path testing is a structural testing method that involves using the source code of a program in
order to find every possible executable path. It helps to determine all faults lying within a piece
of code. This method is designed to execute all or selected path through a computer program.

Any software program includes, multiple entry and exit points. Testing each of these points is a
challenging as well as time-consuming. In order to reduce the redundant tests and to achieve
maximum test coverage, basis path testing is used.

Basis Path Testing in Software Engineering

Basis Path Testing in software engineering is a White Box Testing method in which test cases
are defined based on flows or logical paths that can be taken through the program. The objective
of basis path testing is to define the number of independent paths, so the number of test cases
needed can be defined explicitly to maximize test coverage.

In software engineering, Basis path testing involves execution of all possible blocks in a program
and achieves maximum path coverage with the least number of test cases. It is a hybrid method
of branch testing and path testing methods.

Here we will take a simple example, to get a better idea what is basis path testing include

In the above example, we can see there are few conditional statements that is executed depending
on what condition it suffice. Here there are 3 paths or condition that need to be tested to get the
output,

 Path 1: 1,2,3,5,6, 7
 Path 2: 1,2,4,5,6, 7
 Path 3: 1, 6, 7
Steps for Basis Path testing
The basic steps involved in basis path testing include

 Draw a control graph (to determine different program paths)

 Calculate Cyclomatic complexity (metrics to determine the number of independent paths)
 Find a basis set of paths
 Generate test cases to exercise each path

Advantages of Basic Path Testing

 It helps to reduce the redundant tests
 It focuses attention on program logic
 It helps facilitates analytical versus arbitrary case design
 Test cases which exercise basis set will execute every statement in a program at least once

Conclusion:

Basis path testing helps to determine all faults lying within a piece of code.

Basis Path Testing is a white-box testing technique based on the control structure of a program
or a module. Using this structure, a control flow graph is prepared and the various possible paths
present in the graph are executed as a part of testing. Therefore, by definition,

Basis path testing is a technique of selecting the paths in the control flow graph, that provide a
basis set of execution paths through the program or module.

Since this testing is based on the control structure of the program, it requires complete
knowledge of the program’s structure. To design test cases using this technique, four steps are
followed :

1. Construct the Control Flow Graph

2. Compute the Cyclomatic Complexity of the Graph
3. Identify the Independent Paths
4. Design Test cases from Independent Paths

Let’s understand each step one by one.

1. Control Flow Graph –

A control flow graph (or simply, flow graph) is a directed graph which represents the control
structure of a program or module. A control flow graph (V, E) has V number of nodes/vertices
and E number of edges in it. A control graph can also have :
  Junction Node – a node with more than one arrow entering it.
 Decision Node – a node with more then one arrow leaving it.
 Region – area bounded by edges and nodes (area outside the graph is also counted as a region.).

Below are the notations used while constructing a flow graph :

 Sequential Statements –
 If – Then – Else –

 Do – While –

 While – Do –
  Switch – Case –

Cyclomatic Complexity –
The cyclomatic complexity V(G) is said to be a measure of the logical complexity of a program.
It can be calculated using three different formulae :

1. Formula based on edges and nodes :

V(G) = E-N+2
 Where,
e is number of edges,
n is number of vertices,

For example, consider first graph given above,

where, e = 4, n = 4 and p = 1

So,
Cyclomatic complexity V(G)
= 4 - 4 + 2
= 2

2. Formula based on Decision Nodes :

V(G) = d + P

where,
d is number of decision nodes,
P is number of connected nodes.

For example, consider first graph given above,

where, d = 1 and p = 1

So,
Cyclomatic Complexity V(G)
= 1 + 1
= 2

3. Formula based on Regions :

V(G) = number of regions in the graph

For example, consider first graph given above,

Cyclomatic complexity V(G)

= 1 (for Region 1) + 1 (for Region 2)
= 2

Hence, using all the three above formulae, the cyclomatic complexity obtained remains same. All
these three formulae can be used to compute and verify the cyclomatic complexity of the flow
graph.

Note –

1. For one function [e.g. Main( ) or Factorial( ) ], only one flow graph is constructed. If in a program,
there are multiple functions, then a separate flow graph is constructed for each one of them.
 Also, in the cyclomatic complexity formula, the value of ‘p’ is set depending of the number of
graphs present in total.
2. If a decision node has exactly two arrows leaving it, then it is counted as one decision node.
However, if there are more than 2 arrows leaving a decision node, it is computed using this
formula :

d = k - 1

Here, k is number of arrows leaving the decision node.

Independent Paths :
An independent path in the control flow graph is the one which introduces at least one new edge
that has not been traversed before the path is defined. The cyclomatic complexity gives the
number of independent paths present in a flow graph. This is because the cyclomatic complexity
is used as an upper-bound for the number of tests that should be executed in order to make sure
that all the statements in the program have been executed at least once.

Consider first graph given above here the independent paths would be 2 because number of
independent paths is equal to the cyclomatic complexity.
So, the independent paths in above first given graph :

 Path 1:

A -> B

 Path 2:

C -> D

Note –
Independent paths are not unique. In other words, if for a graph the cyclomatic complexity
comes out be N, then there is a possibility of obtaining two different sets of paths which are
independent in nature.

Design Test Cases :

Finally, after obtaining the independent paths, test cases can be designed where each test case
represents one or more independent paths.

Advantages :
Basis Path Testing can be applicable in the following cases:

1. More Coverage –
Basis path testing provides the best code coverage as it aims to achieve maximum logic coverage
instead of maximum path coverage. This results in an overall thorough testing of the code.
2. Maintenance Testing –
When a software is modified, it is still necessary to test the changes made in the software which
as a result, requires path testing.
 3. Unit Testing –
When a developer writes the code, he or she tests the structure of the program or module
themselves first. This is why basis path testing requires enough knowledge about the structure
of the code.
4. Integration Testing –
When one module calls other modules, there are high chances of Interface errors. In order to
avoid the case of such errors, path testing is performed to test all the paths on the interfaces of
the modules.
5. Testing Effort –
Since the basis path testing technique takes into account the complexity of the software (i.e.,
program or module) while computing the cyclomatic complexity, therefore it is intuitive to note
that testing effort in case of basis path testing is directly proportional to the complexity of the
software or program.

Control Structure Testing

Control structure testing is used to increase the coverage area by testing various control
structures present in the program. The different types of testing performed under control
structure testing are as follows-

1. Condition Testing
2. Data Flow Testing
3. Loop Testing

1. Condition Testing :
Condition testing is a test cased design method, which ensures that the logical condition and
decision statements are free from errors. The errors present in logical conditions can be incorrect
boolean operators, missing parenthesis in a booleans expression, error in relational operators,
arithmetic expressions, and so on.

The common types of logical conditions that are tested using condition testing are-

1. A relation expression, like E1 op E2 where ‘E1’ and ‘E2’ are arithmetic expressions and
‘OP’ is an operator.
2. A simple condition like any relational expression preceded by a NOT (~) operator.
For example, (~E1) where ‘E1’ is an arithmetic expression and ‘a’ denotes NOT
operator.
3. A compound condition consists of two or more simple conditions, Boolean operator, and
parenthesis.
For example, (E1 & E2)|(E2 & E3) where E1, E2, E3 denote arithmetic expression and
‘&’ and ‘|’ denote AND or OR operators.
 4. A Boolean expression consists of operands and a Boolean operator like ‘AND’, OR,
NOT.
For example, ‘A|B’ is a Boolean expression where ‘A’ and ‘B’ denote operands and |
denotes OR operator.

2. Data Flow Testing :

The data flow test method chooses the test path of a program based on the locations of the
definitions and uses all the variables in the program.

The data flow test approach is depicted as follows suppose each statement in a program is
assigned a unique statement number and that theme function cannot modify its parameters or
global variables.
For example, with S as its statement number.

DEF (S) = {X | Statement S has a definition of X}

USE (S) = {X | Statement S has a use of X}

If statement S is an if loop statement, them its DEF set is empty and its USE set depends on the
state of statement S. The definition of the variable X at statement S is called the line of statement
S’ if the statement is any way from S to statement S’ then there is no other definition of X.

A definition use (DU) chain of variable X has the form [X, S, S’], where S and S’ denote
statement numbers, X is in DEF(S) and USE(S’), and the definition of X in statement S is line at
statement S’.

A simple data flow test approach requires that each DU chain be covered at least once. This
approach is known as the DU test approach. The DU testing does not ensure coverage of all
branches of a program.

However, a branch is not guaranteed to be covered by DU testing only in rar cases such as then
in which the other construct does not have any certainty of any variable in its later part and the
other part is not present. Data flow testing strategies are appropriate for choosing test paths of a
program containing nested if and loop statements.

3. Loop Testing :
Loop testing is actually a white box testing technique. It specifically focuses on the validity of
loop construction.
Following are the types of loops.

1. Simple Loop – The following set of test can be applied to simple loops, where the
maximum allowable number through the loop is n.
1. Skip the entire loop.
2. Traverse the loop only once.
3. Traverse the loop two times.
4. Make p passes through the loop where p<n.
5. Traverse the loop n-1, n, n+1 times.
2. Concatenated Loops – If loops are not dependent on each other, contact loops can be
tested using the approach used in simple loops. if the loops are interdependent, the steps
are followed in nested loops.
3. Nested Loops – Loops within loops are called as nested loops. when testing nested loops,
the number of tested increases as level nesting increases.
The following steps for testing nested loops are as follows-
1. Start with inner loop. set all other loops to minimum values.
2. Conduct simple loop testing on inner loop.
3. Work outwards.
4. Continue until all loops tested.
4. Unstructured loops – This type of loops should be redesigned, whenever possible, to
reflect the use of unstructured the structured programming constructs.