Modellbaserad testautomatisering

Översikt och aktuell utmaning i befintliga tester

Testautomatiseringsparadigmet fortsätter att "utvecklas". Organisationer har bevittnat och varit en del av denna utveckling genom åren. Testteam är en del av "Been there, done that"-klubben när det kommer till konventionella testautomatiseringstekniker. En del av oss sitter bokstavligen på högen av automatiserade testskript, känner oss nervösa, osäkra på om projektgruppen har tillräcklig testtäckning. Automationsingenjörer har alltid automatiserat testfallen och uppdaterat skripten för ändringar i testfall, skapat nya testfall och tagit bort testskript som inte längre är giltiga. Team strävar efter att underhålla olika testfalls- och testskriptversioner; listan är oändlig.

Människor kämpar för att identifiera och schemalägga de tester som ska utföras och hantera den exponentiella ökningen av efterfrågan på testning mot olika miljöer. Sedan finns det en grupp som alltid säger: "Det är automatiserat... Varför inte köra allt!"

Idag är utmaningarna som testledare står inför inte nya utan blir kritiska i takt med att saker och ting förändras. Svarstiden blir pressad som aldrig, och alla kämpar för att få in innovation, AI i testautomatisering.

Automatiseringsstrategiskift

Under årens lopp har traditionella testautomatiseringsmetoder gett fördelar, men med den enorma initialkostnaden beroende på flera faktorer som infrastruktur, verktyg, teknologier, kompetensuppsättningar. Vi bevittnar ett skifte från konventionella testautomatiseringsmetoder som använder testfall/berättelser som bas för att skapa testautomatisering till ett "modellbaserat" testsätt.

Även om övergången inte är svår så finns det ett större behov av att ändra tankesätt och få en högre komfortnivå med modellbaserad testautomation. Testledare som är vana vid att underhålla stora uppsättningar och versioner av testfall kan bli lite obekväma av att se en modell och inga testfall alls!

Det finns redan tillgängliga verktyg för att skapa ett systems modell, och många av dem tillhandahåller en mekanism för att köra en modell som täcker olika vägar och verifieringspunkter. Med några iterationer och övning kan man skapa och köra modeller för att förstå hur och vilka typer av virtuella testfall som utvecklas och implementeras från modellen.

Vad är modellbaserad testning (MBT)

MBT är en testteknik när vi definierar en abstrakt modell som beskriver ett mjukvarubeteende och sedan använder denna modell för att testa den verkliga programvaran baserat på förutsägelser av vägar.

Den abstrakta testfärgen fungerar som en grund på vilken den körbara testsviten härleds. Den körbara testsviten (automatiseringsskript) som mappas med de abstrakta testfallen kan kommunicera direkt med SUT (System Under Test).

Nyckelkomponenter i modellbaserad testning

Modell

En modell är en grafisk representation av systemets beteende med stater och åtgärder. Modellen börjar med initiala villkor och slutar med utgångsförhållanden. Beteende kan beskrivas i termer av ingångssekvenser, åtgärder, villkor, utdata och dataflöde från input till output.

En modell tolkas som eller översätts till ett tillståndsövergångssystem eller finita-tillståndsautomation. Tillståndsövergångsdiagrammet representeras av applikationens modell, en riktad graf där noder representerar applikationens tillstånd och kanter representerar övergångarna .

En typisk modell kan representeras i olika former baserat på det valda verktyget. Några sådana exempel visas nedan:

Testa vägar

Modellen visar bara användarscenarier av möjliga vägar baserat på initiala och utgångsförhållanden. Testvägar inkluderar alla möjliga permutationer och kombinationer av att gå genom de mellanliggande noderna mellan initiala och utgångsförhållanden. Till skillnad från den traditionella testautomatiseringsmetoden är testvägar inte villkorade av skriftliga testskript. Vägen som tas under exekveringen är slumpmässig och beror på exekveringsmotoralgoritmen, med hänsyn till olika kriterier som "täckningsprocent, "vikt" etc.

Hur modellbaserad testning kan hjälpa

Med framväxten av modellbaserad testautomatisering vid horisonten började möjligheterna med futuristiska testautomatiseringsidéer att diskuteras. Några av våra kunder, produktföretagen, kunde omedelbart inse fördelarna med MBT i ständigt föränderliga miljöer.

MBT har hjälpt testhantering att drastiskt minska ansträngningarna för testfall, skriptgenerering, granskning och omarbetning. Ändå är en av de främsta fördelarna med att använda MBT testtäckning. Med den konventionella testautomatiseringsmetoden påverkas täckningen av antalet manuella tester som skapas eller antalet automatiserade testfall.

Det finns en risk att missa flera testscenarier när man skriver de manuella eller automatiserade testskripten. När det gäller modeller definierar en testingenjör eller affärsanalytiker alla möjliga tillstånd och åtgärder för ett skärm- eller användningsfallsscenario. Testtäckningsprocenten ökas drastiskt eftersom testerna genereras automatiskt för alla möjliga kombinationer av tillstånd och åtgärder mellan initial- och utgångstillstånd.

Det finns enorma möjligheter för ytterligare förbättringar av testtäckningen med modellbaserad testautomatisering med AI/ML.

Konventionell vs. Modellbaserad testning

Testfall följer fastställda procedurer i den konventionella testmetoden, där mänskligt omdöme är grunden. För att täcka olika vägar eller procedurer måste man skapa nya tester. Men i MBT är de flesta sökvägar härledda från modeller som är noggrant mappade med kraven och automatiskt genererade testskript eller sviter. Skillnaden är uppenbar om vi ser arbetsflödena nedan.

Fördelar och slutsats

Det konventionella tillvägagångssättet kräver avsevärda ansträngningar för att testa automatisering, även för en liten förändring av affärskraven. Men uppdatering av respektive modellkomponent med MBT införlivar ändringarna snabbt. För testproffs är MBT en övertygande metod med följande fördelar:

• Det börjar med specifikationer genom att förstärka tanken att QA-engagemang hör hemma i början av upptäcktsstadiet.
• Den hittar vanligtvis design- och specifikationsbuggar innan koden ens existerar.
• Definiera funktionskrav exakt för att matcha användarnas förväntningar bättre.
• Minska planeringstiden genom att tillhandahålla komponenter i funktionsspecifikationsdokument.
• Testtäckning kan hittas redan innan några testskript har skrivits med offline-testkörningar med modeller utan SUT.
• Automatisera generering av testfall, skapa fler testfall på kortare tid
• Maximera testtäckningen med färre testfall
• Mindre underhåll av automatiseringsskript
• Kortare testcykeltid