Hvad er modelbaseret test?

Hvad er modelbaseret test?

Modelbaseret test er en softwaretestteknik, hvor den testede softwares kørselsadfærd kontrolleres i forhold til forudsigelser fra en model. En model er en beskrivelse af et systems adfærd, udtrykt i form af inputsekvenser, handlinger, betingelser, output og datastrømmen fra input til output. En brugbar model skal være praktisk forståelig, genanvendelig og delbar, og den skal beskrive det testede system præcist.

Der findes adskillige modeller, og hver enkelt beskriver et forskelligt aspekt af systemadfærd. Almindelige eksempler er:

• Dataflow
• Styr flow
• Afhængighedsgrafer
• Beslutningstabeller
• Statens overgangsmaskiner

Modelbaseret testning beskriver, hvordan et system opfører sig som reaktion på en handling bestemt af modellen. Angiv handlingen, og kontroller derefter, om systemet reagerer, som modellen forudsiger. Enhver afvigelse mellem de to er enten en fejl i softwaren eller en fejl i modellen, og begge er værd at finde.

Det er en let formel metode til validering af et system, og den kan anvendes lige så let til hardwaretestning som til softwaretestning. Fordi testene kommer fra en specifikation af adfærd snarere end fra koden, passer teknikken sammen med sort kasse test familie af softwaretestteknikker.

Modelbaseret testeksempel

Den enkleste måde at aflæse en adfærdsmodel på er at følge den til ende. Diagrammet nedenfor viser en lille tekstredigeringsopgave, hvor hver boks repræsenterer en tilstand, som applikationen kan være i, og hver pil repræsenterer en handling, en bruger kan udføre.

Modellen forklarer en forenklet tilgang til at skrive digte i Notesblok og de mulige handlinger relateret til hvert trin. For hver handling, såsom at starte applikationen, indtaste et digt eller gemme filen, en test sag kan genereres, og outputtet verificeres. At gå en anden vej gennem det samme diagram, for eksempel at starte og lukke uden at gemme, producerer en anden testcase uden ekstra designomkostninger, hvilket er det økonomiske argument for hele teknikken.

Typer af MBT

Der findes to typer modelbaserede testrammer, og forskellen mellem dem er simpelthen, hvornår testtrinnene produceres:

• Offline / a priori: Generering af testpakker før de udføres. En testpakke er en samling af testcases, og i denne tilstand gemmes, gennemgås og genkøres pakken som enhver anden automatiseringstest aktiv.
• Online / på farten: Generering af testsuiter under testudførelse, hvor det næste trin vælges baseret på, hvordan systemet faktisk reagerede på det foregående.

Offline-generering er egnet til regulerede miljøer, der har brug for en gennemgåelig og gentagelig suite. Online-generering er egnet til langvarige, udforskende sessioner mod tilstandsfulde systemer, fordi generatoren kan reagere på det reelle svar snarere end det forudsagte.

Sådan fungerer modelbaseret testning

Uanset hvilket framework der anvendes, følger teknikken de samme fem faser. Hver fase producerer en artefakt, som den næste fase forbruger, hvilket er grunden til, at modellen, og ikke testscriptet, bliver det, teamet vedligeholder.

• Trin 1: Byg modellen. Oversæt krav eller en specifikation til et abstracen model for forventet adfærd, der definerer tilstandene, overgangene mellem dem og de input, der udløser hver overgang.
• Trin 2: Vælg kriterierne for testens udvælgelse. Kriterier fortæller generatoren, hvornår den skal stoppe. Almindelige kriterier er dækning af alle tilstande, som besøger hver tilstand mindst én gang; dækning af alle overgange, som træner hver pil mindst én gang; og dækning af stier eller dataflow for dybere udforskning.
• Trin 3: Generer mavemusklertract-testtilfælde. Værktøjet går rundt i modellen og udsender sekvenser af abstract trin, der opfylder de valgte kriterier, sammen med det forventede resultat ved hvert trin.
• Trin 4: Konkretiser mavemusklernetract-tests. Et adapterlag kortlægger hver abstracat træde i gang med en reel handling mod systemet, såsom en interaktion med brugergrænsefladen, en API opkald eller en protokolbesked. Dette kortping skrives én gang og genbruges af hver genereret test.
• Trin 5: Udfør og tildel domme. De konkrete tests kører mod det system, der testes, hver observeret respons sammenlignes med modelforudsigelsen, og en bestået eller ikke-bestået dom registreres. tractilbage til det modelelement, der producerede det.

tracDen praktiske udbytte af den funktionalitet, der blev skabt i trin 5. Når et krav ændres, ændres modellen, og de berørte tests regenereres i stedet for at blive omskrevet, hvilket er grunden til, at teams, der udfører hyppige regressionstest mod en stabil specifikation gavner mest.

Forskellige modeller i test

For at forstå MBT er det nødvendigt at forstå nogle af de modeller, der forklares nedenfor. Hver af dem bytter udtrykskraft mod indsats, så valget afhænger af, hvor kompleks den adfærd, der testes, egentlig er.

Endelige maskiner

Denne model hjælper testere med at vurdere resultatet afhængigt af det valgte input. Forskellige kombinationer af input kan resultere i en tilsvarende tilstand i systemet.

Systemet vil have en specifik tilstand og en aktuel tilstand, som styres af et sæt input givet af testerne.

Overvej eksemplet nedenfor. Et system giver medarbejdere mulighed for at logge ind på en applikation. Medarbejderens aktuelle status er "Ude", og den bliver "Ind", når medarbejderen logger ind på systemet. I status "Ind" kan en medarbejder se, udskrive og scanne dokumenter i systemet.

Tilstandsmaskinen for det eksempel er vist her, hvor hver pil er mærket med det input, der forårsager overgangen.

Statsdiagrammer

Et tilstandsdiagram er en udvidelse af den finite tilstandsmaskine og kan bruges til komplekse og realtidssystemer. Tilstandsdiagrammer beskriver forskellige systemadfærd, de har et bestemt antal tilstande, og systemets adfærd analyseres og repræsenteres i form af hændelser for hver tilstand. Den udvidelse, der betyder noget i praksis, er hierarki: et tilstandsdiagram tillader indbyggede og parallelle tilstande, så en maskine, der ville have brug for snesevis af flade tilstande, kan tegnes kompakt.

For eksempel registreres fejl i fejlhåndteringsværktøjet med statussen Ny. Når en fejl er rettet af udviklerne, skal statussen ændres til Rettet. Hvis en fejl ikke er rettet, ændres statussen til Genåbnet. Tilstandsdiagrammer bør designes, så der kaldes en hændelse for hver tilstand.

Den pågældende defektlivscyklus er tegnet nedenfor, hvor hver status vises som en tilstand, og hver arbejdsgangshandling er den hændelse, der flytter defekten mellem dem.

Unified Modeling Language (UML)

Unified Modeling Language (UML) er et standardiseret modelleringssprog til generelle formål. UML inkluderer et sæt grafiske notationsteknikker, der bruges til at oprette visuelle modeller, der kan beskrive meget kompliceret systemadfærd.

UML har notationer som:

• Aktiviteter
• Skuespillere
• Forretningsproces
• Komponenter
• Programmeringssprog

Aktivitets- og tilstandsmaskindiagrammerne er dem, testgeneratorer læser oftest, som eksemplet på UML-modellen nedenfor illustrerer.

Modelbaserede testværktøjer

En model på papir genererer intet i sig selv. En generator er nødvendig for at følge modellen og generere teststier, og værktøjsmarkedet opdeles i open source-generatorer og kommercielle testdesignplatforme.

• GraphWalker — et open source-værktøj, der læser modeller formet som rettede grafer og genererer teststier ud fra dem, med valgbare generatorer og stopbetingelser.
• fMBT — et open source-modelbaseret testværktøjssæt fra Intel, der understøtter testgenerering og -udførelse mod tilstandsmodeller.
• Conformiq — et kommercielt automatiseret testdesignprodukt, der udleder testcases og scripts fra grafiske adfærdsmodeller.
• MaTeLo og MBTsuite — kommercielle platforme rettet mod statistiske brugsmodeller og generering af tests i eksisterende automatiseringsrammer.
• Spec Explorer — Microsoft's modelbaserede testudvidelse til Visual Studio, som er bredt citeret i litteraturen om protokoltestning.

Udvælgelsen afhænger mindre af funktionslister end af to spørgsmål: hvilken notation teamet rent faktisk kan tegne, og om værktøjet kan udsende tests til det automatiseringsframework, der allerede er i brug. En generator, der producerer suiter, som ingen kan udføre, tilføjer et trin til processen i stedet for at fjerne et.

Modelbaseret testning vs. traditionelt testdesign

Kontrasten til håndskrevne testdesign er værd at fremhæve, fordi de to tilgange fejler på forskellige steder i stedet for at den ene blot er bedre.

Aspect	Modelbaseret test	Traditionelt testdesign
Kilde til testcases	Genereret automatisk fra en adfærdsmodel	Skrevet individuelt af en tester ud fra krav
Effekt af en ændring af krav	Opdater modellen, og generer de berørte tests	Find og rediger hver berørt testcase manuelt
Dækning	Målt i forhold til modelkriterier såsom alle tilstande eller alle overgange	Målt i forhold til krav og afhængig af testers vurdering
Forudgående omkostninger	Høj: modelleringsfærdigheder, værktøjsopsætning og et adapterlag	Lav: en tester kan begynde at skrive med det samme
Bedste pasform	Stateful, langlivede systemer med en stabil specifikation	Korte projekter, engangsartikler og udforskende arbejde
Hovedfejltilstand	En forkert eller forældet model genererer lydløst forkerte tests	Huller og dubletter ophobes på tværs af en stor suite

Udviklingen nedenfor sætter teknikken i kontekst: manuel testudførelse gav plads til automatiseret udførelse, og modelbaserede tilgange flytter automatiseringen et niveau tidligere, ind i selve testdesignet.

Udfordringer ved modelbaseret test

Implementering af MBT i en organisation kræver en betydelig investering af penge og kræfter. Følgende er ulemperne ved MBT i software Engineering:

• Testere har brug for modelleringsfærdigheder, som traditionelt testdesign ikke kræver.
• Læringskurven er lang, og det første projekt koster normalt mere, end det sparer.
• Selve modellen kan være svær at forstå og gennemgå, især når den vokser.
• En model, der afviger fra specifikationen, genererer sikre, forkerte tests.
• Adapterlaget, der drejer mavemusklernetracSkridt til reelle handlinger skal skrives og vedligeholdes separat.
• Modelstørrelsen vokser hurtigt, så en ubegrænset tilstandsmodel kan producere flere stier, end noget team kan udføre.

Ingen af ​​disse er en grund til at undgå teknikken, men tilsammen forklarer de, hvorfor MBT normalt introduceres på ét stabilt delsystem først i stedet for på tværs af et helt system. livscyklus for softwaretest på en gang.

Fordele ved modelbaseret testning

I forhold til disse omkostninger er fordelene ved MBT:

• Nem vedligeholdelse af testcases og testsuiter, fordi modellen redigeres i stedet for de individuelle tests.
• Omkostningsreduktion over et langvarigt projekts levetid.
• Forbedret test dækning, da generatoren udforsker stier, som en person ville springe over.
• Forskellige genererede suiter kan køre parallelt på et hvilket som helst antal maskiner.
• Tidlig fejldetektering, fordi tvetydigheder opstår, mens modellen bygges, før nogen kode udføres.
• En stigning i antallet af defekter fundet for den samme testindsats.
• Tidsbesparelser på testdesign, når modellen og adapteren findes.
• Forbedret jobtilfredshed for testere, idet indsatsen skifter fra gentagne scripts til modellering og analyse.

Testere konstruerer mentale modeller alligevel, mens de arbejder, og MBT flytter blot disse mentale modeller over på papir, hvor de kan gennemgås, versioneres og genbruges. Hvor teknikken passer sammen med de andre tilgængelige tilgange er beskrevet i typer af softwaretestning.

Ofte Stillede Spørgsmål