The art of software testing. Myers (2nd edition) (2004) (811502), страница 28
Текст из файла (страница 28)
Debugging with a storage dump.2. Debugging according to the common suggestion to “scatterprint statements throughout your program.”3. Debugging with automated debugging tools.The first, debugging with a storage dump (usually a crude displayof all storage locations in hexadecimal or octal format) is the mostinefficient of the brute force methods. Here’s why:Debugging159• It is difficult to establish a correspondence between memorylocations and the variables in a source program.• With any program of reasonable complexity, such a memorydump will produce a massive amount of data, most of which isirrelevant.• A memory dump is a static picture of the program, showing thestate of the program at only one instant in time; to find errors,you have to study the dynamics of a program (state changesover time).• A memory dump is rarely produced at the exact point of theerror, so it doesn’t show the program’s state at the point ofthe error.
Program actions between the time of the dump andthe time of the error can mask the clues you need to find theerror.• There aren’t adequate methodologies for finding errors byanalyzing a memory dump (so many programmers stare, withglazed eyes, wistfully expecting the error to expose itselfmagically from the program dump).Scattering statements throughout a failing program to display variable values isn’t much better. It may be better than a memory dumpbecause it shows the dynamics of a program and lets you examineinformation that is easier to relate to the source program, but thismethod, too, has many shortcomings:• Rather than encouraging you to think about the problem, it islargely a hit-or-miss method.• It produces a massive amount of data to be analyzed.• It requires you to change the program; such changes can maskthe error, alter critical timing relationships, or introduce newerrors.• It may work on small programs, but the cost of using it in largeprograms is quite large.
Furthermore, it often is not evenfeasible on certain types of programs such as operating systemsor process control programs.160The Art of Software TestingAutomated debugging tools work similarly to inserting print statements within the program, but rather than making changes to theprogram, you analyze the dynamics of the program with the debugging features of the programming language or special interactivedebugging tools. Typical language features that might be used arefacilities that produce printed traces of statement executions, subroutine calls, and/or alterations of specified variables.
A common function of debugging tools is the ability to set breakpoints that cause theprogram to be suspended when a particular statement is executed orwhen a particular variable is altered, and then the programmer canexamine the current state of the program. Again, this method islargely hit or miss and often results in an excessive amount of irrelevant data.The general problem with these brute force methods is that theyignore the process of thinking.
You can draw an analogy between program debugging and solving a homicide. In virtually all murder mystery novels, the mystery is solved by careful analysis of the clues andby piecing together seemingly insignificant details. This is not a bruteforce method; roadblocks or property searches would be.There also is some evidence to indicate that whether the debugging teams are experienced programmers or students, people whouse their brains rather than a set of aids work faster and more accurately in finding program errors. Therefore, we could recommendbrute force methods only (1) when all other methods fail or (2) as asupplement to, not a substitute for, the thought processes we’lldescribe next.Debugging by InductionIt should be obvious that careful thought will find most errors without the debugger even going near the computer.
One particularthought process is induction, where you move from the particulars ofa situation to the whole. That is, start with the clues (the symptomsof the error, possibly the results of one or more test cases) and lookDebugging161Figure 7.1The inductive debugging process.for relationships among the clues. The induction process is illustratedin Figure 7.1.The steps are as follows:1. Locate the pertinent data.
A major mistake debuggers make isfailing to take account of all available data or symptoms aboutthe problem. The first step is the enumeration of all youknow about what the program did correctly and what it didincorrectly—the symptoms that led you to believe there wasan error. Additional valuable clues are provided by similar, butdifferent, test cases that do not cause the symptoms to appear.2. Organize the data.
Remember that induction implies thatyou’re processing from the particulars to the general, so thesecond step is to structure the pertinent data to let youobserve the patterns. Of particular importance is the searchfor contradictions, events such as that the error occurs onlywhen the customer has no outstanding balance in his or hermargin account. You can use a form such as the one shown162The Art of Software TestingFigure 7.2A method for structuring the clues.in Figure 7.2 to structure the available data.
The “what”boxes list the general symptoms, the “where” boxes describewhere the symptoms were observed, the “when” boxes listanything that you know about the times that the symptomsoccur, and the “to what extent” boxes describe the scope andmagnitude of the symptoms. Notice the “is” and “is not”columns; they describe the contradictions that may eventuallylead to a hypothesis about the error.3. Devise a hypothesis. Next, study the relationships among theclues and devise, using the patterns that might be visible inthe structure of the clues, one or more hypotheses about thecause of the error. If you can’t devise a theory, more data areneeded, perhaps from new test cases.
If multiple theoriesseem possible, select the more probable one first.4. Prove the hypothesis. A major mistake at this point, given thepressures under which debugging usually is performed, isskipping this step and jumping to conclusions to fix theDebugging163problem. However, it is vital to prove the reasonableness ofthe hypothesis before you proceed. If you skip this step,you’ll probably succeed in correcting only the problemsymptom, not the problem itself. Prove the hypothesis bycomparing it to the original clues or data, making sure thatthis hypothesis completely explains the existence of the clues.If it does not, either the hypothesis is invalid, the hypothesisis incomplete, or multiple errors are present.As a simple example, assume that an apparent error has beenreported in the examination grading program described in Chapter4.
The apparent error is that the median grade seems incorrect insome, but not all, instances. In a particular test case, 51 students weregraded. The mean score was correctly printed as 73.2, but themedian printed was 26 instead of the expected value of 82. By examining the results of this test case and a few other test cases, the cluesare organized as shown in Figure 7.3.Figure 7.3An example of clue structuring.164The Art of Software TestingThe next step is to derive a hypothesis about the error by lookingfor patterns and contradictions.
One contradiction we see is that theerror seems to occur only in test cases that use an odd number of students. This might be a coincidence, but it seems significant, since youcompute a median differently for sets of odd and even numbers.There’s another strange pattern: In some test cases, the calculatedmedian always is less than or equal to the number of students (26 ⬉51 and 1 ⬉ 1). One possible avenue at this point is to run the51-student test case again, giving the students different grades frombefore to see how this affects the median calculation. If we do so, themedian is still 26, so the “is not–to what extent” box could be filledin with “the median seems to be independent of the actual grades.”Although this result provides a valuable clue, we might have beenable to surmise the error without it.
From available data, the calculated median appears to equal half of the number of students,rounded up to the next integer. In other words, if you think of thegrades as being stored in a sorted table, the program is printing theentry number of the middle student rather than his or her grade.Hence, we have a firm hypothesis about the precise nature of theerror. Next, prove the hypothesis by examining the code or by running a few extra test cases.Debugging by DeductionThe process of deduction proceeds from some general theories orpremises, using the processes of elimination and refinement, to arriveat a conclusion (the location of the error).
See Figure 7.4.As opposed to the process of induction in a murder case, for example, where you induce a suspect from the clues, you start with a set ofsuspects and, by the process of elimination (the gardener has a validalibi) and refinement (it must be someone with red hair), decide thatthe butler must have done it. The steps are as follows:1.
Enumerate the possible causes or hypotheses. The first step is todevelop a list of all conceivable causes of the error. TheyDebugging165Figure 7.4The deductive debugging process.don’t have to be complete explanations; they are merely theories to help you structure and analyze the available data.2. Use the data to eliminate possible causes. Carefully examine allof the data, particularly by looking for contradictions(Figure 7.2 could be used here), and try to eliminate all butone of the possible causes. If all are eliminated, you needmore data through additional test cases to devise new theories.
If more than one possible cause remains, select the mostprobable cause—the prime hypothesis—first.3. Refine the remaining hypothesis. The possible cause at this pointmight be correct, but it is unlikely to be specific enough topinpoint the error. Hence, the next step is to use the available clues to refine the theory. For example, you might startwith the idea that “there is an error in handling the last transaction in the file” and refine it to “the last transaction in thebuffer is overlaid with the end-of-file indicator.”4. Prove the remaining hypothesis. This vital step is identical tostep 4 in the induction method.As an example, assume that we are commencing the function testing of the DISPLAY command discussed in Chapter 4.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
