GUI-testning: UI-testcases og eksempler

⚡ Smart opsummering

GUI-testning validerer alle synlige elementer i en applikation – knapper, menuer, ikoner, tekstbokse og layouts – så skærme opfører sig og vises præcis som angivet på tværs af browsere, enheder og skærmopløsninger, før rigtige brugere overhovedet rører ved dem.

🖥️ Anvendelsesområde: Valider størrelse, placering, justering, skrifttyper, farver, fejlmeddelelser og billeder for alle kontrolelementer, en bruger kan se eller klikke på.
🎯 Forretningsscenarie: Brugere bedømmer først en applikation på dens brugerflade, så en forvirrende eller ødelagt skærm koster vedtagelse, selv når logikken bagved er fejlfri.
🧩 Fem typer: Funktionalitets-, brugervenligheds-, kompatibilitets-, tilgængeligheds- og visuel ydeevnetjek besvarer hver især et forskelligt spørgsmål om den samme skærm.
🔍 Tjekliste først: Byg en genanvendelig GUI-tjekliste, der dækker elementgeometri, læsbarhed, opløsningsadfærd, stavning, scrollbarer og deaktiverede felter.
🇧🇷 Tre teknikker: Manuel inspektion, optagelse og afspilning og modelbaseret generering, der forudsiger uønskede tilstande, som et script aldrig ville nå.
🤖 Automatiser gentagelse: Scriptstabile, højfrekvente regressionsstier og reserver menneskelige testere til udforskende og erfaringsmæssig vurdering.
🛡️ Vedligeholdelse af snit: Brug stabile lokatorer, adskil testdata fra testtrin og skærmbilleder af versioner, så mindre layoutredigeringer ikke ødelægger alle scripts.

Læs mere

For at forstå GUI-testning, lad os først forstå, hvad en GUI er.

Hvad er GUI?

Der er to typer grænseflader til en computerapplikation. Kommandolinjegrænsefladen er, hvor du skriver tekst, og computeren reagerer på denne kommando. GUI står for Graphical User Interface, hvor du interagerer med computeren ved hjælp af billeder frem for tekst.

Følgende er de GUI-elementer, som kan bruges til interaktion mellem brugeren og applikationen:

GUI-test er en validering af ovenstående elementer.

Hvad er GUI-testning?

GUI test er en softwaretesttype, der kontrollerer softwarens grafiske brugergrænseflade. Formålet med test af grafisk brugergrænseflade (GUI) er at sikre, at softwareapplikationens funktionalitet fungerer i henhold til specifikationerne ved at kontrollere skærme og kontroller som menuer, knapper, ikoner osv.

GUI er det, brugeren ser. Besøg guru99.com, og den hjemmeside, der vises, er webstedets GUI. Kildekoden forbliver skjult; kun brugerfladen er synlig. GUI-testning fokuserer derfor på designstruktur og om billeder gengives korrekt.

I skærmbilledet ovenfor starter GUI-testen med at bekræfte, at hvert billede er fuldt synligt i forskellige browsere. De resterende kontroller på den samme side er:

Linkene er tilgængelige, og hver knap fungerer, når der klikkes på den.
Ændring af skærmstørrelse får aldrig billeder eller tekst til at krympe, beskæres eller overlappe hinanden.
Intet i layoutet skjules, når browservinduet gøres smallere.

💡 Tip: Kør den samme side i 1920×1080, 1366×768 og 375×812, før du logger eventuelle fejl. Mange rapporter om "defekt layout" er simpelthen utestede breakpoints.

Behov for GUI-test

Nu er det grundlæggende koncept for GUI-testning klart. De få spørgsmål, der vil melde sig i dit hoved, vil være:

Hvorfor testes GUI?
Er det virkelig nødvendigt?
Er det ikke nok at teste en applikations funktionalitet og logik i sig selv, og hvorfor bruge ekstra tid på brugerfladen?

For at få svaret, tænk som en bruger og ikke som en tester. En bruger har ingen viden om, hvordan applikationen er bygget. Det er brugergrænsefladen, der afgør, om brugeren fortsætter med applikationen eller opgiver den.

En normal bruger observerer først applikationens design og udseende, og hvor let det er at forstå brugerfladen. Hvis en bruger ikke er fortrolig med brugerfladen, eller finder applikationen kompleks at forstå, vil vedkommende aldrig komme tilbage. GUI er derfor en kilde til bekymring, og der bør udføres korrekt test for at sikre, at brugerfladen er fri for fejl.

Typer af GUI-testning

At vide, hvorfor brugerfladen er vigtig, er kun halvdelen af billedet. GUI-testning er en familie af fem typer, og hver besvarer et forskelligt spørgsmål om den samme skærm.

Funktionel GUI-testning: Bekræfter, at hver kontrol gør, hvad den lover. Tæt forbundet med funktionstest, den spørger, om en knap sender, en rullemenu filtrerer, og et felt accepterer gyldigt input.
Usability test: Måler hvor let en rigtig person udfører en opgave. Test af brugervenlighed ser på navigationsdybde, læsbarhed og om fejlmeddelelser rent faktisk hjælper.
Kompatibilitetstest: Gentager de samme skærmbilleder på tværs af browsere, operativsystemer og enhedsstørrelser. Cross browser test fanger renderingsfejl, der kun optræder i én motor.
Tilgængelighedstest: Verificerer tastaturnavigation, skærmlæseretiketter og farvekontrast i forhold til WCAG. Tilgængelighedstest er nu et compliancekrav på mange markeder, ikke et valgfrit ekstraudstyr.
Visuel og ydeevnetest: Sammenligner gengivne skærmbilleder med en basislinje og måler, hvor hurtigt brugerfladen males og reagerer, overlapperping med test af ydeevne.

De fleste teams kører alle fem, men vægter dem forskelligt: et offentligt websted læner sig op ad kompatibilitet og tilgængelighed, et internt dashboard på funktionelle kontroller.

Hvad tjekker du i GUI-testning?

Følgende tjekliste vil sikre detaljeret GUI-test i softwaretest.

Tjek alle GUI-elementerne for størrelse, position, bredde, længde og accept af tegn eller tal. For eksempel skal du kunne give input til inputfelterne.
Tjek, at du kan udføre den tilsigtede funktionalitet af applikationen ved hjælp af GUI
Kontroller, at fejlmeddelelserne vises korrekt
Tjek for tydelig afgrænsning af forskellige sektioner på skærmen
Kontroller, at skrifttypen, der bruges i et program, er læsbar
Kontroller, at justeringen af teksten er korrekt
Kontroller, at farven på skrifttypen og advarslerne er æstetisk tiltalende
Tjek, at billederne har god klarhed
Kontroller, at billederne er korrekt justeret
Tjek placeringen af GUI-elementer for forskellige skærmopløsninger.

GUI-testteknikker

Når tjeklisten er færdig, er den næste beslutning, hvordan den skal udføres. GUI-testteknikker kan kategoriseres i tre dele:

Manuel baseret test

Under denne tilgang kontrolleres grafiske skærme manuelt af testere i overensstemmelse med kravene i forretningskravsdokumentet.

Optag og genafspil

GUI-testning kan udføres ved hjælp af automatiseringsværktøjer. Dette gøres i to dele. Under optagelse registreres testtrin af automatiseringsværktøjet. Under afspilning udføres de optagede testtrin på den applikation, der testes. Eksempel på sådanne værktøjer – QTP.

Modelbaseret test

En model er en grafisk beskrivelse af et systems adfærd. Den hjælper os med at forstå og forudsige systemets adfærd. Modeller hjælper med at generere effektive testcases ved hjælp af systemkravene. Diagrammet nedenfor viser, hvordan en model driver testgenerering:

Følgende skal overvejes i forbindelse med denne modelbaserede test:

Byg modellen
Bestem input til modellen
Beregn det forventede output for modellen
Kør testene
Sammenlign det faktiske output med det forventede output
En beslutning om yderligere handling på modellen

Nogle af de modelleringsteknikker, hvorfra testcases kan udledes:

Diagrammer – Afbilder et systems tilstand og kontrollerer tilstanden efter noget input.
Beslutningstabeller – Tabeller, der bruges til at bestemme resultater for hvert anvendt input

Modelbaseret testning er en udviklende teknik til at generere testcases ud fra kravene. Dens største fordel sammenlignet med ovenstående to metoder er, at den kan bestemme uønskede tilstande, som din GUI kan opnå.

Manuel vs. automatiseret GUI-testning

To af disse tre teknikker er manuelle, og én er automatiseret, hvilket rejser det praktiske spørgsmål om, hvor hver især hører hjemme. Manuel test sætter et menneske foran skærmen, så det opfanger akavede arbejdsgange, klodset formulering og animationer, der føles forkerte – vurderinger, som intet manuskript kan fælde.

Automatiseret test afspiller de samme interaktioner tusindvis af gange uden træthed, hvilket gør det til det rigtige svar til stabile regressionsstier og til at gentage én suite på tværs af mange browsere. Ulempen er vedligeholdelse: automatiserede GUI-scripts går i stykker, når en locator eller et layout ændres. De fleste modne teams kører derfor en hybrid, hvor de automatiserer det gentagelige og reserverer folk til det oplevelsesmæssige.

faktor	Manuel GUI-testning	Automatiseret GUI-testning
Bedste for	Nye skærme, udforskende kontroller, udseende og funktionalitet	Stabile regressionspakker, kørsel på tværs af browsere
Hastighed pr. cyklus	Langsom, begrænset af testertimer	Hurtig, kører uden opsyn natten over
Forudgående omkostninger	Lav	Høj (scripting og opsætning af framework)
Vedligeholdelse	Intet udover opdatering af tjeklisten	Væsentligt, når grænsefladen ændres
Fanger subjektive problemer	Ja	Ingen

Eksempler på GUI-testtests

GUI-test involverer dybest set

Test af størrelse, position, bredde, højde af elementerne.
Test af de fejlmeddelelser, der bliver vist.
Test af de forskellige sektioner af skærmen.
Test af skrifttypen om den er læsbar eller ej.
Test af skærmen i forskellige opløsninger ved hjælp af zoom ind og ud som 640 x 480, 600×800 osv.
Afprøvning af justeringen af tekster og andre elementer som ikoner, knapper osv. er på korrekt plads eller ej.
Test af farverne på skrifttyperne.
Test af farverne på fejlmeddelelserne, advarselsmeddelelser.
Tester om billedet har god klarhed eller ej.
Test af justeringen af billederne.
Test af stavemåden.
Brugeren må ikke blive frustreret, mens han bruger systemgrænsefladen.
Test af om grænsefladen er påtractiv eller ej.
Test af rullepanelerne i henhold til størrelsen på siden, hvis nogen.
Test af de deaktiverede felter, hvis nogen.
Test af billedernes størrelse.
Test af overskrifterne, om de er korrekt justeret eller ej.
Test af farven på hyperlinket.

Demo: Sådan laver du GUI-test

Ovenstående liste bliver langt tydeligere, når den anvendes på en rigtig skærm, så her vil vi bruge nogle eksempler på testcases til den følgende dialog.

Nedenfor er et eksempel på testcases, som består af brugergrænseflade- og brugervenlighedstestscenarier. Hvis du ikke har skrevet dem før, kan du se hvordan man skriver testcases først.

Testtilfælde 01 – Bekræft at tekstfeltet med etiketten “Kildemappe” er justeret korrekt.

Testtilfælde 02 – Bekræft at tekstfeltet med etiketten “Pakke” er justeret korrekt.

Testtilfælde 03 – Bekræft etiketten med navnet "Gennemse” er en knap, som er placeret i slutningen af TekstBox med navnet "Kildemappe".

Testtilfælde 04 – Bekræft etiketten med navnet "Gennemse” er en knap, som er placeret i slutningen af TekstBox med navnet "Pakke".

Testtilfælde 05 – Bekræft at tekstfeltet med etiketten “Navn” er justeret korrekt.

Testtilfælde 06 – Kontroller, at etiketten "modifiers” består af 4 radioknapper med navnet offentlig, standard, privat, beskyttet.

Testtilfælde 07 – Kontroller, at etiketten "modifiers” består af 4 radioknapper, som er justeret korrekt i en række.

Testtilfælde 08 – Kontroller, at etiketten "superklasse" under etiketten "modifiers” består af en dropdown, som skal være korrekt justeret.

Testtilfælde 09 – Kontroller, at etiketten "superklasse" består af en knap med etiketten "Gennemse” på den, som skal være korrekt justeret.

Testtilfælde 10 – Bekræft, at standardmusemarkøren skal ændres til en håndmusemarkør, når du klikker på en hvilken som helst radioknap.

Testtilfælde 11 – Bekræft, at brugeren ikke må kunne skrive i rullemenuen "superklasse".

Testtilfælde 12 – Bekræft, at der skal genereres en korrekt fejl, hvis noget er blevet valgt forkert.

Testtilfælde 13 – Bekræft at fejlen skal genereres i den RØDE farve, hvor det er nødvendigt.

Testtilfælde 14 – Kontroller, at de korrekte etiketter skal anvendes i fejlmeddelelserne.

Testtilfælde 15 – Bekræft, at de enkelte alternativknapper skal vælges som standard hver gang.

Testtilfælde 16 – Kontroller, at TAB-knappen fungerer korrekt under opstart.ping på et andet felt ved siden af det forrige.

Testtilfælde 17 – Kontroller, at alle sider indeholder den korrekte titel.

Testtilfælde 18 – Kontroller, at sideteksten er korrekt justeret.

Testtilfælde 19 – Bekræft, at der vises en korrekt bekræftelsesmeddelelse efter opdatering af et felt.

Testtilfælde 20 – Bekræft, at kun én alternativknap skal vælges, og at der kan markeres mere end enkelt afkrydsningsfelter.

Udfordringer i GUI-testning

Det er ligetil at skrive disse sager;ping dem i live over flere udgivelser er ikke. Inden for softwareudvikling er det mest almindelige problem, når man laver Regressionstest er, at applikationens GUI ændres ofte. Det er meget svært at teste og identificere, om det er et problem eller en forbedring. Problemet manifesterer sig, når du ikke har nogen dokumenter vedrørende GUI-ændringer.

⚠️ Advarsel: Scripts, der lokaliserer elementer via skærmkoordinater eller automatisk genererede ID'er, vil mislykkes i den næste build. Betragt en lokaliseringsstrategi som en del af designet, ikke som en eftertanke.

GUI-testværktøjer

Det rigtige værktøj absorberer en stor del af den omsætning. Følgende er en liste over populære GUI-testværktøjer :

Selenium
QTP
Cucumber
SilkeTest
TestComplete
Squish GUI Tester

Klik her for at lære Selenium, QTP & Cucumber.

Følgende er open source-værktøjer tilgængelige til at udføre automatiseret UI-test.

Produkt	Licenseret under
AutoHotkey	GPL
Selenium	Apache
Sikuli	MIT
Robotramme	Apache
Vand	BSD
Dojo værktøjssæt	BSD

Sikuli er billedbaseret, nyttig når en kontrol ikke har en pålidelig lokalisator; Selenium forbliver standard for test af webapplikationer.

Ofte Stillede Spørgsmål

Ja. Moderne værktøjer læser et krav eller scanner en gengivet skærm og udarbejder kandidatcases, der dækker felter, knapper og valideringsmeddelelser. En tester gennemgår dem stadig, fordi AI ikke kan vide, hvilke skærme der indebærer en reel forretningsrisiko.

Selvreparerende motorer gemmer flere attributter pr. element. Når en locator går i stykker, matcher værktøjet de resterende attributter, reparerer referencen og markerer ændringen. Teams, der bruger det på Selenium Suiterne rapporterer langt færre falske fejl efter kosmetiske redesigns.

GUI-testning spørger, om brugerfladen er korrekt: justering, etiketter, farver og kontroller, der fungerer som angivet. Brugervenlighedstestning spørger, om brugerfladen er brugervenlig, og måler, hvor hurtigt en rigtig person afslutter en opgave. Brugervenlighedstestning er én type GUI-testning.

GUI-testning er en sort boks. Testeren arbejder kun ud fra den synlige grænseflade og kravene, uden at læse kildekoden. Den kører normalt under systemtestning, efter at enheds- og integrationstjek allerede har valideret logikken nedenunder.

Kør et kort sæt kritiske screeninger på hver build og hele suiten hver aften eller før hver udgivelse. Værktøjer som f.eks. UFT Planlæg uovervågede kørsler, så natlig udførelse næsten ikke koster testtid.