Graph Coverage for Source Code. Data Flow Graph Coverage for Source Code

Transcription

1 Graph Coverage for Source Code Data Flow Graph Coverage for Source Code 1

2 Graph Coverage for Design Elements Use of data abstraction and object oriented software has increased importance on modularity and reuse. Therefore testing of software based design (design elements) is more important that past They are usually associated with integration testing. Since modularity, the software components can be tested independently. 2

3 DU Pair Data flow testing criteria use the fact that values are carried from defs to uses. We call these du-pairs They are also known as definition-use, def-use, and du associations in the testing literature The idea of data flow criteria is to exercise du-pairs in various If a def and a use appear on the same node, then it is only a DU-pair if the def occurs after the use and the node is in a loop 3

4 def clear & all uses Definitions A definition d for a variable x reaches a use u if there is a path from d to u that has no other definitions of x (def-clear). The all-uses (AU) criterion requires tests to tour at least one subpath from each definition to each reachable use.

5 // EXAMPLE: return index of the last element in x that equals y. // if y is not in x, return -1. public int findlast (int []x, int y) { for (int i = x.length-1; i>=0; i--) { if (x[i] == y) return i; } return -1; use 3=( def(5) = { i} use (5) = { i} 5

6 Annotated Control Graph Nodes 4 and 6 are final nodes, corresponding to the return statements. Node 2 is introduced to capture the for loop; it has no executable statements. DU (def-use) pairs are shown as a variable name followed by the def node, then the use node. use(3)= def(5) = { i} use (5) = { i} Def -Use Pairs = { (1, 1,x), (1,3,x), (1,3,y), (1, 2,i), (1, 3,i), (1,5,i), (1,6,i), (5, 2,i), (5, 3,i), ( 5, 6,i), (5, 5,i)}

7 Another for Example Control Flow Graph using the function ComputeStats 7

8 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 (inti= 0; i< length; i++) { varsum = varsum + ((numbers [ I ] - mean) * (numbers [ I ] - mean)); } var = varsum / ( length ); sd = Math.sqrt ( var ); i = 0 i = 0 System.out.println ("length: " + length); i < length System.out.println ("mean: " + mean); i >= length System.out.println ("median: " + med); System.out.println ("variance: " + var); 7 8 System.out.println ("standard deviation: " + sd); } i

9 Control Flow Graph for the function ComputeStats 1 ( numbers ) sum = 0 length = numbers.length 2 i = 0 3 i >= length 4 i < length sum += numbers [ i ] i med = numbers [ length / 2 ] mean = sum / (double) length varsum = 0 i = 0 i >= length varsum = i++ 7 i < length 8 var = varsum / ( length ) sd = Math.sqrt ( var ) print (length, mean, med, var, sd) 9

10 Control Flow Graph for the function with Defs & Uses 1 def (1) = { numbers, sum, length } use (1) = { numbers} 2 def (2) = { i } Turn the annotations into defand use sets 3 use (3, 4) = { i, length } use (3, 5) = { i, length } 4 def (4) = { sum, i } use (4) = { sum, numbers, i } def (7) = { varsum, i } use (7) = { varsum, numbers, i, mean } use (6, 7) = { i, length } def (5) = { med, mean, varsum, i } use (5) = { numbers, length, sum } use (6, 8) = { i, length } 8 def (8) = { var, sd } use (8) = { varsum, length, mean, med, var, sd } Ammann & Offutt 10

11 Defs and Uses Tables for the function Node Def Use 1 { numbers, sum, length } 2 { i } 3 { numbers } 4 { sum, i } { numbers, i, sum } 5 { med, mean, varsum, i } 6 { numbers, length, sum } 7 { varsum, i } { varsum, numbers, i, mean } 8 { var, sd } { varsum, length, var, mean, med, var, sd } Edge (1, 2) (2, 3) Use (3, 4) { i, length } (4, 3) (3, 5) { i, length } (5, 6) (6, 7) { i, length } (7, 6) (6, 8) { i, length } 11

12 DU Pairs for the function variable numbers (1, 4) (1, 5) (1, 7) DU Pairs length (1, 5) (1, 8) (1, (3,4)) (1, (3,5)) (1, (6,7)) (1, (6,8)) med (5, 8) var (8, 8) sd (8, 8) mean (5, 7) (5, 8) sum (1, 4) (1, 5) (4, 4) (4, 5) varsum (5, 7) (5, 8) (7, 7) (7, 8) i (2, 4) (2, (3,4)) (2, (3,5)) (2, 7) (2, (6,7)) (2, (6,8)) (4, 4) (4, (3,4)) (4, (3,5)) (4, 7) (4, (6,7)) (4, (6,8)) (5, 7) (5, (6,7)) (5, (6,8)) (7, 7) (7, (6,7)) (7, (6,8)) Defs come before uses, do not count as DU pairs defs after use in loop, these are valid DU pairs No def-clear path different scope for i No path through graph from nodes 5 and 7 to 4 or 3 12

13 DU Paths for the Function variable DU Pairs DU Paths numbers (1, 4) (1, 5) (1, 7) length (1, 5) (1, 8) (1, (3,4)) (1, (3,5)) (1, (6,7)) (1, (6,8)) [ 1, 2, 3, 4 ] [ 1, 2, 3, 5 ] [ 1, 2, 3, 5, 6, 7 ] [ 1, 2, 3, 5 ] [ 1, 2, 3, 5, 6, 8 ] [ 1, 2, 3, 4 ] [ 1, 2, 3, 5 ] [ 1, 2, 3, 5, 6, 7 ] [ 1, 2, 3, 5, 6, 8 ] med (5, 8) [ 5, 6, 8 ] var (8, 8) No path needed sd (8, 8) No path needed sum (1, 4) (1, 5) (4, 4) (4, 5) [ 1, 2, 3, 4 ] [ 1, 2, 3, 5 ] [ 4, 3, 4 ] [ 4, 3, 5 ] variable DU Pairs DU Paths mean (5, 7) (5, 8) varsum (5, 7) (5, 8) (7, 7) (7, 8) i (2, 4) (2, (3,4)) (2, (3,5)) (4, 4) (4, (3,4)) (4, (3,5)) (5, 7) (5, (6,7)) (5, (6,8)) (7, 7) (7, (6,7)) (7, (6,8)) [ 5, 6, 7 ] [ 5, 6, 8 ] [ 5, 6, 7 ] [ 5, 6, 8 ] [ 7, 6, 7 ] [ 7, 6, 8 ] [ 2, 3, 4 ] [ 2, 3, 4 ] [ 2, 3, 5 ] [ 4, 3, 4 ] [ 4, 3, 4 ] [ 4, 3, 5 ] [ 5, 6, 7 ] [ 5, 6, 7 ] [ 5, 6, 8 ] [ 7, 6, 7 ] [ 7, 6, 7 ] [ 7, 6, 8 ] 13

14 DU Paths for the function No Duplicates There are 38 DU paths for the function, but only 12 unique [ 1, 2, 3, 4 ] [ 1, 2, 3, 5 ] [ 1, 2, 3, 5, 6, 7 ] [ 1, 2, 3, 5, 6, 8 ] [ 2, 3, 4 ] [ 2, 3, 5 ] [ 4, 3, 4 ] [ 4, 3, 5 ] [ 5, 6, 7 ] [ 5, 6, 8 ] [ 7, 6, 7 ] [ 7, 6, 8 ] 4 expect a loop not to be entered 6 require at least one iteration of a loop 2 require at least two iterations of a loop 14

15 Graph Coverage for Design Elements Structural Graph Coverage for Design Elements 15

16 Structural Graph Coverage for Design Elements Use of data abstraction and object oriented software has increased importance on modularity and reuse. Therefore testing of software based design (design elements) is more important that past They are usually associated with integration testing. Since modularity, the software components can be tested independently. 16

17 Data Flow Coverage at the Design Level Data flow couplings among units and classes are more complicated than control flow couplings When values are passed, they change names Many different ways to share data Finding defs and uses can be difficult finding which uses a def can reach is very difficult When software gets complicated testers should get interested That s where the faults are! Caller : A unit that invokes another unit Callee : The unit that is called Callsite : Statement or node where the call appears Actual parameter : Variable in the caller Formal parameter : Variable in the callee 17

18 Data Flow Graph Coverage for Design Elements This technique can be limited to the unit interfaces Data flow is concerned only with last-defs before calls and returns and first-uses after calls and returns. The last-defs before a call are locations with defs that reach uses at callsites The last-defs before a return are locations with defs that reach a return statement. 18

19 Data Flow Graph Coverage for Design Finally Elements All-du-Paths coverage requires that we tour every simple path from every last-def to every first-use. As before, the All-du-Paths criterion can be satisfied by tours that include sidetrips. All-du-Paths is also called All-Coupling-du-Paths coverage. 19

20 Example Call Site void Main() M B (x) interface M end Main B (Y) M end B Callee Caller Actual Parameter Formal Parameter Applying data flow criteria to def-use pairs between units is too expensive This technique is limited to the unit interface Too many possibilities But this is integration testing, and we really only care about the interface 20

21 Data-Bound Relationships Between Design Elements Caller: unit that invokes the callee An actual parameter (value passed to the callee by the caller; ) is in the caller Its value is assigned to a formal parameter in the callee. 21

22 Coupling Three different ways that different program parts might interact: Parameter Coupling: relationships between caller and callees; passing data as parameters; Shared Data Coupling: one unit writes to some in-memory data, another unit reads this data; External Data Coupling: one unit writes data e.g. to disk, another read reads the data. 22

23 Parameter Coupling 23

24 def-use pairs as Normal Coupling Data Flow Analysis I def use A () intra-procedural data flow (within the same unit) The method A() contains def and use. Here the variable is omitted It is assumed that all du pairs refer to the same variable. This is classic Data Flow Coverage for design elements 24

25 def-use pairs as Normal Coupling Data Flow Analysis II All du pairs between a caller A() and a callee B() This example is another classic Data Flow Coverage for design elements 25

26 Coupling Data-flow We are only testing variables that have a definition on one side and a use on the otherside we do not impose test requirements in the following case: 26

27 Inter-procedural DU Pairs If we focus on the interface, then we just need to consider the last definitions of variables before calls and returns and first uses inside units and after calls Last-def : The set of nodes that define a variable x and has a def-clear path from the node through a call site to a use in the other unit Can be from caller to callee (parameter or shared variable) or from callee to caller as a return value First-use : The set of nodes that have uses of a variable y and for which there is a def-clear and use-clear path from the call site to the nodes 27

28 du-pairs between Callers and Callees The last-defs are 2, 3 The first-uses are 12, 13 28

29 Inter-procedural DU pairs last-def & first-use The last-def is the definition that goes through the call or return Can be from caller to callee (parameter or shared variable) or from callee to caller as a return value The first-use picks up that definition. 29

30 Coupling DU -Pairs 30

31 Caller Inter-procedural DU Pairs F x = 14 M y = G (x) DU pair M print (y) last-def callsite first-use 1 2 x = 5 x = 4 3 x = Z = y Last Defs 2, 3 First Uses 11, 12 B (int y) 12 T = y Callee G(a) DU pair print (a) M b = 42 M return (b) first-use last-def Coupling du-pairs The callsite has two du-pairs. o x in F() is passed to a in G() o b in G() is returned andassigned to y in F(). 4 B (x) 13 print (y) last-defs and first -uses o The unit on the left, the caller calles the callee B, with one actual parameter x, which is assigned to formal parameter y. o x is defined at nodes 1,2,3, but def at node 1 cannot reach the callsite at node 4, thus last-defs for x is the set {2,3}. o The formal parameter y is used at nodes 11,12,13, but use-clear path goes from the entry point at node 10 to 13, so the first-uses for y is the set {11,12}. 31