All about White Box Testing
Firstly let us understand the meaning of White Box 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. It is a methodology to design the test cases that uses the control structure of the application to design test cases. White box testing is used to test the program code, code structure and the internal design flow.
A number of defects get amplified because of incorrect translation of requirements and design into program code. Let us see different techniques of white box testing.
Primarily White Box Testing comprises of two sub-streams of testing like:
1) Static White box Testing
2) Dynamic White box Testing
Comparison among Static White Box Testing & Dynamic White Box Testing
Static White box testing: It is a type of testing in which the program source code is tested without running it. We only need to examine and review the code. It means that we need not execute the code. We need to find out whether
a)The code works according to the functional requirements.
b)The code has been written in accordance with the design developed earlier in the project life cycle.
c) The code for any functionality has been missed out.
d) The code handles errors properly.
Static testing can be done by human being or with the help of specialized tools. Thus we can define static white box testing as a process involving a methodical & careful examination of the software architecture, basic design or its code with a view to hunt for bugs without executing it. It is called structural analysis as well sometimes.
Dynamic white box testing: This involves testing a running program. So, now binaries and executables are desired. We try to test the internal logic of the program now. It entails running the actual product against some pre-designed test cases to exercise as much of the code as possible.
Some of the key Dynamic White Box Testing processes are as under:
Unit / Code Functional Testing:
It is the process of testing in which the developer performs some quick checks prior to subjecting the code to more extensive code coverage testing or code complexity testing. It can be performed in many ways
a) At the initial stages, the developer or tester can perform certain tests based on the input variables and the corresponding expected output variables. This can be a quick test. If we repeat these tests for multiple values of input variables also then the confidence level of the developer to go to the next level increases.
b) For complex modules, the tester can insert some print statements in between to check whether the program control passes through all statements and loops. It is important to remove the intermediate print statements after the defects are fixed.
c) Another method is to run the product under a debugger or an Integrated Development Environment (IDE). These tools involve single stepping of instructions, setting break points at any function or instruction.
All these initial tests, actually fall under “Debugging” category rather than under �’Testing” category of activities. These are placed under “White Box Testing” head as all are related to the knowledge of code structure.
Code Coverage Testing:
Code coverage testing involves designing and executing test cases and finding out the percentage of code that is covered by testing. The percentage of code covered by a test is found by adopting a technique called as the instrumentation of code. These tools rebuild the code, do product linking with a set of libraries provided by the tool, monitor the portions of code covered, reporting on the portions of the code that are covered frequently, so that the critical or most-often portions of code can be identified.