CMP 4266

Software Development UG1

Lecture – 5

(Based on Lecture Slides Prepared by Richard Kay & Dr. Shadi Basurra)

CMP4266, School of CTN, Birmingham City University.

Outline

● Introduction to debugging
● Syntax Errors
● Code inspection
● Fixing compilation errors

● Runtime Errors
● Understanding runtime exception tracebacks

● Logical Errors
● Plan, then test
● Break Points
● Watch variables
● Use of the IDLE debugger

● Test Table Design

CMP 4266, School of CS and DT, Birmingham City University.
Introduction to debugging

 Debugging means identifying and

fixing errors or bugs in programs.

 Sometimes the term: bug is also

used to refer to a mistake or fault
in other places which has to be
found and fixed.

 This name might have originated

from a hardware error resulting
from a moth found within a relay in
an early computer, discovered and
photographed by Grace Hopper in
1940s.

CMP 4266, School of CS and DT, Birmingham City University.

Type of Errors

 Syntax Errors:
– Common syntax errors could be incorrect indentation, missing
elements, misspelling etc. Easiest to find, by code inspection or the
interpreter reports it at compilation time.

 Runtime Errors:
– May go unnoticed at compilation time and only revealed at runtime.

 Logical Error:
– Usually the hardest to find. Can be identified by observing/watching the
program behaviour.

CMP 4266, School of CS and DT, Birmingham City University.

 Syntax Errors

CMP 4266, School of CS and DT, Birmingham City University.

Syntax Errors - Code inspection

 Python interpreter will find these kinds of errors when it tries to

compile your program, and exit with an error message without
running anything.
 Syntax errors are mistakes in the use of the Python language.
 It's a good idea to give code a thorough visual inspection first,
before trying to compile it.

– Check for layout/indentation

– Check for punctuation

– Check for spelling mistakes

CMP 4266, School of CS and DT, Birmingham City University.

Code inspection: checking for consistency of layout

 Python interpreter uses the indentation to mark the beginning and end of
blocks.
 Some of the block control key words in Python are def, for, if, else, elif, try,
except etc.
 Example

1. def test():
2. for year in [2000,1903,2008,2009]:
3. if(isleap(year)):
4. isornot=""
5. else:
6. isornot="not "
7. print(str(year)+" is "+isornot+"a leap year“)

How does the interpreter know which statements are controlled by which
block controls ? It can't form a layout like this.
CMP 4266, School of CS and DT, Birmingham City University.
Code inspection: correcting block structure

1. def test():
2. for year in [2000,1903,2008,2009]:
3. if(isleap(year)):
4. isornot=""
5. else:
6. isornot="not "
7. print(str(year)+" is "+isornot+"a leap year“)

How many times should the print statement execute ?

CMP 4266, School of CS and DT, Birmingham City University.

Code inspection: correcting block structure

1. def test():
2. for year in [2000,1903,2008,2009]:
3. if(isleap(year)):
4. isornot=""
5. else:
6. isornot="not "
7. print(str(year)+" is "+isornot+"a leap year“)

How many times should the print statement execute ?

CMP 4266, School of CS and DT, Birmingham City University.

Code inspection: correcting block structure

1. def test():
2. for year in [2000,1903,2008,2009]:
3. if(isleap(year)):
4. isornot=""
5. else:
6. isornot="not "
7. print(str(year)+" is "+isornot+"a leap year“)

How many times should the print statement execute ?

CMP 4266, School of CS and DT, Birmingham City University.

Code inspection: checking punctuation

 Brackets and quotes (i.e. () [] {} "" ' ‘) must appear as matching pair.
 Block control statements def, if, for, while etc. must end with a : colon.
 A backslash \ or % escape can make the following character into something
different.
 List items are separated using commas (,).

1. def test( :
2. for year in [2000.1903'2008,2009 };
3. if (isleap(year):
4. isornot='"
5. else
6. isornot="not \"
7. print(str(year)+" is " &isornot+"a leap year“)

This code has 10 punctuation errors.

CMP 4266, School of CS and DT, Birmingham City University.

Code inspection: checking spelling

1. def test():
2. for y in [2000,1903,2008,2009]:
3. if(isleap(year)):
4. isornot=""
5. else:
6. isorno="not "
7. print(str(yaer)+" is "+issornot+"a leap year“)
8. Test()

 The defined function name needs to be checked against all calls to it.
 The variables used for year and isornot also need consistent spelling.
 Use edit find (<ctrl><f>) and find again (<ctrl><g>) to check consistency
and to cycle through occurrences of same function, module, class or
variable name.

CMP 4266, School of CS and DT, Birmingham City University.

Fixing compilation errors 1

 The compiler will

report a location
within code where it
detects an error
preventing
compilation.

 The error might be

at the place in the
code where the error
is detected.

CMP 4266, School of CS and DT, Birmingham City University.

Fixing compilation errors 2

 Or the real error might

be before the place in
the code where the
compiler detects the
error. Can you spot the
syntax error in the line
above the else?

 We still need to do a
careful visual code
inspection.

CMP 4266, School of CS and DT, Birmingham City University.

 Runtime Error

CMP 4266, School of CS and DT, Birmingham City University.

Runtime errors

 If a program is syntactically correct – that is, free of syntax

errors – it will be run by the Python interpreter.
 However, the program may exit unexpectedly during execution
if it encounters a runtime error
 Some examples of Python runtime errors:
– division by zero
– performing an operation on incompatible types
– using a variable which has not been defined
– accessing a list element or object attribute which doesn’t exist
– trying to access a file which doesn’t exist

CMP 4266, School of CS and DT, Birmingham City University.

Reading runtime exception tracebacks

 The traceback which

occurs when an
exception is raised at
runtime helps us
locate and identify the
error causing a crash,
but we'll also need to
inspect and
understand the code
which raised it.

 Can be handled by
careful coding and
exception handling

CMP 4266, School of CS and DT, Birmingham City University.

 Logical Error

CMP 4266, School of CS and DT, Birmingham City University.

Logical Error

 Logical errors are the most difficult to fix.

 They occur when the program runs without crashing, but produces
an incorrect result.
 The error is caused by a mistake in the program’s logic. Hence, you
won’t get an error message, because no syntax or runtime error has
occurred.
 You will have to find the problem on your own by reviewing all the
relevant parts of your code
 Here are some examples of mistakes which lead to logical errors:
– using the wrong variable name
– indenting a block to the wrong level
– Wrong mathematical calculation
– making a mistake in a boolean expression

CMP 4266, School of CS and DT, Birmingham City University.

Exercise 5.1 – Identifying syntax &
runtime errors (20 minutes)
In-class
Exercise

 Download and unzip the exercise-5.1-buggy.zip from Moodle

which exists under the section “Week 5”.
 Identify and fix 9 syntax and runtime errors in the code.
 You should put a #comment next to each identified error
indicating the error type e.g. #runtime or #syntax
 Once the software is fixed, the software output should look like
the following:

CMP4266 , School of CS & DT, Birmingham City University.

Break Points

 A break point is a source code line where we temporarily pause the running
program while we are in the process of debugging it.

 If the program has done everything it should have correctly prior to the
breakpoint, the error must be after the breakpoint.

 We can then set another breakpoint, and check whether the error we are
searching for occurs between the 2 breakpoints, to narrow down search
space.

CMP 4266, School of CS and DT, Birmingham City University.

IDLE Debugger

 IDLE has a built in debugger that allows to analyze the program's state
after each statement

 IDLE debugger enable us to step into functions one source code line at a
time, step over these or out of them as needed, or just run the program
normally. We can watch the variables change as we do this.

 If we have modularised our program into a number of small functions, this

will give us more flexible control of our program while running it within the
debugger.

 Start a program in debug mode

– In Python Shell window, select File>Open to open a python script
– In Python Shell window, select Debug>Debugger to initiate the Debug Control
– In Source program window, select Run>Run Module
CMP 4266, School of CS and DT, Birmingham City University.
IDLE Debugger

CMP 4266, School of CS and DT, Birmingham City University.

IDLE Debugger

 Buttons:
– Go: Run the program until the next breakpoint
- To set breakpoints, right click on a line and choose “set breakpoint”.
– Step: Execute the next statement. If the next statement is a function call
execution will step into the function
– Over: Same as step, except if the next statement is a function call, it will
not step into the function.
– Out: complete the current function

 Options:
– Stack: Displays the current running function
– Source: Displays the current statement in the source file
– Locals: Displays the local variables and their values
– Globals: Displays the global variables with their values

CMP 4266, School of CS and DT, Birmingham City University.

Spyder Debugger - Watch runtime variable values

CMP 4266, School of CS and DT, Birmingham City University.

Test Case

 Test Case is the basic component to perform software testing. In the most
general form test cases
– specifies the actual input values and anticipate output values
– identifies any constrains on the execution of the test case (e.g. processor
speed, available memory)

 Test case execution: is the process of executing the software system

– under the constraints specified in the test case
– using the inputs specified in the test case
– observing the results and comparing them to those specified by the test case
– If the observed result varies from the anticipated result, then a failure has been
detected

CMP 4266, School of CS and DT, Birmingham City University.

Test Case Design

 Testing cannot guarantee the absence of all defects, so test-case design is

important to try to make tests as complete as possible.

 The basic approach to design test cases depends on i) the software’s

specification only (black box testing), or ii) the software’s specification and
the code that implements the software (white box testing)

 Test case design should consider many issues

– Equivalence partitioning
– Boundary value analysis
– Statement coverage
– Decision/condition coverage

CMP 4266, School of CS and DT, Birmingham City University.

Test Case Design - Equivalence partitioning

 Equivalence partitioning
– Possible inputs could be very large and infinite, so testing is limited to a small
subset of inputs.
- Divide a set of test conditions into partitions that can be considered the same.
- Then we take one value from each partition for testing. The hypothesis is, if one value of the partition pass, all
other values will also pass. Likewise, if one condition in one partition fails, all numbers in this condition will fail.

 Example
– Let's consider the behaviour of tickets in the Flight reservation application, while
booking a new flight.
– Ticket values 1 to 10 are considered valid & ticket is booked. While value 11 to
99 are considered invalid for reservation and error message will appear, "Only
ten tickets may be ordered at one time."

CMP 4266, School of CS and DT, Birmingham City University.

Test Case Design - Boundary value analysis

 Boundary value analysis

– Test cases are designed based on the boundary values between the
partitions identified during the previous Equivalence partitioning test.
- select the input from the boundary values
- select inputs that produce output boundary values

 Example

CMP 4266, School of CS and DT, Birmingham City University.

Statement coverage & Decision/condition coverage

 Code coverage: how completely test cases execute the code

of the software system. Attempt should be made so that test
cases
– enter and exit every module/methods/procedures.
– execute every line of code
– follow every logic and decision path through the software

 Decision/condition coverage
– every condition in a decision in the program has taken all possible
outcomes at least once
– every decision in the program has taken all possible outcomes at least
once.

CMP 4266, School of CS and DT, Birmingham City University.

Test Table Design (Example)

CMP 4266, School of CS and DT, Birmingham City University.

Programme specification

 A programmer has developed a software to allow users to

view, create, and edit contacts and contact lists.
 Once the programme starts, it loads all existing contacts, and
then view a basic menu as shown below:

CMP 4266, School of CS and DT, Birmingham City University.

Test cases TC1

Test Software Input Expected Actual output Passed

Case Feature output /Failed
ID

TC1 View contact User to run the programme. A list of already A list of existed Passed
list Main menu to appear with 4 existing contacts will appear
options: contacts will
User to input option: v appear

CMP 4266, School of CS and DT, Birmingham City University.

Test cases TC2

Test Software Input Expected Actual output Passed

Case Feature output /Failed
ID
TC2 Add a new User to run the programme. A new contact A new contact has Passed
contact Main menu to appear with 4 should be been added to the
options: added to the system, and is visible
User to input option: a list, and the in the list of contacts
user should be
able to view
once the option
view contacts
list is selected

The system will prompt the

user to enter the name and
phone number of the new
contact

CMP 4266, School of CS and DT, Birmingham City University.

Test cases TC3

Test Software Input Expected Actual output Passed

Case Feature output /Failed
ID
TC3 Deleting User to run the programme. Alice and her Alice and her relevant Passed
existing A main menu to appear with 4 phone number Phone No has been
contact options: to be deleted deleted from the
User to input option: d from the system.
system.
This is apparent when
selecting the v option
to list all available
contacts.

The user will be asked for the

index of the contact to be
deleted.

This should delete Alice with

her Phone No

CMP 4266, School of CS and DT, Birmingham City University.

Test cases TC4

Test Software Input Expected output Actual output Passe

Case Feature d/Fail
ID ed
TC4 Deleting non- User to run the programme. User should get a Software to Failed
existing A main menu to appear with 4 warning message crash:
contact options: “Invalid index IndexError: list
User to input option: d number” and assignment
should be sked to index out of
re-enter a valid range
index number
ranging between 1
and 3

The user will be asked to provide

the index of the contact to be
deleted.

Although there are only 3 contacts,

the user asked for contact with
index 10 to be deleted. This contact
does not exist.

CMP 4266, School of CS and DT, Birmingham City University.

Test cases TC5

Test Software Input Expected Actual output Passed

Case Feature output /Failed
ID
TC5 Quit the User to run the programme. the system The system has quitted Passed
system Main menu to appear with 4 shutdown with with no problems
options: no issues
User to input option: q to exit
the system.

CMP 4266, School of CS and DT, Birmingham City University.

GUI Based Testing (Example)

 The screenshot shows the application in action with a user

adding a new name and address

Test Case ID System Feature Input Expected Output Observed Output

TC-1 Adding a new address Input text in text fields A new address book is
Forname: added, and displayed on
John the MyAddresses main
Surname: window
Doe
Email:
[email protected]
Phone:
555
Press OK Button

CMP 4266, School of CS and DT, Birmingham City University.

 Exercise 5.2 – Identify logical errors &
write a Test Table (25 minutes)
In-class
Exercise

 Download and unzip the exercise-5.2-buggy.zip from Moodle which

exists under the section “Week 5”.
 Identify and fix 4 logical errors in the code.
 Write a test table for the given calculator software.
 You should put a #logical error next to each identified error in the code.
 Once the software is fixed, the software output should look like the
following:

CMP4266 , School of CS & DT, Birmingham City University.