6. Testing and Verification

1. 6. Testingand Verification Yan Shi CS/SE 2630 Lecture Notes

2. Software Life Cycle A typical waterfall model

3. 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!

4. 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

5. Code Inspection Team • A minimum formal inspection team includes: • DesignatedModerator: 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.

6. Steps of inspection • Planning: • 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

7. 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 isfalse), 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!!!

8. 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 }

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

10. Exception Handling: C++ vs. Java

11. 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.

12. 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 & ); int a; } myNames::GetData( int& value ) { … } cout << yourNames::a;