Hvad er testautomatisering? En enkel og klar introduktion
Der findes to former for testning i softwareverdenen – manuel og automatiseret testning. Nogle typer af manuel testning, såsom opdagelsestestning og brugervenlighedstestning, er uvurderlige. Du kan udføre andre former for testning – f.eks. regressionstest og funktionel testning – manuelt, men det er en temmelig ødsel praksis for mennesker at blive ved med at gøre det samme igen og igen. Det er disse former for gentagne tests, der egner sig til automatisering af tests.
Testautomatisering er en praksis, hvor man kører tests automatisk, administrerer testdata og udnytter resultaterne til at forbedre softwarekvaliteten. Det er primært en kvalitetssikringsforanstaltning, men aktiviteterne indebærer engagement fra hele softwareproduktionsteamet. Fra forretningsanalytikere til udviklere og DevOps-ingeniører kræver det inddragelse af alle for at få mest muligt ud af testautomatisering.
Dette indlæg vil give dig en forståelse på højt niveau af, hvad testautomatisering handler om. Der findes alle slags tests, men ikke alle bør automatiseres; lad os derfor starte med generelle kriterier for testautomatisering.
Kriterier for automatisering
En test skal opfylde nogle kriterier for at blive automatiseret – ellers kan det ende med at koste mere, end det sparer. Når alt kommer til alt, er et af hovedmålene med automatisering at spare tid, kræfter og penge. Her er nogle generelle kriterier for automatisering af test. Det er startpunkter, vel at mærke. Dine kriterier kan variere alt efter dine forhold.
Gentagelig
Testen skal kunne gentages. Der er ingen mening i at automatisere en test, der kun kan køres én gang. En gentagelig test har følgende tre trin:
- Sæt testen op, herunder data og miljø.
- Udfør funktionen og mål resultatet.
- Rens data og miljø op.
I det første trin skal vi kunne sætte miljøet i en konsistent tilstand. Med andre ord, hvis vi har en test for forsøg på at tilføje en eksisterende bruger, skal vi sikre os, at brugeren eksisterer, før vi udfører testen. Når testen er afsluttet, skal miljøet returneres til grundtilstanden.
Determinant
Når en funktion er determinant, betyder det, at resultatet er det samme, hver gang den køres med det samme input. Det samme gælder for tests, der kan automatiseres. Lad os f.eks. sige, at vi ønsker at teste en additionsfunktion. Vi ved, at 1 + 1 = 2, og at 394,19 + 5,81 = 400,00. Addition er en determinantfunktion.
Software kan på den anden side bruge et så stort antal variable input, at det er svært at få det samme resultat over tid. Nogle variabler kan endda være tilfældige, hvilket kan gøre det vanskeligt at bestemme det specifikke resultat. Softwaredesign kan kompensere for dette ved at tillade testinput via et testharness.
Andre funktioner i en applikation kan være additive; f.eks. vil oprettelse af en ny bruger føje til antallet af brugere. Når vi tilføjer en bruger, ved vi i det mindste, at antallet af brugere kun må vokse med én. Hvis test udføres parallelt, kan det dog give uventede resultater. Isolation kan forhindre denne form for falske positive resultater.
Uopfattet
Du kan ikke automatisere spørgsmål om meninger. Det er her, hvor brugervenlighedstest, betatest osv. virkelig brillerer. Brugerfeedback er vigtigt, men det kan bare ikke automatiseres … beklager!
Typer af automatiserede tests
Der er så mange typer af tests, hvoraf mange kan automatiseres, at vi ikke rigtig kan få dem alle med i ét indlæg. Men her er nok til at give dig et godt udgangspunkt.
Kodeanalyse
Der findes faktisk mange forskellige typer af kodeanalyseværktøjer, herunder statisk analyse og dynamisk analyse. Nogle af disse tests kigger efter sikkerhedsfejl, mens andre tjekker stil og form. Disse tests kører, når en udvikler tjekker kode ind. Ud over at konfigurere regler og holde værktøjerne opdateret er der ikke meget testskrivning at gøre med disse automatiserede tests.
Unit Tests
Du kan også automatisere en unit test suite. Unit-tests er designet til at teste en enkelt funktion, eller en enhed, af en operation isoleret. De kører typisk på en buildserver. Disse tests er ikke afhængige af databaser, eksterne API’er eller filopbevaring. De skal være hurtige og er designet til kun at teste koden og ikke de eksterne afhængigheder.
Integrationstests
Integrationstests er en anden slags dyr, når det kommer til automatisering. Da en integrationstest – som nogle gange kaldes end-to-end-test – skal interagere med eksterne afhængigheder, er de mere komplicerede at opsætte. Ofte er det bedst at oprette falske eksterne ressourcer, især når der er tale om ressourcer uden for din kontrol.
Hvis du f.eks. har en logistik-app, der er afhængig af en webtjeneste fra en leverandør, kan din test fejle uventet, hvis leverandørens tjeneste er nede. Betyder det, at din app er i stykker? Det kan det måske, men du bør have tilstrækkelig kontrol over hele testmiljøet til at oprette hvert scenarie eksplicit. Du må aldrig være afhængig af en ekstern faktor til at bestemme resultatet af dit testscenarie.
Automatiserede accepttests
Der er flere metoder i dag, der anvender automatiserede accepttests (AAT), men de gør grundlæggende det samme. Adfærdsdrevet udvikling (BDD) og automatiseret accept testdrevet udvikling (AATDD) ligner hinanden. De følger begge den samme praksis med at oprette accepttesten, før funktionen udvikles.
I sidste ende kører den automatiserede accepttest for at afgøre, om funktionen leverer det, der er aftalt. Derfor er det afgørende for udviklere, forretningen og QA at skrive disse tests sammen. De fungerer som regressionstests i fremtiden, og de sikrer, at funktionen holder det forventede.
Regressionstests
Men uden AAT’er på plads er du nødt til at skrive regressionstests efterfølgende. Selv om begge er former for funktionelle tests, er der stor forskel på, hvordan de skrives, hvornår de skrives, og hvem der skriver dem, og hvem der skriver dem. Ligesom AAT’er kan de styres gennem et API af kode eller en brugergrænseflade. Der findes værktøjer til at skrive disse tests ved hjælp af en GUI.
Præstationstest
Der findes mange former for præstationstest, men de tester alle et eller andet aspekt af en applikations ydeevne. Vil den kunne holde til ekstremt pres? Testes systemet for høj varme? Er det simpel responstid under belastning, vi er ude efter? Hvad med skalerbarhed?
I nogle tilfælde kræver disse test at emulere et stort antal brugere. I dette tilfælde er det vigtigt at have et miljø, der er i stand til at udføre en sådan bedrift. Cloudressourcer er tilgængelige til at hjælpe med denne form for test, men det er også muligt at bruge on-premises ressourcer.
Røgetest
Hvad er en røgtest? Det er en grundlæggende test, der normalt udføres efter en implementering eller et vedligeholdelsesvindue. Formålet med en røgtest er at sikre, at alle tjenester og afhængigheder er oppe og kører. En røgtest er ikke beregnet til at være en fuldstændig funktionel test. Den kan køres som en del af en automatiseret implementering eller udløses gennem et manuelt trin.
Generel proces for automatisering af test
Nu da vi har set kriterier for automatisering og nok typer af automatiserede test til at have en fornemmelse af tingene, er her den generelle proces for automatisering af test. Der er tre hovedtrin i testautomatisering: forberedelse, handling, rapportering af resultater.
Forberedelse
Først skal vi forberede tilstanden, testdataene og det miljø, hvor testene finder sted. Som vi har set, kræver de fleste tests, at miljøet skal være i en bestemt tilstand, før en handling finder sted. I et typisk scenarie kræver dette en vis opsætning. Enten skal dataene manipuleres, eller applikationen skal sættes i en bestemt tilstand eller begge dele!
Take Action
Når tilstanden og/eller miljøet er i den foruddefinerede tilstand, er det tid til at tage action! Testdriveren vil køre testen, enten ved at kalde en applikations API eller brugergrænseflade eller ved at køre koden direkte. Testdriveren er ansvarlig for at “køre” testene, men teststyringssystemet tager ansvaret for at koordinere alt, herunder rapportering af resultater.
Rapportere resultater
Et testautomatiseringssystem vil registrere og rapportere resultater. Disse resultater kan komme i en række forskellige formater og kan endda skabe problembilletter eller fejl i et arbejdssporingssystem. Det grundlæggende resultat er dog et bestået eller ikke bestået. Normalt er der en grøn eller rød indikator for hvert testscenarie for at angive bestået eller mislykket.
Sommetider er testene ufyldestgørende eller kører ikke af en eller anden grund. Når dette sker, vil automatiseringssystemet have en fuld log over output, som udviklerne kan gennemgå. Denne log hjælper dem med at opspore problemet. Ideelt set vil de være i stand til at afspille scenariet igen, når de har sat en rettelse i værk.
Bottom line
Bottom line er dette: Testautomatisering hjælper med at forbedre kvaliteten med hastighed. Men ikke alle test kan automatiseres. Der er helt sikkert en investering involveret. Med så mange typer af test er det vigtigt, at du får den rigtige blanding. Testpyramiden er en simpel tommelfingerregel til at hjælpe med at få dette rigtigt. Den siger, at de fleste tests bør være enhedstests, efterfulgt af servicetests og derefter UI-tests.
Et testautomatiseringssystem koordinerer testproblemer, herunder håndtering af testdata, afvikling af tests og sporing af resultater. Testautomatisering er det næste skridt for teams, der er ved at blive overvældet af byrden ved at gentage de samme manuelle tests, som burde automatiseres.
Author bio: Dette indlæg blev skrevet af Phil Vuollet. Phil bruger software til at automatisere processer for at forbedre effektiviteten og gentageligheden. Han skriver om emner, der er relevante for teknologi og forretning, holder lejlighedsvis foredrag om de samme emner, og han er en familiefar, der nyder at spille fodbold og brætspil med sine børn.