testing_and_debugging

Document Sample
testing_and_debugging Powered By Docstoc
					CS1101: Programming Methodology
http://www.comp.nus.edu.sg/~cs1101x/


               Aaron Tan
   Overview
      Testing and debugging are important activities in
       software development.
      Techniques and tools are introduced.
      Part of the material here comes from chapter 13 of
       Cohoon and Davidson‟s book and chapter 6 of Barnes
       and Kolling‟s book “Objects first with Java”.




Acknowledgement: Cohoon and Davidson; Barnes and Kolling.
                               CS1101X: Testing and Debugging   2
Programming Errors
   Compilation errors
       Syntax error (example: missing a semi-colon).
       Semantic error. (For example, applying modulus % on floating-
        point value for certain programming languages. In Java ,is it
        fine? Yes!)
       Easiest type of errors to fix.
   Runtime errors
       Occur at runtime.
       Java‟s exception mechanism can catch such errors.
   Logic errors
       Program runs but produces incorrect result.
       Hard to characterize, hence hardest to fix.
   Programming errors are also known as bugs
       Origin: a moth in the Mark I computer.

                           CS1101X: Testing and Debugging               3
Testing and Debugging (1/7)
   Testing
       To determine if a code contains errors.
   Debugging
       To locate the error and fix it.
   Documentation
       To improve maintainability of the code.
       Include sensible comments, good coding style and clear logic.


                          Testing                              Error?

                                                                   Yes
                                          Debug


                              CS1101X: Testing and Debugging             4
   Testing and Debugging (2/7)
    Unit testing
          Test of individual parts of an application – a single method, a single
           class, a group of classes, etc.
    Positive versus negative testing
          Positive testing – testing of functionality that we expect to work.
          Negative testing – testing cases we expect to fail, and handle
           these cases in some controlled way (example: catch handler for
           exception).
    Test automation
          Regression testing – re-running tests that have previously been
           passed whenever a change is made to the code.
          Write a test rig or a test harness.
This and the next slides involve materials not covered yet or to be covered in other
modules (such as Software Engineering). You will need to gain relevant experience
before you can appreciate them. Hence I will skip them for the moment.
                                    CS1101X: Testing and Debugging                     5
Testing and Debugging (3/7)
   Modularization and interfaces
       Problem is broken into sub-problems and each sub-problem is
        tackled separately – divide-and-conquer.
       Such a process is called modularization.
       The modules are possibly implemented by different programmers,
        hence the need for well-defined interfaces.
       The signature of a method (its return type, name and parameter
        list) constitutes the interface. The body of the method
        (implementation) is hidden – abstraction.
       Good documentation (example: comment to describe what the
        method does) aids in understanding.

    static double max(double a, double b)
                       Returns the greater of two double values.


                            CS1101X: Testing and Debugging          6
Testing and Debugging (4/7)
   Manual walkthroughs
       Pencil-and-paper.
       Tracing the flow of control between classes and objects.
       Verbal walkthroughs




                           CS1101X: Testing and Debugging          7
Testing and Debugging (5/7)
   Print statements
       Easy to add
       Provide information:
            Which methods have been called
            The value of parameters
            The order in which methods have been called
            The values of local variables and fields at strategic points
       Disadvantages
            Not practical to add print statements in every method
            Too many print statements lead to information overload
            Removal of print statements tedious




                               CS1101X: Testing and Debugging               8
Testing and Debugging (6/7)
   Debugger
       Provides
          Stepping (step and step-into)

          Breakpoint

          Tracking of every object‟s state




               Program testing can be used to show the
               presence of bugs, but never to show their
               absence. – Edgar Dijkstra


                           CS1101X: Testing and Debugging   9
Testing and Debugging (7/7)
   Tips and techniques
       Start off with a working algorithm
       Incremental coding/test early
       Simplify the problem
       Explain the bug to someone else
       Fix bugs as you find them
       Recognize common bugs (such as using „=‟ instead of „==‟, using
        „==‟ instead of equals( ), dereferencing null, etc.)
       Recompile everything
       Test boundaries
       Test exceptional conditions
       Take a break


                         CS1101X: Testing and Debugging             10
Turning Debugging Info On/Off
public static int sum(int a, int b) {
   int left = 0;                 Add an extra boolean
   int right = data.length - 1; debugging field to the class.
   if (debugging) {
     System.out.println("sum called with a = " + a
                           + " b = " + b);
   }
   int total = a + b;
   if (debugging) {
     System.out.println("total = " + total);
   }
   return total;
}
      Debugging on.                     Debugging off.
      debugging = true;                 debugging = false;
      int ans = sum(3,5);               int ans = sum(3,5);

                      CS1101X: Testing and Debugging            11
Black-box and White-box Testing
   White-box testing indicates that we can “see” or examine
    the code as we develop test cases
   Black-box testing indicates that we cannot examine the
    code as we devise test cases
       Seeing the code can bias the test cases we create
       Forces testers to use specification rather than the code
   Complementary techniques




                            CS1101X: Testing and Debugging         12
Testing Thoroughly (1/2)
   Recall our discussion last week. Richard couldn‟t spot the
    error in this code of his.
           // To find the maximum among 3 integer
           // values in variables num1, num2, num3.
           int max = 0;
           if (num1 > num2 && num1 > num3)
             max = num1;
           if (num2 > num1 && num2 > num3)
             max = num2;
           if (num3 > num1 && num3 > num2)
             max = num3;

   He tested it on many sets of data: <3,5,9>, <12,1,6>,
    <2,7,4>, etc. and the program works for all these data.
   But he didn‟t test it with duplicate values! Eg: <3,3,3>,
    <7,2,7>, etc.
                       CS1101X: Testing and Debugging           13
Testing Thoroughly (2/2)
   Richard wrote another program.
          // To find the maximum among 3 integer
          // values in variables num1, num2, num3.
          int max = 0;
          if (num1 > max)
            max = num1;
          if (num2 > max)
            max = num2;
          if (num3 > max)
            max = num3;

   He was told that the program doesn‟t work but again he
    couldn‟t figure out why. He has tested it on many data
    sets, including duplicate values!
   Can you tell him what he missed out in his testing?
   Don‟t forget the special cases!
                      CS1101X: Testing and Debugging         14
 Testing Boundaries
    It is important to test the boundary conditions.
final int CALENDAR_START = 1583;
// validate input
if ((year < CALENDAR_START) || (month < 1) || (month > 12))
{
   System.output.println("Bad request: " + year + " " + month);
}

                     Input Year          Input Month
                        1582                      2
                        1583                      0
                        1583                     13
                        1583                      1
                        1583                     12
                        CS1101X: Testing and Debugging            15
Path Testing
   Paths: different routes that your program can take
       Design test data to check all paths
       Example
                                                                 <x=0, z=1>
                                           if (x != 3)            Paths A, B, G, H.
        if (x != 3) {
          y = 5;                       A                 E
        }                                                        <x=3, z=3>
        else {                   y=5                    z=z-x     Paths E, F, C, D.
          z = z - x;
        }                             B                  F
                                           if (z > 1)
        if (z > 1) {
                                      C                  G
          z = z / x;
        }                      z=z/x                     z=0
        else {
          z = 0;
        }                              D                     H

                            CS1101X: Testing and Debugging                        16
   Integration and System Testing
    Integration testing is done as modules or components are
     assembled.
          Attempts to ensure that pieces work together correctly
          Test interfaces between modules

    System testing occurs when the whole system is put
     together




This comes in when you start to write bigger programs.


                                    CS1101X: Testing and Debugging   17
Debugger
   Using the debugger
       Stepping
       Breakpoint
       Inspecting variables
   I will illustrate on DrJava




                         CS1101X: Testing and Debugging   18
Other readings
   Some websites
     http://www.cs.wustl.edu/~kjg/CS101_SP97/Notes/Debugging/debugging.
      html
     http://www.csl.mtu.edu/cs2321/www/SELectures/SELeccture3_Debuging
      AndTesting.htm




                        CS1101X: Testing and Debugging              19
End of File




 CS1101X: Testing and Debugging   20

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:6
posted:4/16/2011
language:English
pages:20