1. Interaction Modeling for Testing We would generate the test cases based on our understanding of the interactions that may happen. The source is, again, mostly from requirements specification The timing and place where interactions may occur is often not well specified and become a source of problem

2. Modeling the Requirements Concerned with entities (or constructs) interacting with each other Every Requirement spec must specify these “basic” concepts: (as described before) –functions (actions to transform data and control) –data –events (triggers) –ports (device or source/destination of ) –threads (thread := a sequence of activities) Again, we would also need the “non-functional” (e.g. performance)

3. A E/R Model of 5 Interacting Entities (may not be the “ideal” model) Data Event Port Thread Action 1..n input 1..n 1..n output 1..n 1..n occur sequenceOf Would knowing these relations help in designing test cases? ----- minimal?

4. Interaction “Taxonomy” Time independent interaction --- static Time dependent interaction – dynamic –These may be either on a single processor –Or span multiple processors Static - Single processor Static - Multi processor Dynamic - Single processor Dynamic - Multi processor Most Difficult ?

5. Modeling Interactions Static : – Decision Tables √ √ (you have seen multiple times) Dynamic Single Processor : – Finite State Machine √ (modeling the ATM system) Dynamic Multiple Processors : –Petri Net (will be introduced in this lesson)

6. Components of a Decision Table C1 C2 C3 a1 a2 a3 a4 a5 T T T T F F F F T T F F T F T F x x x x x x x x x x conditions actions values of conditions actions taken R1 R2 R3 R4 R5 R6 R7 R8 rules R1 says when all conditions are T, then actions a1, a2, and a5 occur ---- Note that this is static; there is NO “time” or “sequence” concept

7. Triangle Problem Example 1.a < b + c 2.b < a + c 3.c < a + b 4.a = b 5.a = c 6.b = c 1.Not triangle 1.Scalene 2.Isosceles 3.Equilateral 4.“impossible” F T T T T T T T T T T - F T T T T T T T T T - - F T T T T T T T T - - - T T T T F F F F - - - T T F F T T F F - - - T F T F T F T F X X X X X X X X X X X Note the Impossible cases Pick input for each of the columns Assume a, b and c are all between 1 and 200

8. Finite State Machine (more formal definition) A Finite State Machine is composed of : –S : a set of states –S i : a special initial state from the set S –S t : a subset of S called “accept” or terminating states –I : a set of input symbols –T : a set of transition rules which maps S x I -> S sisi B A 1 1 0 0 0 1 StSt Terminates with 11 or 00. “Accepts” strings of 1’s and 0’s that terminate with 00 or 11 Incorporates the notion of “time” or “sequence” --- we used this model for ATM system

9. Petri Net Model - Concurrency/Distributed model A Petri Net is a model that is composed of : –P : set of places –T : set of transitions –A: Set of directed arcs which run between places and transitions; (PxT) U (TxP) [ sometimes (PxT) and (TxP) are called Inputs and Outputs] –M :Set of tokens ; initial mapping of P -> Integers P1 P2 P3 P4 There must be a token in each of the place that inputs to the transition for a transition to be “fired.” This is necessary, but may not be sufficient. t1 t2 tokens Note that: P2 and P3 can also occur concurrently

10. An example of “mutually” exclusive threads P5 t1 P4 P2 P1 P3 t2 Note that: t1 or t2 can occur at any time but not simultaneously in this multi-thread system. What happens if we place 2 tokens in P2 ---- ?

11. Event Driven Petri Net An Event driven Petri Net is a Petri Net with and additional set of nodes, called Events: P : set of places T : set of transitions E : set of events A: Set of directed arcs which run between places and transitions; [ (P U E) x T ] U [ T x (P u E) ] M :Set of tokens ; initial mapping of (P U E) -> Integers P1 P3 P4 t1 t2 tokens E1 Token assignment may be key to “firing”

12. Consider the Example of Windshield Wiper Cond 1: Lever Cond 2: dial Action - wiper Off Int Int Int Low High NA 1 2 3 NA NA 0 4 6 12 30 60 A static view (no time/sequence)of the system using Logic/Decision table Int is intermittent

13. Modeling Windshield Wiper with Decision Table We would have conditions of {off, int1,int2,int3, Low and high}, the 6 conditions. So the decision table would have 2 6 = 64 columns for “rules” --- some are not sensible –The dial conditions is embedded in Int1, Int2, and Int3 –Actions will just be wiper speed Lever Off Lever Int1 Int2 Int3 Lever Low Lever High Wiper Speed T _ T F _ T F 0...... F T _.. F T F 4.....  64 columns

14. Modeling Windshield Wiper with Finite State Machine There will be 6 states = { Off, Int1, Int2, Int3, Low, High} “Off” state is both the starting and the terminating state There are 4 alphabet = {shift-D, shift-U, turn-c, turn-cc} The transitions are shown in the Finite State Diagram below Int3 Int2 Int1LowHigh Off Shift-D Shift-U Shift-D Shift-U turn-c turn-cc turn-c turn-cc turn-c; turn-cc turn-c; turn-cc turn-c; turn-cc ** Note: In designing test cases with “time/sequence” consideration, you may ask what happens if you shift-D at Int2 or turn-cc (counter-clock) at Int1.

15. Modeling Windshield Wiper with Event Driven Petri Net There will be 6 Places = {Off, Int1,Int2, Int3, Low, Hi} There will be 4 Events = {S-d, S-u, T-c, T-cc} There will be 10 transitions= {t1,----,t10} The tokens are not be shown here since they may be mapped in too many ways here Off Int1 Low Hi Int3 Int2 S-u S-d S-u S-d T-cc T-c t1 t4 t6 t5 t10 t9 t8 t7 t3 t2 1)Would you generate test cases for shift-up and Int2, which is not shown? 2)Also, how would you populate the tokens? 3)How does “time” come into play for “firing” ?

16. Does Finite State Machine or Petri Net help in modeling threads and interactions? We would generate the test cases based on our understanding of the interactions that may happen. (the expected interaction with shifting and turning of dial shown in Logic/Decision tables) The source is mostly Requirements Specification (which may be incomplete) *** The timing and place where interactions may occur is often not well specified and become a source of problem. (the shift-down or turn of dial that are not specified in the FSM or Petri Net) ***