Return to Video

The Seven Steps of Debugging - Software Debugging

  • 0:00 - 0:04
    Welcome to the last unit in our debugging course where we review
  • 0:04 - 0:08
    the material we've seen so far and put it all together.
  • 0:08 - 0:12
    Now at the end of the course, let's put everything together to see
  • 0:12 - 0:15
    what we do when we encounter a new bug.
  • 0:15 - 0:21
    When we see a new bug, the first thing we do is to make sure it gets processed.
  • 0:21 - 0:24
    So we enter it in the problem database.
  • 0:24 - 0:28
    We've seen the stages the problem report goes through from unconfirmed
  • 0:28 - 0:32
    via new to assigned, when it's assigned to an individual developer,
  • 0:32 - 0:35
    and finally resolved and closed.
  • 0:35 - 0:43
    Any new problem needs to go into the problem database.
  • 0:43 - 0:50
    In the long run, checking problems also helps you in coming up with statistics
  • 0:50 - 0:55
    on how long it takes you to fix a bug, how many bugs there are that still need to be fixed,
  • 0:55 - 0:59
    as well as where are the bugs are that need to be fixed?
  • 0:59 - 1:04
    Such that in your program, you know where the locations are
  • 1:04 - 1:10
    that overtime have the highest bug density, and therefore needs special attention.
  • 1:10 - 1:16
    For all of this, tracking the problem is the first prerequisite.
  • 1:16 - 1:23
    The next step is to reproduce the problem because only when you are reproducing a problem,
  • 1:23 - 1:27
    do you know whether you will actually be able to fix it.
  • 1:27 - 1:34
    We have seen what the individual inputs are that all influence a program execution.
  • 1:34 - 1:41
    Most important being static data, user interaction and the interaction with the environment
  • 1:41 - 1:48
    but also more trouble issues like the debugger which influences the program
  • 1:48 - 1:53
    or time randomness and other issues that may be hard to control.
  • 1:53 - 1:59
    In order to reproduce the problem, you must get all of this under your control.
  • 1:59 - 2:05
    Reproducing your problem can be particularly hard when you're collecting such data from the field
  • 2:05 - 2:10
    because data and user interaction may contain sensitive data.
  • 2:10 - 2:17
    This is why we have also seen the techniques of statistical debugging which relate execution features
  • 2:17 - 2:23
    such as allowing the program being executed on that to failures and success
  • 2:23 - 2:27
    by collecting such data from the field, you'll be able to find out
  • 2:27 - 2:32
    which features of the execution correlate with failures
  • 2:32 - 2:38
    and these features can be features such as executed lines or returned values of functions.
  • 2:38 - 2:43
    The next step in debugging is to automate and simplify.
  • 2:43 - 2:46
    The idea being that you write a test gate
  • 2:46 - 2:51
    at which you can reproduce the bug at any time automatically.
  • 2:51 - 2:56
    At first, this helpful, of course, for doing regression testing
  • 2:56 - 3:00
    such that you can always verify whether the problem is there or not.
  • 3:00 - 3:05
    However, results are helpful to automatically simplify the problem
  • 3:05 - 3:11
    if you have a big input which causes a failure, then an automatic test
  • 3:11 - 3:15
    can help you automatically simplifying this input.
  • 3:15 - 3:21
    The technique of delta debugging takes this big input and with the help of an automatic test
  • 3:21 - 3:29
    automatically simplifies it to an input in which every single item is relevant for reproducing the failure.
  • 3:29 - 3:36
    This can be a great aid as it comes to understanding what makes the failure occur and what not.
  • 3:36 - 3:43
    Once you have simplified the problem, the next step will be to find possible infection origin.
  • 3:43 - 3:48
    If your program fails, you can see its execution as a succession of state.
  • 3:48 - 3:55
    The last state is what you see as a failure and you want to figure out where did this failure come from.
  • 3:55 - 3:59
    The concept of dependencies helps you figuring out
  • 3:59 - 4:04
    the possible sources of an infection and rule out all the other ones.
  • 4:04 - 4:07
    When you're tracking back where a failure came from,
  • 4:07 - 4:11
    you frequently have the choice of looking at multiple possible origins.
  • 4:11 - 4:17
    But you'd like to do is to focus first on those origins which are most likely.
  • 4:17 - 4:23
    If you know that some state is already infected that is wrong, you will focus on this one first.
  • 4:23 - 4:29
    If you know from some earlier state that this caused this later state,
  • 4:29 - 4:32
    you will also like to focus on this one.
  • 4:32 - 4:39
    If you know from statistical debugging that some feature is correlated with the failure, go for it.
  • 4:39 - 4:45
    And if you have reason to believe that some particular state is likely to be buggy anyway,
  • 4:45 - 4:49
    for instance, because of it's bug history, you also go for it.
  • 4:49 - 4:54
    And we have seen techniques how to determine all of these in particular assertions
  • 4:54 - 5:00
    which help a lot for finding out immediately during the execution
  • 5:00 - 5:03
    whether some part of the state is erroneous or not.
  • 5:03 - 5:08
    The sixth step is to isolate the infection chain.
  • 5:08 - 5:14
    What this means is for every likely origin, you go and conduct an experiment
  • 5:14 - 5:17
    to see whether it actually is the cause of the failure.
  • 5:17 - 5:22
    For this, you used the scientific method. You set up a hypothesis.
  • 5:22 - 5:26
    This could be the cause. This could be the cause. This could be the cause.
  • 5:26 - 5:29
    Make up an appropriate prediction.
  • 5:29 - 5:33
    Set up an experiment and based on the observation,
  • 5:33 - 5:38
    you either refine your hypothesis or you reject your hypothesis.
  • 5:38 - 5:44
    Be sure to make these steps explicit as it helps structure your thinking
  • 5:44 - 5:50
    and as it helps you interrupting and resuming your debugging activities as needed.
  • 5:50 - 5:56
    You repeat this going backwards throughout the program until you arrive at a place
  • 5:56 - 6:03
    where the incoming data is same but the outgoing data is infected.
  • 6:03 - 6:11
    The statement which generates this infection is the defect. This is the last step of debugging.
  • 6:11 - 6:17
    To correct the defect, such that it no longer produces an infection
  • 6:17 - 6:21
    but actually makes the program behave correctly.
  • 6:21 - 6:29
    Before you fix the defect, you should be sure that the defect actually is the defect.
  • 6:29 - 6:34
    That is that by changing it appropriately, the problem will be fixed.
  • 6:34 - 6:40
    You should have a clear understanding about how your correction fixes the defect.
  • 6:40 - 6:43
    And then, there are also some chores to be made.
  • 6:43 - 6:46
    You need to verify that the failure no longer occurs.
  • 6:46 - 6:52
    You need to make sure that your correction did not introduce new problems
  • 6:52 - 6:57
    and again assertions as we've seen them in this course, helped you a lot with that.
  • 6:57 - 7:02
    You may also wish to search your code to check whether the same mistake
  • 7:02 - 7:06
    was made elsewhere and fix these locations as well.
  • 7:06 - 7:12
    Note how these seven steps of debugging can be easily memorized by looking at their first letters
  • 7:12 - 7:15
    which formed the word TRAFFIC.
  • 7:15 - 7:21
    Traffic may not immediately be related to debugging unless
  • 7:21 - 7:27
    you're debugging traffic programs but the way that infections propagate to the program
  • 7:27 - 7:30
    and what's happening during a program execution
  • 7:30 - 7:35
    can be as confusing as more than traffic in a real big city.
  • 7:35 - 7:41
    With these seven steps, you're done with debugging. Congratulations!
  • 7:41 - 7:43
    And now, let's move on to the next part.
Tytuł:
The Seven Steps of Debugging - Software Debugging
Video Language:
English
Team:
Udacity
Projekt:
CS259 - Software Debugging
Duration:
07:46

English subtitles

Revisions Compare revisions