1. CITS5501 Software Quality and Testing Logic and Path Coverage From Introduction to Software Testing, 2 nd ed, Ammann & Offutt

2. Introduction to Software Testing (Ch 3) © Ammann & Offutt2 Ch. 3 : Logic Coverage Four Structures for Modeling Software Graphs Logic Input Space Syntax Use cases Specs Design Source Applied to DNF Specs FSMs Source Input Models Integ Source

3. Introduction to Software Testing (Ch 3) © Ammann & Offutt3 Covering Logic Expressions (3.1) Logic expressions show up in many situations Covering logic expressions is required by the US Federal Aviation Administration for safety critical software Logical expressions can come from many sources – Decisions in programs – FSMs and statecharts – Requirements Tests are intended to choose some subset of the total number of truth assignments to the expressions

4. Introduction to Software Testing (Ch 3) © Ammann & Offutt4 Logic Predicates and Clauses A predicate is an expression that evaluates to a boolean value Predicates can contain – boolean variables – non-boolean variables that contain >, =, <=, != – boolean function calls Internal structure is created by logical operators – ¬ – the negation operator –  – the and operator –  – the or operator –  – the implication operator –  – the exclusive or operator –  – the equivalence operator A clause is a predicate with no logical operators

5. Introduction to Software Testing (Ch 3) © Ammann & Offutt5 Examples (a = n*o) Four clauses: – (a < b) – relational expression – f (z) – boolean-valued function – D – boolean variable – (m >= n*o) – relational expression Most predicates have few clauses – It would be nice to quantify that claim! Sources of predicates – Decisions in programs – Guards in finite state machines – Decisions in UML activity graphs – Requirements, both formal and informal – SQL queries

6. Introduction to Software Testing (Ch 3) © Ammann & Offutt6 Testing and Covering Predicates (3.2) We use predicates in testing as follows : – Developing a model of the software as one or more predicates – Requiring tests to satisfy some combination of clauses Abbreviations: – P is the set of predicates – p is a single predicate in P – C is the set of clauses in P – C p is the set of clauses in predicate p – c is a single clause in C

7. Introduction to Software Testing (Ch 3) © Ammann & Offutt7 Predicate and Clause Coverage The first (and simplest) two criteria require that each predicate and each clause be evaluated to both true and false Predicate Coverage (PC) : For each p in P, TR contains two requirements: p evaluates to true, and p evaluates to false. Clause Coverage (CC) : For each c in C, TR contains two requirements: c evaluates to true, and c evaluates to false. When predicates come from conditions on edges, this is equivalent to edge coverage PC does not evaluate all the clauses, so …

8. Introduction to Software Testing (Ch 3) © Ammann & Offutt8 Predicate Coverage Example ((a = n*o) predicate coverage Predicate = true a = 5, b = 10, D = true, m = 1, n = 1, o = 1 = (5 = 1*1) = true  true  TRUE = true Predicate = false a = 10, b = 5, D = false, m = 1, n = 1, o = 1 = (10 = 1*1) = false  false  TRUE = false

9. Introduction to Software Testing (Ch 3) © Ammann & Offutt9 Clause Coverage Example ((a = n*o) Clause coverage Two tests (a < b) = true a = 5, b = 10 (a < b) = false a = 10, b = 5 D = true D = false m >= n*o = true m = 1, n = 1, o = 1 m >= n*o = false m = 1, n = 2, o = 2 true cases 1) a = 5, b = 10, D = true, m = 1, n = 1, o = 1 false cases 2) a = 10, b = 5, D = false, m = 1, n = 2, o = 2

10. Introduction to Software Testing (Ch 3) © Ammann & Offutt10 Problems with PC and CC PC does not fully exercise all the clauses, especially in the presence of short circuit evaluation CC does not always ensure PC – That is, we can satisfy CC without causing the predicate to be both true and false – This is definitely not what we want ! The simplest solution is to test all combinations …

11. Introduction to Software Testing (Ch 3) © Ammann & Offutt 11 Combinatorial Coverage CoC requires every possible combination Sometimes called Multiple Condition Coverage Combinatorial Coverage (CoC) : For each p in P, TR has test requirements for the clauses in Cp to evaluate to each possible combination of truth values. a < bDm >= n*o ((a = n*o) 1TTTT 2TTFF 3TFTT 4TFFF 5FTTT 6FTFF 7FFTF 8FFFF

12. Introduction to Software Testing (Ch 3) © Ammann & Offutt12 Combinatorial Coverage This is simple, neat, clean, and comprehensive … But quite expensive! 2 N tests, where N is the number of clauses –Impractical for predicates with more than 3 or 4 clauses The literature has lots of suggestions – some confusing The general idea is simple: Test each clause independently from the other clauses Getting the details right is hard What exactly does “independently” mean ? The book presents this idea as “making clauses active” …

13. Introduction to Software Testing (Ch 3) © Ammann & Offutt13 Active Clauses Clause coverage has a weakness : The values do not always make a difference Consider the first test for clause coverage, which caused each clause to be true: – (5 = 1*1) Only the first clause counts ! To really test the results of a clause, the clause should be the determining factor in the value of the predicate Determination : A clause c i in predicate p, called the major clause, determines p if and only if the values of the remaining minor clauses c j are such that changing c i changes the value of p This is considered to make the clause active

14. Introduction to Software Testing (Ch 3) © Ammann & Offutt14 Determining Predicates Goal : Find tests for each clause when the clause determines the value of the predicate This is formalized in several criteria that have subtle, but very important, differences P = A  B if B = true, p is always true. so if B = false, A determines p. if A = false, B determines p. P = A  B if B = false, p is always false. so if B = true, A determines p. if A = true, B determines p.

15. Introduction to Software Testing (Ch 3) © Ammann & Offutt15 General and Restricted ICC Unlike ACC, the notion of correlation is not relevant – ci does not determine p, so cannot correlate with p Predicate coverage is always guaranteed General Inactive Clause Coverage (GICC) : For each p in P and each major clause c i in Cp, choose minor clauses c j, j != i, so that c i does not determine p. The values chosen for the minor clauses c j do not need to be the same when c i is true as when c i is false, that is, c j (c i = true) = c j (c i = false) for all c j OR c j (c i = true) != c j (c i = false) for all c j. Restricted Inactive Clause Coverage (RICC) : For each p in P and each major clause c i in Cp, choose minor clauses c j, j != i, so that c i does not determine p. The values chosen for the minor clauses cj must be the same when c i is true as when c i is false, that is, it is required that c j (c i = true) = c j (c i = false) for all c j.

16. Introduction to Software Testing (Ch 3) © Ammann & Offutt16 Logic Coverage Criteria Subsumption Clause Coverage CC Predicate Coverage PC Combinatorial Clause Coverage COC Restricted Active Clause Coverage RACC Restricted Inactive Clause Coverage RICC General Active Clause Coverage GACC Correlated Active Clause Coverage CACC General Inactive Clause Coverage GICC

17. Introduction to Software Testing (Ch 3) © Ammann & Offutt17 Making Clauses Determine a Predicate Finding values for minor clauses c j is easy for simple predicates But how to find values for more complicated predicates ? Definitional approach: – p c=true is predicate p with every occurrence of c replaced by true – p c=false is predicate p with every occurrence of c replaced by false To find values for the minor clauses, connect p c=true and p c=false with exclusive OR p c = p c=true  p c=false After solving, p c describes exactly the values needed for c to determine p

18. Introduction to Software Testing (Ch 3) © Ammann & Offutt18 Examples p = a  b p a = p a=true  p a=false = (true  b) XOR (false  b) = true XOR b = ¬ b p = a  b p a = p a=true  p a=false = (true  b)  (false  b) = b  false = b p = a  (b  c) p a = p a=true  p a=false = (true  (b  c))  (false  (b  c)) = true  (b  c) = ¬ (b  c) = ¬ b  ¬ c “NOT b  NOT c” means either b or c can be false RACC requires the same choice for both values of a, CACC does not

19. Introduction to Software Testing (Ch 3) © Ammann & Offutt19 Repeated Variables The definitions in this chapter yield the same tests no matter how the predicate is expressed (a  b)  (c  b) == (a  c)  b (a  b)  (b  c)  (a  c) – Only has 8 possible tests, not 64 Use the simplest form of the predicate, and ignore contradictory truth table assignments

20. Introduction to Software Testing (Ch 3) © Ammann & Offutt20 A More Subtle Example p = ( a  b )  ( a  ¬ b) p a = p a=true  p a=false = ((true  b)  (true  ¬ b))  ((false  b)  (false  ¬ b)) = (b  ¬ b)  false = true  false = true a always determines the value of this predicate b never determines the value – b is irrelevant ! p = ( a  b )  ( a  ¬ b) p b = p b=true  p b=false = ((a  true)  (a  ¬ true))  ((a  false)  (a  ¬ false)) = (a  false)  (false  a) = a  a = false

21. Introduction to Software Testing (Ch 3) © Ammann & Offutt21 Infeasible Test Requirements Consider the predicate: (a > b  b > c)  c > a (a > b) = true, (b > c) = true, (c > a) = true is infeasible As with graph-based criteria, infeasible test requirements have to be recognized and ignored Recognizing infeasible test requirements is hard, and in general, undecidable Software testing is inexact – engineering, not science

22. © Ammann & Offutt22 Logic Expressions from Source Predicates are derived from decision statements in programs In programs, most predicates have less than four clauses – Wise programmers actively strive to keep predicates simple When a predicate only has one clause, COC, ACC, ICC, and CC all collapse to predicate coverage (PC) Applying logic criteria to program source is hard because of reachability and controllability: – Reachability : Before applying the criteria on a predicate at a particular statement, we have to get to that statement – Controllability : We have to find input values that indirectly assign values to the variables in the predicates – Variables in the predicates that are not inputs to the program are called internal variables Introduction to Software Testing (Ch 3)

23. © Ammann & Offutt23 Specifications in Software Specifications can be formal or informal – Formal specs are usually expressed mathematically – Informal specs are usually expressed in natural language Lots of formal languages and informal styles are available Most specification languages include explicit logical expressions, so it is very easy to apply logic coverage criteria Implicit logical expressions in natural-language specifications should be re-written as explicit logical expressions as part of test design – You will often find mistakes One of the most common is preconditions …

24. Introduction to Software Testing (Ch 3) © Ammann & Offutt24 Preconditions Programmers often include preconditions for their methods The preconditions are often expressed in comments in method headers Preconditions can be in javadoc, “requires”, “pre”, … Example – Saving addresses // name must not be empty // state must be valid // zip must be 5 numeric digits // street must not be empty // city must not be empty Rewriting to logical expression name != “”  state in stateList  zip >= 00000  zip <= 99999  street != “”  city != “” Conjunctive Normal Form

25. © Ammann & Offutt25 Covering Finite State Machines FSMs are graphs – nodes represent state – edges represent transitions among states Transitions often have logical expressions as guards or triggers As we said: Find a logical expression and cover it Introduction to Software Testing (Ch 3)

26. © Ammann & Offutt26 Example—Subway Train All Doors Open Left Doors Open Right Doors Open All Doors Closed trainSpeed = 0  platform=right  (inStation  (emergencyStop  overrideOpen)) trainSpeed = 0  platform=left  (inStation  (emergencyStop  overrideOpen)) secondPlatform = right secondPlatform= left ¬ emergencyStop  ¬ overrideOpen  doorsClear (all three transitions) Introduction to Software Testing (Ch 3)

27. © Ammann & Offutt27 Determination of the Predicate trainSpeed = 0  platform=left  (inStation  (emergencyStop  overrideOpen)) trainSpeed = 0 : platform = left  (inStation  (emergencyStop  overrideOpen)) platform = left : trainSpeed = 0  (inStation  (emergencyStop  overrideOpen)) inStation : trainSpeed = 0  platform = left  (¬ emergencyStop  ¬ overrideOpen) emergencyStop : trainSpeed = 0  platform = left  (¬ inStation  overrideOpen) overrideOpen : trainSpeed = 0  platform = left  (¬ inStation  emergencyStop) Introduction to Software Testing (Ch 3)

28. Introduction to Software Testing (2nd edition) Chapter 6.1, 6.2 Overview Graph Coverage Criteria Paul Ammann & Jeff Offutt http://www.cs.gmu.edu/~offutt/softwar etest/ First version, 23 September 2013

29. Introduction to Software Testing, Edition 2 (Ch 06) © Ammann & Offutt29 Ch. 06 : Graph Coverage Four Structures for Modeling Software Graphs Logic Input Space Syntax Use cases Specs Design Source Applied to DNF Specs FSMs Source Input Models Integ Source

30. Covering Graphs (6.1) Graphs are the most commonly used structure for testing Graphs can come from many sources – Control flow graphs – Design structure – FSMs and statecharts – Use cases Tests usually are intended to “cover” the graph in some way Introduction to Software Testing, Edition 2 (Ch 06) © Ammann & Offutt30

31. Introduction to Software Testing, Edition 2 (Ch 06) © Ammann & Offutt31 Definition of a Graph A set N of nodes, N is not empty A set N 0 of initial nodes, N 0 is not empty A set N f of final nodes, N f is not empty A set E of edges, each edge from one node to another – ( n i, n j ), i is predecessor, j is successor

32. Introduction to Software Testing, Edition 2 (Ch 06) © Ammann & Offutt32 Three Example Graphs 1 32 4 N 0 = { 1} N f = { 4 } 1 3 2 4 N 0 = { } N f = { 4 } 10 1 54 8 2 6 9 3 7 N 0 = { 1, 2, 3 } N f = { 8, 9, 10 } Not a validgraph

33. Introduction to Software Testing, Edition 2 (Ch 06) © Ammann & Offutt33 Paths in Graphs Path : A sequence of nodes – [n 1, n 2, …, n M ] – Each pair of nodes is an edge Length : The number of edges – A single node is a path of length 0 Subpath : A subsequence of nodes in p is a subpath of p Reach (n) : Subgraph that can be reached from n 10 8 9 1 2 3 54 6 7 A Few Paths [ 1, 4, 8 ] [ 2, 5, 9, 6, 2 ] [ 3, 7, 10 ] Reach (1) = { 1, 4, 5, 8, 9, 6, 2, 10 } Reach ({1, 3}) = G Reach([3,7]) = {3, 7, 10}

34. Introduction to Software Testing, Edition 2 (Ch 06) © Ammann & Offutt34 Test Paths and SESEs Test Path : A path that starts at an initial node and ends at a final node Test paths represent execution of test cases – Some test paths can be executed by many tests – Some test paths cannot be executed by any tests SESE graphs : All test paths start at a single node and end at another node – Single-entry, single-exit – N0 and Nf have exactly one node 1 3 2 74 6 5 Double-diamond graph Four test paths [1, 2, 4, 5, 7] [1, 2, 4, 6, 7] [1, 3, 4, 5, 7] [1, 3, 4, 6, 7]

35. Introduction to Software Testing, Edition 2 (Ch 06) © Ammann & Offutt35 Visiting and Touring Visit : A test path p visits node n if n is in p A test path p visits edge e if e is in p Tour : A test path p tours subpath q if q is a subpath of p Path [ 1, 2, 4, 5, 7 ] Visits nodes 1, 2, 4, 5, 7 Visits edges (1, 2), (2, 4), (4, 5), (5, 7) Tours subpaths [1, 2, 4], [2, 4, 5], [4, 5, 7], [1, 2, 4, 5], [2, 4, 5, 7]

36. Introduction to Software Testing, Edition 2 (Ch 06) © Ammann & Offutt36 Tests and Test Paths path (t) : The test path executed by test t path (T) : The set of test paths executed by the set of tests T Each test executes one and only one test path A location in a graph (node or edge) can be reached from another location if there is a sequence of edges from the first location to the second – Syntactic reach : A subpath exists in the graph – Semantic reach : A test exists that can execute that subpath

37. Introduction to Software Testing, Edition 2 (Ch 06) © Ammann & Offutt37 Tests and Test Paths test 1 test 2 test 3 many-to-one test 1 test 2 test 3 many-to-many Test Path 1 Test Path 2 Test Path 3 Non-deterministic software–a test can execute different test paths Test Path Deterministic software–a test always executes the same test path

38. Introduction to Software Testing, Edition 2 (Ch 06) © Ammann & Offutt38 Testing and Covering Graphs (6.2) We use graphs in testing as follows : – Developing a model of the software as a graph – Requiring tests to visit or tour specific sets of nodes, edges or subpaths Test Requirements (TR) : Describe properties of test paths Test Criterion : Rules that define test requirements Satisfaction : Given a set TR of test requirements for a criterion C, a set of tests T satisfies C on a graph if and only if for every test requirement in TR, there is a test path in path(T) that meets the test requirement tr Structural Coverage Criteria : Defined on a graph just in terms of nodes and edges Data Flow Coverage Criteria : Requires a graph to be annotated with references to variables

39. Introduction to Software Testing, Edition 2 (Ch 06) © Ammann & Offutt39 Node and Edge Coverage The first (and simplest) two criteria require that each node and edge in a graph be executed Node Coverage (NC) : Test set T satisfies node coverage on graph G iff for every syntactically reachable node n in N, there is some path p in path(T) such that p visits n. Node Coverage (NC) : TR contains each reachable node in G. This statement is a bit cumbersome, so we abbreviate it in terms of the set of test requirements

40. Introduction to Software Testing, Edition 2 (Ch 06) © Ammann & Offutt40 Structural Coverage Example Node Coverage TR = { 1, 2, 3, 4, 5, 6, 7 } Test Paths: [ 1, 2, 3, 4, 7 ] [ 1, 2, 3, 5, 6, 5, 7 ] 713245 Edge Coverage TR = { (1,2), (1, 3), (2, 3), (3, 4), (3, 5), (4, 7), (5, 6), (5, 7), (6, 5) } Test Paths: [ 1, 2, 3, 4, 7 ] [1, 3, 5, 6, 5, 7 ] Edge-Pair Coverage TR = {[1,2,3], [1,3,4], [1,3,5], [2,3,4], [2,3,5], [3,4,7], [3,5,6], [3,5,7], [5,6,5], [6,5,6], [6,5,7] } Test Paths: [ 1, 2, 3, 4, 7 ] [ 1, 2, 3, 5, 7 ] [ 1, 3, 4, 7 ] [ 1, 3, 5, 6, 5, 6, 5, 7 ] Complete Path Coverage Test Paths: [ 1, 2, 3, 4, 7 ] [ 1, 2, 3, 5, 7 ] [ 1, 2, 3, 5, 6, 5, 6 ] [ 1, 2, 3, 5, 6, 5, 6, 5, 7 ] [ 1, 2, 3, 5, 6, 5, 6, 5, 6, 5, 7 ] … 6

41. Introduction to Software Testing, Edition 2 (Ch 06) © Ammann & Offutt41 Loops in Graphs If a graph contains a loop, it has an infinite number of paths Thus, CPC is not feasible SPC is not satisfactory because the results are subjective and vary with the tester Attempts to “deal with” loops: – 1970s : Execute cycles once ([4, 5, 4] in previous example, informal) – 1980s : Execute each loop, exactly once (formalized) – 1990s : Execute loops 0 times, once, more than once (informal description) – 2000s : Prime paths

42. Introduction to Software Testing, Edition 2 (Ch 06) © Ammann & Offutt42 Simple Paths and Prime Paths Simple Path : A path from node ni to nj is simple if no node appears more than once, except possibly the first and last nodes are the same – No internal loops – A loop is a simple path Prime Path : A simple path that does not appear as a proper subpath of any other simple path Simple Paths : [1,2,4,1], [1,3,4,1], [2,4,1,2], [2,4,1,3], [3,4,1,2], [3,4,1,3], [4,1,2,4], [4,1,3,4], [1,2,4], [1,3,4], [2,4,1], [3,4,1], [4,1,2], [4,1,3], [1,2], [1,3], [2,4], [3,4], [4,1], [1], [2], [3], [4] Prime Paths : [2,4,1,2], [2,4,1,3], [1,3,4,1], [1,2,4,1], [3,4,1,2], [4,1,3,4], [4,1,2,4], [3,4,1,3] 23 1 4

43. Introduction to Software Testing, Edition 2 (Ch 06) © Ammann & Offutt43 Prime Path Coverage A simple, elegant and finite criterion that requires loops to be executed as well as skipped Prime Path Coverage (PPC) : TR contains each prime path in G. Will tour all paths of length 0, 1, … That is, it subsumes node and edge coverage PPC does NOT subsume EPC If a node n has an edge to itself, EPC will require [n, n, m] [n, n, m] is not prime

44. Introduction to Software Testing, Edition 2 (Ch 06) © Ammann & Offutt44 Round Trips Round-Trip Path : A prime path that starts and ends at the same node Simple Round Trip Coverage (SRTC) : TR contains at least one round-trip path for each reachable node in G that begins and ends a round-trip path. Complete Round Trip Coverage (CRTC) : TR contains all round- trip paths for each reachable node in G. These criteria omit nodes and edges that are not in round trips That is, they do not subsume edge-pair, edge, or node coverage

45. Introduction to Software Testing, Edition 2 (Ch 06) © Ammann & Offutt45 Prime Path Example The previous example has 38 simple paths Only nine prime paths Prime Paths [1, 2, 3, 4, 7] [1, 2, 3, 5, 7] [1, 2, 3, 5, 6] [1, 3, 4, 7] [1, 3, 5, 7] [1, 3, 5, 6] [6, 5, 7] [6, 5, 6] [5, 6, 5] Execute loop once Execute loop more than once 6 1 3 2 45 7 Execute loop 0 times

46. Introduction to Software Testing, Edition 2 (Ch 06) © Ammann & Offutt46 Touring, Sidetrips and Detours Prime paths do not have internal loops … test paths might Tour : A test path p tours subpath q if q is a subpath of p Tour With Sidetrips : A test path p tours subpath q with sidetrips iff every edge in q is also in p in the same order The tour can include a sidetrip, as long as it comes back to the same node Tour With Detours : A test path p tours subpath q with detours iff every node in q is also in p in the same order The tour can include a detour from node ni, as long as it comes back to the prime path at a successor of ni

47. Introduction to Software Testing, Edition 2 (Ch 6) © Ammann & Offutt47 Overview A common application of graph criteria is to program source Graph : Usually the control flow graph (CFG) Node coverage : Execute every statement Edge coverage : Execute every branch Loops : Looping structures such as for loops, while loops, etc. Data flow coverage : Augment the CFG – defs are statements that assign values to variables – uses are statements that use variables

48. Introduction to Software Testing, Edition 2 (Ch 6) © Ammann & Offutt48 Control Flow Graphs A CFG models all executions of a method by describing control structures Nodes : Statements or sequences of statements (basic blocks) Edges : Transfers of control Basic Block : A sequence of statements such that if the first statement is executed, all statements will be (no branches) CFGs are sometimes annotated with extra information – branch predicates – defs – uses Rules for translating statements into graphs …

49. Introduction to Software Testing, Edition 2 (Ch 6) © Ammann & Offutt49 CFG : The if Statement if (x < y) { y = 0; x = x + 1; } else { x = y; } 4 1 23 x >= yx < y x = y y = 0 x = x + 1 if (x < y) { y = 0; x = x + 1; } 3 1 2 x >= y x < y y = 0 x = x + 1

50. Introduction to Software Testing, Edition 2 (Ch 6) © Ammann & Offutt50 CFG : The if-Return Statement if (x < y) { return; } print (x); return; 3 1 2 x >= y x < y return print (x) return No edge from node 2 to 3. The return nodes must be distinct.

51. Introduction to Software Testing, Edition 2 (Ch 6) © Ammann & Offutt51 Loops Loops require “extra” nodes to be added Nodes that do not represent statements or basic blocks

52. Introduction to Software Testing, Edition 2 (Ch 6) © Ammann & Offutt52 CFG : while and for Loops x = 0; while (x < y) { y = f (x, y); x = x + 1; } 1 x = 0 43 y =f(x,y) x = x + 1 x >= yx < y for (x = 0; x < y; x++) { y = f (x, y); } 1 x = x + 1 2 35 x >= yx < y y = f (x, y) 4 2 dummy node x = 0 implicitly initializes loop implicitly increments loop

53. Introduction to Software Testing, Edition 2 (Ch 6) © Ammann & Offutt53 CFG : do Loop, break and continue x = 0; do { y = f (x, y); x = x + 1; } while (x < y); println (y) 1 x = 0 3 2 x >= y x < y y = f (x, y) x = x+1 1 x = 0 83 x = x + 1 break y < 0 24567 y =f(x,y) y == 0 y = y*2 continue x = 0; while (x < y) { y = f (x, y); if (y == 0) { break; } else if y < 0) { y = y*2; continue; } x = x + 1; } print (y);

54. Introduction to Software Testing, Edition 2 (Ch 6) © Ammann & Offutt54 CFG : The case (switch) Structure read ( c) ; switch ( c ) { case ‘N’: y = 25; break; case ‘Y’: y = 50; break; default: y = 0; break; } print (y); 5 1 read ( c ); c == ‘N’ y = 0; break; 243 c == ‘Y’ default y = 50; break; y = 25; break; print (y);

55. © Ammann & Offutt Example Control Flow – Stats public static void computeStats (int [ ] numbers) { int length = numbers.length; double med, var, sd, mean, sum, varsum; sum = 0; for (int i = 0; i < length; i++) { sum += numbers [ i ]; } med = numbers [ length / 2]; mean = sum / (double) length; varsum = 0; for (int i = 0; i < length; i++) { varsum = varsum + ((numbers [ I ] - mean) * (numbers [ I ] - mean)); } var = varsum / ( length - 1.0 ); sd = Math.sqrt ( var ); System.out.println ("length: " + length); System.out.println ("mean: " + mean); System.out.println ("median: " + med); System.out.println ("variance: " + var); System.out.println ("standard deviation: " + sd); } Introduction to Software Testing, Edition 2 (Ch 6) 55© Ammann & Offutt

56. Control Flow Graph for Stats public static void computeStats (int [ ] numbers) { int length = numbers.length; double med, var, sd, mean, sum, varsum; sum = 0; for (int i = 0; i < length; i++) { sum += numbers [ i ]; } med = numbers [ length / 2]; mean = sum / (double) length; varsum = 0; for (int i = 0; i < length; i++) { varsum = varsum + ((numbers [ I ] - mean) * (numbers [ I ] - mean)); } var = varsum / ( length - 1.0 ); sd = Math.sqrt ( var ); System.out.println ("length: " + length); System.out.println ("mean: " + mean); System.out.println ("median: " + med); System.out.println ("variance: " + var); System.out.println ("standard deviation: " + sd); } i = 0 i >= length i < length i++ i >= length i < length i = 0 i++ 1 2 3 5 4 6 8 7 Introduction to Software Testing, Edition 2 (Ch 6) 56© Ammann & Offutt

57. Control Flow TRs and Test Paths—EC 1 2 3 5 4 6 8 7 TR A. [ 1, 2 ] B. [ 2, 3 ] C. [ 3, 4 ] D. [ 3, 5 ] E. [ 4, 3 ] F. [ 5, 6 ] G. [ 6, 7 ] H. [ 6, 8 ] I. [ 7, 6 ] Test Path [ 1, 2, 3, 4, 3, 5, 6, 7, 6, 8 ] Edge Coverage Introduction to Software Testing, Edition 2 (Ch 6) 57© Ammann & Offutt

58. iA, B, D, E, F, G, I, JC, H 58 Control Flow TRs and Test Paths—EPC 1 2 3 5 4 6 8 7 TR A. [ 1, 2, 3 ] B. [ 2, 3, 4 ] C. [ 2, 3, 5 ] D. [ 3, 4, 3 ] E. [ 3, 5, 6 ] F. [ 4, 3, 5 ] G. [ 5, 6, 7 ] H. [ 5, 6, 8 ] I. [ 6, 7, 6 ] J. [ 7, 6, 8 ] K. [ 4, 3, 4 ] L. [ 7, 6, 7 ] Test Paths i. [ 1, 2, 3, 4, 3, 5, 6, 7, 6, 8 ] ii. [ 1, 2, 3, 5, 6, 8 ] iii. [ 1, 2, 3, 4, 3, 4, 3, 5, 6, 7, 6, 7, 6, 8 ] Edge-Pair Coverage TPTRs touredsidetripsii A, C, E, H iii A, B, D, E, F, G, I, J, K, L C, H Introduction to Software Testing, Edition 2 (Ch 6) © Ammann & Offutt

59. 59 Control Flow TRs and Test Paths—PPC 1 2 3 5 4 6 8 7 TR A. [ 3, 4, 3 ] B. [ 4, 3, 4 ] C. [ 7, 6, 7 ] D. [ 7, 6, 8 ] E. [ 6, 7, 6 ] F. [ 1, 2, 3, 4 ] G. [ 4, 3, 5, 6, 7 ] H. [ 4, 3, 5, 6, 8 ] I. [ 1, 2, 3, 5, 6, 7 ] J. [ 1, 2, 3, 5, 6, 8 ] Test Paths i. [ 1, 2, 3, 4, 3, 5, 6, 7, 6, 8 ] ii. [ 1, 2, 3, 4, 3, 4, 3, 5, 6, 7, 6, 7, 6, 8 ] iii. [ 1, 2, 3, 4, 3, 5, 6, 8 ] iv. [ 1, 2, 3, 5, 6, 7, 6, 8 ] v. [ 1, 2, 3, 5, 6, 8 ] Prime Path Coverage iA, D, E, F, GH, I, JTPTRs touredsidetripsii A, B, C, D, E, F, G,H, I, J iii A, F, H J iv D, E, F, I J v J Introduction to Software Testing, Edition 2 (Ch 6) © Ammann & Offutt