Software Debugging
Debugging:
A Diagnostic Process
Debugging
Debuggingisisnot
notTesting
Testing
Debugging
Debugging occurs
occurs asas aa consequence
consequence ofof
successful
successfultesting
testing
When
When aa test test case
case uncovers
uncovers an an error,
error,
debugging
debugging isis the
the process
process that
that results
results inin the
the
removal
removalofofthe
theerror
error
Debugging
Debugging isis the
the process
process that
that connects
connects aa
symptom
symptomtotoaacause,
cause,thereby
therebyleading
leadingtotoerror
error
correction
correction
Its
Its an
an art.
art. Some
Some people
people are
are good
good atat itit and
and
some
somearen’t
aren’t
The Debugging Process
test cases
new test results
cases
regression
tests suspected
causes
corrections
Debugging
identified
causes
Debugging Effort
time required to
correct the error
and conduct
regression tests
time required to
diagnose the
symptom and
determine the cause
(always exactly 25% )
Symptoms and Causes
• Symptom and cause may be
geographically separated.
• Symptom may disappear when
another problem is fixed.
• Cause may be due to a combination of
non-errors.
symptom • Cause may be due to a system or
cause compiler error.
• Cause may be due to assumptions
that everyone believes.
• Symptom may be intermittent.
Psychological Considerations
Commenting on the human aspects of debugging,
Shneiderman states:
Debugging is one of the more frustrating parts of programming. It has
elements of problem solving or brain teasers, coupled with the
annoying recognition that you have made a mistake. Heightened
anxiety and the unwillingness to accept the possibility of errors
increases the task difficulty. Fortunately, there is a great sigh of relief
and a lessening of tension when the bug is ultimately … corrected.
Consequences of Bugs
infectious
catastrophic
Damage extreme
serious
disturbing
annoying
mild
Bug Type
Bug Categories: function-related bugs, system-related
bugs, data bugs, coding bugs, design bugs,
documentation bugs, standards violations, etc.
Debugging Strategies
Debugging is straightforward application of the scientific
method that has been developed over 2,500 years. The basis
of debugging is to locate the problem’s source by binary
partitioning, through working hypotheses that predict new
values to be examined.
Debugging Techniques
1. Brute force – print out values of “all” the
variables, at “every” step, look through the mass
of data, and find the error.
2. Backtracking – begin with symptom of error.
Trace backwards from there (by hand) to error.
(continued)
Debugging Techniques
3. Cause Elimination
• Induction – moving from particular to general:
• Run error-detecting test with lots of different input.
• Based on all the data generated, hypothesize an error
cause.
• Run another test to validate the hypothesis.
• If hypothesis is not validated, generate a new
hypothesis and repeat.
Debugging Techniques
• Deduction – moving from general to particular:
• Consider all possible error causes.
• Generate tests to eliminate each (we
hope/expect all but one will succeed).
• We may then be able to use further tests to
further refine the error cause.
Debugging Hints
• First, think about the symptom you are seeing – don’t
run off half-cooked.
• Use tools (e.g., dynamic debuggers) to gain more
insight, and to make the steps reproducible.
• If at an impasse, get help from someone else.
• Be absolutely sure to conduct regression tests when
you do fix the bug.
The people Factor:
Any discussion of debugging approaches and tools is
incomplete without mention of powerful ally-other
people! A fresh viewpoint, unclouded by hours of
frustration, can do wonders. A final maxim for
debugging might be: When all else fails, get help!
Correcting the error
Correction of error can introduce new errors, so before
making the correction, Software Engineer must ask:
Is the cause of the bug reproduced in another part of the
program?
What “next bug” might be introduced by the fix that I’m
about to make?
What could we have done to prevent this bug in the first
place?
References:
Software Engineering - A practitioner’ s Approach
by Roger S. Pressman
Chapter 13
• 13.7
