Modellbaserad Test

Tänk er att kunna beskriva ett systems förväntade beteende på något begripligt och visuellt sätt. Tänk er dessutom, att dessa beskrivningar är begripliga för datorer. Tänk er till sist att datorerna inte bara verifierar detta systems förväntade beteende, de hittar buggar också!

Detta är vad man kan få ut av Modellbaserad Test [MBT].

I den här artikeln, tänkte jag kort, introducera MBT för er.

Modellerna

De främst två typer av modeller som jag personligen har arbetat med, och därmed tar upp.

1. tillståndsmaskiner
2. klassificeringsträd, eller beslutsträd

De kan lösa olika typer av testning, men det de har gemensamt är:

1. Modellerna skapas av personer med domänkunskap av Systemet Under Test [SUT]. Det krävs ingen programeringskunskap för att skapa modeller, utan det är kunskapen om det som ska testas som är viktigast.
2. De är visuella, vilket i sin tur ger effekter som:
   * Exponerar test för andra än test. Att fler förstår sig på hur test testar, är aldrig dåligt. Det är inte ovanligt att modeller blir underlag för diskussioner kring hur ett system egentligen ska bete sig.
   * Lättare att förstå testdesignen. Testautomationen blir väsentligt lättare att underhålla, felsöka samt utvidga.
3. Separerar testdesignen från testautomationskoden. Det betyder att ingen egentlig testlogik ligger i den kod man skriver för att driva sina automatiska tester. En trevlig spinn-off effekt av detta är att det underlättar eventuella byten av testautomationsverktyg. Naturligtvis får man skriva om koden som realiserar modellerana, men själva testdesignen förbli intakt, eftersom den ligger i just modellerna.

Tillståndsmaskiner

I ett testsammanhang, så är en tillståndmaskin en beskrivning av ett systems förväntade beteende. Man ritar in alla de tillstånd man vi uppnå under ett test. Under ett test, så används dessa tillstånd som verifieringspunkter, för att kolla av att SUT verkligen har antagit respektive tillstånd. För att beskriva vad som krävs för att ta sig från ett tillstånd till ett annat, så ritar man en pil mellan två tillstånd.

I modellen ovan, så beskrivs ett förväntat betende när man loggar in på en känd svensk musikstreamingtjänst. Här har testaren velat beskriva; att när man loggar in, så måste man autenticera sig, och man har en möjlighet att ange, att när man nästa gång startar klienten, så vill man bli automatiskt inloggad.

Modellen kan nu parsas av ett verktyg, som genererar en promenad genom modellen. Denna promenad, eller testsekvens, ges till ett automationsverktyg som kör det faktiska testet.

Verktyg

yEd

För att editera och rita modeller har jag en absolut favorit. yEd från yWorks. Hämta den genast från: http://www.yworks.com/en/products_yed_about.html

Verktyget är inte Open Source, men det är gratis att använda utan restriktioner, och funkar på alla plattformar där Java6 funkar.

Verktyget är lättjobbat, och har en bra automatisḱ layout-hanterare med en mängd olika varianter på layouts. Ett grymt bra verktyg!

GraphWalker

Detta verktyg kan läsa tillståndsmodller sparade i graphml-format, samt generera både offline eller online testsekvenser ur dessa.

Verktyget är Open Source, och hämtas från: http://graphwalker.org/

Du kan köra verktyget på vilken plattform som helst där Java6 funkar.

Om man kör sina tester online, vilket betyder att testsekvensen genereras runtime (min favorit), så kan man koppla GraphWalker direkt till Java-program, eller indirekt till vilket annat programmeringsspråk eller verktyg som helst, där man kan prata Web Services SOAP. (Exempel på det är perl, ruby, python eller HP Functional Testing)

I GraphWalker kan man blanda olika sekvensgenereringsstrategier med olika stoppvillkor, vilket innebär att man från en och samma modell, kan skapa olika typer av tester, tex:

1. Regressionstester
2. ‘Happy Paths’-tester
3. Funktionstester
4. Bugjägartester
5. Stabilitetstester

Klassificeringsträd eller Beslutsträd

Ett smart sätt att ta fram testfall, eller generera möjliga kombinationer av testdata, är att bygga klassificeringsträdsmodeller.

Modellen ovan säger att vi har 3 olika inparametrar för en login[dialog]. Detta vi vill testa med olika indata. Om vi skulle vilja kombinera alla parametrar med varandra, så får vi 18 testfall.

Verktyg

CTE XL

Detta program är inte Open Source, men det är gratis att använda. Ladda ner det från:http://www.berner-mattner.com/en/berner-mattner-home/products/cte/cte-xl/index-cte-xl.html

Tyvärr funkar det bara smärtfritt på Windows, och användargränssnittet kunde fungera bättre, men oj vad kul den är att använda. Riktigt roligt blir det när man börjar använda verktygets inbyggda testfallsgenererare. Det kan reducera 100.000 testfall till några få hundra om man använder sig av alla-par metoden. Den har tom nåt den kallar ‘threewise’, som reducerar löjligt höga testfallstal, till hanterbara siffror.

Dessutom, om man vill ha riktigt kul, så kan man bygga sin egen parser, som på grundval av CTEs testfallrapport, automatiskt kan köra testfallen, och dessutom räkna ut förväntat utfall på varje enskild testkombination! Kanske lite överkurs, men grymt kraftfullt.

Om man vill veta mer?

Den 19:e april kommer Användargruppen i Sverige för Modellbaserad test, att hålla en träff  i Stockholm. Kolla in http://graphwalker.org/mbtugs-4

Om ni blev intresserade av Modellbaserad Test, så föreslår jag att ni anmäler genast!

Kristian Karl