How to Perform White Box Testing
I’ve been working in software testing for about ten years, and during that time I’ve observed that testers are the most passionate people in the entire software industry.
This is mostly because there is always room for improvement for testers. If they want to, a tester can have full development of a technology, method, or domain.
The adage “There is always a darker side” is also accurate, though.
Testers also indeed avoid the type of testing that they feel to be very complicated and the developer’s piece of cake. Yes, it is referred to as “White Box Testing”.
White Box Testing Coverage
White Box Testing ensures coverage of the code’s specifications.
#1) Code coverage
#2) Segment coverage: Ensure that each code statement is executed once.
#3) Branch Coverage or Node Testing: Coverage of each code branch.
#4) Compound Condition Coverage: For multiple conditions, test each condition with multiple paths and a combination of different paths to reach that condition.
#5) Basis Path Testing: Each independent path in the code is taken for testing.
#6) Data Flow Testing (DFT): In this approach, you track the specific variables through each calculation, thus defining the set of intermediate paths through the code.
DFT reflects dependencies, but it is mainly through sequences of data manipulation. In short, each data variable is tracked and its use is verified. This approach uncovers bugs like variables used but not initialized, declared but not used, and so on.
#7) Path Testing: Path testing is where all paths through the code are defined and covered. It’s a time-consuming task.
#8) Loop Testing: These strategies relate to testing single loops, concatenated loops, and nested loops. Independent and dependent code loops and values are tested with this approach.
Why do We Perform WBT
To ensure the following:
- All independent paths within a module have been exercised at least once.
- Their true and false values verify all logical decisions.
- All loops are executed at their boundaries and within their operational bounds of internal data structure validity.
To discover the following bugs:
- Logical errors creep into our work when we design and implement functions, conditions, or controls that are external to the program.
- Design errors are because of the difference between the logical flow of the program and the actual implementation.
- Typographical errors and syntax checking.
Does this testing require detailed programming skills?
We need to write test cases that ensure the complete coverage of the program logic.
For this, we need to know the program well, i.e. We need to know the specifications and the code to be tested. Knowledge of programming languages and logic is required for this type of testing.
Limitations
Difficult to test every path of the loops in the program. This means exhaustive testing is not possible for large systems. This does not mean that WBT is not effective. Selecting important logical paths and data structures for testing is practically possible and effective.
The Difference Between White-Box and Black-Box Testing
To put it in simple terms:
White box testing involves viewing and testing the actual code, whereas black box testing involves testing the software from the perspective of the user. While internal system code is not visible during black box testing, it is visible and tested during WBT.
White box testing is used by both developers and testers. It enables them to distinguish between lines of code that have been run and those that have not. This could be a sign of an error or a lack of reasoning, which could ultimately have unfavorable effects.
Steps to Perform WBT
Step #1: Understand the functionality of an application through its source code. This means that a tester must be well-versed in the programming language and the other tools as well as techniques used to develop the software.
Step #2: Create the tests and execute them.
When we discuss the concept of testing, “coverage” is considered to be the most important factor. Here I will explain how to have maximum coverage from the context of White box testing.
Types and Techniques of White Box Testing
There are several types and different methods for each white box testing type.
See the image given below for your reference.
Today, we are going to focus mainly on the execution testing types of the unit testing white box technique’.
3 Main White Box Testing Techniques include:
- Statement Coverage
- Branch Coverage
- Path Coverage
Note that the statement, branch, or path coverage does not identify any bugs or defects that need to be fixed. It only identifies those lines of code which are either never executed or remain untouched. Based on this, we can focus on further testing.
Let’s understand these techniques one by one with a simple example.
#1) Statement Coverage
In a programming language, a statement is nothing but a line of code or instruction for the computer to understand and act accordingly. A statement becomes an executable statement when it gets compiled and converted into the object code and performs the action when the program is in running mode.
Hence “Statement Coverage”, as the name itself suggests, is the method of validating whether every line of the code is executed at least once.
#2) Branch Coverage
“Branch” in a programming language is like the “IF statements”. An IF statement has two branches: True and False. So in Branch coverage (also called Decision coverage), we validate whether each branch is executed at least once.
In the case of an “IF statement”, there will be two test conditions:
- One to validate the true branch.
- Else to validate the false branch.
Hence, in theory, Branch Coverage is a testing method that when executed ensures that every branch from each decision point is executed.
#3) Path Coverage
Path coverage tests all the paths of the program. This is a comprehensive technique that ensures that all the paths of the program are traversed at least once. Path Coverage is even more powerful than Branch coverage. This technique is useful for testing complex programs.
Let’s take a simple example to understand all these white-box testing techniques.
White Box Testing Example
Consider the simple pseudocode given below:
| 1234 | INPUT A & BC = A + BIF C>100PRINT “ITS DONE” |
For Statement Coverage, we would only need one test case to check all the lines of the code.
This means:
If I consider TestCase_01 to be (A=40 and B=70), then all the lines of code will be executed.
Now the question arises:
- Is that sufficient?
- What if I consider my Test case as A=33 and B=45?
Because the Statement coverage will only cover the true side, for the pseudo-code, only one test case would NOT test it. As a tester, we have to consider the negative cases as well.
Hence, for maximum coverage, we need to consider “Branch Coverage”, which will evaluate the “FALSE” conditions.
In the real world, you may add appropriate statements when the condition fails.
So now the pseudocode becomes:
| 12345678 | INPUT A & BC = A + BIF C>100PRINT “ITS DONE”ELSEPRINT “ITS PENDING” |
Since Statement coverage is not sufficient to test the entire pseudo code, we would require Branch coverage to ensure maximum coverage. So for Branch coverage, we would require two test cases to complete the testing of this pseudo code.
TestCase_01: A=33, B=45
TestCase_02: A=25, B=30
With this, we can see that every line of the code is executed at least once.
Here are the Conclusions that have been derived so far:
- Branch Coverage ensures more coverage than Statement coverage.
- Branch coverage is more powerful than Statement coverage.
- 100% Branch coverage itself means 100% statement coverage.
- However, 100 % statement coverage does not guarantee 100% branch coverage.
Now let’s move on to Path Coverage:
As mentioned earlier, Path coverage is used to test complex code snippets, which involve loop statements or a combination of loops and decision statements.
Consider this pseudocode:
| 123456789 | INPUT A & BC = A + BIF C>100PRINT “ITS DONE”END IFIF A>50PRINT “ITS PENDING”END IF |
Now, to ensure maximum coverage, we would require 4 test cases.
How? Simply there are 2 decision statements, so for each decision statement, we would need two branches to test. One for true conditions and the other for false conditions. So for 2 decision statements, we would require 2 test cases to test the true side and 2 test cases to test the false side, which makes 4 test cases.
To simplify this, let’s consider the flowchart of the pseudocode we have:
In order to have full coverage, we would need the following test cases:
TestCase_01: A=50, B=60
TestCase_02: A=55, B=40
TestCase_03: A=40, B=65
TestCase_04: A=30, B=30
So the paths covered will be:
Red Line – TestCase_01 = (A=50, B=60)
Blue Line = TestCase_02 = (A=55, B=40)
Orange Line = TestCase_03 = (A=40, B=65)
Green Line = TestCase_04 = (A=30, B=30)
White Box Testing Tools
Given below is a list of the top white box test tools.
#1) Veracode
Veracode’s white box testing tools will help you identify and resolve software flaws quickly and easily at a reduced cost. It supports several application languages like .NET, C++, JAVA, etc, and also enables you to test the security of desktop, web, and mobile applications. Still, there are several other benefits of the Veracode tool.
#2) EclEmma
EclEmma was initially designed for test runs and analysis within the Eclipse workbench. It is considered a free Java code coverage tool and has several features as well. If you want to install or get more details about EclEmma, please refer to the link provided.
#3) RCUNIT
RCUNIT is a framework used for testing C programs. RCUNIT can be used accordingly based on the terms of the MIT License. It is free to use and to install or know more about it.
#4) cfix
cfix is one of the unit testing frameworks for C/C++ which solely aims at making test suites development as simple and easy as possible. Meanwhile, cfix is typically specialized for NT Kernel mode and Win32.
#5) Googletest
Googletest is Google’s C++ test framework. Test Discovery, Death tests, Value-parameterized tests, fatal & non-fatal failures, XML test report generation, etc are a few features of Googletest but there are several other features as well. Linux, Windows, Symbian, and Mac OS X are a few platforms where Googletest has been used.
#6) EMMA
Emma is an easy-to-use free JAVA code coverage tool. It includes several features and benefits. To Download and know more about Emma, please check the link given below.
#7) NUnit
An open-source, user-friendly framework for unit testing, NUnit eliminates the need for manual intervention in evaluating test results. It is compatible with every.NET language. Additionally, it allows parallel testing under NUnit and data-driven testing.
While NUnit 3 is published under an MIT license, previous versions of NUnit used the NUnit license. However, both licenses permit unrestricted, free use. Please click the link below to download NUnit and learn more about it.
#8) CppUnit
CppUnit is a unit testing framework written in C++ and is considered the port of JUnit. The test output for CppUnit may be either in the XML or text format. It creates unit tests with its class and runs tests in the test suites. It is licensed under LGPL. To download and know more about CppUnit please check the link given below.
#9) JUnit
JUnit is a simple unit testing framework that supports test automation in the Java Programming Language. It mainly supports Test Driven Development and provides a Test coverage report as well. It is licensed under an Eclipse Public License. For more information on JUnit and to download it at no cost, please visit the link provided.
#10) JSUnit
JSUnit is considered to be the port of JUnit to JavaScript. It is an open-source unit testing framework to support Client-sided Javascript. It is licensed under GNU Public License 2.0, GNU Lesser Public License 2.1, and Mozilla Public License 1.1. To download and know more about JSUnit please check the link given below.
Also, check all the tools that we have listed under Static code analysis here.
Don’t hesitate to suggest additional simple or advanced tools you use for the white box technique.
Conclusion
Relying only on black box testing is not sufficient for maximum test coverage. We need to have a combination of both black and white box testing techniques to cover maximum defects.
If done properly, white box testing will certainly contribute to the software quality. It’s also good for testers to participate in this testing as it can provide the most “unbiased” opinion about the code.
You may be interested in:
What is REST API with an example?
Vulnerability scanning in Security Testing
Software Testing topics for presentation
Generative AI business use cases
Error: Contact form not found.
WhatsApp us