Model Based Testing Course Software Testing & Verification 2013/14 Wishnu Prasetya

Finite State Machine/Automaton Many variants, depending on the purpose. Let’s take this one: a structure M = (S, s 0, F, E,I,R,P) – S is the set of states of the automaton – s 0  S is its initial state, assuming we only have one. – F  S is the set of its final states, if any. – E is a set of labels on the transitions, representing events/actions. – R is a subset of S  E  S, describing the transitions – I is a set of labels on the states, representing predicates that should hold there – P is a mapping S  Set I, describing which predicates label which states (thus hold on the state). Deterministic; non-deterministic if from some state s, there is an event a that can take M to multiple states. 2

FSA, Modelling a Simple Web Shop 3 selection view +cart selection view item view item view + cart slider(low,hi),... phone(k) selectBtn buy(k) remove(k) buy(k) phone(k) selectBtn slider(low,hi), buy(k), remove slider(low,hi),..., buy(k), remove(k) representing a set of transitions

Advantage & infrastructure A test case is a path through the automaton, e.g. of the form:  1 ;  2 ; assert(q),  1 is a prefix to set-up the state;  2 is the tested sequence; q is an oracle. Automated generation of test sequences  beyond our scope Manual: – guided by use cases (the list of functionalities you have to test) You can make the testing more systematic, by aiming for some concept of model coverage, such as: – edge-pair coverage (note that this is not the same as event-pair coverage) Require logging to infer the state and invoked events 4

Model transformation Making a model more abstract reduces the number of test cases; but of course at the cost of decreased precision. Conversely, making a model more concrete can strengthen your test. Some typical transformation: – Transitions/edges merging – States merging – State splitting 5

Transitions merging Let A be the set of transitions with the same source and destinations. Suppose A’  A actually triggers equivalent behavior; we can merge all transitions in A’ into a new single transition representing the entire A’. 6 S1S2 a,b,c, x,y,z S1S2 , 

State Merging If  is a path through an FSA, its sentence is the sequence of events that label the transitions in the path. Two states s 1 and s 2 are path-equivalent if it possible to merge them into a new state , such that for any path  in the FSA,  [  /s1,  /s2] is a path in the new automaton; and “in a way” also vice versa. Such pair of states can be merged into new state . The predicate that holds in  is /\ P(s 1 ) \/ /\ P(s 2 ) 7 S1 S2  a b c a r t a b rt c cb

State Splitting A state s can be split into multiple states, e.g. s 1 and s 2. Transitions that go to or from s, have to be re-routed to-go- to/to-go-from either s 1 or s 2 ; you have to think which, but the new states should be path-equivalent. The new state each gets a subset of the labels of s; you have to think which predicates are supposed to hold on each. 8 selection-view, N==0 selection-view, 0<N<20 selection-view selection-view, N>20

A concurrent system A system of concurrently running entities can be modeled by multiple FSAs Let M1 and M2 be two FSAs with S1 and S2 as disjoint sets of states. M1 || M2 describes M1 and M2 running concurrently. The states of M1 and M2 are pairs from S1  S2. The transitions are (s,u)  a  (t,u), if s  a  t is a transition in M1; analogously (s,u)  b  (s,v); and (s,u)  c  (t,v) if s  c  t and u  c  v are transitions in M1 and M c a c b M1: M2: 0,01,1 c a b M1|| M2 :

Model of an Simple Game 10 SpaceShip: alivedestroyedgameover move(d) tick alive expired collided tick Bullet: alivecollided tick Asteroids: The FSA Asteroids represent a set of asteroids. The states: alive : at least one asteroid is alive collided: at least one asteroid collides empty : no more asteroid left empty (tick represents frame update)

Using || automaton Usually too big to be constructed manually; automate this. Also too complex to be used to guide manual testing. We fall back to the use-case based testing. Use the || automaton to calculate your coverage, e.g. over its states or transitions. If your coverage is still unacceptably low, use the information to guide you to write new test cases. 11