Hvad er dynamisk test? Typer, teknikker og eksempler
Thomas Hamilton
⚡ Smart opsummering
Dynamisk testning udfører applikationen og observerer, hvordan den kørende kode opfører sig med reelle input, så testere kan validere funktionalitet, ydeevne og stabilitet, som ingen dokumentgennemgang kan afsløre.
Hvad er dynamisk test?
Dynamisk test er en softwaretestmetode, der bruges til at teste den dynamiske adfærd af softwarekode. Hovedformålet med dynamisk testning er at undersøge softwareadfærd med dynamiske variabler - variabler, der ikke er konstante - og at finde svage områder i softwarens runtime-miljø. Koden skal udføres for at teste den dynamiske adfærd.
Testning er verifikation og validering, og det kræver begge V'er at fuldføre testen. Verifikation udføres ved statisk testning, som gennemgår krav, designdokumenter og kode uden at køre dem. Validering udføres ved dynamisk testning, som kører buildet og sammenligner, hvad applikationen rent faktisk gør, med hvad den skal.
Tabellen nedenfor adskiller de to fra hinanden med et enkelt blik.
| Aspect | Statisk testning (verifikation) | Dynamisk testning (validering) |
| Code henrettet | Ingen | Ja |
| Typiske aktiviteter | Revvisninger, gennemgange, inspektioner, statisk analyse | Udførelse af testcases på tværs af alle testniveauer |
| Spørgsmål besvaret | Bygger vi produktet rigtigt? | Bygger vi det rigtige produkt? |
| Defekter fundet | Tvetydige krav, overtrædelser af kodningsstandarder, død kode | Forkert output, hukommelseslækager, timingfejl, integrationsfejl |
| Starter | Så snart en artefakt eksisterer | Når en eksekverbar build findes |
| Relativ pris for en reparation | Lavere, fordi fejl opdages tidligere | Højere, fordi defekter opstår senere |
Eksempel på dynamisk test
Et kort eksempel viser, hvordan dynamisk testning fungerer i praksis.
Antag, at en loginside testes. Den har to felter, Brugernavn og Adgangskode, og Brugernavnet er begrænset til alfanumeriske tegn.
Når brugeren indtaster brugernavnet som "Guru99”, accepterer systemet det. Når brugeren indtaster “Guru99@123”, kaster applikationen en fejlmeddelelse. Dette resultat viser, at koden fungerer dynamisk baseret på brugerinput.
Dynamisk testning betyder derfor at arbejde med det faktiske system, give input og sammenligne applikationens faktiske adfærd med den forventede adfærd – med andre ord at arbejde med systemet med den hensigt at finde fejl.
Dynamisk testning er derfor processen med at validere en softwareapplikation, som en slutbruger ville gøre under forskellige miljøer, for at bygge den rigtige software.
Hvad gør dynamisk test?
Hovedformålet med dynamiske tests er at sikre, at softwaren fungerer korrekt under og efter installationen, og at den leverer en stabil applikation uden større fejl. Ingen software er fuldstændig fejlfri, og test kan vise tilstedeværelsen af fejl, men aldrig deres fravær.
Dynamiske tests sikrer også konsistens på tværs af softwaren, som dette eksempel viser.
I en bankapplikation er der flere skærme, såsom Mine konti, Pengeoverførsel og Bill Betal. Alle indeholder et beløbsfelt.
Antag, at feltet Mine konti viser beløbet som 25,000, pengeoverførsel viser $25,000, og Bill Betalingsskærmen viser $25000. Beløbet er det samme, men måden det vises på er ikke, hvilket gør softwaren inkonsekvent.
Konsistens er ikke begrænset til funktionalitet. Det dækker også standarder som ydeevne, brugervenlighed og kompatibilitet, hvilket er grunden til, at dynamisk testning er så vigtig.
Typer af dynamisk test
Dynamisk testning er opdelt i to kategorier.
- Hvid Box Test
- Sort Box Test
Diagrammet nedenfor viser de to kategorier i forhold til de testniveauer, der ligger under dem.
Hver type og dens tilsigtede formål er beskrevet nedenfor.
Hvid Box Test — en softwaretestmetode, hvor den interne struktur og design er kendt af testeren. Hovedformålet er at kontrollere, hvordan systemet fungerer baseret på koden. Den udføres primært af udviklere eller white box-testere med programmeringskendskab.
Sort Box Test — en testmetode, hvor den interne struktur, kode og design IKKE er kendt af testeren. Hovedformålet er at verificere funktionaliteten af det system, der testes. Denne type test kræver, at hele testsuiten udføres, udføres hovedsageligt af testere og kræver ingen programmeringskendskab.
Black box-testning er igen opdelt i to typer.
- Funktionstest
- Ikke-funktionel test
Funktionstest
Funktionel test udføres for at verificere, at alle de udviklede funktioner stemmer overens med de funktionelle specifikationer. Det udføres ved at udføre den funktionelle test tilfælde skrevet af QA-teamet. I denne fase testes systemet ved at give input, verificere output og sammenligne de faktiske resultater med de forventede resultater.
Der findes forskellige niveauer af funktionel testning, hvoraf de vigtigste er de fire nedenfor.
- Enhedstest — en enhed er et lille, testbart stykke kode. Enhedstestning udføres på en individuel softwareenhed og udføres af udviklere.
- Integrationstest — udføres efter enhedstestning ved at kombinere de individuelle testbare enheder. Det udføres enten af udviklere eller af testere.
- Systemtest — udføres for at sikre, at systemet fungerer i henhold til kravene. Det udføres generelt, når hele systemet er klar, af testere, når buildet er frigivet til QA-teamet.
- Acceptantestning — udføres for at verificere, om systemet opfylder forretningskravene og er klar til brug eller implementering. Det udføres generelt af slutbrugerne.
Ikke-funktionel test
Ikke-funktionel test er en testteknik, der ikke fokuserer på funktionelle aspekter, men i stedet koncentrerer sig om ikke-funktionelle egenskaber ved systemet, såsom hukommelseslækager, ydeevne eller robusthed. Ikke-funktionel testning udføres på alle testniveauer.
Der findes mange ikke-funktionelle testteknikker, hvoraf de vigtigste er de fem nedenfor.
- Test af ydeevne — kontrollerer, om systemets responstid er normal i henhold til kravene under den ønskede netværksbelastning.
- Gendannelsestest — verificerer, hvor godt et system gendanner sig efter nedbrud og hardwarefejl.
- Test af kompatibilitet — verificerer, hvordan systemet opfører sig i forskellige miljøer.
- Sikkerhedstest — verificerer applikationens robusthed og sikrer, at kun autoriserede brugere og roller har adgang til systemet.
- Usability Testing — verificerer systemets brugervenlighed for slutbrugerne, og hvor trygge disse brugere er med det.
Dynamiske testteknikker
Når typerne er afgjort, er det næste spørgsmål, hvordan en dynamisk testcyklus rent faktisk kører.
Dynamiske testteknikker i STLC bestå af opgaver som kravanalyse til testene, testplanlægning, design og implementering af testcases, opsætning af testmiljø, udførelse af testcases, fejlrapportering og endelig testlukning. Enhver opgave i dynamisk test afhænger af fuldførelsen af den foregående opgave i testprocessen.
Inden for STLC'en starter den faktiske dynamiske testproces med testcasedesign. Diagrammet nedenfor viser rækkefølgen af aktiviteter, som hver især er beskrevet bagefter.
Før processen påbegyndes, skal strategien for dynamisk testning aftales.
En teststrategi bør primært fokusere på de tilgængelige ressourcer og tidsrammen. Baseret på disse to faktorer skal testens formål, testens omfang, testfaserne eller -cyklusserne, typen af miljø, de antagelser eller udfordringer, der kan opstå, og risiciene dokumenteres.
Når strategien er defineret og accepteret af ledelsen, starter den egentlige testcase-designproces.
Testdesign og implementering
I denne fase identificerer teamet følgende.
- Funktioner, der skal testes
- Testbetingelser afledt af disse funktioner
- Dækningselementer afledt af testbetingelserne
- Testtilfælde afledt af dækningselementerne
Sort kasse testdesignteknikker såsom ækvivalenspartitionering, randværdianalyse, test af beslutningstabeller og test af tilstandsovergang er det, der forvandler en testbetingelse til et konkret sæt af eksekverbare tilfælde.
Opsætning af testmiljø
testmiljø bør altid være magen til produktionsmiljøet. I denne fase installeres buildet, og testmaskinerne administreres og konfigureres.
Test udførelse
I denne fase udføres testcasene faktisk, enten manuelt eller via automatisering, og de faktiske resultater registreres i forhold til de forventede resultater.
Fejlrapport fanget
Baseret på udførelsen, hvis de forventede og faktiske resultater ikke er de samme, skal testcasen markeres som Fail, og en fejl skal logges i defekthåndtering proces.
Fordele ved dynamisk test
- Dynamisk test afslører defekter, der anses for at være for vanskelige eller komplicerede at opdage, og som statisk analyse slet ikke kan dække.
- Softwaren udføres fra start til slut, hvilket hæver kvaliteten af både produktet og projektet.
- Dynamisk testning er et vigtigt middel til at opdage sikkerhedstrusler i et kørende system.
- Runtime-fejl, såsom hukommelseslækager, timingproblemer og integrationsfejl, dukker op her og ingen andre steder.
Ulemper ved dynamisk test
- Dynamisk testning er tidskrævende, fordi det kræver en stor mængde ressourcer at udføre applikationen eller koden.
- Det øger projektets omkostninger, fordi det ikke starter tidligt i softwarens livscyklus, og problemer, der rettes i senere faser, koster mere at reparere.
- Et produktionslignende miljø og realistiske testdata er forudsætninger, og begge dele kræver en indsats at opbygge og vedligeholde.
