Modellvezérelt tesztelés Paróczi Zsombor

A legnagyobb kérdés Hogyan kontrollálható az állapotrobbanás a tesztelés érdemi rontása nélkül.

Előadás felépítése MBT-ről általában 3 kiválasztott cikk Search-based testing for Event-B Syntactic Abstraction of B Models to Generate Tests Model-Based Testing of Object-Oriented Reactive Systems with Spec Explorer

MBT Model based testing

MBT Black-box rendszer / szoftver tesztelés Modellt készítünk (sok esetben kézzel) Modell alapján generáljuk a teszteket Végrehajtjuk a teszteket TestSuite TC#1 TC#2 TC#N TCP Connection establishment “The active open is performed by the client sending a SYN to the server. It sets the segment's sequence number to a random value A. In response, the server replies with a SYN-ACK. The acknowledgment number is set to one more than the received sequence number (A + 1), and the sequence number that the server chooses for the packet is another random number, B. Finally, the client sends an ACK back to the server. The sequence number is set to the received acknowledgement value, and the acknowledgement number is set to one more than the received sequence number i.e. B + 1. “ Model Forrás: Konformancia tesztelés diasor – Távközlő hálózatok , Csöndes Tibor, Ericsson Kft., R&D

Előnyök Hátrányok Csak a modellt kell karbantartani Modell hibái is kiderülhetnek Sokszor a formális modell rendelkezésre áll (távközlő rendszerek) Párhuzamosan írható a teszt és a kód Állapottér robbanásra figyelni kell Tesztesetek nehezebben hordozhatóak Modell “készítése” kritikus folyamat Nagyon sok múlik a tesztgeneráló algoritmuson

MBT dimenziói Forrás: A taxonomy of model-based testing (M. Utting, A. Pretschner, B. Legeard)

FSM - Finite State Machine Def: Egy determinisztikus véges automata a következő hatos: ahol: az állapotok véges halmaza a bemenetek véges halmaza a kimenetek véges halmaza az állapot átmenet függvény, mely leképezi a jelenlegi állapotot és a bemenetet a következő állapotra: a kimeneti függvény, mely leképezi a jelenlegi állapotot és a bemenetet a kimenetre: a kezdeti állapot Megjegyzés: Különbség a nyelvi automatákhoz képest: a fent definiált FSM egy bemenetre egy kimenetet ad és nincs elfogadó állapot. (Így tudunk tesztelni!) Forrás: Tesztsorozat generálás diasor – Távközlő hálózatok , Csöndes Tibor, Ericsson Kft., R&D

EFSM – Extended Finite State Machine Def: Egy determinisztikus kiterjesztett véges automata a következő tizes: ahol: a predikátumok véges halmaza, azaz egy bemeneti eseményhez egy adott állapotban és változó kombinációban az igaz, vagy hamis értéket rendeli. a változók véges halmaza az akciók véges halmaza a változók kezdeti értéke Forrás: Tesztsorozat generálás diasor – Távközlő hálózatok , Csöndes Tibor, Ericsson Kft., R&D

Ez egy gráf! Állapotok = Gráf pontjai (összes változó összes binárisa 2n) Akciók = Gráf élei Tesztelő él (Testing edge) legyen a következő: Az automata állapotba vitele bemeneti esemény előidézése és kimenet ellenőrzése A várt állapot ellenőrzése Forrás: Tesztsorozat generálás diasor – Távközlő hálózatok , Csöndes Tibor, Ericsson Kft., R&D

Klasszikus módszerek DS módszer W módszer UIO sorozatok módszere TT módszer Egy minimális költségű tesztsorozatot keresni, amely leteszteli az FSM összes állapotátmenetét, egyenértékű azzal, hogy keresünk egy Vidéki kínai postás (RCP) utat gráf élein: Minimális költségű út, mely az FSM kezdeti állapotából indul, végighalad -ben lévő éleken legalább egyszer és visszatér a kezdeti állapotba. Természetesen E-ben lévő éleket is használhatunk a bejárás során Forrás: Tesztsorozat generálás diasor – Távközlő hálózatok , Csöndes Tibor, Ericsson Kft., R&D

Search-based testing for Event-B Alin Stefanescu – University of Pitesti, Romania 13th CREST Open Workshop

Event-B Forrás: Alin Stefanescu – CREST Open workshop – London 2011

Event-B teszt generálás

Explicit állapottér

Probléma megközelítése

Probléma megközelítése

GA megközelítés

Fitness

Eredmények

Syntactic Abstraction of B Models to Generate Tests J. Julliand, N. Stouls, P.-C. Bué, and P.-A. Masson Tests and Proofs 2010, Malaga : Spain (2010)

Ötlet A teljes részgráf egy részén tesztek végrehajtása Hogyan lehet részgráfot létrehozni? Állapotok részhalmazára szűkítés Releváns változók kiemelése Data-Flow Fependency Only Data-Flow and Control-Flow Dependencies Állapot részhalmazból abstract modell Abstract modell és “teszt cél” (TP) összevetése, ebből már kevesebb és rövidebb teszt lesz.

Absztrakció

Model-Based Testing of Object-Oriented Reactive Systems with Spec Explorer Margus Veanes, Colin Campbell, Wolfgang Grieskamp, Wolfram Schulte, Nikolai Tillmann, Lev Nachmanson Microsoft 2007

Spec Explorer Spec# és AsmL modellező nyelvek Modell ellenőrző FSM alapján tesztek előállítása .NET nyelvű programok konformancia tesztelése

Példa: Chat The chat system is a distributed, reactive system with an arbitrary number of clients. Each client may post text messages that will be delivered by the system to all other clients that have entered the chat session. The system delivers pending messages in FIFO order with local consistency. However, if there are multiple senders, the messages may be interleaved arbitrarily.

Modell készítése Client osztály “entered” bool változó “unreceivedMsgs” kliensre még meg nem érkezett, de már mások által elküldött üzenetek listája Konstruktor Enter akció Send akció Receive akció

Spec# leírás (1) class Client { bool entered; Map<Client,Seq<string>> unreceivedMsgs; [Action] Client() { this.unreceivedMsgs = Map; foreach (Client c in enumof(Client), c != this){ c.unreceivedMsgs[this] = Seq{}; this.unreceivedMsgs[c] = Seq{}; } entered = false;

Spec# leírás (2) [Action] void Enter() requires !entered; { entered = true; } [Action] void Send(string message) requires entered; { foreach (Client c in enumof(Client), c != this, c.entered) c.unreceivedMsgs[this] += Seq{message};

Spec# leírás (3) [Action(Kind=ActionAttributeKind.Observable)] void Receive(Client sender, string message) requires sender != this && unreceivedMsgs[sender].Length > 0 && unreceivedMsgs[sender].Head == message; { unreceivedMsgs[sender] = unreceivedMsgs[sender].Tail; }

2 kliensre az állapottér

Miért ilyen “egyszerű” a gráf? “Üres” tesztek szűrése Állapottér szűkítés Felhasználói annotálás Elfogadó állapotok definíciója Állapot invariánsok Paraméter szűkítés Funkció korlátozás Direkt állapot szűrés Állapot csoportosítás

Állapottér szűkítés Egy adott állapotban az előfeltételek alapján szűrnek A tesztelésnél a következő lépés vizsgálatánál már teljesült precondition alapján Pl.: Konstruktor után “entered” false lesz, ezért az Enter() meghívható

Felhasználói annotálás 3 tényleges aktívan hívható akció van 1 “megfigyelhető” akció Kényszeríthető és letiltható egy adott akció figyelése

Elfogadó állapotok definíciója Egyszerű leírással adható meg, mit jelent az elfogadó állapot Példában minden állapot, kivéve a kezdeti állapot és amikor van meg nem érkezett üzenet enumof(Client).Size > 0 && Forall{ c in enumof(Client), s in c.unreceivedMsgs.Keys; c.unreceivedMsgs[s].Length == 0}

Állapot invariánsok Minden állapotban érvényes állítások (nem relevánsak vagy előre tudjuk, hogy nem fordulhat elő) Példában: egyik kliens sem kapja meg a saját üzenetét Forall{ c in enumof(Client); c notin c.unreceivedMsgs.Keys } Ellenőrzést az eszköz elvégzi, de az állapotot elrejti

Paraméter szűkítés Alapméretezett értékek Típus alapú korlátozás Paraméter alapú korlátozás Funkció paraméter alapú korlátozás Példában: Message csak “Hi” lehet Message: Set{c in enumof(Client);<c,"hi">}.

Funkció korlátozás Funkciók végrehajtásának nemtriviális előfeltételekhez való kötése Példában: Minden kliens konstruktor végrehajtása után lehet csak a Send() parancsot meghívni enum Mode { Creating, Entering, Sending }; Mode CurrentMode { get { if (enumof(Client).Size < 2) return Mode.Creating; if(Set{cin enumof(Client),!c.entered;c}.Size<2) return Mode.Entering; return Mode.Sending; } }

Direkt állapot szűrés Rákövetkezések külön korlátozása Példában: Egy adott üzenetet egy kliens csak egyszer küld el mielőtt az mindenkihez megérkezne Forall{c in enumof(Client), s in c.unreceivedMsgs.Keys, m1 in c.unreceivedMsgs[s], m2 in c.unreceivedMsgs[s]; m1 != m2}

Állapot csoportosítás Több állapotot egy osztályba lehet sorolni, egy reprezentatív elem kiválasztásával Példában: Belépések illetve üzenetküldések sorrendje a tesztet (és a modellt) sem módosítja – azonos típusúak a kliensek Bag{c in enumof(Client); <c.entered,Bag{<s,m> in c.unreceivedMsgs; m}>} (n kliensnél ez n! belépési sorrend lehetne, ebből csak egyet látunk)

A legnagyobb kérdés Hogyan kontrollálható az állapotrobbanás a tesztelés érdemi rontása nélkül.

Én megkaptam a választ… … de ha vannak kérdések, örömmel válaszolok.