1. 6. Testing and 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
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:
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.

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

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

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 { int value; 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
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.

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