Vad är modellbaserad testning?

Vad är modellbaserad testning?

Modellbaserad testning är en mjukvarutestningsteknik där körtidsbeteendet hos den testade programvaran kontrolleras mot förutsägelser gjorda av en modell. En modell är en beskrivning av ett systems beteende, uttryckt i termer av inmatningssekvenser, handlingar, villkor, utdata och dataflödet från indata till utdata. En användbar modell måste vara praktiskt förståelig, återanvändbar och delbar, och den måste beskriva det testade systemet exakt.

Det finns många modeller tillgängliga, och var och en beskriver en annan aspekt av systembeteende. Vanliga exempel är:

• Data flöde
• Styrningsflöde
• Beroendegrafer
• Beslutstabeller
• Statliga övergångsmaskiner

Modellbaserad testning beskriver hur ett system beter sig som svar på en handling som bestäms av modellen. Ange handlingen och kontrollera sedan om systemet svarar som modellen förutspår. Eventuella skillnader mellan de två är antingen en defekt i programvaran eller ett fel i modellen, och båda är värda att hitta.

Det är en lätt formell metod för att validera ett system, och den kan lika gärna tillämpas på hårdvarutestning som på mjukvarutestning. Eftersom testerna kommer från en specifikation av beteende snarare än från koden, passar tekniken med svartbox testning familj av tekniker för mjukvarutestning.

Modellbaserat testexempel

Det enklaste sättet att läsa en beteendemodell är att följa den till fullo. Diagrammet nedan visar en liten textredigeringsuppgift, där varje ruta representerar ett tillstånd som applikationen kan vara i och varje pil representerar en åtgärd en användare kan vidta.

Modellen förklarar ett förenklat tillvägagångssätt för att skriva poesi i Anteckningar och de möjliga åtgärderna relaterade till varje steg. För varje åtgärd, som att starta programmet, skriva in en dikt eller spara filen, en testfall kan genereras och utdata verifieras. Att gå en annan väg genom samma diagram, till exempel starta och stänga utan att spara, producerar ett annat testfall utan extra designkostnad, vilket är det ekonomiska argumentet för hela tekniken.

Typer av MBT

Det finns två typer av modellbaserade testramverk, och skillnaden mellan dem är helt enkelt när teststegen produceras:

• Offline / a priori: Generering av testsviter innan de körs. En testsvit är en samling testfall, och i detta läge lagras, granskas och körs om sviten som alla andra automatiseringstestning tillgång.
• Online / i farten: Generering av testsviter under testkörning, där nästa steg väljs baserat på hur systemet faktiskt reagerade på det föregående.

Offline-generering passar reglerade miljöer som behöver en granskningsbar, repeterbar svit. Online-generering passar långvariga utforskande sessioner mot tillståndskänsliga system, eftersom generatorn kan reagera på det verkliga svaret snarare än det förutspådda.

Hur modellbaserad testning fungerar

Oavsett vilket ramverk som används följer tekniken samma fem steg. Varje steg producerar en artefakt som nästa steg konsumerar, vilket är anledningen till att modellen, och inte testskriptet, blir det som teamet underhåller.

• Steg 1: Bygg modellen. Översätt krav eller en specifikation till en abstracen modell för förväntat beteende, som definierar tillstånden, övergångarna mellan dem och de insignaler som utlöser varje övergång.
• Steg 2: Välj urvalskriterier för testet. Kriterier talar om för generatorn när den ska stoppa. Vanliga kriterier är täckning av alla tillstånd, som besöker varje tillstånd minst en gång; täckning av alla övergångar, som utövar varje pil minst en gång; och täckning av sökvägar eller dataflöden för djupare utforskning.
• Steg 3: Generera magmusklertract-testfall. Verktyget går runt modellen och avger sekvenser av abstracde steg som uppfyller de valda kriterierna, tillsammans med det förväntade resultatet vid varje steg.
• Steg 4: Konkretisera magmusklernatract-tester. Ett adapterlager mappar varje abstracatt vidta en verklig åtgärd mot systemet, såsom en interaktion med användargränssnittet, en API samtal eller ett protokollmeddelande. Den här kartanping skrivs en gång och återanvänds av varje genererat test.
• Steg 5: Verkställ och tilldela domar. De konkreta testerna körs mot systemet som testas, varje observerat svar jämförs med modellförutsägelsen och ett godkänt eller underkänt omdöme registreras. tractillbaka till modellelementet som producerade den.

Ocuco-landskapet tracDen praktiska utdelningen som skapades i steg 5 är den praktiska vinsten. När ett krav ändras ändras modellen, och de berörda testerna genereras istället för att skrivas om, vilket är anledningen till att team som utför frekventa regressionstestning mot en stabil specifikation gynnas mest.

Olika modeller i testning

För att förstå MBT är det nödvändigt att förstå några av de modeller som förklaras nedan. Var och en av dem byter uttryckskraft mot ansträngning, så valet beror på hur komplicerat beteendet som testas verkligen är.

Finita tillståndsmaskiner

Denna modell hjälper testare att bedöma resultatet beroende på vald ingång. Olika kombinationer av ingångarna kan resultera i ett motsvarande tillstånd i systemet.

Systemet kommer att ha ett specifikt tillstånd och ett aktuellt tillstånd, vilket styrs av en uppsättning indata som ges av testarna.

Tänk på exemplet nedan. Ett system låter anställda logga in i en applikation. Medarbetarens nuvarande status är "Ute" och blir "In" när medarbetaren loggar in i systemet. I statusen "In" kan en medarbetare visa, skriva ut och skanna dokument i systemet.

Tillståndsmaskinen för det exemplet visas här, med varje pil märkt med den ingång som orsakar övergången.

Statliga diagram

Ett tillståndsdiagram är en utvidgning av den finita tillståndsmaskinen och kan användas för komplexa och realtidssystem. Tillståndsdiagram beskriver olika beteenden hos systemet, de har ett bestämt antal tillstånd, och systemets beteende analyseras och representeras i form av händelser för varje tillstånd. Den utvidgning som är viktig i praktiken är hierarkin: ett tillståndsdiagram tillåter kapslade och parallella tillstånd, så en maskin som skulle behöva dussintals platta tillstånd kan ritas kompakt.

Till exempel rapporteras fel i felhanteringsverktyget med statusen Ny. När ett fel har åtgärdats av utvecklare måste statusen ändras till Åtgärdat. Om ett fel inte är åtgärdat ändras statusen till Återöppna. Tillståndsdiagram bör utformas så att en händelse anropas för varje tillstånd.

Den fellivscykeln ritas nedan, där varje status visas som ett tillstånd och varje arbetsflödesåtgärd som den händelse som flyttar felet mellan dem.

Unified Modelling Language (UML)

Unified Modelling Language (UML) är ett standardiserat modelleringsspråk för allmänt bruk. UML innehåller en uppsättning grafiska notationstekniker som används för att skapa visuella modeller som kan beskriva mycket komplicerat systembeteende.

UML har notationer som:

• Stationer & aktiviteter
• Skådespelare
• Affärsprocess
• Komponenter
• Programmeringsspråk

Aktivitets- och tillståndsmaskindiagrammen är de som testgeneratorer läser oftast, vilket exempel-UML-modellen nedan illustrerar.

Modellbaserade testverktyg

En modell på papper genererar ingenting på egen hand. En generator behövs för att följa modellen och generera testvägar, och verktygsmarknaden är uppdelad i generatorer med öppen källkod och kommersiella testdesignplattformar.

• GraphWalker — ett verktyg med öppen källkod som läser modeller formade som riktade grafer och genererar testvägar från dem, med valbara generatorer och stoppvillkor.
• fMBT — en uppsättning modellbaserade testverktyg med öppen källkod från Intel som stöder testgenerering och exekvering mot tillståndsmodeller.
• Conformiq — en kommersiell automatiserad testdesignprodukt som härleder testfall och skript från grafiska beteendemodeller.
• MaTeLo och MBTsuite — kommersiella plattformar inriktade på statistiska användningsmodeller och generering av tester i befintliga automatiseringsramverk.
• Spec Explorer - Microsofts modellbaserade testtillägg för Visual Studio, flitigt citerat i litteraturen om protokolltestning.

Urvalet beror mindre på funktionslistor än på två frågor: vilken notation teamet faktiskt kan rita, och om verktyget kan generera tester i det automatiseringsramverk som redan används. En generator som producerar sviter som ingen kan köra lägger till ett steg i processen istället för att ta bort ett.

Modellbaserad testning kontra traditionell testdesign

Kontrasten mot handskriven testdesign är värd att lyfta fram, eftersom de två metoderna misslyckas på olika ställen snarare än att den ena helt enkelt är bättre.

Aspect	Modellbaserad testning	Traditionell testdesign
Källa för testfall	Genereras automatiskt från en beteendemodell	Skrivet individuellt av en testare utifrån kraven
Effekt av en kravändring	Uppdatera modellen, generera de berörda testerna på nytt	Lokalisera och redigera varje påverkat testfall manuellt
Rapportering	Mätt mot modellkriterier som alla tillstånd eller alla övergångar	Mätt mot krav och beroende på testarens bedömning
Kostnad på förhand	Hög: modelleringsförmåga, verktygsuppsättning och ett adapterlager	Låg: en testare kan börja skriva omedelbart
Bästa passform	Tillståndsstarka, långlivade system med stabil specifikation	Korta projekt, engångsreportage och utforskande arbete
Huvudfelläge	En felaktig eller inaktuell modell genererar tyst felaktiga tester	Luckor och dubbletter ackumuleras i en stor svit

Utvecklingen nedan sätter tekniken i sitt sammanhang: manuell testkörning gav vika för automatiserad körning, och modellbaserade metoder flyttar automatiseringen en nivå tidigare, in i själva testdesignen.

Utmaningar med modellbaserad testning

Implementering av MBT i en organisation kräver en avsevärd investering av pengar och ansträngning. Följande är nackdelarna med MBT i mjukvaruutveckling:

• Testare behöver modelleringsfärdigheter som traditionell testdesign inte kräver.
• Inlärningskurvan är lång, och det första projektet kostar oftast mer än det sparar.
• Själva modellen kan vara svår att förstå och granska, särskilt när den väl växer.
• En modell som avviker från specifikationen genererar säkra, felaktiga tester.
• Adapterlagret som förvandlar magmusklernatracStegen till verkliga handlingar måste skrivas och underhållas separat.
• Modellstorleken växer snabbt, så en obegränsad tillståndsmodell kan producera fler sökvägar än något team kan utföra.

Inget av detta är en anledning att undvika tekniken, men tillsammans förklarar de varför MBT vanligtvis introduceras på ett stabilt delsystem först snarare än över ett helt system. livscykel för mjukvarutestning genast.

Fördelar med modellbaserad testning

I motsats till dessa kostnader är fördelarna med MBT:

• Enkelt underhåll av testfall och testsviter, eftersom modellen redigeras snarare än de enskilda testerna.
• Kostnadsreduktion under ett långvarigt projekts livslängd.
• Förbättrad testtäckning, eftersom generatorn utforskar vägar som en person skulle hoppa över.
• Olika genererade sviter kan köras parallellt på ett valfritt antal maskiner.
• Tidig defektdetektering, eftersom oklarheter uppstår medan modellen byggs, innan någon kod exekveras.
• En ökning av antalet defekter som hittas för samma testinsats.
• Tidsbesparingar vid testdesign när modellen och adaptern väl finns.
• Förbättrad arbetstillfredsställelse för testare, i takt med att arbetet övergår från repetitivt skriptarbete till modellering och analys.

Testare konstruerar mentala modeller ändå medan de arbetar, och MBT flyttar helt enkelt dessa mentala modeller till papper där de kan granskas, versioneras och återanvändas. Var tekniken passar in i de andra tillgängliga metoderna beskrivs i typer av mjukvarutestning.

Vanliga frågor