GUI-testing: UI-testtilfeller og eksempler

For å forstå GUI-testing, la oss først forstå hva et GUI er.

Hva er GUI?

Det finnes to typer grensesnitt for en dataapplikasjon. Kommandolinjegrensesnitt er der du skriver inn tekst og datamaskinen svarer på den kommandoen. GUI står for Graphical User Interface hvor du samhandler med datamaskinen ved hjelp av bilder i stedet for tekst.

Følgende er GUI-elementene som kan brukes for interaksjon mellom brukeren og applikasjonen:

GUI-testing er en validering av elementene ovenfor.

Hva er GUI-testing?

GUI-testing er en programvaretesttype som kontrollerer det grafiske brukergrensesnittet til programvaren. Formålet med testing av grafisk brukergrensesnitt (GUI) er å sikre at funksjonaliteten til programvareapplikasjonen fungerer i henhold til spesifikasjonene ved å sjekke skjermer og kontroller som menyer, knapper, ikoner osv.

GUI er det brukeren ser. Besøk guru99.com, og hjemmesiden som vises er nettstedets GUI. Kildekoden forblir skjult; bare grensesnittet er synlig. GUI-testing fokuserer derfor på designstruktur og om bilder gjengis riktig.

I skjermbildet ovenfor starter GUI-testing med å bekrefte at hvert bilde er fullstendig synlig i forskjellige nettlesere. De gjenværende kontrollene på den samme siden er:

• Lenkene er tilgjengelige, og hver knapp fungerer når du klikker på den.
• Endring av skjermstørrelse fører aldri til at bilder eller tekst krymper, beskjæres eller overlapper hverandre.
• Ingenting i oppsettet skjules når nettleservinduet gjøres smalere.

💡 Tips: Kjør den samme siden i 1920×1080, 1366×768 og 375×812 før du logger eventuelle feil. Mange rapporter om «ødelagt layout» er rett og slett uprøvde avbruddspunkter.

Behov for GUI-testing

Nå er det grunnleggende konseptet med GUI-testing klart. De få spørsmålene som vil slå deg inn vil være:

• Hvorfor tester GUI?
• Er det virkelig nødvendig?
• Er det ikke nok å teste funksjonaliteten og logikken til en applikasjon i seg selv, og hvorfor bruke ekstra tid på grensesnittet?

For å få svaret, tenk som en bruker og ikke som en tester. En bruker har ingen kunnskap om hvordan applikasjonen ble bygget. Det er grensesnittet som avgjør om brukeren fortsetter med applikasjonen eller forlater den.

En vanlig bruker legger først merke til designet og utseendet til applikasjonen, og hvor lett det er å forstå grensesnittet. Hvis en bruker ikke er komfortabel med grensesnittet, eller synes applikasjonen er kompleks å forstå, vil vedkommende aldri komme tilbake. GUI er derfor et problem, og skikkelig testing bør utføres for å sikre at grensesnittet er fritt for feil.

Typer GUI-testing

Å vite hvorfor grensesnittet er viktig er bare halve bildet. GUI-testing er en familie av fem typer, og hver av dem svarer på et annet spørsmål om den samme skjermen.

• Funksjonell GUI-testing: Bekrefter at hver kontroll gjør det den lover. Nært knyttet til funksjonstesting, den spør om en knapp sender inn, en rullegardinmeny filtrerer og et felt godtar gyldig inndata.
• Brukervennlighetstesting: Måler hvor lett en ekte person fullfører en oppgave. Brukervennlighetstesting ser på navigasjonsdybde, lesbarhet og om feilmeldinger faktisk hjelper.
• Kompatibilitetstesting: Gjentar de samme skjermbildene på tvers av nettlesere, operativsystemer og enhetsstørrelser. Kryss nettlesertesting fanger opp gjengivelsesfeil som bare vises i én motor.
• Tilgjengelighetstesting: Verifiserer tastaturnavigasjon, skjermleseretiketter og fargekontrast mot WCAG. Tilgjengelighetstesting er nå et samsvarskrav i mange markeder, ikke et valgfritt tillegg.
• Visuell og ytelsestesting: Sammenligner gjengitte skjermbilder med en grunnlinje og måler hvor raskt grensesnittet maler og reagerer, overlapperping med ytelsestesting.

De fleste team kjører alle fem, men vekter dem ulikt: et offentlig nettsted lener seg på kompatibilitet og tilgjengelighet, et internt dashbord på funksjonskontroller.

Hva sjekker du i GUI-testing?

Følgende sjekkliste vil sikre detaljert GUI-testing i programvaretesting.

• Sjekk alle GUI-elementene for størrelse, posisjon, bredde, lengde og aksept av tegn eller tall. Du må for eksempel kunne gi inndata til inndatafeltene.
• Sjekk at du kan utføre den tiltenkte funksjonaliteten til applikasjonen ved å bruke GUI
• Kontroller at feilmeldingene vises riktig
• Se etter Tydelig avgrensning av ulike seksjoner på skjermen
• Sjekk at fonten som brukes i et program er lesbar
• Sjekk at justeringen av teksten er riktig
• Sjekk fargen på skriften og advarselsmeldingene er estetisk tiltalende
• Sjekk at bildene har god klarhet
• Sjekk at bildene er riktig justert
• Sjekk plasseringen av GUI-elementer for forskjellig skjermoppløsning.

GUI-testteknikker

Når sjekklisten er ferdig, er neste avgjørelse hvordan den skal utføres. GUI-testteknikker kan kategoriseres i tre deler:

Manuell basert testing

Under denne tilnærmingen blir grafiske skjermer kontrollert manuelt av testere i samsvar med kravene angitt i forretningskravdokumentet.

Ta opp og spill av

GUI-testing kan gjøres ved hjelp av automatiseringsverktøy. Dette gjøres i to deler. Under opptak registreres testtrinnene av automatiseringsverktøyet. Under avspilling utføres de innspilte testtrinnene på applikasjonen som testes. Eksempel på slike verktøy – QTP.

Modellbasert testing

En modell er en grafisk beskrivelse av et systems oppførsel. Den hjelper oss å forstå og forutsi systemoppførselen. Modeller bidrar til generering av effektive testtilfeller ved hjelp av systemkravene. Diagrammet nedenfor viser hvordan en modell driver testgenerering:

Følgende må vurderes for denne modellbaserte testingen:

• Bygg modellen
• Bestem innganger for modellen
• Beregn forventet effekt for modellen
• Kjør testene
• Sammenlign den faktiske produksjonen med den forventede produksjonen
• En beslutning om videre handling på modellen

Noen av modelleringsteknikkene som testtilfeller kan utledes fra:

• Diagrammer – Viser tilstanden til et system og sjekker tilstanden etter noen inndata.
• Beslutningstabeller – Tabeller som brukes til å bestemme resultater for hver inndata som brukes

Modellbasert testing er en utviklende teknikk for å generere testtilfeller fra kravene. Dens største fordel, sammenlignet med de to metodene ovenfor, er at den kan bestemme uønskede tilstander som din GUI kan oppnå.

Manuell vs. automatisert GUI-testing

To av disse tre teknikkene er manuelle og én er automatisert, noe som reiser det praktiske spørsmålet om hvor hver av dem hører hjemme. Manuell testing setter et menneske foran skjermen, slik at den fanger opp vanskelige arbeidsflyter, klønete formuleringer og animasjoner som føles feil – vurderinger ingen manus kan felle.

Automatisert testing spiller av de samme interaksjonene tusenvis av ganger uten tretthet, noe som gjør det til det rette svaret for stabile regresjonsbaner og for å gjenta én pakke på tvers av mange nettlesere. Avveiningen er vedlikehold: automatiserte GUI-skript bryter sammen når en lokator eller et layout endres. De fleste modne team kjører derfor en hybrid, automatiserer det repeterbare og reserverer folk til det erfaringsmessige.

Faktor	Manuell GUI-testing	Automatisert GUI-testing
Best for	Nye skjermbilder, utforskende kontroller, utseende og preg	Stabile regresjonspakker, kjøring på tvers av nettlesere
Hastighet per syklus	Treg, begrenset av testertimer	Rask, kjører uten tilsyn over natten
Forhåndskostnad	Lav	Høy (skripting og oppsett av rammeverk)
Vedlikehold	Ingenting utover å oppdatere sjekklisten	Viktig når grensesnittet endres
Fanger opp subjektive problemer	Ja	Nei

Eksempel på testtilfeller for GUI-testing

GUI-testing innebærer i utgangspunktet

1. Testing av størrelse, posisjon, bredde, høyde på elementene.
2. Testing av feilmeldingene som vises.
3. Tester de forskjellige delene av skjermen.
4. Testing av fonten om den er lesbar eller ikke.
5. Testing av skjermen i forskjellige oppløsninger ved hjelp av zooming inn og ut som 640 x 480, 600×800 osv.
6. Testing av justeringen av tekstene og andre elementer som ikoner, knapper osv. er på riktig plass eller ikke.
7. Tester fargene på skriftene.
8. Tester fargene på feilmeldingene, advarselsmeldingene.
9. Tester om bildet har god klarhet eller ikke.
10. Tester justeringen av bildene.
11. Testing av stavemåten.
12. Brukeren må ikke bli frustrert mens han bruker systemgrensesnittet.
13. Tester om grensesnittet er påtractiv eller ikke.
14. Testing av rullefeltene i henhold til størrelsen på siden hvis noen.
15. Testing av de deaktiverte feltene hvis noen.
16. Testing av størrelsen på bildene.
17. Testing av overskriftene om de er riktig justert eller ikke.
18. Testing av fargen på hyperkoblingen.

Demo: Hvordan gjøre GUI-test

Listen ovenfor blir mye tydeligere når den brukes på en ekte skjerm, så her skal vi bruke noen eksempler på testtilfeller for den følgende dialogen.

Nedenfor finner du et eksempel på testtilfeller, som består av brukergrensesnitt- og brukervennlighetstestscenarioer. Hvis du ikke har skrevet dem før, se hvordan skrive testtilfeller først.

Testtilfelle 01 – Bekreft at tekstboksen med etiketten «Kildemappe” er riktig justert.

Testtilfelle 02 – Bekreft at tekstboksen med etiketten «Pakke” er riktig justert.

Testtilfelle 03 – Bekreft etiketten med navnet «Søk” er en knapp som er plassert på slutten av TekstBox med navnet "Kildemappe».

Testtilfelle 04 – Bekreft etiketten med navnet «Søk” er en knapp som er plassert på slutten av TekstBox med navnet "Pakke».

Testtilfelle 05 – Bekreft at tekstboksen med etiketten «Navn” er riktig justert.

Testtilfelle 06 – Kontroller at etiketten «Modifikatorer” består av 4 radioknapper med navnet offentlig, standard, privat, beskyttet.

Testtilfelle 07 – Kontroller at etiketten «Modifikatorer” består av 4 radioknapper som er riktig justert på rad.

Testtilfelle 08 – Kontroller at etiketten «Superklasse" under etiketten "Modifikatorer” består av en rullegardin som må være riktig justert.

Testtilfelle 09 – Kontroller at etiketten «Superklasse" består av en knapp med etiketten "Søk” på den som må være riktig justert.

Testtilfelle 10 – Bekreft at standard musepeker må endres til håndmusepekeren når du klikker på en hvilken som helst radioknapp.

Testtilfelle 11 – Bekreft at brukeren ikke skal kunne skrive i rullegardinmenyen «Superklasse».

Testtilfelle 12 – Bekreft at det må genereres en riktig feilmelding hvis noe er valgt feilaktig.

Testtilfelle 13 – Bekreft at feilen må genereres i RØD farge der det er nødvendig.

Testtilfelle 14 – Kontroller at riktige etiketter må brukes i feilmeldingene.

Testtilfelle 15 – Bekreft at de enkelte alternativknappene må velges som standard hver gang.

Testtilfelle 16 – Kontroller at TAB-knappen fungerer som den skal under hopping.ping på et annet felt ved siden av det forrige.

Testtilfelle 17 – Kontroller at alle sidene inneholder riktig tittel.

Testtilfelle 18 – Kontroller at sideteksten er riktig justert.

Testtilfelle 19 – Kontroller at det vises en skikkelig bekreftelsesmelding etter oppdatering av et felt.

Testtilfelle 20 – Bekreft at bare én alternativknapp må være valgt, og at mer enn én avmerkingsboks kan være valgt.

Utfordringer i GUI-testing

Det er enkelt å skrive disse sakene;ping dem i live over flere utgivelser er ikke. Innen programvareutvikling er det vanligste problemet når man gjør Regresjonstesting er at applikasjonens GUI endres ofte. Det er veldig vanskelig å teste og identifisere om det er et problem eller forbedring. Problemet manifesterer seg når du ikke har noen dokumenter angående endringer i GUI.

⚠️ Advarsel: Skript som lokaliserer elementer etter skjermkoordinater eller automatisk genererte ID-er vil mislykkes i neste bygging. Behandle en lokaliseringsstrategi som en del av designet, ikke som en ettertanke.

GUI-testverktøy

Riktig verktøy absorberer mye av den uønskede belastningen. Følgende er en liste over populære GUI-testverktøy :

1. Selenium
2. QTP
3. Cucumber
4. SilkeTest
5. TestComplete
6. Squish GUI-tester

Klikk her for å lære Selenium, QTP & Cucumber.

Følgende er åpen kildekode-verktøy tilgjengelig for å utføre automatisert UI-test.

Produkt	Lisensiert under
AutoHotkey	GPL
Selenium	Apache
Sikuli	MIT
Robotramme	Apache
Vann	BSD
Dojo verktøysett	BSD

Sikuli er bildebasert, nyttig når en kontroll ikke har noen pålitelig lokator; Selenium forblir standard for testing av webapplikasjoner.

Spørsmål og svar