1. Creator: ACSession No: 13 Slide No: 1Reviewer: SS CSE300Advanced Software EngineeringFebruary 2006 Testing - Techniques CSE300 Advanced Software Engineering University of Sunderland © 2006 Anne Comer anne.comer@sunderland.ac.uk

2. CSE300Advanced Software EngineeringFebruary 2006 Creator/Editor: ACSession No:13 Slide No: 2Reviewer: SS Testing Shows - “ Testing cannot show the absence of defects, it can only show that software errors are present.”

3. CSE300Advanced Software EngineeringFebruary 2006 Creator/Editor: ACSession No:13 Slide No: 3Reviewer: SS Verification & Validation Any engineered product can be tested in one of two ways: test vs. the specified functions - Validation “doing the right thing” test vs. the internal workings - Verification “doing the thing right”

4. CSE300Advanced Software EngineeringFebruary 2006 Creator/Editor: ACSession No:13 Slide No: 4Reviewer: SS The Testing ‘V’ Lifecycle rquirment s Reqrts and Specification System design Detailed design Module code and test Subsystem integration test System integration test Acceptance test Subsystem integration test plan System integration test plan Acceptance test plan

5. CSE300Advanced Software EngineeringFebruary 2006 Creator/Editor: ACSession No:13 Slide No: 5Reviewer: SS Unit Testing individual units are tested separately units or modules may be single functions, procedures or programs done incrementally, usually by the programmer who coded it uses stubs and drivers white box testing most appropriate at this stage tests local data structures, boundary conditions, independent paths, error handling paths a formal test plan should be specified and written

6. CSE300Advanced Software EngineeringFebruary 2006 Creator/Editor: ACSession No:13 Slide No: 6Reviewer: SS Black and White Box Testing FUNCTIONS INTERNAL WORKINGS - testing the working of each function BLACK BOX TEST - testing that ‘all the gears work’ WHITE BOX TEST

7. CSE300Advanced Software EngineeringFebruary 2006 Creator/Editor: ACSession No:13 Slide No: 7Reviewer: SS White Box Testing “to ensure that all statements and conditions have been executed at least once....” - Basis path testing...... flow graphs, cyclomatic complexity, deriving tests -Control structure testing..... condition tests, data flow tests, loop tests

8. CSE300Advanced Software EngineeringFebruary 2006 Creator/Editor: ACSession No:13 Slide No: 8Reviewer: SS Why Cover? Logic errors and incorrect assumptions are inversely proportional to a path’s execution probability. Although we often believe a path is not likely to be executed, reality is counter-intuitive. Typographical errors are random; it’s likely that untested paths will contain some.

9. CSE300Advanced Software EngineeringFebruary 2006 Creator/Editor: ACSession No:13 Slide No: 9Reviewer: SS Basis Path Testing (i) First, compute the cyclomatic complexity: Number of simple decisions (predicate nodes) + 1 or Number of areas or Edges - nodes + 2

10. CSE300Advanced Software EngineeringFebruary 2006 Creator/Editor: ACSession No:13 Slide No: 10Reviewer: SS Basis Path Testing (ii) Next we derive the independent paths. Since cyclomatic complexity = 4 there are four independent paths: path 1: 1,2,3,6,7,8 path 2: 1,2,3,5,7,8 path 3: 1,2,4,7,8 path 4: 1,2,4,7,1,2,4,...7,8 1 2 4 3 56 7 8

11. CSE300Advanced Software EngineeringFebruary 2006 Creator/Editor: ACSession No:13 Slide No: 11Reviewer: SS Basis Path Testing (iii) You don’t need a flow chart, but a picture will help when you trace program paths. Count each simple logical test, compound tests count as two or more. Basis path tests should be applied to critical modules

12. CSE300Advanced Software EngineeringFebruary 2006 Creator/Editor: ACSession No:13 Slide No: 12Reviewer: SS Simple Loop Tests Minimum conditions for simple loops skip the loop entirely only one pass through the loop two passes through the loop m passes through the loop, m<n (n-1), n, (n+1) passes through the loop where n is the maximum number of allowable passes

13. CSE300Advanced Software EngineeringFebruary 2006 Creator/Editor: ACSession No:13 Slide No: 13Reviewer: SS Nested Loops Start at the innermost loop, setting all outer loops to their minimum values. Test the loop, using the steps for Simple Loops (add tests for out-of-range or excluded values). Move to the next loop out, set up and test as in previous step, holding all inner loops at typical values and outer loops at their minimum values. Continue until the outermost loop has been tested.

14. CSE300Advanced Software EngineeringFebruary 2006 Creator/Editor: ACSession No:13 Slide No: 14Reviewer: SS Concatenated Loops If the loops are independent of one another then treat each as a simple loop. If the loops are not independent, loop counter for the first loop is the initial value for the second, treat them as Nested Loops.

15. CSE300Advanced Software EngineeringFebruary 2006 Creator/Editor: ACSession No:13 Slide No: 15Reviewer: SS Testing Stages –Subsystem & System Testing –Acceptance Testing Other Types of Testing –Regression Testing –Debugging