Hva er dynamisk testing? Typer, teknikker og eksempler

Hva er dynamisk testing?

Dynamisk testing er en metode for programvaretesting som brukes til å teste den dynamiske oppførselen til programvarekode. Hovedformålet med dynamisk testing er å undersøke programvareoppførsel med dynamiske variabler – variabler som ikke er konstante – og å finne svake områder i programvarens kjøretidsmiljø. Koden må kjøres for å teste den dynamiske oppførselen.

Testing er verifisering og validering, og det kreves begge V-ene for å fullføre testingen. Verifisering utføres ved statisk testing, som gjennomgår krav, designdokumenter og kode uten å kjøre dem. Validering utføres ved dynamisk testing, som kjører byggingen og sammenligner hva applikasjonen faktisk gjør med hva den skal gjøre.

Tabellen nedenfor skiller de to fra hverandre på et raskt blikk.

Aspekt	Statisk testing (verifisering)	Dynamisk testing (validering)
Code henrettet	Nei	Ja
Typiske aktiviteter	Revvisninger, gjennomganger, inspeksjoner, statisk analyse	Utførelse av testtilfeller på tvers av alle testnivåer
Spørsmål besvart	Bygger vi produktet riktig?	Bygger vi det riktige produktet?
Defekter funnet	Tvetydige krav, brudd på kodestandarder, død kode	Feil utdata, minnelekkasjer, tidsfeil, integrasjonsfeil
Starter	Så snart en gjenstand eksisterer	Når en kjørbar versjon finnes
Relativ kostnad for en reparasjon	Lavere, fordi feil oppdages tidligere	Høyere, fordi feil dukker opp senere

Eksempel på dynamisk testing

Et kortfattet eksempel viser hvordan dynamisk testing oppfører seg i praksis.

Anta at en innloggingsside testes. Den har to felt, brukernavn og passord, og brukernavnet er begrenset til alfanumeriske tegn.

Når brukeren skriver inn brukernavnet som «Guru99», godtar systemet det. Når brukeren skriver inn «Guru99@123», kaster applikasjonen en feilmelding. Dette resultatet viser at koden fungerer dynamisk basert på brukerinndata.

Dynamisk testing betyr derfor å jobbe med det faktiske systemet, gi input og sammenligne applikasjonens faktiske oppførsel med forventet oppførsel – med andre ord å jobbe med systemet med den hensikt å finne feil.

Dynamisk testing er derfor prosessen med å validere en programvareapplikasjon slik en sluttbruker ville gjort, under forskjellige miljøer, for å bygge riktig programvare.

Hva gjør dynamisk testing?

Hovedmålet med dynamiske tester er å sikre at programvaren fungerer som den skal under og etter installasjon, og leverer en stabil applikasjon uten større feil. Ingen programvare er helt feilfri, og testing kan vise tilstedeværelsen av feil, men aldri fraværet av dem.

Dynamiske tester sikrer også konsistens på tvers av programvaren, som dette eksemplet viser.

I en bankapplikasjon finnes det flere skjermbilder, som Mine kontoer, Pengeoverføring og Bill Betal. Alle inneholder et beløpsfelt.

Anta at feltet Mine kontoer viser beløpet som 25 000, pengeoverføring viser 25 000 dollar og Bill Betalingsskjermen viser 25 000 dollar. Beløpet er det samme, men måten det vises på er ikke det, noe som gjør programvaren inkonsekvent.

Konsistens er ikke begrenset til funksjonalitet. Det dekker også standarder som ytelse, brukervennlighet og kompatibilitet, og det er derfor dynamisk testing er så viktig.

Typer dynamisk testing

Dynamisk testing er klassifisert i to kategorier.

• Hvit Box Testing
• Svart Box Testing

Diagrammet nedenfor kartlegger de to kategoriene mot testnivåene som ligger under dem.

Hver type og dens tiltenkte formål er beskrevet nedenfor.

Hvit Box Testing — en metode for programvaretesting der den interne strukturen og designet er kjent for testeren. Hovedmålet er å sjekke hvordan systemet yter basert på koden. Den utføres hovedsakelig av utviklere eller white-box-testere som har programmeringskunnskap.

Svart Box Testing — en testmetode der den interne strukturen, koden og designet IKKE er kjent for testeren. Hovedmålet er å verifisere funksjonaliteten til systemet som testes. Denne typen testing krever at hele testpakken kjøres, utføres hovedsakelig av testere og krever ingen programmeringskunnskaper.

Black box-testing er igjen klassifisert i to typer.

• Funksjonell testing
• Ikke-funksjonell testing

Funksjonell testing

Funksjonell testing utføres for å bekrefte at alle funksjonene som er utviklet samsvarer med de funksjonelle spesifikasjonene. Det utføres ved å utføre den funksjonelle test tilfeller skrevet av QA-teamet. I denne fasen testes systemet ved å gi innspill, verifisere utdataene og sammenligne de faktiske resultatene med de forventede resultatene.

Det finnes ulike nivåer av funksjonstesting, hvorav de viktigste er de fire nedenfor.

• Enhetstesting — en enhet er et lite, testbart stykke kode. Enhetstesting utføres på en enkelt programvareenhet og utføres av utviklere.
• Integrasjonstesting — utføres etter enhetstesting, ved å kombinere de individuelle testbare enhetene. Dette utføres enten av utviklere eller testere.
• Systemtesting — utføres for å sikre at systemet oppfører seg i henhold til kravene. Dette utføres vanligvis av testere når hele systemet er klart, etter at bygget er utgitt til QA-teamet.
• Akseptprøving — utføres for å bekrefte om systemet oppfyller forretningskravene og er klart for bruk eller utrulling. Dette utføres vanligvis av sluttbrukerne.

Ikke-funksjonell testing

Ikke-funksjonell testing er en testteknikk som ikke fokuserer på funksjonelle aspekter, men i stedet konsentrerer seg om ikke-funksjonelle egenskaper ved systemet, som minnelekkasjer, ytelse eller robusthet. Ikke-funksjonell testing utføres på alle testnivåer.

Det finnes mange ikke-funksjonelle testteknikker, hvorav de viktigste er de fem nedenfor.

• Ytelsestesting — sjekker om systemets responstid er normal, i henhold til kravene, under ønsket nettverksbelastning.
• Gjenopprettingstesting – verifiserer hvor godt et system gjenoppretter seg etter krasj og maskinvarefeil.
• Test av kompatibilitet – verifiserer hvordan systemet oppfører seg i ulike miljøer.
• Sikkerhetstesting — verifiserer applikasjonens robusthet, og sikrer at bare autoriserte brukere og roller har tilgang til systemet.
• Brukervennlighetstesting — verifiserer systemets brukervennlighet for sluttbrukerne, og hvor komfortable disse brukerne er med det.

Dynamiske testteknikker

Når typene er avgjort, er det neste spørsmålet hvordan en dynamisk testsyklus faktisk kjøres.

Dynamiske testteknikker i STLC bestå av oppgaver som kravanalyse for testene, testplanlegging, design og implementering av testcase, oppsett av testmiljø, utførelse av testcase, feilrapportering og til slutt testavslutning. Hver oppgave i dynamisk testing avhenger av fullføringen av den forrige oppgaven i testprosessen.

Innenfor STLC starter den faktiske dynamiske testprosessen med testcasedesign. Diagrammet nedenfor viser rekkefølgen av aktiviteter, som hver er beskrevet etterpå.

Før man går inn i prosessen, må man avtale strategien som skal følges for dynamisk testing.

En teststrategi bør hovedsakelig fokusere på tilgjengelige ressurser og tidsramme. Basert på disse to faktorene må testingens mål, testingens omfang, testfasene eller -syklusene, typen miljø, antagelsene eller utfordringene som kan oppstå, og risikoene dokumenteres.

Når strategien er definert og akseptert av ledelsen, starter den faktiske testcase-designprosessen.

Testdesign og implementering

I denne fasen identifiserer teamet følgende.

• Funksjoner som skal testes
• Testbetingelser avledet fra disse funksjonene
• Dekningselementer utledet fra testforholdene
• Testtilfeller utledet fra dekningselementene

Svart boks teknikker for testdesign som ekvivalenspartisjonering, grenseverdianalyse, testing av beslutningstabell og testing av tilstandsovergang er det som gjør en testbetingelse om til et konkret sett med kjørbare tilfeller.

Test miljøoppsett

Ocuco test miljø bør alltid være lik produksjonsmiljøet. I denne fasen installeres byggingen og testmaskinene administreres og konfigureres.

Test utførelse

I denne fasen blir testtilfellene faktisk utført, enten manuelt eller via automatisering, og de faktiske resultatene registreres mot de forventede resultatene.

Feilrapport fanget

Basert på utførelsen, hvis forventede og faktiske resultater ikke er de samme, må testtilfellet markeres som Fail og en feil logges i feilhåndtering prosess.

Fordeler med dynamisk testing

• Dynamisk testing avdekker feil som anses som for vanskelige eller kompliserte å fange opp, og som statisk analyse ikke kan dekke i det hele tatt.
• Programvaren kjøres fra ende til annen, noe som hever kvaliteten på både produktet og prosjektet.
• Dynamisk testing er en viktig metode for å oppdage sikkerhetstrusler i et kjørende system.
• Kjøretidsfeil som minnelekkasjer, timingproblemer og integrasjonsfeil dukker opp her og ingen andre steder.

Ulemper med dynamisk testing

• Dynamisk testing er tidkrevende fordi det krever store mengder ressurser å kjøre applikasjonen eller koden.
• Det øker kostnadene for prosjektet, fordi det ikke starter tidlig i programvarens livssyklus, og problemer som fikses i senere stadier koster mer å reparere.
• Et produksjonslignende miljø og realistiske testdata er forutsetninger, og begge deler krever innsats å bygge og vedlikeholde.

Spørsmål og svar