curriculum.naf.orgcurriculum.naf.org/packaged/assets/downloads/technolog… · Web viewTo fix the...

AOIT Introduction to Programming

Lesson 11Advanced Debugging Techniques

Student Resources

Resource Description

Student Resource 11.1 Debugging: Buggy House Program

Student Resource 11.2 Reading: Advanced Debugging Techniques

Student Resource 11.3 Notes and Practice: Advanced Debugging Techniques

Student Resource 11.4 Design and Coding: Olympic Rings Debug Program

Student Resource 11.5 Reading: Documenting Bugs and Fixes

Student Resource 11.6 Notes and Practice: Documenting Bugs and Fixes

Student Resource 11.7 Course List: Bugs and Fixes

Copyright © 2009–2015 NAF. All rights reserved.

AOIT Introduction to ProgrammingLesson 11 Advanced Debugging Techniques

Student Resource 11.1

Debugging: Buggy House ProgramStudent Names:_____________________________________________________ Date:____________

Directions: Open sample program house_buggy_NOcomments.py. Run it to see what bugs you observe. Then follow the directions in the two sections below.

Finding the BugsWrite descriptions for all the bugs you observe in house_buggy_NOcomments.py.

Note: There is space for five descriptions below. There may be five or fewer than five bugs in the program.

1. First bug description (line of code causing the bug and why):

2. Second bug description (line of code causing the bug and why):

3. Third bug description (line of code causing the bug and why):

4. Fourth bug description (line of code causing the bug and why):

5. Fifth bug description (line of code causing the bug and why):



Fixing the BugsTo fix the bugs, save the program as house.py, fix the bugs in the new program, and comment the code in the program. Follow this process:

1. Put meaningful bug description comments above each of the bugs in the program.

2. Fix the bugs, comment out the buggy lines, and add comments to your new (correct) lines of code.

3. Write meaningful comments for the rest of the lines in the program. Make sure that for each line there is a comment beginning with a comment character (#).




Reading: Advanced Debugging Techniques

This presentation does the following:

• Explains what debugging is and how it relates to testing

• Explains different debugging approaches

• Analyzes the bugs and debugging approaches for the Buggy House program

• Analyzes the debugging techniques used in the Hangman program

• Previews the advanced debugging approaches to be used in the culminating project



In professional programming environments, debugging tends to involve a methodical approach to finding and eliminating bugs, or defects, in computer programs.

Debugging in professional programming organizations is included as part of development and unit-testing.

Debugging is related to, but not synonymous with, testing. Testing helps to find the bugs, and debugging eliminates them.

Professional programmers usually have a number of sophisticated tools at their disposal, including tracing and debugging applications closely aligned with their coding environments. (Tracing involves “tracking” and reporting on the step-by-step progress of the program from start to finish by an application written for that purpose.)

In this course, we won’t be using special tools, but the complex programs you are now writing (and will be writing for the remainder of the course) require a more systematic and sophisticated approach to finding and fixing bugs.

Answer: Methodical means taking a careful, step-by-step approach to accomplishing a given task.



The trick to bug-free code is to not put the bugs into the code in the first place!

We have focused in this course on some programming “best practices” that help you produce high-quality and bug-free code, including good program design and organization and using meaningful comments in the code.

Good organization helps to “chunk” the code into smaller pieces that are easier to test than entire programs.

Both good organization and good comments help you to think through what it is you are trying to do so that you are less likely to make mistakes doing it. Comments help not only you, the coder, but also other people who might be testing or using the code after it is complete (for example, testers and coders working on a future release of the program).



A sophisticated and methodical process is less important with simpler programs, which you have been writing until recently. It is much easier to debug a program of 20 lines than one of 500. This is another reason to use modular design in your code in longer programs by writing functions, modules, or classes.

As you’ll recall from various test plans you have done, heuristic tests involve “playing around with” the program instead of entering precisely prescribed data. Heuristic debugging is similar: you debug using a trial-and-error method. This is common with more simple programs, but it plays a role in complex programs, as well.

The heuristic testing in Guess-A-Number involved making various number guesses, some of which seemed too low and some too high, and observing the results.

In practice, programmers often keep copies of the code with bugs in it. This is because when they are fixing the bugs, other parts of the code sometimes break. Keeping a copy ensures that you have the original code available to you. Another safe debugging technique is to just comment-out code that may not be working. This also allows you to undo changes.



The Buggy House program has three bugs:

• The bottom of the square (the house body) doesn’t draw correctly.

• The roof is tilted at an angle.

• The default turtle has mysteriously appeared and has remained after the drawing is complete.



The first bug has occurred because an incorrect value (50) has been hard-coded into the program. The variable halfside should be used instead.



The second bug is in the for-loop, which should loop four times but loops only three. Do you see why?

A print statement has been inserted that would have helped you track down the bug. Notice that the program comment indicates that the line should finish at 360. If you ran the program with the print statement, it would show the last value as 270, so you would know it was not looping four times.

Instead of using 4*90, you could also use 4*90+1.

This is a tricky bug to find and the most difficult of the three. At a glance, the code looks okay.



This bug involves “dead code” that the programmer probably intended to use but didn’t. The variables x and y are never used.

The fact that the code references the default turtle (there is no myturtle. prefix) means that Python thinks there are two turtles and places the default black arrow in the drawing window.

However, this code doesn’t really do anything and should simply be removed or commented out.

The presence of the default turtle in the drawing window should have been your clue to what was wrong.



Buggy House was a simple program, and you probably found the bugs using heuristics. However, starting with Hangman and continuing through the rest of the course, you need more sophisticated debugging techniques.

You were given some code to test the “chunks” that make up the Hangman program.



Here is the code that was temporarily inserted into the Hangman program to test the code chunks (for example, the user-defined functions).

The featured statement is the print statement. These statements print the state of the program at the time they execute: often they print the value of a variable. That way, as you watch the “debug” version of the program run (that is, the version with the debugging code active), you can see whether a variable has been properly set or even whether it has any value at all. Remember to remove or comment-out debugging code in the final version of the program.



Debugging involves both prevention (that is, following programming best practices) as well as finding and fixing bugs. All of the elements listed on this slide are important in producing bug-free (or nearly bug-free!) code.




Notes and Practice: Advanced Debugging TechniquesStudent Names:_____________________________________________________ Date:____________

Directions: While you are watching the presentation called “Advanced Debugging Techniques,” take notes, and answer the questions in Part 1, below. Then do the independent exercises in Part 2.

Part 1: Notes and AnalysisWrite answers to the questions in the space provided.

1. How are testing and debugging related?

4. In this context, what does methodical mean?

5. How do strict program organization and code comments help to avoid bugs?

6. Describe a heuristic test you did for the Guess-A-Number program.

7. Write the step-by-step process you followed to find and fix one of the bugs in the Buggy House program. Number your steps.

8. What statement is featured in the Hangman debugging code?

Part 2: Independent Practice Open the sample program hangman_stage.py from Lesson 10 (this is the version of Hangman that has the test code). Run the program and observe the results.

Following is the debugging code. In the space provided, write two comments for each of the lines of temporary processing code explaining (1) what output the line of code produces and (2) how the



information could be useful in debugging the program. The first one has been done for you as an example.

Hangman Debugging Code##############################

#PROCESSING SECTION

##############################

#

# Test the initialization code

#

print("*** test the initialization code ***")

# (1) Prints the string "mystery word" and the value of variable "theword"

# (2) Allows you to see if the mystery word is being selected correctly

print("mystery word" , theword)

# (1)

# (2)

print("animal_words" , animal_words)

# (1)

# (2)

print("word_len" , word_len)

# (1)

# (2)

print("guesses" , guesses)

# (1)

# (2)

print("letters_tried" , letters_tried)

#

# Test the user-defined functions

#



print("*** testing the user-defined functions ***")

# (1)

# (2)

print_game_rules(max_incorrect, word_len)

# (1)

# (2)

for i in range(3):

a = prompt_for_letter()

print("prompt_for_letter() returned <"+a+">")

# (1)

# (2)

for i in range(8):

print("bad guesses set to",i)

display_figure(i)




Design and Coding: Olympic Rings Debug ProgramStudent Names:_____________________________________________________ Date:____________

Directions: Open sample program olympic_rings_function.py from Lesson 9. Save it under the name olympic_rings_debug.py in your Lesson 11 folder.

Follow the specific instructions in each section below.

Putting Debugging Code into the New ProgramUsing the debugging statement in the Hangman program as your general model, put similar print statements into the Olympic Rings program you worked on earlier. Your new code needs to meet these general requirements:

● Comment each line of code you enter (or at least every block of code).

● Put one statement in the draw_ring() function to print out all the parameter values. Print out all the values on the same line.

● Print two informational messages in the draw_ring() function to indicate where the drawing begins and where it ends.

● Print one informational message in the processing initialization section of the program to indicate the beginning of the program.

● Print one informational message in the processing section of the program to indicate the beginning of the function calls. (Hint: Do you need one print statement or five to print out all five calls to the function?)

Run your program with the debugging code active.

When you have your program running without errors and you are satisfied with the results you are getting, proceed to the following section.

Explaining How the Debugging Code WorksIn the space below, write your explanation of how your debugging code works. When you are satisfied that it is an accurate and helpful explanation, give it to one of your peer programmers for review and written feedback.

My Explanation of How the Debugging Code Works



Peer Programmer Feedback Does the explanation make sense? Is the information useful?




Reading: Documenting Bugs and Fixes

This presentation does the following:

• Explains the various uses for bug/fix documentation

• Lists and defines the information elements commonly included in bug/fix lists



So far in this course we have used bug/fix information for one of two purposes:

• As an education tool to share with others in the course (or possibly with future students in this course) in the form of a list of key bugs to watch out for

• As a note in the prolog of a program you were handing in for assessment indicating one or more bugs that didn’t get found and fixed

In the first case, the information is historical: presumably you have found and fixed the bug, but you want to warn others about it.

In the second case, the motivation is simply to record the status of your program in a straightforward and honest way.

In professional programming organizations, the key motivators (to record status and to provide educational information) are the same, but the information is kept and recorded somewhat differently than you have been doing in this course.

The internal information is for people on the programming team; for example, peer programmers, testers, managers, and the support teams (that is, people fielding questions from customers).

The external information is for individual application program users or customer or client organizations.

Think a bit about the needs of the internal users vs. those of the external users. How are they the same? How are they different?



Since professionally produced application programs typically are hundreds or even thousands of lines long, a prolog would not be a good place to keep the bug list. However, what often is inserted into the prolog is a unique reference to a bug and a very brief description. This reference is then placed in comments near the code modified or added to fix the bug. A more detailed description of the bug, including who fixed it, details about the problem, and the actions taken would be found in a separate bug log.

In addition to the space problem, bug information in a prolog could not be sorted, ordered, and otherwise “sliced and diced” the way professional bug lists must be. Having this information helps professional organizations manage their activities and personnel, and customers often demand access to this kind of information. Customers need it to decide whether to buy the software product and whether to upgrade to the next release. They use it as a measure of quality. Sometimes customers (and even entire countries, like Germany, or regions, like all the countries in the European Union) require the information. If companies can’t or won’t provide the information, they are not allowed to do business in the country or region!

Most software companies of any size want to do business around the world.

Typically, professional bug/fix information is stored in a relational database management system along with a software application to allow queries against the database.



All of these items would likely be on the company’s internal list.

External lists typically include a unique identifier or name, the product release information, how important the bug is, and when it was fixed (that is, in what release it was fixed rather than the date it was fixed).

Some minor fixes might not show up on external lists, but all fixes should show up on the internal one.



You have used bug lists since the beginning of this course.

For the culminating project, we will revisit the format and purpose of the course bug/fix list and add statistical information.

Writing a bug/fix list in a professional format will be good practice for your future career, whether you work in programming or another field that uses status information and statistical compilation of information.




Notes and Practice: Documenting Bugs and FixesStudent Names:_____________________________________________________ Date:____________

Directions: While you are watching the presentation called “Documenting Bugs and Fixes,” take notes, and answer the questions in Part 1, below. Then do the independent practice exercises in Part 2.

Part 1: Notes and Analysis1. For what two purposes have we used bug/fix lists so far in this course?

2. Write two pieces of information you would include in a list that would be used for both these purposes?

3. Where might you put a bug/fix list to be used for internal purposes?

4. Where might you put a bug/fix list to be used for external purposes?

5. Why are database systems useful places to store program bugs and fixes?

6. Would the name of the programmer responsible for fixing the bug likely be in an external bug/fix list? Why or why not?



Part 2: Independent Practice Spend 5–10 minutes going back through the bugs you have written down so far in this course. Choose three that you believe are significant and might be encountered by other students taking this course. (The bugs don’t need to be currently open, or unresolved; they just need to be “important” and “typical” of the bugs you have encountered so far.)

Write the bugs below, just as you originally wrote them.

Part 3: Formal Bugs and Fixes FormatFor the culminating project, you will be recording bugs in the format discussed in the “Documenting Bugs and Fixes” presentation. That bug/fix list must include the following information:

● Bug name

● Bug category

● Program where the bug was encountered

● Who reported the bug (programmer or tester, and the person’s name)

● Symptoms, description

● Severity:

1 = Most severe: the program does not run

2 = The program produces obviously incorrect results

3 = The program produces incorrect results, but it might not be obvious to a casual user

● Date closed (if this information is not included, the implication is that the bug is still open)

In the space below and on the back of this sheet, rewrite your three bugs from Part 2 of this worksheet using the information and format indicated above.




Course List: Bugs and Fixes Student Names:_______________________________________________________ Date:___________

Directions: Add 6 to 10 bugs to the following table. If you need more room to write, use a separate piece of paper, but keep the same columns and headers.

For information about how this assignment will be assessed, see the criteria that follow the table.

Bug Name

Bug Category Program Reported By Symptoms, Description Severity Date

Closed

Syntax error

Invalid syntax circle.py Programmer:

Jane DoeRunning the program results in a syntax error. 1

Circle not filled in

Incorrect results circle.py Tester: John

Doe The circle is not filled in. 2

Head missing

Missing results snowman.py Programmer:

Alan Roe

When the program has completed execution, the snowman’s head is not drawn.

2

Data conversion incorrect

Incorrect results temperature.py Tester: John

Doe

If test data for Celsius is entered as 0, the converted result is 40, which is incorrect.

2

Cost results missing

Missing results car_cost.py Programmer:

Alan Roe

The program does not print the total cost of the car.

2

Valid password rejected

User input rejected

new_password.py Tester: Mary Roe

The user password of abcd12345 was not accepted.

2

Circles too small

Incorrect results olympic_rings.py Tester: Mary

Roe The circles are too small. 3

Card suit incorrect

Incorrect results shuffle_cards.py Programmer:

Alan RoeProgram always returns spades for the card suit. 2



Make sure your assignment meets or exceeds the following assessment criteria:

● The 6 to 10 bugs added to the course bugs and fixes list represent a cross section of bugs encountered in this course.

● Every column in the table has been completed for every bug in the list. If some data was missing from the original bug description, appropriate data has been entered.

● The severity level chosen for each bug is appropriate for the information in the “Symptoms, Description” column.

● The bug names and categories are succinct but appropriately descriptive.

● The information in the “Symptoms, Description” column is at an appropriate level of detail and would be helpful to a peer programmer assigned to track down and fix the bug.

● The bug information text does not contain spelling or grammatical errors.


curriculum.naf.orgcurriculum.naf.org/packaged/assets/downloads/technolog… · Web viewTo fix the...

Documents

Transcript of curriculum.naf.orgcurriculum.naf.org/packaged/assets/downloads/technolog… · Web viewTo fix the...