|
|
|
|
|
|
|
The approach to testing that we've used here is called code coverage because the test data is designed by looking at the code of the program. Another approach to testing, data coverage, attempts to test as many allowable data values as possible without regard to the program code. Complete data coverage is as impractical as complete code coverage for many programs. For example, program Notices reads four integer values and thus has approximately (2 * INT_MAX)4 possible inputs. (INT_MAX and INT_MIN are constants declared in the header file limits.h. They represent the largest and smallest possible int values, respectively, on your particular computer and C++ compiler.) |
|
|
|
|
|
|
|
|
Often, testing is a combination of these two strategies. Instead of trying every possible data value (data coverage), we examine the code (code coverage) and look for ranges of values for which processing is identical. Then we test the values at the boundaries and, sometimes, a value in the middle of each range. For example, a simple condition, such as |
|
|
|
|
|
|
|
|
divides the integers into two ranges: |
|
|
|
|
|
|
|
|
Thus, we should test the four values INT_MIN, -1, 0, and INT_MAX. A compound condition, such as |
|
|
|
|
|
|
|
|
alpha >= 0 && alpha <= 100 |
|
|
|
|
|
|
|
|
divides the integers into three ranges: |
|
|
|
|
|
|
|
|
Thus, we have six values to test. In addition, to verify that the relational operators are correct, we should test for values of 1 (> 0) and 99 (< 100). |
|
|
|
|
|
|
|
|
Conditional branches are only one factor in developing a testing strategy. We consider more of these factors in later chapters. |
|
|
|
|
|
|
|
|
Tests Performed Automatically During Compilation and Execution |
|
|
|
|
|
|
|
|
Once a program is coded and test data has been prepared, it is ready for compiling. The compiler has two responsibilities: to report any errors and (if there are no errors) to translate the program into object code. |
|
|
|
|
|