Debugging

Download as ppt, pdf, or txt
Download as ppt, pdf, or txt
You are on page 1of 15

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

You might also like