Testautomatisering – Från vision till realisering

”I Had a Dream” eller ”Allt börjar med en dröm eller en vision”

I min förra block ”Testautomatisering – Att lyckas genom att misslyckas” beskrev jag vägen från ett misslyckat försök att automatisera tester till ett lyckat. Nu vill jag beskriva mer detaljerat detta lyckade försök, från vision till realisering. Underhåll av vår testautomatisering blir en annan spännande blogg senare.

Vår vision var en automatiserad test som är driftsäker, lätt att underhålla och som regressionstestar de högst prioriterade funktioner i våra system, och har en mycket bra resultatpresentation. Att vi även skulle kunna funktionstesta automatiserat i projekten drömde vi inte om, men även så fick vi det senare förverkligat på köpet, till vår stora glädje.

Angreppssättet för att realisera vår vision var att vi skulle testa modellbaserat (MBT) med en testverktygsspecialist (konsult) och en testverktygskunnig (anställd). Vi satte upp delmål som vi skulle nå till en viss tidpunkt.

MBT – Modellbaserade tester – Vad är det?

I Modellbaserad test skapar och exekverar man de nödvändiga artefakterna för att kunna genomföra software tester. Testfallen härleds från en modell som beskriver funktionalitet eller delar av funktionalitet av ett system under utveckling (SUD).

—  Grafen modellerar vi via yED (freeware) från yWorks i formatet *.graphml

—  MBT motor GraphWalker tolkar graf enligt vald algoritm, stoppvillkor etc. (skriven i Java, körs som en webservice, open source) och genererar testsekvens

—  Testverktyg exekverar respektive egde (transition) och vertex (state), i vårt fall QTP som via soap får reda på vad som ska göras

Varför modellbaserat? – Fördelar med Modellbaserade tester

—  Testsekvenserna genereras slumpmässigt av GraphWalker

—  Läs mer om GraphWalker på http://graphwalker.org/

—  Ändringar görs i grafen (och kod OM det behövs) vilket underlättar underhållet

—  Diskussioner om hur ett fel upptäcktes, vägen dit etc. görs med hjälp av grafen och inte genom att studera kod!

—  Enkelt att “stänga av” vissa delar av testerna (för applikationsunderhåll etc.)

—  Hittar fel innan test under grafmodellering

—  Grafen isolerar test från verktyg, d.v.s. samma arbetssätt för alla testexekveringsverktyg såsom QTP, Selenium etc.

—  Arbetsfördelning: Utvecklare, testare och även verksamheten kan modellera, medans automatiserare implementerar kod i testexekveringsverktyg (i vårt fall QTP)

—  Testtäckningen ökar markant med samma insats

Skapa grafen

För att skapa grafen tar vi testautomatiserare en utvecklare och en manuell testare till hjälp och diskuterar kring den. Tester som utvecklaren redan har genomfört i enhetstest behöver inte skapas en gång till och manuella testare kommer med bra input på vad som ska testas. Viktigt är att man med så lite tester som möjligt testar så mycket som möjligt. Testerna kan dokumenteras direkt i grafens objekt.

Figur 1 Exempel på en enkel modell i yEd

Scripting i ett testexekveringsverktyg

Utifrån grafen scriptar testautomatiserare koden för att kunna exekvera testerna. Vi använder som sagt QTP. Varje edge och vertex i grafen blir en liten modul i QTP i vårt fall, se figur 2 för edge och figur 3 för vertex.

Figur 2 Exempelkod för en edge (transition)

Figur 3 Exempelkod för en vertex (state)

Presentation av testresultat

På en testkonferens hade jag lärt mig att presentationen av testresultatet är en viktig hörnsten i en lyckad testautomatisering. Vi sparar våra testresultat i en databas och presenterar dessa snyggt på vårt intranät. Resultatpresentationen består av två delar som visas i bild nedan:

1. Översiktlig resultatpresentation: Resultat av olika tester per testmiljö, se figur 4
2. Detaljerad resultatpresentation: Genom att klicka på ett test ID kan man få detaljresultat per test på en ny sida, se figur 5

Figur 4 Exempel Översiktlig resultatpresentation

Figur 5 Exempel Detaljerad resultatpresentation