Debugging

1. 146
If programming language semantics are formally defined, it is possible to
consider a program as a mathematical object.
Using mathematical techniques, it is possible to demonstrate the
correspondence between a program and a formal specification of that
program.
Program is proved to be correct with respect to its specification.
Formal verification may reduce testing costs; it cannot replace testing as
a means of system validation.
Techniques for proving program correctness and axiomatic approaches
The basis of the axiomatic approach
Assume that there are a number of points in a program where the
software engineer can provide assertions concerning program variables
and their relationships. At each of these points, the assertions should be
invariably true. Say the points in the program are P(1), P(2),...P(n). The
associated assertions are a(l), a(2),...,a(n). Assertion a(1) must be an
assertion about the input of the program and a(n) an assertion about the
program output.
To prove that the program statements between points P(i) and P(i+l) are
correct, it must be demonstrated that the application of the program
statements separating these points causes assertion a(i) to be
transformed to assertion a(i+l).
Given that the initial assertion is true before program execution and the
final assertion is true after execution, verification is carried out for
adjacent program statements.
8.10. DEBUGGING
Debugging, a narrow view of software testing, is performed heavily to find
out design defects by the programmer. The limitation of human nature makes it
almost impossible to make a moderately complex program correct the first time.
Finding the problems and get them fixed, is the purpose of debugging in
programming phase.
Debugging is a methodical process of finding and reducing the number
of bugs, or defects, in a computer program or a piece of electronic hardware
thus making it behave as expected. Debugging tends to be harder when various
subsystems are tightly coupled, as changes in one may cause bugs to emerge in
another.

2. 147
Although each debugging experience is unique, certain general principles can
be applied in debugging. This section particularly addresses debugging software,
although many of these principles can also be applied to debugging hardware.
The basic steps in debugging are:
• Recognize that a bug exists
• Isolate the source of the bug
• Identify the cause of the bug
• Determine a fix for the bug
• Apply the fix and test it
8.10.1. The Debugging Process
The debugging process begins with the execution of the test case. Results
are assessed and a lack of correspondence between expected and actual result
is encountered. In many cases, the non-corresponding data is found to be a
symptom of an underlying cause as yet hidden. The debugging process
attempts to match symptom with cause, thereby leading to error correction.
Characteristics of bugs ([Cheung 1990])
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 program
structures exacerbate this situation.
2. The symptom may disappear (temporarily) when another error is
corrected.
Debugging
Suspected
causes
Identified
causes
Corrections
Execution of cases
Regression
Tests
Results
Test
caes
Additional
test
Fig. 8.5 Debugging Process

3. 148
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.
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.
8. The symptom may be due to causes that are distributed across a number
of tasks running on different processors.
The debugging process will always have one of two outcomes:
(1) The cause will be found, corrected, or removed, or
(2) The cause will not be found.
In general, three categories for debugging approaches are proposed:
Brute Force Approach
Backtracking Approach
Cause Elimination Approach
Each of the debugging approaches can be supplemented with debugging tools
such as debugging compliers, dynamic debugging aids, automatic test case
generators, memory dumps, and cross-reference maps.
a. Brute Force Approach
The brute force category of debugging is the most common method for
isolating the cause of an error. This method is generally the least efficient and is
used when everything else fails. A philosophy such as “let the computer find the
error” is used in this approach. Memory dumps are taken, run-time traces are
invoked, and the program is loaded with “write” statements, with the hope that
from the mass of information produced, we will find a clue that can lead us to
the cause of an error.
b. Back Tracking Approach
Debugging by backtracking involves working backward in the source
code from the point where the error was observed in an attempt to identify the
exact point where the error occurred. It may be necessary to run additional test
cases in order to collect more information. This approach can be used
successfully in small programs. The disadvantage with this approach is that if
the program is too large, then the potential backward paths may become
unmanageably large.

4. 149
c. Cause Elimination Approach
Cause elimination approach is manifested by induction or deduction. This
approach proceeds as follows:
1. List possible causes for the observed failure by organizing the data
related to the error occurrence.
2. Devise a “cause hypothesis”.
3. Prove or disprove the hypothesis using the data.
4. Implement the appropriate corrections.
5. Verify the correction. Rerun the failure case to be sure that the fix
corrects the observed symptom.
Check your Progress
i. ____________is the process used to help identify the correctness,
completeness, security and quality of developed computer software.
ii. In other words, testing is nothing but __________ or _________ that is
comparing the actual value with expected one.
iii. _____________ is done to validate the code written and is usually done by the
author of the code.
iv. ________ and __________ are sub-categories of System testing.
v. White box testing is also called as _________ and __________
Solutions
I
Ii
Iii
Iv
V
8.11. REVIEW QUESTIONS
1. What are the Testing objectives, rules in S/W testing fundamentals?
2. Explain the testing information flow.
3. What are the stages available in testing process?
4. Describe art of debugging in software testing strategies.
5. Write short notes on: a. Data flow testing b. Integration testing.