LECTURE 10

Debugging

Dr. Asmau Usman Nile University of Nig.

 Outline

Debugging Process
Psychological Considerations during
Debugging
Debugging Strategies

2
Dr. Asmau Usman Nile University of Nig.
 Introduction
 Software testing is a process that can be
systematically planned and specified.
 Test-case design can be conducted, a
strategy can be defined, and results can be
evaluated against prescribed expectations.
 Debugging occurs as a consequence of
successful testing.
 That is, when a test case uncovers an error,
debugging is the process that results in the
removal of the error.
 The term “debug” general means “get rid of
the bugs”. Sometimes, it also includes
activities related to detecting the presence
of bugs and dealing with them. 10
Dr. Asmau Usman Nile University of Nig.
 The Debugging Process
 Debugging is not testing but often occurs
as a result of testing.
 The debugging process begins with the
execution of a test case.
 Results are assessed and a lack of
correspondence between expected and
actual performance is encountered.
 In many cases, the noncorresponding
data are a symptom of an underlying
cause as yet hidden.
 The debugging process attempts to
match symptom with cause, thereby
leading to error correction.

Dr. Asmau Usman Nile University of Nig.

The Debugging Process Cont.,

11
Dr. Asmau Usman Nile University of Nig.
 The Debugging Process Cont.,
 The debugging process will usually have one of
two outcomes:
(1) the cause will be found and corrected or
(2) the cause will not be found.
 In the latter case, the person performing
debugging may suspect a cause, design a test
case to help validate that suspicion, and work
toward error correction in an iterative fashion.
 Why is debugging so difficult?
 In all likelihood, human psychology has more to
do with an answer than software technology.

Dr. Asmau Usman Nile University of Nig.

 Cont.,
 However, a few characteristics of bugs
provide some indications:-
1. The symptom and the cause may be geographically
remote. That is, the symptom may appear in one part
of a program, while the cause may actually be
located at a site that is far removed. Highly coupled
components worsen this situation.
2. The symptom may disappear (temporarily) when
another error is corrected.
3. The symptom may actually be caused by non-errors
(e.g., round-off inaccuracies).
4. The symptom may be caused by human error that is
not easily traced.

Dr. Asmau Usman Nile University of Nig.

Cont.,

 5. The symptom may be a result of timing

problems, rather than processing problems.
 6. It may be difficult to accurately reproduce
input conditions (e.g., a real-time application in
which input ordering is indeterminate).
 7. The symptom may be intermittent. This is
particularly common in embedded systems that
couple hardware and software inextricably.
 8. The symptom may be due to causes that are
distributed across a number of tasks running on
different processors.

Dr. Asmau Usman Nile University of Nig.

Cont.,

 During debugging, we encounter errors

that range from mildly annoying (e.g., an
incorrect output format) to terrible (e.g.,
the system fails, causing serious
economic or physical damage).
 As the consequences of an error
increase, the amount of pressure to find
the cause also increases.
 Often, pressure forces a software
developer to fix one error and at the
same time introduce two more.

Dr. Asmau Usman Nile University of Nig.

 Psychological Considerations
 Unfortunately, there appears to be some
evidence that debugging ability is an
essential human attribute.
 Some people are good at it and others
aren’t.
 Although experimental evidence on
debugging is open to many interpretations,
large variances in debugging ability have
been reported for programmers with the
same education and experience.
 Although it may be difficult to “learn”
debugging, a number of approaches to the
problem can be proposed.
13
Dr. Asmau Usman Nile University of Nig.
 Debugging Strategies
 Regardless of the approach that is taken,
debugging has one overriding
objective—to find and correct the cause
of a software error or defect.
 The objective is realized by a
combination of systematic evaluation,
intuition, and luck.
 In general, three debugging strategies
have been proposed:
 Brute force,
 Backtracking, and
 Cause elimination.

Dr. Asmau Usman Nile University of Nig.

 Brute Force

 The brute force category of debugging is

probably the most common and least
efficient method for isolating the cause of
a software error.
 You apply brute force debugging
methods when all else fails.
 Using a “let the computer find the error”
philosophy, memory dumps are taken, run-
time traces are raised, and the program is
loaded with output statements.

14
Dr. Asmau Usman Nile University of Nig.
 Backtracking

 Backtracking is a fairly common

debugging approach that can be used
successfully in small programs.
 Beginning at the site where a symptom has
been uncovered, the source code is
traced backward (manually) until the
cause is found.
 Unfortunately, as the number of source
lines increases, the number of potential
backward paths may become
unmanageably large.

Dr. Asmau Usman Nile University of Nig.

 Cause Elimination

 Cause elimination —is manifested by

induction or deduction and introduces
the concept of binary partitioning.
 Data related to the error occurrence are
organized to isolate potential causes.
 A “cause hypothesis” is planned and the
said data are used to prove or disprove
the hypothesis.
 Alternatively, a list of all possible causes is
developed and tests are conducted to
eliminate each.

Dr. Asmau Usman Nile University of Nig.

 Automated Debugging
 Each of these debugging approaches can
be supplemented with debugging tools that
can provide you with semiautomated
support as debugging strategies are
attempted.
 many new approaches have been proposed
and many commercial debugging
environments are available.
 Integrated development environments (IDEs)
provide a way to capture some of the
language-specific predetermined errors (e.g.,
missing end-of-statement characters,
undefined variables, and so on) without
requiring compilation.”

Dr. Asmau Usman Nile University of Nig.

 Cont.,

 A wide variety of debugging compilers,

dynamic debugging aids (“tracers”),
automatic test-case generators, and
cross-reference mapping tools are
available.
 However, tools are not a substitute for
careful evaluation based on a complete
design model and clear source code.

Dr. Asmau Usman Nile University of Nig.

 Correcting the Error
 Once a bug has been found, it must be
corrected.
 But as we have already noted, the correction of
a bug can introduce other errors and therefore
do more harm than good.
 Three simple questions ask before making the
“correction” that removes the cause of a bug
are:
 1. Is the cause of the bug reproduced in
another part of the program?
 In many situations, a program defect is caused by an
wrong pattern of logic that may be reproduced
elsewhere.
 Clear consideration of the logical pattern may result in
the discovery of other errors.
15
Dr. Asmau Usman Nile University of Nig.
2. What “next bug” might be introduced by
the fix I'm about to make?
 Before the correction is made, the source code (or the
design) should be evaluated to assess coupling of logic
and data structures.
 If the correction is to be made in a highly coupled
section of the program, special care must be taken
when any change is made.
3. What could we have done to prevent this
bug in the first place?
 This question is the first step toward establishing a
statistical software quality assurance approach.
 If you correct the process as well as the product, the
bug will be removed from the current program and may
be eliminated from all future programs.

Dr. Asmau Usman Nile University of Nig.

 Mutation Testing
➢ Mutation testing is one approach we
can use to measure the competence
of a set of tests, a way to figure out if
our tests are any good.
➢ You've built your solution, you have
test cases, and they all passed.
➢ Hurray! Not quite. You're not really
done because that's not necessarily
sufficient.
➢ Remember that program testing can
be used to show the presence of
bugs, but never their absence.
Dr. Asmau Usman Nile University of Nig.
 Cont.,

➢ Is there any approach we can use to test

the competence of our tests?
➢ This is where mutation testing comes in.
➢ It's one form of writing adequacy for our
tests.
➢ In mutation testing, we essentially create a
second version of the software.
➢ In this second version, we produce a
mutation, some small artificial fault.

Dr. Asmau Usman Nile University of Nig.

 Cont.,

➢ This mutant will not theoretically

function the same way as the original,
hopefully in some observable way.
➢ Once we have the mutant, we run test
cases against it.
➢ If any of those tests fail, we have
identified the mutant.
➢ If not, it means that our test would not
catch a similar kind of mistake in the
program

Dr. Asmau Usman Nile University of Nig.

 Cont.,

But that's just one tiny mistake and

we don't just create and terminate
one mutant, we make many.
For each mutant, we identify that we
kill the mutant by having any test
case fail when we run against that
mutant.
If we run our tests and every mutant is
identified, we have a pretty good
test suite.

Dr. Asmau Usman Nile University of Nig.

Cont.,
➢ If not, there is some mutant that escapes
discovery by our tests and that is
probably something we want to take a
look at.
➢ We make these mutants by creating a
single change to a single line in the
original.
➢ For example, delta = newGuess - sqrt.

➢ We can make a small change called a

mutation operator, also sometimes called
the mutagen or mutagenic operator.

Dr. Asmau Usman Nile University of Nig.

 Cont.,
➢ It's pretty straightforward that if you
change subtraction with addition,
something should change in how the
system works.
➢ And this is true for really all the other
arithmetic operators.
➢ And if your test cases any one of them,
fails to change, due to this change in the
code, you caught the mutant.
➢ There are lots of these mutation
operators.

Dr. Asmau Usman Nile University of Nig.

 Cont.,

➢ Booleans can be swapped out especially to

test for the fear off by one error.
➢ You can even switch variables if they're the
same type.
➢ Because we're looking for changes that
don't cause a syntax error.
➢ We want mutations that actually survive,
that can be compiled and run.
➢ Based on this, you can calculate a score
based on how many mutants you
terminate, the mutation adequacy score

Dr. Asmau Usman Nile University of Nig.

 Summary
 Software testing accounts for the largest percentage of
technical effort in the software process.
 Regardless of the type of software you build, a strategy for
systematic test planning, execution, and control begins by
considering small elements of the software and moves
outward toward the program as a whole.
 For conventional software, the objective of software testing is
to uncover errors and this objective is achieved through a
series of test steps.
 Unit and integration tests concentrate on functional
verification of a component and incorporation of
components into the software architecture.
 Validation testing demonstrates traceability to software
requirements, and system testing validates software once it
has been incorporated into a larger system.
 Each test step is accomplished through a series of systematic
test techniques that assist in the design of test cases.

27
Dr. Asmau Usman Nile University of Nig.
 The strategy for testing object-oriented software begins
with tests that exercise the operations within a class and
then moves to thread-based testing for integration.
 Threads are sets of classes that respond to an input or
event.
 Usebased tests focus on classes that do not collaborate
heavily with other classes.
 Web and MobileApps are tested in much the same way
as OO systems.
 However, tests are designed to exercise content,
functionality, the interface, navigation, and other
aspects of app performance and security.
 Aditionally, MobileApps require specialized testing
approaches that focus on testing the App on multiple
devices and in real world network environments.

Dr. Asmau Usman Nile University of Nig.

 Unlike testing (a systematic, planned
activity), debugging can be viewed as
an art.
 Beginning with a symptomatic indication
of a problem, the debugging activity
must track down the cause of an error.
 Of the many resources available during
debugging, the most valuable is the
counsel of other members of the
software engineering staff.

Dr. Asmau Usman Nile University of Nig.

Practice Question

Dr. Asmau Usman Nile University of Nig.

NEXT L

Next Topic:

THANKS
Dr. Asmau Usman Nile University of Nig.