Ch. 15: Tesing and Debugging

Transcription

1 Ch. 15: Tesing and Debugging Software bugs cost US tens of billions of dollars Often hear in news about catastrophes due to software bugs NASA loses spacecrafts Airbags in cars do not deploy Etc Software is EVERYwhere door openers, cars, cellphones, microwaves - mundane Nuclear/electrical power stations - national infrastructure Airplanes, spacecrafts high-tech Banks, stocks - financial We cannot afford bugs in software 2009 Vijaykumar ECE495K Lecture Notes: Chapter 11 94

2 Tesing and Debugging Programmers take LONGER to debug than to write the code Testing exposing bugs Debugging fixing bugs No different than what you did with LC Vijaykumar ECE495K Lecture Notes: Chapter 11 95

3 Types of Bugs Syntactic, semantic, algorithmic syntactic bugs Mismatched parenthesis, missing semicolons, etc Undeclared variables Caught by compiler semantic bugs Incorrect loop exit conditions (end points) {multiplication table) Incorrect if-else conditions ( address verifier) Sometimes misplaced semicolons change meaning NOT caught by compiler 2009 Vijaykumar ECE495K Lecture Notes: Chapter 11 96

4 Types of Bugs Algorithmic bugs Design flaws Not capturing all cases e.g., Y2K bug Allocated space only for last 2 digits of year But software lasted lot longer than designers expected! Software lived till 2000 But 2000 indistinguishable from 1900 Major problem for banks, airplanes, infrastructure 2009 Vijaykumar ECE495K Lecture Notes: Chapter 11 97

5 Testing Any line of code that is untested is likely buggy! Putting software through trial inputs and check output Key problem is we cannot test for all possible inputs So we need to be careful with inputs Blackbox and whitebox testing 2009 Vijaykumar ECE495K Lecture Notes: Chapter 11 98

6 Blackbox testing Testing Treat program as blackbox and see if it produces correct output for a given input disregarding program internals Run trials and check outputs These runs are automated Checking is also automated (checker another program) But program and checker could have same bug! Checker programmers not allowed to see original code 2009 Vijaykumar ECE495K Lecture Notes: Chapter 11 99

7 Whitebox testing Testing Blackbox testing doesnot tell which lines were tested Blackbox hard to do if output can be slightly inexact (eg MP3 player) Whitebox tests code internals Per function, per loop etc Often whitebox modifies the code Extra printfs Put extra ifs to check error conditions Eg: tax = calculatetax (income); If (tax < 0 tax > income) printf ( Error in calculatetax\n ); 2009 Vijaykumar ECE495K Lecture Notes: Chapter

8 Debugging Testing exposes the effect but debugging needs to find the cause Debugging Identical to LC-3 debugging it is a whodunit Look at chapter 6 slides Adhoc debugging Look at the code useful only if you know bug is in small region of code Printfs 2009 Vijaykumar ECE495K Lecture Notes: Chapter

9 Source-level debugging Debugging Just like you set breakpoints after an LC-3 assembly instruction (LC-3 simulator), you can set breakpoints after a statement in C code Just like you single-step one instruction at time in assembly (LC-3 simulator), you can single-step one statement at a time in C code Just like you display values of registers in LC-3, you can display values of variables in C 2009 Vijaykumar ECE495K Lecture Notes: Chapter

10 Programming for Correctness Testing/debugging finds and removes buhs But how about avoiding them in the first place (as much as possible) Specifications Make specs as complete as possible Cover corner cases Write a program to convert lower case to capitals? What if user types capitals What if user types non-letters numbers, punctuation, etc 2009 Vijaykumar ECE495K Lecture Notes: Chapter

11 Programming for Correctness Modular Design No repetition of code Put meaningful functionality in functions/routines Functions are small and can be tested standalone helps whitebox testing Libraries help modularity 2009 Vijaykumar ECE495K Lecture Notes: Chapter

12 Defensive programming Comments Programming for Correctness Consistent coding style (variable/function names, indentation) Avoid assumptions unless in specs Look at compiler warnings Unlike errors where program won't compile, with warnings program still compiles so you can ignore warnings but likely cause bugs 2009 Vijaykumar ECE495K Lecture Notes: Chapter