Download presentation

Presentation is loading. Please wait.

Published byPatrick Bumpus Modified about 1 year ago

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

2
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

3
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

4
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

5
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

6
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 ,

7
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

8
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

9
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 :

10
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)

11
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

Similar presentations

© 2016 SlidePlayer.com Inc.

All rights reserved.

Ads by Google