Test conditions (“What”): an item or event to be verified.
Design
How the “what” can be tested: realization Build
Build test cases (imp. scripts, data) Run the system
Execute
Test case outcome with Compare expected outcome
Test result
2
Testing Activities • Test condition – What: Descriptions of circumstances that could be examined (event or item). – Categories: functionality, performance, stress, robustness… – Derive • Using testing techniques (to be discussed) • (Refer to the V-Model) 3
Testing Activities • Design test cases: the details – Input values – Expected outcomes • • • • •
Things created (output) Things changed/updated database? Things deleted Timing …
– Expected outcomes • Known • Unknown (examine the first actual outcome)
– Environment prerequisites: file, net connection … 4
Goodness of test cases • Exec. of a test case against a program P – Covers certain requirements of P; – Covers certain parts of P’s functionality; – Covers certain parts of P’s internal logic.
Partition system inputs and outputs into ‘equivalence sets’ – –
•
If input is a 5-digit integer between 10000 and 99999, equivalence partitions are 99999 If you can predict that certain set of inputs will be treated differently in processing from another one, put them into separate partitions, e.g., Canadian and US addresses (will validate state/province), addresses in other countries (no state validation), etc.
Two test case selection strategies – –
Choose one random test case from each partition Choose test cases at the boundary of the partitions • 09999, 10000, 99999, 100000 8
Search routine specification procedure Search (Key : ELEM ; T: ELEM_ARRAY; Found : in out BOOLEAN; L: in out ELEM_INDEX) ; Pre-condition -- the array has at least one element T’FIRST = i
