ECE 453 – CS 447 – SE 465 Software Testing & Quality Assurance Instructor Kostas Kontogiannis

1. ECE 453 – CS 447 – SE 465 Software Testing & Quality AssuranceInstructorKostas Kontogiannis

2. Overview • Integration Testing • Decomposition Based Integration • Call Graph Based Integration • Path Based Integration • Discussion Ref: “Software Testing A Craftsman's Approach” 2nd edition, Paul C. Jorgensen

3. Path Based Integration Testing • The basic motivation is to combine structural and behavioral type of testing for integration testing as we did for unit testing • The basic idea is to focus on interactions among system units rather than merely to test interfaces among separately developed and tested units • In this respect, interface-based testing is structural while interaction-based is behavioral • Overall we want to express integration testing in terms behavioral threads

4. Extended Concepts (1) • Source node: • a program statement fragment at which program execution begins or resumes. • for example the first “begin” statement in a program. • also, immediately after nodes that transfer control to other units. • Sink node: • a statement fragment at which program execution terminates. • the final “end” in a program as well as statements that transfer control to other units.

5. Extended Concepts (2) • Module execution path: • a sequence of statements that begins with a source node and ends with a sink node with no intervening sink nodes. • Message: • a programming language mechanism by which one unit transfers control to another unit. • can be interpreted as subroutine invocations, procedure calls and function references. • convention: the unit which receives the message always eventually returns control to the message source. • messages can pass data to other units.

6. MM-Paths • MM-Path: • an interleaved sequence of module execution paths and messages. • we can describe sequences of module execution paths that include transfers of control among separate units. • MM-paths always represent feasible execution paths, and these paths cross unit boundaries.

7. MM-Path Example 4 Figure 1 C A 1 B 1 1 2 3 3 2 2 3 4 3 4 5 4 5 6 • The Figure 1 above illustrates an MM-Path (the heavy line) for three modules. • For example, in module A nodes 1 and 5 are source nodes while nodes 4 and 6 are sink nodes. Ref: “Software Testing A Craftsman's Approach” 2nd edition, Paul C. Jorgensen

8. Execution Paths Example • In addition, the following are module execution paths: MEP(A,1) = <1,2,3,6> MEP(B,1) = <1,2> MEP(A,2) = <1,2,4> MEP(B,2) = <3,4> MEP(A,3) = <5,6> MEP(C,1) = <1,2,4,5> MEP(C,2) = <1,3,4,5>

9. MM-Path Graph • Given a set of units, • their MM-Path graph is the directed graph in which nodes are module execution paths and, • edges correspond to messages and returns from one unit to another • The definition is with respect to a set of units. • It directly supports composition of units and composition based integration testing. • It is possible to compose down to level of individual module execution paths • but it would be more detailed than necessary.

10. MM-Path Graph Example MEP(A,2) MEP(B,1) MEP(A,1) MEP(C,1) Figure 2 MEP(B,2) MEP(C,2) MEP(A,3) The Figure 2 above illustrates the MM-Path graph for the example in Figure 1. The solid arrows indicate messages and the corresponding returns are indicated by dotted arrows. Ref: “Software Testing A Craftsman's Approach” 2nd edition, Paul C. Jorgensen

11. MM-Path Analogy • MM-Paths implement a function that transcends unit boundaries, thus we have the following relationship: • Consider the “intersection” of an MM-Path with a unit. • The module execution paths in this intersection are an analog of a slice with respect to the (MM-Path) function. • Hence the module execution paths in such an intersection are the restriction of the function to the unit in which they occur.

12. MM-Path Endpoints • There are three observable behavioral criteria that put endpoints on MM-Paths: • event quiescence: occurs when a system is nearly idle, waiting for a port input event to trigger further processing. • This is a system level property with an analog at the integration level: message quiescence. • message quiescence: occurs when a unit that sends no messages is reached (i.e. module C in Figure 1). • data quiescence: occurs when a sequence of processing culminates in the creation of stored data that is not immediately used.

13. Atomic System Function • Data quiescence occurs when a sequence of processing culminates in the creation of stored data that is not immediately used. • These criteria are “natural” endpoints for MM-Paths. • A second guideline for MM-Paths serves to distinguish integration from system testing: • atomic system function (ASF): is an action that is observable at the system level in terms of port input and output events. • It begins with a port input event, • traverses one or more MM-Paths, • and terminates with a port output event.

14. Atomic System Function • When viewed from the system level, there is no compelling reason to decompose an ASF into lower levels of detail (hence the atomicity). • For example in the ATM case, • an example of an ASF is card entry, cash dispensing, or session closing. • While PIN entry would probably be too big since it might entail a molecular system function

15. Atomic System Function • ASFs are an upper limit for MM-Paths: • MM-Paths should not cross ASF boundaries. • ASFs represent the seam between integration and system testing: • they are the largest item to be tested during integration testing, • and the smallest item for system testing.

16. ASF Example B A C MM-path: Interleaved sequence of module exec path and messages Module exec path: entry-exit path in the same module Atomic System Function: port input, … {MM-paths}, … port output Test cases: exercise ASFs

17. Call Graph as a Model for Module Interaction 11. procedure Acc(x,y) refx, y 12. j:= 1: 13. whilejsy 14. Add(x,j); 15. Inc(j); 16. endwhile 17. return 18. procedure Inc(z) ref z 19. Add(z.1): 20. return 21. procedure Add(a,b) ref a; value b 22. a:=a+b; 23. return 1. programSums 2. read(n); 3. i:= 1; 4. while i <= n 5. sum:=0; 6. Acc(sum,i); 7. write(sum, i); 8. i : = i + l ; 9. endwhile 10. end. Sums sum, i Acc x, j j Add Inc z, 1 Call Graph

18. Program Summary Graph 11. procedure Acc(x,y) refx, y 12. j:= 1: 13. whilejsy 14. Add(x,j); 15. Inc(j); 16. endwhile 17. return 18. procedure Inc(z) ref z 19. Add(z.1): 20. return 21. procedure Add(a,b) ref a; value b 22. a:=a+b; 23. return 1. programSums 2. read(n); 3. i:= 1; 4. while i <= n 5. sum:=0; 6. Acc(sum,i); 7. write(sum, i); 8. i : = i + l ; 9. endwhile 10. end. Sums Acc Inc Add 5 x sum a 13 z 1 7 17 i y z 3 j 15 9 x 11 x 12 j 18 y 16 4 10 1 i z a 14 2 z x sum 1

19. Interprocedural Program Summary Graph 11. procedure Acc(x,y) refx, y 12. j:= 1: 13. whilejsy 14. Add(x,j); 15. Inc(j); 16. endwhile 17. return 18. procedure Inc(z) ref z 19. Add(z.1): 20. return 21. procedure Add(a,b) ref a; value b 22. a:=a+b; 23. return 1. programSums 2. read(n); 3. i:= 1; 4. while i <= n 5. sum:=0; 6. Acc(sum,i); 7. write(sum, i); 8. i : = i + l ; 9. endwhile 10. end. Sums Acc Inc Add {U6} 5 x sum a 13 z 1 7 17 i y 3 {U2, U3, U5}} z {U6} j {U6} 15 9 x {U6} 11 x U1: sum in line 7 U2: i in line 7 U3: i in line 8 U4: j in line 13 U5: y in line 13 U6: a in line 22 12 j {U1, U4, U6} y 16 4 10 1 i z {U2. U3} a 14 2 {U1} z 18 x {U4, U6} sum 1

20. Discussion on Behavioral Integration Testing • MM-Paths and ASFs are a hybrid of functional and structural testing. • They are functional in sense that each represents an action with inputs and outputs, • all functional testing techniques are potentially applicable. • The structural side is how they are identified : • MM-Path graph.

21. Discussion on Behavioral Integration Testing • We avoid the pitfalls of structural testing, • and at same time, integration testing gains a fairly seamless junction with system testing. • Advantages come at a price: • more effort to identify MM-Paths and ASFs. • Effort may be offset by elimination of stub/driver development. • Also may be an overkill for applications which are not event driven.