Lecture 11: Debugging

来源：互联网发布：netbeans怎么编写java 编辑：程序博客网时间：2024/05/23 13:05

1 Reproduce the Bug

Start by finding a small, repeatable test case that produces the failure.
Once you’ve found a small test case, find and fix the bug using that smaller test case, and then go back to the original buggy input and confirm that you fixed the same bug.

Propose a hypothesis, consistent with all the data, about where the bug might be, or where it cannot be.
It helps to think about your program as modules, or steps in an algorithm, and try to rule out whole sections of the program at once.

Run a different test case
Insert a print statement or assertion in the running program, to check something about its internal state.
Set a breakpoint using a debugger, then single-step through the code and look at variable and object values.

Bug localization by binary search
Prioritize your hypotheses
- Different parts of the system have different likelihoods of failure.
- Old, well-tested code is probably more trustworthy than recently-added code.
- Java library code is probably more trustworthy than yours.
Swap components.
- If you suspect the Java runtime, run with a different version of Java.
- If you suspect the operating system, run your program on a different OS.
- If you suspect the hardware, run on a different machine.
- If you suspect your binarySearch() implementation, then substitute a simpler linearSearch() instead.
Make sure your source code and object code are up to date.
Get help.
Sleep on it, If you’re too tired, you won’t be an effective debugger. Trade latency for efficiency. :)

Ask yourself whether the bug was a coding error, like a misspelled variable or interchanged method parameters, or a design error, like an underspecified or insufficient interface.
Think also whether the bug has any relatives.

[1] 6.005 — Software Construction on MIT OpenCourseWare | OCW 6.005 Homepage at https://ocw.mit.edu/ans7870/6/6.005/s16/

0 0