6. Testing and Verification Yan Shi CS/SE 2630 Lecture Notes

Software Life Cycle A typical waterfall model

Test Plan and Test Specification See “Test Document Description (MS Word)” at http://www.uwplatt.edu/~shiy/courses/cs263/ Start planning for testing early! You should start test plan after you have a mature draft of requirement specification. Design your test cases when you design your system! Test specification is usually done during detailed design. In fact, unit test specification should be part of the detailed design document!

Inspection and Walkthrough Inspection: one member of a team reads the code line by line and other members point our errors. Walkthrough: a team performs a manual simulation of the program. Both are static software verification activities. Inspection is more formal than walkthrough. Both can be applied to code design unit test

Code Inspection Team A minimum formal inspection team includes: Designated Moderator: an inspector responsible for organizing and reporting on inspection Author: developer of work product At least one peer inspector: often chosen to represent specific role- designer, tester, technical writer, SQA, etc. Walkthroughs generally do not include designated moderator and are often led by the author of the software.

Steps of inspection Planning: Preparation Meeting Rework Follow-up choose the inspection team schedule the following steps Preparation author collects all artifacts to be inspected inspector get familiar with background knowledge Meeting defects are pointed out and recorded Rework author makes changes to the artifacts in response to defects Follow-up moderator verifies the corrections and finish inspection summary report

Evaluation Assertion An assertion is a logical proposition that can be true or false. void assert ( int expression ); If the expression of this macro compares equal to 0 (i.e., the expression is false), a message is written to the standard error device and terminate the program execution. #include <assert.h> to disable this macro, #define NDEBUG right before #include <assert.h> Examples: assert(length > 0); // abort if length is negative. Important Note: assert is used for debugging! DONOT make your code dependent of the expression evaluated!!!

Try-Throw-Catch We’d like to handle the exceptions by ourselves, instead of ugly system error! try { // Code that may cause an exception if ( condition ) throw exception_name; // usually a string } catch ( Type variable ) // Code that handles the exception

Example try { int value; cin >> value; if ( value < 0 ) throw string("Negative values!"); } catch ( string message) cout << "An exception occurred. “ << “Exception message: " << message << endl;

Exception Handling: C++ vs. Java All types can be thrown as exception Only throwable and exception objects catch (…) // catch all kind of exceptions Catch ( Exception e ) No such block There is a block called finally that is always executed after the try-catch block to do cleanup work.

Common Exceptions C++ provides support to handle exceptions via a hierarchy of classes: The class exception is the base class of the exception classes provided by C++. Multiple handlers (i.e., catch expressions) can be chained; each one with a different parameter type. Only the handler whose argument type matches the type of the exception specified in the throw statement is executed.

Namespace Name clashes occur when different libraries containing same names are used simultaneously. namespace pollution: dumping many names into the namespace. A namespace groups a collection of names that logically belong together. namespace myNames { void GetData( int& ); int a; } namespace yourNames void GetData( int & ); myNames::GetData( int& value ) { … } cout << yourNames::a;