January 2011 Edition
Computer Science Department, University of Cape Town
| MIT Notes Home | Edition Home |
| MSc-IT Study Material January 2011 Edition Computer Science Department, University of Cape Town | MIT Notes Home | Edition Home | |
Once a test case has been executed and a bug located, debugging begins. Debugging is the process of locating the cause of a software error and correcting it. Unfortunately, this is not necessarily an easy process. Software engineers are only ever presented with the software's behaviour, and they do not directly see the error's cause. Debugging, then, relies on the software engineer to determine from the software's incorrect behaviour the causes of this behaviour.
Debugging begins with the software failing a test case. The software engineer debugging the software will then hypothesise a possible cause and implement the needed changes to correct this in the software. The failed test is then rerun. Further test cases may also be written to help narrow down the actual cause. This all occurs iteratively, with each step hopefully providing more information to the developer as to the root cause of the error.
A number of debugging tactics have been proposed. They can be used alone, although they become far more effective when used in combination with each other.
This is conceptually the simplest of the methods, and often the least successful. This involves the developer manually searching through stack-traces, memory-dumps, log files, and so on, for traces of the error. Extra output statements, in addition to break points, are often added to the code in order to examine what the software is doing at every step.
This method has the developer begin with the code that immediately produces the observable error. The developer than backtracks through the execution path, looking for the cause. Unfortunately, the number of execution paths which lead to any given point in the software can become quite large the further the cause of the bug is from where the error occurs, and so this method can become impractical.
In this method, the developer develops hypotheses as to why the bug has occurred. The code can either be directly examined for the bug, or data to test the hypothesis can be constructed. This method can often result in the shortest debug times, although it does rely on the developers understanding the software well.