White Box Testing
What is White Box Testing?
White box testing is a technique that uses a program’s internal or source code to design different test cases to check the quality of the program. In this technique, the internal structure and implementation of how an application works are known to the tester.
White box testing is also known by many other names such as Glass Box Testing, Clear Box Testing, and Open Box Testing.
What Does White Box Testing Focus On?
Following are the steps that are taken into consideration while performing white box testing:
- Verification of security holes in source code
- Testing of any broken or incomplete path
- To verify the flow of structure as mentioned in the software requirement document
- To check the conditionality of all loops and the overall functionality of the software
- To check if all the expected outcomes are met
- Line-by-line verification of code
The above-mentioned steps can be executed at each level of testing i.e Unit, Integration and System Testing.
White Box Testing Focuses On verifying the proper flow and functionality of the application. The test cases are executed and the output is compared to the desired outcome, if any of the output does not match the expected outcome, it means that a bug is encountered.
Types of White Box Testing
White box testing covers different types of tests. The various types of testing are given below:
1. Path Testing
Path Testing is a white-box testing approach based on a program’s control structure. A control flow graph is created using the structure, and the different pathways in the graph are tested as part of the process. Because this testing is dependent on the program’s control structure, it involves a thorough understanding of the program’s structure.
2. Loop Testing
Loops are one of the fundamental concepts that are implemented in a large number of algorithms. Loop Testing is concerned with determining the loop validity of these algorithms. The goal of this testing is to uncover any vulnerabilities that may exist in any particular loop. One example of a vulnerability that can be found in loop testing is wrong indexes in loops. When the indexes in an iterative loop are not correctly programmed, it could result in more bytes being copied than needed.
3. Conditional Testing
In this type of testing, the logical conditions for every value are checked, whether it is true or false. This means that both the if and else conditions are verified, in the case of an IF-ELSE conditional statement.
4. Unit Testing
A unit test is a method of testing a unit, which is the smallest piece of code in a system that can be logically separated. Unit testing ensures that each component performs as intended.
5. Mutation Testing
Mutation testing is a type of testing based on alterations or mutations. Minute modifications are made to the source code to see if the provided test cases can discover bugs in the code. The ideal situation would be for none of the test cases to pass. If the test succeeds, it indicates that there is a mistake in the code. The mutant (the modified form of our code) is said to have survived. If the test fails, there was no error in the code, and the mutant was eliminated. Our objective is to eliminate all mutations.
6. Integration Testing
Integration testing is performed to check that modules/components operate as intended when combined, i.e. to ensure that modules that performed fine independently do not have difficulties when merged.
7. Penetration Testing
White box penetration testing, also known as crystal or oblique box pen testing, provides the tester with complete network and system data, including network maps and passwords. This saves time and lowers the overall cost of an engagement. In software testing, we use the engagement model. An engagement model is a strategy that defines the basis of collaboration between the software development company and the client. The focus of an engagement model is on the demands, needs, and interests of the client. It also assures flexibility, responsibility, and a level of control. A white box penetration test may be used to simulate a specific attack on a given system by employing as many attack paths as feasible.
8. Testing based on Memory Perspective
The size of the code could increase due to the following factors:
There is no code reuse: Consider the following scenario: We have four different blocks of code written for the development of software, and the first 10 lines of each code block are identical. Now, these 10 lines could be written as a function and can be made available to the four code blocks listed above. Furthermore, if a defect exists, we may alter a line of code in the function rather than the entire code.
If one programmer produces code with a file size of up to 250kb, another programmer may develop equivalent code with different logic with a file size of up to 100kb.
9. Test Performance of the Program
An application might be slow due to several factors and a developer or tester can't go through each line of code to detect a bug and verify it. Tools like Rational Quantify are used to come over this issue. There are some other tools as well available in the industry for the same purpose, such as WebLOAD, LoadNinja, LoadView, and StresStimulus.
A general performance test using Rational Quantify is carried out in the below-given procedure.
Once the code for the application is complete, this tool will go through the entire code while executing it and the outcome would be displayed in the shape of thick and thin lines on a result sheet.
The thick line indicates which part of the code is time-consuming and when the lines would appear as thin, this means that the program’s efficiency has been improved.
And, rather than doing it manually, the developers will execute white box testing automatically since it saves time.
White Box Testing Techniques
1. Statement Coverage
One of the main objectives of white box testing is to cover as much of the source code as possible. Code coverage is a measure that indicates how much of an application’s code contains unit tests that validate its functioning.
Using concepts such as statement coverage, branch coverage, and path coverage, it is possible to check how much of an application’s logic is really executed and verified by the unit test suite. These different white box testing techniques are explained below.
2. Branch Coverage
In programming, “branch” is equivalent to, say, an “IF statement” where True and False are the two branches of an IF statement.
As a result, in Branch coverage, we check if each branch is processed at least once.
There will be two test conditions in the event of an “IF statement”:
One is used to validate the “true” branch, while the other is used to validate the “false” branch.
3. Path Coverage
Path coverage examines all the paths in a given program. This is a thorough strategy that assures that all program paths are explored at least once. Path coverage is more effective than branch coverage. This method is handy for testing complicated applications.
4. Decision Coverage
Decision Coverage is a white box testing methodology that reports the true or false results of each boolean expression present in the source code. The purpose of decision coverage testing is to cover and validate all available source code by guaranteeing that each branch of each potential decision point is traversed at least once.
A decision point is a point when there is a possibility of the occurrence of two or more outcomes from control flow statements such as an if statement, a do-while statement or a switch case statement.
Expressions in this coverage can become difficult at times. As a result, achieving 100% coverage is quite difficult.
5. Condition Coverage
Condition coverage, also known as expression coverage, is a testing method for testing and evaluating the variables or sub-expressions in a conditional statement. The purpose of condition coverage is to examine the outcome of each logical condition.
Only expressions with logical operands (an operand is considered a logical operand if it has its output as either TRUE or FALSE) are examined in this coverage. Condition coverage does not ensure complete decision coverage.
6. Multiple Condition Coverage
In this testing technique, all the different combinations of conditions for each decision are evaluated.
For example, we have the following expression,
So, in this case, the test cases would be as given below:
The point to be noted here is that in this example we have 2 expressions A and B, and as result, we have 4 test cases. So, similarly, for 3 conditions we will have 8 test cases.
So, the general formula for Multiple Condition Coverage is that for n conditions, there will be 2n test cases.
7. Finite State Machine Coverage
Finite state machine coverage is one of the most difficult forms of code coverage approach. This is due to the fact that it works on the design’s functionality. This coverage approach requires you to count the number of times a state is visited or transited. It also determines how many sequences are contained within a finite state system. A sequence in a Finite State Machine is a sorted list of inputs or outputs.
8. Control Flow Testing
This testing technique aims to establish the program’s execution order by use of a control structure.
To construct a test case for the program, the control structure of the programme is used. The tester selects a specific section of a programme to build the testing path.
It is used mostly in unit testing. The test cases are represented using the control graph of the program.
The control Flow Graph consists of the node, edge, decision node, and junction node for all execution paths.
Quick Notes:
- Node A node is used to create a basic path for procedures. It depicts the sequence in which different operations are to be carried out.
- Edge An edge in a control flow graph is used to link the directions between different nodes.
- Decision Node A decision node is used to determine the next node for a given procedure as per the result of the last operation carried out.
- Junction Node It is the point where at least three links meet.
How do you Perform White Box Testing?
The process of performing white box testing is divided into the following steps:
1. Understanding the Code
The first and most critical step is to analyze the source code of the application being tested. A tester should be familiar with the internal structure of the code, as this will help in testing the application. A better understanding of source code will also help in identifying and writing the critical test cases that trigger security vulnerabilities and helps in achieving 100% test coverage. Because application security is the primary goal, testers should be aware of the product’s security risks.
2. Creating and Executing Test Cases
The second step includes the real development of test cases based on Statement/Decision/Condition/Branch coverage, as well as the actual execution of test cases to ensure that the software has been tested completely. The test cases will be written by the tester by dividing the applications into categories as Statement/Decision/Condition/Branch.
- Statement coverage will include those statements that are executed at least once during the execution of the program.
- Similarly, branch coverage will include the outcome for every code module (statement or loop).
- A decision coverage will include reports for each boolean expression present in the source code. An expression is said to be boolean if it evaluates to either TRUE or FALSE.
- And, conditional coverage is used to test the variables used in different types of conditional statements like IF / ELSE, SWITCH etc.
Example for Control Flow Graph
In the graph above, “Start”, “Age”, “Eligible”, “Not Eligible” and “Stop” are nodes.
N > = 18 depicts the decision node, and the arrows depicting the flow of operations are edges.
Finally, the point where the 3 edges meet is the junction node in the above control flow graph.
9. Data Flow Testing
Data Flow Testing is the test technique that focuses on data variables and their values, which are utilized by using the control flow diagram for the programming logic of the software product. In Data flow testing, a type of white box testing, every data variable is tracked and verified. The primary principle behind this test is to identify coding problems that might result in incorrect implementation and use of data variables or data values, i.e. data anomalies like variables declared but not used in the code later, in the software code.
White Box Testing Example
For understanding how to create test cases in white box testing, let’s consider the pseudo code given below:
- INPUT A & B
- C = A + B
- IF C>100
- PRINT “ITS DONE”
- ELSE
- PRINT “ITS PENDING”
Since the goal of white box testing is to verify and cross-check all the different loops, branches and decision statements, so to exercise white box testing in the code given above, the two test cases would be –
- A= 33, B=45
- A=40, B=70
For the first test case, A=33, B=45; C becomes 78, due to which it will skip the 4th line in the pseudo-code, since C < 100 and will directly print the 6th line, i.e ITS PENDING.
Now, for the second test case, A=40, B=70; C becomes 110, which means that C > 100 and therefore it will print the 4th line and the program will be stopped.
These test cases will ensure that each line of the code is traversed at least once and will verify for both true and false conditions.
White Box Testing Tools
Some of the common white box testing tools used are given below –
- Veracode
- RCUNIT
- cfix
- GoogleTest
- EMMA
- NUnit
Advantages of White Box Testing
- Optimization of code by the revelation of hidden faults.
- Transparency of the internal code structure helps to derive the type of input data needed to adequately test an application.
- This incorporates all conceivable code paths, enabling a software engineering team to carry out comprehensive application testing.
Disadvantages of White Box Testing
- A complicated and expensive process that involves the skill of an experienced professional, programming ability and knowledge of the underlying code structure.
- A new test script is necessary when the execution changes too frequently.
- Detailed testing with the white box testing approach is significantly more demanding if the application covers many different areas, such as the Gojek Super App.
Conclusion
White box testing is a helpful way to simulate the actions of testers who have complete knowledge of the internal operations of the target system. It gives the tester complete access to the internal information of the program. Thus, as many structural loopholes as possible may be identified.