Lecture 11: Debugging - After the System is Deployed

最新推荐文章于 2019-04-22 16:53:50 发布

_tianyuxue

最新推荐文章于 2019-04-22 16:53:50 发布

阅读量326

点赞数

分类专栏：软件工程文章标签： bug 调试

本文链接：https://blog.csdn.net/jitianyu123/article/details/65437413

版权

21 篇文章 0 订阅

订阅专栏

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.