White-box testing

From Wikipedia, the free encyclopedia
Jump to: navigation, search

White-box testing (also known as clear box testing, glass box testing, transparent box testing, and structural testing) is a method of testing software that tests internal structures or workings of an application, as opposed to its functionality (i.e. black-box testing). In white-box testing an internal perspective of the system, as well as programming skills, are used to design test cases. The tester chooses inputs to exercise paths through the code and determine the appropriate outputs. This is analogous to testing nodes in a circuit, e.g. in-circuit testing (ICT).

While white-box testing can be applied at the unit, integration and system levels of the software testing process, it is usually done at the unit level. It can test paths within a unit, paths between units during integration, and between subsystems during a system–level test. Though this method of test design can uncover many errors or problems, it might not detect unimplemented parts of the specification or missing requirements.

White-box test design techniques include:

  • Control flow testing
  • Data flow testing
  • Branch testing
  • Path testing
  • Statement coverage
  • Decision coverage


White-box testing is a method of testing the application at the level of the source code. The test cases are derived through the use of the design techniques mentioned above: control flow testing, data flow testing, branch testing, path testing, statement coverage and decision coverage as well as modified condition/decision coverage. White-box testing is the use of these techniques as guidelines to create an error free environment by examining any fragile code. These White-box testing techniques are the building blocks of white-box testing, whose essence is the careful testing of the application at the source code level to prevent any hidden errors later on.[1] These different techniques exercise every visible path of the source code to minimize errors and create an error-free environment. The whole point of white-box testing is the ability to know which line of the code is being executed and being able to identify what the correct output should be.[1]


  1. Unit testing. White-box testing is done during unit testing to ensure that the code is working as intended, before any integration happens with previously tested code. White-box testing during unit testing catches any defects early on and aids in any defects that happen later on after the code is integrated with the rest of the application and therefore prevents any type of errors later on.[1]
  2. Integration testing. White-box testing at this level are written to test the interactions of each interface with each other. The Unit level testing made sure that each code was tested and working accordingly in an isolated environment and integration examines the correctness of the behaviour in an open environment through the use of white-box testing for any interactions of interfaces that are known to the programmer.[1]
  3. Regression testing. White-box testing during regression testing is the use of recycled white-box test cases at the unit and integration testing levels.[1]

Basic procedure[edit]

White-box testing's basic procedures involve the understanding of the source code that you are testing at a deep level to be able to test them. The programmer must have a deep understanding of the application to know what kinds of test cases to create so that every visible path is exercised for testing. Once the source code is understood then the source code can be analyzed for test cases to be created. These are the three basic steps that white-box testing takes in order to create test cases:

  1. Input, involves different types of requirements, functional specifications, detailed designing of documents, proper source code, security specifications.[2] This is the preparation stage of white-box testing to layout all of the basic information.
  2. Processing Unit, involves performing risk analysis to guide whole testing process, proper test plan, execute test cases and communicate results.[2] This is the phase of building test cases to make sure they thoroughly test the application the given results are recorded accordingly.
  3. Output, prepare final report that encompasses all of the above preparations and results.[2]


White-box testing is one of the two biggest testing methodologies used today. It primarily has three advantages:

  1. Side effects of having the knowledge of the source code is beneficial to thorough testing.[3]
  2. Optimization of code by revealing hidden errors and being able to remove these possible defects.[3]
  3. Gives the programmer introspection because developers carefully describe any new implementation.[3]


Although White-box testing has great advantages, it is not perfect and contains some disadvantages. It has two disadvantages:

  1. White-box testing brings complexity to testing because to be able to test every important aspect of the program, you must have great knowledge of the program. White-box testing requires a programmer with a high-level of knowledge due to the complexity of the level of testing that needs to be done.[3]
  2. On some occasions, it is not realistic to be able to test every single existing condition of the application and some conditions will be untested.[3]


In penetration testing, white-box testing refers to a methodology where a white hat hacker has full knowledge of the system being attacked. The goal of a white-box penetration test is to simulate a malicious insider who has knowledge of and possibly basic credentials for the target system.

See also[edit]


  1. ^ a b c d e Williams, Laurie. White-Box Testing. pp. 60–61, 69. Retrieved 13 February 2013. [verification needed]
  2. ^ a b c Ehmer Khan, Mohd (July 2011). "Different Approaches to White Box Testing Technique for Finding Errors". International Journal of Software Engineering and Its Applications 5: 1–6. Retrieved 12 February 2013. 
  3. ^ a b c d e Ehmer Khan, Mohd (May 2010). "Different Forms of Software Testing Techniques for Finding Errors". IJCSI International Journal of Computer Science Issues 7 (3): 12. Retrieved 12 February 2013. 

External links[edit]