Automatiseret test
Den aktuelle version af siden er endnu ikke blevet gennemgået af erfarne bidragydere og kan afvige væsentligt fra den
version , der blev gennemgået den 30. august 2018; checks kræver
6 redigeringer .
Automatiseret softwaretest er en del af testprocessen i kvalitetskontrolfasen af softwareudviklingsprocessen . Den bruger softwareværktøjer til at køre test og kontrollere resultaterne af kørslen, hvilket hjælper med at reducere testtiden og forenkle testprocessen.
Historie
De første forsøg på "automatisering" dukkede op i DOS- og CP/M -operativsystemernes æra . Derefter bestod det i at udstede kommandoer til applikationen gennem kommandolinjen og analysere resultaterne. Lidt senere blev fjernopkald tilføjet via API'et til arbejde over netværket . Først Automatiseret test er nævnt i Frederick Brooks' bog The Mythical Man-Month , som taler om mulighederne for at bruge enhedstestning . Men virkelig testautomatisering begyndte først at udvikle sig i 1980'erne.
Tilnærmelser
Der er to hovedtilgange til testautomatisering: test på kodeniveau og test af brugergrænseflade (specifikt GUI-test). Den første type omfatter især enhedstestning . Til den anden - efterligning af brugerhandlinger - funktionel test (ved hjælp af specielle testrammer . )
GUI-automatisering
Den mest almindelige form for automatisering er applikationstest gennem en grafisk brugergrænseflade ( GUI ) . Populariteten af denne type test skyldes to faktorer: For det første testes applikationen på samme måde, som en person vil bruge den, og for det andet er det muligt at teste applikationen uden at have adgang til kildekoden.
GUI-automatisering har udviklet sig over 4 generationer af værktøjer og teknikker:
- Optagelses-/ afspilningsværktøjer registrerer testerens handlinger under manuel test . De giver dig mulighed for at udføre test uden direkte menneskelig indgriben i lang tid, hvilket øger produktiviteten betydeligt og eliminerer den "dumme" gentagelse af gentagne handlinger under manuel test. Samtidig kræver enhver lille ændring af den software, der testes, en omskrivning af de manuelle tests. Derfor er denne første generation af værktøjer ikke effektiv eller skalerbar.
- Scripting , en form for programmering på sprog, der er specielt designet til at automatisere softwaretest, afhjælper mange af problemerne med optagelses- og afspilningsværktøjer. Men udviklingen udføres af programmører på højt niveau, som arbejder adskilt fra testerne, der direkte kører testene. Derudover er scripts bedst egnede til at teste GUI'er og kan ikke injiceres, pakkes eller kombineres i et system på nogen måde. Endelig kræver ændringer af den software, der testes, komplekse ændringer af de tilsvarende scripts, og opretholdelsen af et stadigt voksende bibliotek af testscripts bliver trods alt en uoverkommelig opgave.
- Datadrevet test er en metode, der bruges i testautomatisering. Det særegne er, at testscripts udføres og verificeres på basis af data, der er lagret i et centralt datavarehus eller database. Databasens rolle kan udføres af ODBC-ressourcer, csv- eller xls-filer osv. Datadrevet test er kombinationen af flere interagerende testscripts og deres datakilder i en ramme, der bruges i metodikken. I denne ramme bruges variabler både til inputværdier og til outputtestværdier: i et testscript er navigation gennem applikationen, læsning af datakilder og logningstest normalt kodet. Så logikken, der skal udføres i scriptet, afhænger også af dataene.
- Søgeordsbaseret testautomatisering involverer opdeling af sagsoprettelsesprocessen i 2 faser: planlægningsfasen og implementeringsfasen . I dette tilfælde er den endelige test ikke en programkode, men en beskrivelse af en sekvens af handlinger med deres parametre (for eksempel "opret en bruger i databasen med login XXX og adgangskode YYY"). I dette tilfælde er rammen ansvarlig for den direkte implementering af søgeord (handlinger), og det er nok for testdesigneren at have en idé om hele sættet af handlinger implementeret i rammeværket. Dette gør det muligt at lave test for folk, der ikke har programmeringsevner.
Problemer
Et af hovedproblemerne ved automatiseret test er dens kompleksitet: på trods af, at det giver dig mulighed for at eliminere nogle af de rutinemæssige operationer og fremskynde udførelsen af tests, kan der bruges store ressourcer på at opdatere selve testene. Dette gælder for begge typer automatisering. Ved refactoring er det ofte også nødvendigt at opdatere enhedstests, og ændring af testkoden kan tage lige så lang tid som at ændre hovedkoden. På den anden side, når du ændrer applikationens grænseflade, er det nødvendigt at omskrive alle de test, der er knyttet til de opdaterede vinduer, som med et stort antal test kan optage betydelige ressourcer.
Ansøgninger
Der er mange applikationer til testautomatisering. Den mest populære af dem ifølge resultaterne fra 2007: [1]
Brug af disse værktøjer hjælper testere med at automatisere følgende opgaver:
- produkt installation
- oprettelse af testdata
- GUI interaktion
- problemdefinition
Automatiske test kan dog ikke helt erstatte manuel test. Automatisering af alle test er en meget dyr proces, og derfor er automatisk test kun et supplement til manuel test. Den bedste use case for automatiserede test er regressionstest .
Værktøjskasse
Se også
Noter
- ↑ SoftJournal 'September 2007/ SoftJournal 'September 2007 (link ikke tilgængeligt) . Hentet 12. april 2010. Arkiveret fra originalen 23. marts 2010. (ubestemt)
Links