8.11 Review

Debugging heuristics don’t lend themselves to easy categorization, as strategies and tactics do.

The first heuristic to apply is often called stabilizing the problem. The goal of stabilization is reproducibility. The first step in stabilizing a program is to obtain an undesired behavior each time the program executes. The next step is to obtain the same undesired behavior each time the program executes. The third step is to obtain the same undesired behavior in different environments. The fourth step is to obtain the same undesired behavior on different platforms.

The second heuristic to apply is to create a standalone test case. A test case typically has two parts: the program and the input data. We present heuristics for creating test case programs and test input data.

To cut down a file-oriented application into a standalone test, create a file that contains the inputs required to get the program just prior to the point where the problem occurs. Insert a call to record the program state just prior to the problem. Run the program with the log file, capture the program state, build a new driver that sets that state directly, and replace the old driver with the new one.

To cut down a GUI application into a standalone test, create a log that contains the mouse and keyboard actions required to get the program just prior to the point where the problem occurs. Insert a call to record the program state just prior to the problem. Run the program with the log file, capture the program state, build a new driver that sets that state directly, and replace the old driver with the new one.

To cut down a problem with a compiler into a standalone test, identify the part of the input program that caused the problem and correlate it with the compiler’s internal data structures. Remove all parts of the input program that aren’t required to reproduce the problem.

The best test case is the one in which all input elements have been removed that have no bearing on whether the undesired behavior occurs. One approach to cutting down a test input data set is to take a random selection of elements and either add or remove elements until you have just enough to cause the problem to manifest itself.

A second approach to cutting down a test input data set is to consider frequency of use and misuse of the elements of the structure. Another approach to cutting down a test input data set is to reduce several aspects of the input simultaneously. The aspects of a test data set include size, sequence, and values.

Categorizing the problem is a heuristic that can be used any time in the debugging process. Use a collection of general questions to categorize the behavior of the program with regard to correctness, completion, robustness, and efficiency.

Describing the problem according to a standard methodology is a heuristic that is normally used in the early stages of diagnosis. One approach is to answer standard questions that focus on those things that occurred or existed or were observed versus those things that did not occur or exist or weren’t observed. Another approach is to answer standard questions that focus on the difference between the normal or expected situation and what actually happened.

Explaining the problem to someone else is helpful when you have used up the hypotheses generated by the other heuristics. Communicating forces us to organize our thoughts so that the other person will understand. The other person won’t necessarily share our internalized assumptions, and we will have to explain them to make sense of the problem.

Recalling a similar problem is a heuristic that can be used at any time in the debugging process. It is much easier if you keep a log of bugs you have worked on. There are a number of dimensions along which two problems can be similar, and there are degrees of similarity along these dimensions. It is reasonable to hypothesize that two problems that are similar in a number of dimensions may have the same root problem.

Drawing a diagram is a heuristic that can be used any time in the debugging process. If you draw a representation of the actual behavior of the program, such as the control-flow or data-flow graph, look for actual anomalies. If you draw a representation of the ideal behavior of the program, such as the data-structure layout, look for potential anomalies.

Choosing a hypothesis from historical data is a heuristic to use when you have been working on a defect for some time, and you’re running out of hypotheses.