Glass box testing requires the intimate knowledge of program internals, while black box testing is based solely on the knowledge of the system requirements. Being primarily concerned with program internals, it is obvious in SE literature that the primary effort to develop a testing methodology has been devoted to glass box tests. However, since the importance of black box testing has gained general acknowledgement, also a certain number of useful black box testing techniques were developed.

It is important to understand that these methods are used during the test design phase, and their influence is hard to see in the tests once they're implemented.

Software testing approaches that examine the program structure and derive test data from the program logic. Structural testing is sometimes referred to as clear-box testing since white boxes are considered opaque and do not really permit visibility into the code.

• Structural testing

• Clear Box testing

• Open Box Testing

• Static and Dynamic Analysis static analysis techniques do not necessitate the execution of the software, dynamic analysis is what is generally considered as ``testing``, i.e. it involves running the system.

• Statement Coverage Testing performed where every statements is executed at least once.

• Branch Coverage Running a series of tests to ensure that all branches are tested at least once.

• Path Coverage Testing all paths.

• All-definition-use-path Coverage All paths between the definition of a variable and the use of that definition are now identified and tested.

• approximates the partitioning done by execution equivalence

• reveals errors in "hidden" code:

• beneficent side-effects

• optimizations (e.g. charTable that changes reps when size > 100)

int abs(int x)

{

// effects: return -x if x, x otherwise if (x < -1) return -x;

else

return x;

}

black-box subdomains: x < 0, x >= 0

glass-box subdomains: x < -1, x >= -1

intersect the subdomains, giving: x < -1, x = -1, x >= 0

testing these subdomains reveals the error

• program executes differently under two inputs with same specs

In this testing technique, you use the code at hand to determine a test suite. Ideally, you want test data that exercises all possible paths through your code; however, this isn't always possible, and we can approximate by ensuring that each path is visited at least once.

As an example, consider the following program:

There are four if statements in this code and no loops (these are the source of multiple paths in your code). They form a total of eight paths through the program (verify this!):

To test this, we must come up with eight sets of data (income and number of dependents), one to test each possible path. Ranges for income are fairly evident for each case; we need only select an appropriate number of dependents for each case. The following table shows one test suite, and the expected results (TaxTotal):

To complete the glass-box testing process, you would test your program with all eight input sets, and verify that the output matches the expected result. If all outputs match, then the code passes the test.