Lederskab inden for test: Værktøjer til testkørsel

Automatisering af test (testudførelse)

Emnet testautomatisering (som regel via en grafisk brugergrænseflade) står højt på de fleste testeres og testansvarliges dagsorden. Ved første øjekast ser disse værktøjer ud til at rumme store muligheder, men mange organisationer, der ønsker at automatisere noget af eller hele deres funktionelle test, støder på problemer.

Vi går ikke i for mange tekniske detaljer i denne artikel, men vi berører nogle af de problemstillinger, der er relevante for test- og projektledere, som skal udarbejde en forretningscase for automatisering. Vi ser på:

• Hvad du får og ikke får med værktøjer til testudførelse
• Testautomatisering af grafisk brugergrænseflade (GUI)
• Testautomatisering af API'er og tjenester
• Regressionstest
• Testautomatiseringsrammer

Det er vigtigt at have realistiske forventninger til, hvad automatisering kan og ikke kan, så de næste afsnit kan måske virke noget pessimistiske.

Hvad du får og ikke får med værktøjer til testudførelse

Uanset om du tester Windows-skrivebordsprogrammer, websteder eller mobile enheder, er principperne for testautomatisering samt fordelene og faldgruberne de samme. Det, du får med værktøjer, er:

• En utrættelig, angiveligt fejlfri robot, der efter behov og så ofte, du ønsker det, kan køre de skriptbaserede tests, du vil.
• En præcis sammenligning mellem testenes resultater og/eller udfald og de forberedte forventede resultater på det detaljeringsniveau, du er villig til at programmere ind i værktøjet.

Det, du ikke får, er:

• Fleksibilitet og smidige reaktioner på anomalier, fejl eller tvivlsom adfærd.
• En menneskelig testers øjne og tænkning, som er i stand til at træffe beslutninger om at udforske, stille spørgsmål, eksperimentere med og udfordre det system, der testes.
• Gratis tests. Du skal for eksempel stadig designe tests samt forberede testdata og forventede resultater.
• Selvom værktøjer til testudførelse tilbyder en række funktioner, mangler de ofte avancerede funktioner til datalagring. Hvis du ønsker en mere omfattende løsning, kan du udforske den bedste tilgængelige software til databaseadministration.

Lad os se nærmere på betydningen af disse fordele og problemer.

Hvis du er en rimeligt kompetent programmør, er det ligetil at implementere procedurebaserede tests, der udføres af mennesker, som automatiserede procedurer i dit værktøjs scriptsprog, så værktøjet kan udføre dem præcist.

Så længe det miljø og de data, der bruges af din testapplikation, er konsistente, kan du forvente, at dine tests kører pålideligt igen og igen. Dette er det indlysende løfte ved automatiseret testudførelse.

Men automatiserede tests simulerer ikke præcist, hvad (gode) testere gør, når de tester.

En test, der køres af et værktøj, er IKKE det samme som den samme test, der køres af et menneske.

Hvis en test er skrevet som et script, fortæller den måske testeren, hvad vedkommende skal gøre. Men testere kan se ud over den simple sammenligning mellem et forventet resultat og det resultat, der vises på en skærm.

Testere skal navigere til testens placering og være opmærksomme på unormal adfærd – kommandoernes reaktioner, reaktionernes hastighed, skærmens udseende og adfærden hos de objekter, der påvirkes af applikationens skiftende tilstand.

Den menneskelige tester kan, når vedkommende observerer en anomali, sætte på pause, gå sine trin efter igen eller se nærmere på applikationen eller dataene, før han eller hun konkluderer, at applikationen fungerer korrekt (eller ej), og beslutter, om den skriptbaserede test skal fortsætte, om testens data og script skal justeres, eller om testen skal fortsætte som planlagt.

Mennesker er fleksible, hvorimod værktøjer kun gør præcis det, du programmerer dem til. I en skærmbaseret transaktion indtaster værktøjet data, klikker på en knap og kontrollerer, om der vises en meddelelse eller et resultat – og det er alt. Med menneskelige testere får du så meget mere, som vi tager for givet. 

I princippet er det muligt at programmere et værktøj til at udføre alle de kontroller, som et menneske udfører instinktivt – men du skal skrive en masse kode og bruge tid på at fejlfinde dine tests. Selv da får du ikke menneskets evne til at beslutte, hvad der skal gøres som det næste – at holde pause, fortsætte, ændre testen undervejs eller undersøge en anomali mere grundigt.

Ingen steder er værktøjers ufleksibilitet mere tydelig end ved reaktion på, at synkroniseringen mellem testskriptet og systemet under test går tabt. Måske stemmer et forventet resultat ikke overens, systemet går ned, eller brugergrænsefladens adfærd (for eksempel en ændret rækkefølge af felter eller et nyt felt) afviger fra det, testskriptet forventer. Hvad gør værktøjet? Det forsøger at fortsætte, og en strøm af scriptfejl eller nedbrud følger. 

Ja, du kan og bør have håndteringer af uplanlagte hændelser i dit script for at opfange testfejl. Tab af synkronisering, uoverensstemmelser mellem systemtilstand og testdata, ændringer i rækkefølgen af felter, nye felter eller fjernede felter er ting, som testeren kan genkende og reagere på, uden at testningen går i stå. Værktøjer kan ikke gøre dette uden en stor programmeringsindsats fra din side.

Der er også ulemper ved at bruge mennesker til at følge skripter med tests. Testere kan blive besatte af at følge testskriptet og glemme at bruge deres observationsevner. De overser måske åbenlyse anomalier, fordi de koncentrerer sig om at følge testskriptet. Denne mindre optimale tilgang er præcis det, vi får fra automatisering af testudførelsen.

Blind overholdelse af testskripter er en dårlig idé for menneskelige testere, men det er det bedste, vi kan gøre med testautomatisering.

I denne sammenligning af testere, der følger skripter, og værktøjer, der kører tests, har vi ikke taget højde for, hvad eksplorative testere gør. Den eksplorative tilgang giver testere frihed til at undersøge og teste, hvor og hvordan de vil. 

Det er tydeligt, at værktøjer ikke kan simulere denne aktivitet. Endnu vigtigere er det, at værktøjer ikke kan afgrænse, prioritere og modellere et systems funktionalitet og risici samt designe tests i overensstemmelse hermed.

Testanalyse og testdesign er nødvendige aktiviteter, uanset om en test udføres af et menneske eller et værktøj.

Der er yderligere begrænsninger for, hvad værktøjer til testudførelse kan gøre:

• Værktøjer til testudførelse gør præcis det, du programmerer dem til – hverken mere eller mindre
• Værktøjer udfører normalt ikke opbygning og konfiguration af miljøer og applikationer eller indlæsning af testdata
• Værktøjer designer ikke testtilfælde eller skripter og forbereder ikke testdata og forventede resultater
• Værktøjer kan ikke træffe velovervejede beslutninger, når der opstår uventede hændelser.

Hvis du vil optimere dine testudførelsesprocesser, kan integration med robust software til teststyring give mere effektive arbejdsgange og forbedret rapportering.

Testautomatisering af grafiske brugergrænseflader (GUI)

Det er omkring femogtyve år siden, værktøjer til GUI-testautomatisering kom på markedet, men antallet af mislykkede implementeringer af GUI-testværktøjer er stadig højt. Det skyldes hovedsageligt, at forventningerne til automatisering sættes for højt – og værktøjer, der bruges uden disciplin, vil aldrig leve op til dem.

Værktøjer til GUI-testautomatisering har ry for at være nemme at bruge som produkter, men vanskelige at administrere, når de applikationer, der testes (og dermed testskripter), skal ændres. Disse værktøjer er meget følsomme over for ændringer i brugergrænsefladen. Ændringer i skærmobjekters placering, rækkefølge og størrelse samt tilføjelse eller fjernelse af skærmobjekter kan alle påvirke skripter. Mere tekniske ændringer, såsom omdøbning af skærmobjekter eller ændring af ‘usynlige’ indlejrede GUI-biblioteker, giver også problemer.

GUI-testautomatisering fungerer bedst, når der er disciplin omkring:

• Udviklingsprocessen samt ændringer og udgivelser håndteres omhyggeligt. For eksempel analyseres ændringers påvirkning, og testere underrettes. 
• Tilgangen til udvikling af testskripter. Erfarne testautomatiseringsingeniører anvender systematiske navngivningskonventioner, mappestrukturer, modulære og genanvendelige komponenter, defensive programmeringsteknikker og så videre.

Udvikling af skripter til testautomatisering er en opgave, der kræver mere end grundlæggende programmeringsfærdigheder og frem for alt erfaring med automatisering og det anvendte værktøj. Når tests automatiseres i stor skala, er der også behov for designfærdigheder. 

Uanset hvordan leverandører beskriver værktøjer – “uden skripter”, “kan bruges af ikke-programmører” eller “brugere kan også automatisere” – har du stadig brug for en programmørs tankegang, designfærdigheder og en systematisk tilgang.

Testautomatisering af API'er og tjenester

Hvor der findes komponenter eller funktionalitet, der er implementeret som tjenester og kaldes af tynde klienter eller mobilklienter, udføres testningen ved hjælp af en API eller via tjenestekald. Denne testform udføres enten ved hjælp af specialudviklet kode skrevet af udviklere eller ved hjælp af dedikerede værktøjer til API- eller tjenestetest. Under alle omstændigheder er den sædvanlige tilgang at automatisere testningen på den ene eller anden måde.

Fordi API'et er ‘tættere’ på den kode, der skal testes, kan testene være langt mere fokuserede på den funktionalitet, der skal testes. Kompleksiteten ved navigation gennem brugergrænsefladen og selve testningen gennem brugergrænsefladen kan naturligvis omgås. Derfor er den generelle regel:

Hvis den funktionalitet, der testes (på kode- eller komponentniveau), kan testes med et funktionskald, et API eller et servicekald, bliver automatisering lettere – og anbefales.

Test gennem API'et har klare fordele.

• Selvom du skal bruge eller skrive kode, bliver selve testene meget lettere at anvende (der er ingen brugergrænseflade at tage hensyn til).
• Når et API-kald først er skrevet som et script, handler det blot om at opstille det udvalg af testcases, du vil anvende. Der er ingen begrænsning på antallet af tests, du kan udføre.
• API-baserede tests kører normalt meget hurtigere, hvilket gør denne testform velegnet til tilgange med kontinuerlig levering, hvor implementeringspipelinen er stærkt automatiseret og skal kunne reagere hurtigt.

‘Pyramiden for testautomatisering’ (en Google-søgning vil vise hundredvis af eksempler på grafikken) er næsten universelt blevet taget i brug for at præsentere anbefalingen om, at indsatsen for testautomatisering i højere grad bør fokusere på udvikler- eller API-test end på test gennem den grafiske brugergrænseflade.

• Brug UI-tests, når brugerens arbejdsgang skal afprøves, men i et begrænset omfang, fordi tests er dyre og kan være langsomme at køre.
• Brug API- eller servicekald, når den funktionalitet, der testes, kan isoleres, og når hastighed og nem automatisering er afgørende.

Regressionstest

Den klassiske anvendelse af automatiserede værktøjer er udførelsen af regressionstests. Disse tests køres én gang og betragtes som nøjagtige gengivelser af den forventede adfærd. Når enten applikationskoden, der testes, tilknyttede genanvendelige biblioteker eller testmiljøet ændres, giver disse tests en vis sikkerhed for, at den nødvendige funktionalitet ikke er blevet påvirket negativt af ændringen.

Du kan forestille dig de automatiserede tests som en form, som systemet under test skal passe ind i. Testene bør naturligvis ‘bestå’ alle de kontroller, der tidligere blev udført. Ved at køre dem igen forsøger du at demonstrere funktionel ækvivalens mellem den nye softwareversion og den tidligere version. Der er nogle enkle principper, du skal følge:

• For det første skal de udførte tests og kontroller udvælges, så de giver dig tillid til, at uønskede ændringer i adfærden ikke er til stede. Disse tests fungerer som en ‘snubletråd’, der opdager forskelle i adfærden.
• Når fejl rettes, eller der foretages andre softwareændringer, kan der være tilfælde, hvor adfærd ændres (korrekt), men hvor dine tests fejler en kontrol, når de møder den ændrede adfærd. Enten skal du ændre dine tests på forhånd eller lade dem fejle og rette dem bagefter. Nogle gange er det hurtigere helt at fjerne de fejlslagne tests og oprette nye tests fra bunden som erstatning. Under alle omstændigheder skal disse ændrede tests derefter køres til ende og bestå.
• Hvis systemet under test ikke er stabilt, har mange fejl eller gennemgår omfattende ændringer mellem udgivelser, er det muligvis ikke økonomisk gennemførligt at vedligeholde et sæt automatiserede tests. Selvom systemets funktionalitet ikke ændrer sig, kan brugergrænsefladen stadig være under udvikling – en ustabil UI gør også automatisering sværere at vedligeholde. Omkostningerne ved at undersøge testfejl og vedligeholde tests kan overstige deres nytte. Det kan være klogt at teste de mindre stabile dele af systemet manuelt, indtil de er blevet stabile.

Test gennem brugergrænsefladen kan til tider være besværlig, dyr og langsom at udføre. Før du går i gang med testautomatisering af GUI'en eller automatiserer blot ét script, er det fornuftigt at overveje, om test af den vigtigste funktionalitet ville være lettere, hurtigere og mere økonomisk ved hjælp af et API.

Den klassiske anvendelse af automatiserede værktøjer er udførelsen af regressionstests. Se vores liste over de bedste værktøjer til softwaretest for at sikre, at du bruger de mest effektive værktøjer til dette.

Rammer til testautomatisering

Test-rammer er en vigtig del af enhver vellykket automatiseret testproces. Tænk på dem som et sæt retningslinjer, der bruges til at oprette og designe testcases. Brug af dem kan øge dit testteams hastighed og effektivitet, forbedre testnøjagtigheden, mindske risici og reducere omkostningerne til testvedligeholdelse. Lad os nu se på to af disse.

Når man diskuterer rammer til testautomatisering, er det vigtigt at overveje den rolle, som værktøjer til QA-automatisering spiller i udformningen af en effektiv teststrategi.

Enhedstest-rammer

Enhedstest-rammer har eksisteret i flere år og bruges i vid udstrækning af programmører til at teste deres kode. Udviklertests har en tendens til at være ret lokaliserede – de tester trods alt normalt en enkelt komponent, hvor grænseflader til andre komponenter eller databaser er simuleret eller erstattet af stubbe. Selvom enhedstests derfor kræver opsætnings- og nedlukningstrin før og efter testkørslerne, er disse opgaver typisk begrænset til at køre tests af en enkelt komponent. Der vil være separate testsamlinger for hver komponent.

Enhedstests, der oprettes af udviklere, er normalt versionsstyrede og administreres parallelt med komponentkoden. Typisk tager faciliteter til kontinuerlig integration kildekoden og alle enhedstests og kører dem efter hver commit af ny kode og/eller nye tests. Alle udviklere kan se resultatet af disse tests, så en testfejl i CI bliver meget synlig. Det har høj prioritet i teams, der bruger CI på denne måde, at rette fejl i tests og kode, så den seneste version af systemet altid består alle CI-tests.

Rammer til automatisering af integrations- og systemtests

I de senere år er GUI-testværktøjer blevet integreret med CI-værktøjer ved hjælp af virtualiserede testenheder, miljøer og kørsel via kommandolinjegrænseflader. Mange organisationer har været i stand til fuldstændigt at integrere kørsel af enheds-, API-tests og GUI-tests gennem CI-tjenester.

Mange testteams driver dog stadig deres egne testmiljøer adskilt fra udviklings- eller CI-tjenester. Disse teams har en tendens til at opbygge deres egne rammer til testautomatisering, fordi CI-værktøjer er for udviklerorienterede, eller fordi proprietære værktøjer er utilstrækkelige.

GUI-tests har en tendens til at implementere ende-til-ende-tests eller brugerrejser ved hjælp af forskellige applikationer, hardwareenheder og miljøer. Disse tests skal problemfrit opsætte integrerede testmiljøer og forberedte testdata på forskellige platforme, og det kræver privilegerede, komplekse procedurer samt varierede tekniske miljøer at få dem til at fungere. Langt de fleste teams, der bruger GUI-testautomatisering, opbygger deres egne unikke, men effektive, rammer til automatisering.

Rammer til GUI-automatisering varierer i kompleksitet fra værktøjer, der minder om enhedstestværktøjer, til komplekse og omfattende faciliteter, der kræves for at administrere miljøer, applikationsbygninger, enorme mængder testdata, meddelelser og synkronisering på tværs af platforme og miljøer samt meddelelser og notifikationer til teammedlemmer.

Nogle proprietære værktøjer leveres med hjælpeprogrammer eller testseler til at administrere, udføre og rapportere fra suiter af automatiserede tests. Disse har varierende værdi, så mange organisationer skriver deres egne rammer til testautomatisering for at udvide deres funktionalitet. I de senere år er rammernes anvendelsesområde vokset, og der findes ikke længere en enkelt eller enkel definition, så lad os nu se på, hvad rammer til testautomatisering kan gøre for softwareteams.

En ramme til testautomatisering udvider funktionaliteten i testudførelsesmotorer.

Konfiguration af testsuite

Rammen integrerer automatiserede tests i meningsfulde samlinger eller klynger af tests. Disse samlinger kan konfigureres, så tests kan køres i et hierarki af sekvenser, grupper eller vilkårlige udvalg. Disse værktøjer kan omfatte funktioner til datadrevne tests ved hjælp af forberedte tabeller med testdata. Dette er den enkleste form for ramme — populære værktøjer tilbyder normalt en eller anden form for konfiguration af testsuiter.

Opsætning og nedlukning

Rammen håndterer alle opsætnings- og nedlukningsaktiviteter for en enkelt test, samling eller hel suite. Opsætning kan indebære oprettelse af testmiljøer fra bunden, fuldstændige konfigurationer samt indlæsning af testdatabaser og andre datakilder fra bunden. Nedlukning kan omfatte oprydning i testdata eller nulstilling eller sletning af delvise eller komplette miljøer. Rammen kan integreres med orkestreringsværktøjer til pipelines og være underlagt deres kontrol.

Håndtering af undtagelser

En fejl i en test – uanset om den forekommer i systemet under test eller skyldes manglende synkronisering – kan håndteres ensartet ved at rapportere hændelsen og normalt tillade, at de resterende tests i samlingen fortsætter med at køre. Rammen kan programmeres til at håndtere fejl i testkontroller, manglende synkronisering, tidsudløb under kørsel og andre udvalgte testresultater – hvert med tilpassede procedurer.

Logning og meddelelser

Rammen logger testkørsel og kørselsstatus ensartet på tværs af alle testsamlinger. Rammen udløser enten rapporter fra de værktøjer, der udfører tests, eller leverer en ensartet rapporteringsjournal over al opsætning, udførelse og nedlukning af tests. Rammen kan interagere med ChatOps-bots for at informere teamet om undtagelser og give teammedlemmer mulighed for at sætte testsuiter på pause, stoppe, gentage eller genstarte dem.

Testabstraktion med domænespecifikt sprog

Der er opstået to forskellige typer rammer på markedet, som abstraherer kode til testudførelse til modeller eller menneskeligt læselig eller ikke-teknisk tekst:

• Rammer baseret på nøgleord gør det muligt at definere tests ved hjælp af nøgleord. Kald til funktionerne i udførelsesmotoren implementeres som engelsklignende kommandoer med pladsholdere for parametre eller data. Brugerdefinerede, genanvendelige moduler kan defineres og kaldes ved hjælp af almindelige tekstkommandoer på samme måde. Der findes rammer til alle former for grænseflader, herunder GUI, tjenester, API'er, kommandolinjefortolkere og så videre. Scripts kan afprøve funktionalitet på tværs af forskellige operativsystemer og enhedsplatforme.
• Rammer til adfærdsdrevet udvikling (BDD) gør det muligt at registrere historier og scenarier (eksempler), der beskriver funktioners adfærd, ved hjælp af et domænespecifikt sprog (DSL). Det mest populære sprog er det såkaldte Gherkin, som bruger sprogstrukturen “given … when … then …” til at registrere eksempler. Strukturen given/when/then repræsenterer effektivt forudsætninger, trin og efterbetingelser for testtilfælde. BDD-værktøjer konverterer teksten med given/when/then til funktionskald i et programmeringssprog. Udvikleren (eller testeren) skal implementere testfiksturerne eller koden, der foretager kald til en testudførelsesmotor. På denne måde kan kravets sprog (historien) forbindes direkte med koden til testudførelsen.

Modelbaserede rammer

I dette tilfælde gør værktøjer det muligt at oprette en model af systemet under test. Den kan være automatisk afledt af en webside, hvor værktøjet scanner HTML-koden, registrerer formularer og felter og opbygger en model, hvorfra stier gennem formularerne enten kan genereres automatisk eller udvælges af testeren. Objektkort til mobilapps eller andre intelligente enheder kan også opbygges manuelt. Ved hjælp af stierne gennem objektkortet foretages kald til funktionerne i testudførelsesmotoren på en måde, der minder om BDD- og nøgleordsdrevne værktøjer. I princippet kan tests opbygges grafisk uden kode. Værktøjer inden for dette område er relativt nye og forbedres hurtigt. Forvent, at deres anvendelse vil accelerere i fremtiden.

Tilmeld dig The QA Leads nyhedsbrev for at få besked, når nye dele af serien udkommer. Disse indlæg er uddrag fra Pauls kursus i ledelse inden for test, som vi varmt anbefaler, hvis du ønsker at gå mere i dybden med dette og andre emner. Hvis du gør det, kan du bruge vores eksklusive kuponkode QALEADOFFER og få $60 i rabat på den fulde kursuspris!

Relateret læsning: 10 BEDSTE VÆRKTØJER TIL OVERVÅGNING AF WEBSERVERE