Ch. 6: Debugging

Diagnosis: Find the cause from the symptoms
Debugging: Diagnosis of a engineered system, usually a computer.
1. Use of “bug” for malfunction predates the computer. Edison used it, and has earlier origins.
2. Moth found in the Mark II.
Relevant properties of a computer.
1. Precision, e.g., letter O and digit 0.
2. Literal operation.
  1. A computer cannot know what you meant.
  2. No “common sense”.
3. Consistent: Do the same thing every time.
  1. Usually. Exceptions mean the behavior depends one something you don't know about.
  2. Looks like a random failure.
Sources of trouble.
1. Bad input data.
2. Bad instruction: An error in the program.
Debugging steps.
1. Reproduce the error: Try to be sure what causes the behavior.
2. Be precise about what is wrong.
3. Eliminate obvious errors: “Is is plugged in?”
4. Divide into parts, and test separately.
5. Predict the results of your tests, and see if actual behavior agrees.
6. If you reach a dead end, start over. Try more and better.
Testing a Program.
1. Test plan.
  1. Consider each required behavior.
  2. Plan actions to demonstrate that behavior under all relevant circumstances.
  3. Note the expected correct response.
2. Black box testing: Choose tests based on specification.
3. White box testing: Choose tests based on program code.