Software Testing. Overview

Transcription

1 Software Testing Overview Software is NOT simply programming! Complex development process required Domain of Software Engineering Top Down software development popular The WaterFall model... November 28, 2001 Copyright 2001 by Bill Havens 1 of 15

2 WaterFall Model Initiation Analysis Design Implementation Testing Maintenance November 28, 2001 Copyright 2001 by Bill Havens 2 of 15

3 WaterFall Details Basic Model Each step independent of succeeding steps. Steps take deliverables from previous steps Produce deliverables for next step Responsibilities... November 28, 2001 Copyright 2001 by Bill Havens 3 of 15

4 WaterFall Responsibilities Phase Who Performs Deliverable Initiation Managers Request for development Analysis Systems analyst Functional specification Design Systems architect Design specification Implementation Programmer Documented code Testing Systems tester Test plan and report Maintenance Maintenance programmer November 28, 2001 Copyright 2001 by Bill Havens 4 of 15

5 Problems with Top Down Design Its Authoritarian! (decisions from above) No feedback from subsequent steps Assumes that all necessary information available at each step. Real World development does not (usually) work this way. Software business exists at the bleeding edge of what is possible (c.f. leading edge technology). Need a development model which facilitates dynamic innovation... November 28, 2001 Copyright 2001 by Bill Havens 5 of 15

6 Prototype Development Use functional specs to build (and then discard) a series of experimental prototypes. Prototypes developed in most convenient language (Java, Lisp, Prolog, Visual Basic,???) Lessons learned as feedback to previous steps. More research and less development oriented. Very popular approach. November 28, 2001 Copyright 2001 by Bill Havens 6 of 15

7 Object Oriented Design (OOD) Overview Basic Idea: use the Requirements Spec to discover the abstract objects in the problem. Describe the abstract objects formally Assign behaviour to the objects (anthropomorphism) to implement the desired system. Abstract classes of related objects from the abstraction Implement the classes in some OO language (e.g. Java) November 28, 2001 Copyright 2001 by Bill Havens 7 of 15

8 Software Testing Overview Important issue (both in industry and class) Goal: to find as many software errors as possible before release. Types of errors: 1. Syntax errors: detected usually by compiler public integer foo(n) { return (n + sqrt(n)) } Pioneer spacecraft counter example 2. Logic errors: program computes something different than specs. Classic C example public int fact(int n) { if (n=0) return 1; return fact(n-1); } November 28, 2001 Copyright 2001 by Bill Havens 8 of 15

9 3. Verification errors: mistake (or imprecision) in requirements specs Programmers implement what they see in the specs NOT what designer intended! 4. RunTime errors: bad assumptions about the environment Different computers Different Operating Systems Different Web browsers Note: Java attempts to overcome these problems (partially) 5. Maintenance errors: somebody doesnt understand your code. Removing a bug frequently introduces new bugs! Proper source code documentation is essential Using standard indentation style and commenting Note: JavaDoc helps here November 28, 2001 Copyright 2001 by Bill Havens 9 of 15

10 Testing Approaches Two basic approaches 1. Black Box: All viable inputs and expected outputs are tested. Useful for algorithms with predictable and tractable I/O. Expensive with large datasets Difficult with real-time or interactive systems. 2. Glass Box: All sections of the code are exercised. OOD relevant. Design of code coverage testing plans. Unit testing of each module/object All behaviour must be tested Ever statement executed November 28, 2001 Copyright 2001 by Bill Havens 10 of 15

11 Unit Testing in Java Java Support 1. Printing to System.out 2. main methods in each class 3. Custom error handlers 4. Sophisticated debugging environments Debugging via Printing Traditional FORTRAN style debugging Simply print a trace of important milestones in the execution of your code Example: public void foo (int n) { System.out.println( foo called with n = +n);... } November 28, 2001 Copyright 2001 by Bill Havens 11 of 15

12 Main methods in each class Java VM requires specifying which class contains the main method to run your program. Example: java myprogram Runs this method: public class myprogram { public static void main( String[] args )... } BUT you can define many main methods in your other classes Each used to Unit Test that particular class Example: unit testing the myvector class public class myvector extends Vector { public static void main(string[] args) { Vector me = new Vector(...); System.out.println( my vector contents: + me.tostring()); } November 28, 2001 Copyright 2001 by Bill Havens 12 of 15

13 Custom Error Handlers Create a static error handler class public class myerror { public static void verify( boolean test, String message ) { if (test) return; // test succeeded // otherwise signal an error System.out.print( *** error - ); System.out.println(message); Thread.dumpStack(); } } Usage myerror.verify( n < MaxSize, oops- n is too big! ); which prints on failure *** error - oops- n is too big! java.lang.exception: Stack trace at java.lang.thread.dumpstack(thread.java.xxx) at myerror.verify(xxxxxx) etc... November 28, 2001 Copyright 2001 by Bill Havens 13 of 15

14 Sophisticated Debugging Environments Provided by tools such as JBuilder, CodeWarrior, ProjectBuilder Support for: 1. Tracing method calls and returns 2. Stopping/continuing at preset breakpoints 3. Monitoring values of key variables. 4. More... See tool documentation for details November 28, 2001 Copyright 2001 by Bill Havens 14 of 15

15 Test Plans Three levels of testing 1. Unit Testing (as above) 2. Functional Testing (after system build) 3. Beta Testing (with help of clients) Test Plans Formal document describing procedures for validating software 1. Typical cases: run expected situations first Just get it working! 2. Extreme cases: try limits of intended function What happens when we give it extrema values? 3. Invalid cases: see what happens on nonsense cases (brittleness) Your code should never crash! November 28, 2001 Copyright 2001 by Bill Havens 15 of 15