Ch. 6: Debugging
  1. Diagnosis: Find the cause from the symptoms
  2. 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.
  3. 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.
  4. Sources of trouble.
    1. Bad input data.
    2. Bad instruction: An error in the program.
  5. 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.
  6. 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.