1. CX002-3-3 Introduction to Web Programming Testing

2. CX002-3-3 Introduction to Web ProgrammingTesting Contents Overview –Rationale and outline Test Plan Static Testing –Program inspection Dynamic Testing –Black Box –White Box Conclusion

3. CX002-3-3 Introduction to Web ProgrammingTesting Introduction Why test? –Functional reasons –Financial reasons –Marketing reasons How to go about testing? What kinds of test? How much testing?

4. CX002-3-3 Introduction to Web ProgrammingTesting Testing in General Verification and validation – fit for purpose Static testing and dynamic testing Testing can reveal presence of errors Testing cannot prove absence of errors! –Need to balance between effort put in and returns for that effort

5. CX002-3-3 Introduction to Web ProgrammingTesting Test Plan Sets out standards to be adhered to Describes tests, items for testing, resources/ constraints Major components of the plan: –Testing process –Requirements traceability –Tested items –Testing schedule –Test recording procedure –Hardware and software requirements –Constraints

6. CX002-3-3 Introduction to Web ProgrammingTesting Testing Process Unit testing – individual components (independent) Module testing – dependent components (independent) Sub-system testing – module collections (interface errors) System testing – integrated sub-systems (validate functional/non-functional requirements) Acceptance testing (beta testing)

7. CX002-3-3 Introduction to Web ProgrammingTesting V-Model Requirements specification System specification System design Detailed design Service Acceptance test System integration test Sub-system integration test Module and unit code and test Sub-system integration test plan System integration test plan Acceptance test plan from: Sommerville, 1995. “Software Engineering”, 5 th edn, Addison-Wesley p. 451

8. CX002-3-3 Introduction to Web ProgrammingTesting Regression Testing Defect testing vs. debugging Regression testing applied having ‘fixed’ some code –Expensive –Unnecessary? Mitigated by reducing/removing dependencies in the code

9. CX002-3-3 Introduction to Web ProgrammingTesting Progam/Document Inspection Review to find defects/issues Team of at least four people carry out roles such as: –Author, reader, inspector, moderator

10. CX002-3-3 Introduction to Web ProgrammingTesting Inspection Process Planning Overview (500 source code statements per hour) Individual preparation (125 per hour) Inspection meeting (90-125 per hour – 2 hours max) Rework Follow-up

11. CX002-3-3 Introduction to Web ProgrammingTesting Requires Precise specification Team familiar with the organisation’s standards Up-to-date version being inspected Checklist Experience

12. CX002-3-3 Introduction to Web ProgrammingTesting Checklist sample Data faults –Initialise variables before use? –Are all variables used? –Upper bound array size Control faults –Conditional statements correct? –Exhaustive case statements?

13. CX002-3-3 Introduction to Web ProgrammingTesting Program Inspections No concern with interactions between errors Possible to inspect partial systems Can include standards compliance, maintainability, etc.

14. CX002-3-3 Introduction to Web ProgrammingTesting Example Type an integer between 1 and 5 (inclusive) to get the string equivalent (1=“One”, 2=“Two”, etc.) if UserNumber is between 1 and 5 NumberArray() of String = “One”, “Two”, “Three”, “Four”, “Five” output NumberArray(UserNumber)

15. CX002-3-3 Introduction to Web ProgrammingTesting Test Cases Set of inputs, execution conditions, expected outputs Defect test cases –Cause the system to perform incorrectly

16. CX002-3-3 Introduction to Web ProgrammingTesting Black Box Testing Also known as ‘Functional Testing’ References the program specification Focus on the ‘behaviour’ of the system –Studies the inputs and outputs that these lead to Looking to break the program –Identify inputs with high probability of causing anomalies –Relies on heuristics to determine these

17. CX002-3-3 Introduction to Web ProgrammingTesting Black Box Testing Equivalence Partitioning –Categorisation of possible test cases into partitions – common characteristics –Identified from program specification and general testing guidelines (common sense) –Each test case belongs to one partition

18. CX002-3-3 Introduction to Web ProgrammingTesting Example Type an integer between 1 and 5 (inclusive) to get the string equivalent (1=“One”, 2=“Two”, etc.) InputConditionOutput Integerbetween 1 and 5 (inclusive) String equivalent Integeroutside 1 and 5Nothing Non-integerbetween 1 and 5 (inclusive) Nothing

19. CX002-3-3 Introduction to Web ProgrammingTesting Black Box Testing Boundary Value Analysis –Values at extremes of input domains cause most problems –Test cases generated from these boundary values

20. CX002-3-3 Introduction to Web ProgrammingTesting White Box Testing Also known as ‘Structural Testing’ Requires knowledge of system structure Can be used to identify further equivalence partitions

21. CX002-3-3 Introduction to Web ProgrammingTesting White Box Testing Path Testing –Test every execution path –Produce flow graph nodes represent decisions arcs/edges represent control flow –An independent path traverses 1 new edge –Design Test Case for each independent path –Complexity quickly leads to uncertain coverage

22. CX002-3-3 Introduction to Web ProgrammingTesting White Box Testing Path Testing –Cyclomatic Complexity (CC) CC (G) = (Number(edges) – Number(nodes)) + 2 If – Then - Else Loop - While Case - Of (diagrams from: Sommerville, 1995. “Software Engineering”, 5 th edn, Addison-Wesley p. 474)

23. CX002-3-3 Introduction to Web ProgrammingTesting Example if UserNumber is between 1 and 5 NumberArray() of String = “One”, “Two”, “Three”, “Four”, “Five” output NumberArray(UserNumber) 1 23 4 UserNumber between 1 and 5 CC = (4 – 4) + 2 = 2 Two Test Cases (one for each path)

24. CX002-3-3 Introduction to Web ProgrammingTesting Dynamic Testing Test emergent properties of integrated systems Test system outputs meet customer requirements

25. CX002-3-3 Introduction to Web ProgrammingTesting Q & A