Inkrementel test i softwaretest er en metode, der giver teams mulighed for at nedbryde individuelle moduler, teste dem isoleret og integrere dem i etaper. Det hjælper med at finde fejl tidligt, reducerer kompleksiteten og øger testdækningen.
I denne artikel dykker vi ned i inkrementel test, forklarer, hvad det er, og udforsker de forskellige typer, processer, tilgange, værktøjer og meget mere, der er forbundet med denne nyttige metode.
Hvad er inkrementel testning?
Test er en af de vigtigste faser i softwareudviklingens livscyklus (SDLC). Ligesom med SDLC er test opdelt i forskellige logiske trin. Inkrementel test er en af disse faser, og den finder typisk sted i løbet af
integrationstest
og lige efter
enhedstest
.
Inkrementel testning er en pragmatisk tilgang til softwaretest, der opdeler store eller komplekse programmer i håndterbare, mundrette bidder. I stedet for at integrere og teste et helt softwaresystem på én gang, ser inkrementel test på moduler og implementerer en trinvis verificeringsproces.
Softwaremoduler er typisk selvstændige enheder af kode, der udfører specifikke opgaver eller funktioner. Hvor granulære disse moduler er, afhænger af forskellige faktorer, såsom kodningspraksis, udviklingsmetoder eller endda det programmeringssprog, du bruger.
Moduler testes uafhængigt af hinanden under unit testing. Derefter, under integrationstesten, integreres hvert modul stykke for stykke – eller i trin. Denne proces sikrer, at hvert modul fungerer godt sammen. Men for at verificere hvert modul fuldt ud, er testerne nødt til at simulere komponenter, der endnu ikke er implementeret, eller eksterne systemer. For at gøre dette har de brug for hjælp fra stubbe og drivere.
Hvad er stubs og drivers i inkrementel test?
Stubs og drivere er vigtige værktøjer til softwaretest. Disse midlertidige kodestykker bruges under integrationstest, fordi de giver teams mulighed for at efterligne adfærd og grænseflader for forskellige moduler eller komponenter.
1. Stubbe:
Stubs efterligner moduler, der endnu ikke er udviklet, og som derfor ikke er tilgængelige for test. De gør det muligt for modulet under test (MUT) at kalde på ufuldstændige moduler. Resultatet er, at MUT’en kan testes isoleret, selv når relaterede moduler ikke er tilgængelige.
2. Chauffører:
Drivere simulerer på den anden side opførslen af moduler, der kalder MUT. I testmiljøet kan disse drivere sende MUT-testdataene. Igen gør dette det lettere at teste moduler isoleret uden behov for eksterne afhængigheder.
Brug af stubs eller drivere reducerer udviklingstiden, forbedrer kodekvaliteten og øger teamets produktivitet. Men beslutningen om, hvilken man skal bruge, afhænger af, hvilken testmetode der er mest hensigtsmæssig. Vi vil uddybe dette i et afsnit nedenfor, der handler om de forskellige typer af inkrementel integrationstest.
Forskellige typer af inkrementel
Integrationstest
Inkrementelle testtyper kan groft inddeles i tre kategorier. Lad os udforske hver enkelt.
1. Top-down inkrementel integration
Top-down inkrementel integration starter med at teste de højest rangerende moduler i et system. Derfra integrerer og tester den gradvist moduler af lavere orden.Der er to hovedscenarier, hvor top-down inkrementel integration anvendes. Det er de:
- Når et system er meget stort eller meget komplekst
- Når udviklingsteamet arbejder på mange moduler på samme tid.
Trin til inkrementelle top-down-integrationer
- Identificer kritiske moduler
- Opret stubbe for at efterligne moduler af lavere orden
- Udvikle drivere til at interagere med de overordnede moduler for at sende dem data og fortolke modulets output.
- Unit-test af kritiske moduler med drivere og stubs
- Integrer moduler af lavere orden og udskift gradvist stubs med rigtige implementeringer
- Refaktorering af drivere, så de passer til de nye moduler
- Gentag, indtil alle moduler af lavere orden er integreret og testet.
2. Trinvis integration nedefra og op
Bottom-up inkrementelle integrationer går i den modsatte retning. Med denne tilgang testes systemets laveste (eller mindst kritiske) moduler, mens højere moduler gradvist tilføjes. Denne tilgang er velegnet i forskellige scenarier, f.eks:
- Når du har med mindre systemer at gøre
- Når et system er modulariseret
- Når du er bekymret for enten nøjagtigheden eller fuldstændigheden af stubbe.
Trin til trinvis integration nedefra og op
- Identificer moduler af lavere orden
- Unit-test af moduler af lavere orden for at verificere deres individuelle funktionalitet
- Udvikle drivere til at fungere som mellemled med moduler af lavere orden
- Opret stubbe for at simulere opførslen af moduler af højere orden
- Integrer de næste moduler, fra lavere til højere orden, og erstat gradvist stubs med rigtige implementeringer.
- Refaktorering af drivere, så de passer til de nye moduler
- Gentag, indtil alle moduler af højere orden er integreret og testet.
3. Funktionel inkrementel integration
Inkrementel integrationstest af funktioner er den næste almindelige type inkrementel test i softwaretest. Mens de to foregående typer fokuserede på moduler af højere og lavere orden, er funktionel inkrementel test baseret på funktionaliteten af et bestemt modul.
Funktionel inkrementel integration bruges i
Agile/DevOps-metodologier
og det er et fremragende valg til applikationer med komplekse afhængigheder mellem moduler eller komponenter.
Trin til funktionel inkrementel integration
- Identificer individuelle moduler og komponenter med veldefinerede grænseflader
- Verificer funktionaliteten af hvert modul via unit testing
- Integrere de mest minimale kernemoduler i systemet og sikre, at det fungerer.
- Tilføj gradvist enkelte moduler, og test funktionaliteten ved hvert trin.
- Refaktorér koden, efterhånden som hvert modul tilføjes
- Når alle moduler er tilføjet, testes funktionalitet og ydeevne.
Fordele og ulemper ved en inkrementel testmetode
Nu burde du have en idé om, hvorfor inkrementel test er en populær tilgang. Men som alle softwaretestmetoder har den sine fordele og ulemper. Lad os se nærmere på nogle af disse fordele og ulemper.
Fordele ved en inkrementel testtilgang
1. Fleksibilitet
Som alle softwareudviklere og testere kun alt for godt ved, kan kravene ændre og udvikle sig i løbet af SDLC, nogle gange ret dramatisk. Inkrementel testning er dynamisk nok til, at teams kan tilpasse sig under testprocessen og indarbejde nye planer og retninger.
2. Tidlig opdagelse af fejl
Det bedste tidspunkt at opdage en fejl eller defekt er så tidligt som muligt. Når udviklere verificerer små moduler enkeltvis, er det langt lettere at identificere og løse problemer. Desuden mindsker det sandsynligheden for, at der opstår store problemer sent i udviklingen.
3. Enkelhed
Softwaretest kan være en meget kompleks proces. Et af de mest overbevisende aspekter ved inkrementel test er, hvordan den opdeler testbyen i brugbare dele. I stedet for at håndtere en overvældende kompleksitet kan testerne fokusere på og endda prioritere bestemte moduler. Denne fordel er en guds gave til store og komplekse applikationer.
4. Lavere risiko for regression
Regression er et tidskrævende og komplekst problem inden for softwareudvikling. Inkrementel test kan mindske hyppigheden af og risikoen ved regression, fordi det giver teams mulighed for at teste moduler individuelt og håndtere problemer, efterhånden som de opstår. Når det bruges med fast
regressionstest
kan teams spare en masse tid og besvær.
5. Muligheder for feedback
En ofte overset fordel ved inkrementel test er, at det giver teams råderum til at sammensætte prototyper og MVP’er. Derfra kan interessenter og investorer vurdere den grundlæggende funktionalitet i processen og give uvurderlig feedback. Denne situation kan spare en masse tid og penge og føre til mere robuste produkter.
Ulemper ved en inkrementel testtilgang
1. Spørgsmål om integration
Det er ønskeligt at teste moduler separat, fordi det deler en kompleks applikation op i håndterbare bidder. Integrationen af disse moduler kan dog resultere i nye og uventede fejl. Derfor skal en trinvis testtilgang planlægges omhyggeligt og bevidst.
2. Testpakkens kompleksitet
Med flere testcases for hvert modul og deres respektive interaktion med hinanden, kan testsuiter blive komplekse at spore og administrere. For store og komplicerede apps gør dette grundig dokumentation eller teststyringsværktøjer til en nødvendighed.
3. Mere arbejde
Monolitisk testning er mere kompleks, men kræver mindre testning. Ved at teste mange moduler hver for sig kræver inkrementel test mere arbejde. Men fordelene ved inkrementel testning, som f.eks. tidlig opdagelse af fejl, betyder, at den ekstra indsats er en tidsbesparende investering. Naturligvis,
automatisering af softwaretest
kan hjælpe med at reducere denne indsats.
4. Øgede krav til ledelsen
Inkrementel testning kræver, at flere teams arbejder sammen. For eksempel bliver udviklings-, test- og DevOps-teams nødt til at arbejde sammen. Denne situation skaber yderligere ledelseskrav og kræver god kommunikation mellem disse teams for at sikre, at de er fokuserede og trækker mod de samme mål.
Eksempel på inkrementel test
Den nemmeste måde at forstå en inkrementel testmetode på er måske at tænke på et eksempel. Her er en simpel situation, der kan hjælpe med at visualisere processen.
1. Eksempel på inkrementel test af en mobilbank-app
Scenarie: Et team er ved at bygge en mobilbank-app. Appen er sammensat af flere forskellige moduler, der gør det muligt:
- 2FA og biometrisk brugerverifikation
- Transaktionsbehandling
- Dashboard til styring af finansielle data
Målsætning: Teamet ønsker at teste integrationen af hvert modul og afgøre, om de fungerer godt sammen. Som et resultat bygger de tre testcases.
Testtilfælde 1
I den første testcase ønsker teamet at sikre, at brugeren ved at indtaste biometriske data eller password får adgang til både transaktionsbehandling og dashboardet til styring af finansielle data.
Appen består testen, hvis brugeren kan indtaste sine oplysninger og få mulighed for at tilgå transaktioner.
Testtilfælde 2
Den næste testcase er designet til at se, hvordan appen håndterer uautoriserede transaktioner.
Appen består testen, hvis et forsøg på at foretage en uautoriseret transaktion blokeres, og appen udsender en fejlmeddelelse.
Testtilfælde 3
Den sidste integrationstest går ud på at validere, om appen kan foretage transaktioner samtidigt.
Appen består testen, hvis brugeren kan starte en transaktion og få adgang til sine finansielle oplysninger på samme tid uden datainkonsistens eller problemer.
Er en inkrementel testtilgang den
det samme som inkrementel testning?
Nej, det er det ikke. Inkrementalitetstest refererer til en statistisk marketingmetode, der måske er bedst kendt som attributionsmodellering. Kort sagt hjælper det marketingteams med at forstå effekten af reklamekampagner, marketingkanaler eller bestemte strategier.
Mens interessen for denne form for modellering er vokset i de senere år takket være “døden” af cookies og tredjepartsdata, er den eneste relation, det har til inkrementel testning, et fælles ord.
Top 3 værktøjer til inkrementel test
#1. ZAPTEST
Ud over at levere førsteklasses
RPA
tilbyder ZAPTEST en række automatiseringsværktøjer til softwaretest, der er perfekte til trinvis testning. Nogle af funktionerne omfatter:
Håndtering af testdata
: Reducer mængden af tid og kræfter, der er involveret i inkrementel testning, ved at give teams mulighed for at genbruge testdata.- Optagelse og afspilning af manuskript: Dette værktøj uden kode giver teams mulighed for at optage og udføre scripts og spare en masse tid under inkrementel testning.
- Genanvendelige testmoduler: ZAPTEST er meget modulopbygget og giver teams mulighed for at oprette og genbruge testmoduler og spare betydelige mængder tid i testprocessen.
Alt i alt tilbyder ZAPTEST en kraftfuld og varieret testautomatiseringssuite, der er velegnet til enhver form for test, herunder inkrementel test.
#2. Selen
Selenium er en open source testautomatiseringsplatform, der er bygget til at lette test af mobilapplikationer. Værktøjerne understøtter flere mobile platforme (Android, iOS, Windows) og bruger stubs og drivere til at simulere moduler.
#3. Testsigma
Testsigma er en cloud-baseret platform til testautomatisering. Det kan bruges til at teste web- og mobilapplikationer og er velegnet til trinvis testning takket være kodeløs testoprettelse og integration med CI/CD-pipelines.
Afsluttende tanker
Inkrementel test i softwaretest er en vigtig del af integrationstest. Det giver teams mulighed for at opdele moduler i let testbare dele, før de langsomt integreres. Fordelene her er, at hvert modul kan verificeres for fejl og derefter for, hvordan det integreres med de tilsluttede dele.
Sammen med vores førsteklasses
RPA
værktøjer tilbyder ZAPTEST automatisering af softwaretest uden kode, der både er på tværs af platforme og applikationer. Desuden er vores testpakke spækket med funktioner som CI/CD-integration, robust rapportering og analyse samt førsteklasses support og kundeservice.
