Theory and Practice of Software Testing

1. Theory and Practice of Software Testing Chapter 14 Presman Software Testing Tactics

2. Testing objectives [MYE79] • Testing is a process of executing a program with the goal of finding an error. • A good test is one that has a high probability of finding an error

3. Good Testing • Has a high probability of finding an error • Is Not redudant • Should be “best f breed” • Should be neither too simple nor too complex

4. Testing Techniques • Test information flow • Test case design • White box testing • Basis path testing • Black box Testing • Equivalence Partitioning • Boundary Value Analysis

5. Test Information flow evaluation Software configuration errors test results Error rate data debug corrections testing Reliability model test configuration Predicted reliability Expected results

6. White-Box testing • Sometime called Glass-box testing • A test case design philosophy that uses the control program structure to derive test case • Knowledge of the program is used to identify additional test cases

7. White-Box testing • Objective is to exercise all program statements (not all path combinations) • Every instruction • Every decision • A set of paths that meets these criteria is said to provide cover or complete cover

8. White-box testing

9. Basis Path Testing • One of white box testing technique • The objective of basis path testing is to derive a logical complexity measure of procedural design and defining a basis set of execution paths • Test case derived to exercise the basis set to execute every statement in the program at least one time during testing

10. Basis Path testing • Uses flow graph or program graph that shows nodes representing program decisions and vertex representing the flow of control • Statements with conditions are therefore nodes in the flow graph • Node is any point in the program where the control either joins, or forks or both • Nodes are joined by edges or links

12. Contoh Program

14. Predicate Node • Node that contain a conditiona • Can be compound with logical operator : “and” / “or”

18. Independent Path (IP) Independent Path is any path through the program that introduces at least one new set processing statement or a new condition

19. A set of independent path • 1-2-10-11-13 • 1-2-10-12-13 • 1-2-3-10-11-13 • 1-2-3-4-5-8-9-2-… • 1-2-3-4-5-6-8-9-2-… • 1-2-3-4-5-6-7-8-9-2…

20. Process to deriving Test Cases • Map the design or code to the corresponding flow graph • Compute the cyclomatic complexity of the resultant flow graph • Identify a basis set of independent paths • Prepare test cases that will force execution of each path in the basis set

21. Cyclomatic Complexity : V(G) • Metric that provides a quantitative measure of logical complexity of a program • Define the number of independent path in the basis set of a program • The number of tests cases used to test all control statements equals the cyclomatic complexity

22. Compute Cyclomatic Complexity • V(G) = R • V(G)= P +1 • V(G) = E –N +2 Where : • R is the number of regions of the flow graph • P is the number of logical expressions (or predicates node) • E is the number of flow graph edges • N is the number of flow graph nodes

23. Path 1 test case • Specification of Inputs • Value (k) = valid input, where k < i • Value (i) = -999 where 2 i 100 • Specification of Output (expected results): • correct average based on k values and correct totals should be computed • Note: • This test case must be test as part of path 4, 5, and 6 tests

24. Path 2 test case • Inputs • Value (1) = -999 • Expected results: • Average = -999; other total at initial values

25. Path 3 test case • Inputs • Attempt to process 101 or more values • The first 100 values should be valid • Expected results: • correct average based on k values and correct totals should be computed

26. Path 4 test case • Inputs • Value (i) = valid input, i < 100 • Value (k) < minimum where k<i • Expected results: • correct average based on k values and correct totals should be computed

27. Path 5 test case • Inputs • Value (i) = valid input where i< 100 • Value (i)> maximum where k i • Expected results: • correct average based on n values and correct totals should be computed

28. Path 6 test case • Inputs • Value (i) = valid input where i< 100 • Expected results: • correct average based on n values and correct totals should be computed

29. Main tactics on path selection • A sufficient number of paths to achieve coverage • Selection of short, functionally sensible paths • Minimizing the number of changes from path to path (one decision changing at a time) • Favor more but simpler paths over fewer but complicated paths

30. Effectiveness path testing • Approximately between 60-70% of all bugs can be caught in unit testing using basis path testing

31. Main Limitations of Basis path testing • Can not be used to show totally wrong or missing functions • Interface errors may not be caught • Database errors may not be caught • Not all initialization errors are caught by path testing

32. Graph Metrices • A tabular representation of flow graph with link weight addition to provide information about control flow • A square matrix whose size ( row & column) is equal to the number of node on flow graph • Existing connection ( 1 & 0)

33. Link Weight • Probability an edge will be executed • Processing time expended, • Memory required, • Resources required, during traversal of a link

34. Control Structure Testing • Condition Testing a test case design method that exercise the logical conditions contained in a program module • Data Flow Testing a method to select a test path of a program according to the location of definitions and uses of variable in the program • Loop Testing a white box testing technique that focuses exclusively on the validity of loop construct

35. Loop Testing 4 different classes of loop : • Simple loop • Nested loop • Concatenated loop • Unstructured loop

37. Simple Loop test criteria The following set of test can be applied to a simple loop of size max • Skip the loop entirely • One pass through the loop • Two passes through the loop before existing • M passes through the loop where M < max • max-1, max, max+1 passes through the loop

38. Nested Loop test criteria • Start at the inner loop. Set all other loop to a minimum value • Conduct simple loop testing for the innermost loop • Work outward, repeat for all loops. Keeping all other outer loops at minimum value & other nested loops to “typical value” • Continue until all loops tested

39. Concatenated Loops • If independent loops, use simple loop testing • If dependent, treat as nested loops

40. Unstructured Loops • Don’t test - redesign