Download Ada in Action

Chapter 5. Testing Software Components and Programs
133
and/or filter the noise waveform. You should have a good idea of the characteristics of the noise in your
system (if you don't, you haven't done your homework), and should be able to model it. Simulate a
representative noise waveform and store it in NOISE.DAT.
The third step is to add each element in CLEAN.DAT to the corresponding element in NOISE.DAT, and
store the result in INPUT.DAT. You now have a realistic, noisy input signal for testing your algorithm.
Finally, process the noisy input and store the result in OUTPUT.DAT. You can compare OUTPUT.DAT
to TRUTH.DAT to see how well the algorithm performed in the presence of noise. You can do this as
often as you want with different kinds of input signals and different kinds of noise.
5.3.
Selecting Input Conditions
Now that we know what truth is, we need to know how to select input values. The five methods generally
used to do this are 100% testing, uniform sampling, Monte Carlo testing, good judgment, and dumb luck.
I hesitated to include the last method, but lets be honest-- that's how many error are found!
5.3.1. Testing Every Case
Clearly the best thing you can do is to test every possible input. This usually isn't practical, but in some
special cases it is. For example, all possible inputs to the ASCII_UTILITIES.Upper_Case function that
returns a character can be easily be tested. Just write a program that loops through all 128 ASCII
characters and compares the input character with the output character. If they are the same, do nothing. If
they are different, then print the input character, the output character, and call new_line. You should get
26 lines of output that look like this:
aA
bB
cC
(and so on)
xX
yY
zZ
Here's another case where 100% testing is possible: Suppose we want to test the COORDINATES
package, and the input values are given as one byte integers. That means the values can range from -128
to +127 feet. Figure 42 shows a short test program to check the COORDINATES package transformations
for all possible inputs. It uses the inverse function technique to test both Transform functions by
transforming a rectangular point into a polar point, and then transforming it back again. The program
does this for all rectangular positions included in the area from 128 feet west to 127 feet east, and 128 feet
south to 127 feet north. It keeps track of the largest errors, and prints them when finished. It also tells us
how long it took the test program to run.
The two previous examples are exceptions to the general rule. It is more likely that the COORDINATES
package has to work for all locations 100 miles from the origin. In theory, we could 100% test this
package by simply changing the loop limits to +/- 528,000 feet to get full 100 mile testing coverage. In
practice we can't do this. It took 177 seconds for the test program shown in Figure 42 to run on a 10 MHz
AT Clone. The number of points tested was 256**2 = 65,536 points. That's 370 points per second. To test
(2*528,000 + 1)**2 points would take 753,473,124 seconds. That's almost 24 years. By the time we
finished testing it, the weapon it was being designed for would be obsolete.
Ada in Action