![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](https://image.slidesharecdn.com/debugging-221028065629-df0aa5aa/85/Debugging-pdf-2-320.jpg)
Debugging.pdf
- 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.