White Box Testing
White-Box Testing
White-box testing is a verification technique software engineers can use to examine if their code works as expected. In this chapter, we will explain the following:
• a method for writing a set of white-box test cases that exercise the paths in the code
• the use of equivalence partitioning and boundary value analysis to manage the number of test cases that need to be written and to examine error-prone/extreme “corner” test cases
• how to measure how thoroughly the test cases exercise the code
White-box testing is testing that takes into account the internal mechanism of a system or component (IEEE, 1990). White-box testing is also known as structural testing, clear box testing, and glass box testing (Beizer, 1995). The connotations of “clear box” and “glass box” appropriately indicate that you have full visibility of the internal workings of the software product, specifically, the logic and the structure of the code. Using the white-box testing techniques outlined in this chapter, a software engineer can design test cases that (1) exercise independent paths within a module or unit; (2) exercise logical decisions on both their true and false side; (3) execute loops at their boundaries and within their operational bounds; and (4) exercise internal data structures to ensure their validity (Pressman, 2001).
There are six basic types of testing: unit, integration, function/system, acceptance, regression, and beta. White-box testing is used for three of these six types:
• Unit testing, which is testing of individual hardware or software units or groups of related units (IEEE, 1990). A unit is a software component that cannot be subdivided into other components (IEEE, 1990). Software engineers write white-box test cases to examine whether the unit is coded correctly. Unit testing is important for ensuring the code is solid before it is integrated with other code. Once the code is integrated into the
White-box testing is a verification technique software engineers can use to examine if their code works as expected. In this chapter, we will explain the following:
• a method for writing a set of white-box test cases that exercise the paths in the code
• the use of equivalence partitioning and boundary value analysis to manage the number of test cases that need to be written and to examine error-prone/extreme “corner” test cases
• how to measure how thoroughly the test cases exercise the code
White-box testing is testing that takes into account the internal mechanism of a system or component (IEEE, 1990). White-box testing is also known as structural testing, clear box testing, and glass box testing (Beizer, 1995). The connotations of “clear box” and “glass box” appropriately indicate that you have full visibility of the internal workings of the software product, specifically, the logic and the structure of the code. Using the white-box testing techniques outlined in this chapter, a software engineer can design test cases that (1) exercise independent paths within a module or unit; (2) exercise logical decisions on both their true and false side; (3) execute loops at their boundaries and within their operational bounds; and (4) exercise internal data structures to ensure their validity (Pressman, 2001).
There are six basic types of testing: unit, integration, function/system, acceptance, regression, and beta. White-box testing is used for three of these six types:
• Unit testing, which is testing of individual hardware or software units or groups of related units (IEEE, 1990). A unit is a software component that cannot be subdivided into other components (IEEE, 1990). Software engineers write white-box test cases to examine whether the unit is coded correctly. Unit testing is important for ensuring the code is solid before it is integrated with other code. Once the code is integrated into the