Vad är dynamisk testning? Typer, tekniker & exempel
Thomas Hamilton
⚡ Smart sammanfattning
Dynamisk testning kör applikationen och observerar hur den körande koden beter sig med verkliga indata, så att testare kan validera funktionalitet, prestanda och stabilitet som ingen dokumentgranskning kan avslöja.
Vad är dynamisk testning?
Dynamisk testning är en metod för mjukvarutestning som används för att testa det dynamiska beteendet hos mjukvarukod. Huvudsyftet med dynamisk testning är att undersöka mjukvarubeteende med dynamiska variabler – variabler som inte är konstanta – och att hitta svaga områden i mjukvarans körtidsmiljö. Koden måste köras för att testa det dynamiska beteendet.
Testning är verifiering och validering, och det krävs båda V:erna för att göra testningen komplett. Verifiering utförs genom statisk testning, som granskar krav, designdokument och kod utan att köra dem. Validering utförs genom dynamisk testning, som kör bygget och jämför vad applikationen faktiskt gör med vad den ska göra.
Tabellen nedan skiljer de två åt i korthet.
| Aspect | Statisk testning (verifiering) | Dynamisk testning (validering) |
| Code exekveras | Nej | Ja |
| Typiska aktiviteter | Revvisningar, genomgångar, inspektioner, statisk analys | Testfallskörning på alla testnivåer |
| Fråga besvarad | Bygger vi produkten rätt? | Bygger vi rätt produkt? |
| Defekter funna | Tvetydiga krav, överträdelser av kodningsstandarder, död kod | Felaktig utdata, minnesläckor, tidsfel, integrationsfel |
| Startar | Så snart en artefakt existerar | När en körbar version finns |
| Relativ kostnad för en reparation | Lägre, eftersom fel upptäcks tidigare | Högre, eftersom defekter uppstår senare |
Exempel på dynamisk testning
Ett kortfattat exempel visar hur dynamisk testning fungerar i praktiken.
Anta att en inloggningssida testas. Den har två fält, användarnamn och lösenord, och användarnamnet är begränsat till alfanumeriska tecken.
När användaren anger användarnamnet som "Guru99”, accepterar systemet det. När användaren anger “Guru99@123”, visar programmet ett felmeddelande. Resultatet visar att koden agerar dynamiskt baserat på användarinmatningen.
Dynamisk testning innebär därför att arbeta med det faktiska systemet, ge indata och jämföra applikationens faktiska beteende med det förväntade beteendet – med andra ord att arbeta med systemet med avsikt att hitta fel.
Dynamisk testning är därför processen att validera en mjukvaruapplikation som en slutanvändare skulle göra, under olika miljöer, för att bygga rätt programvara.
Vad gör dynamiska tester?
Huvudsyftet med dynamiska tester är att säkerställa att programvaran fungerar korrekt under och efter installationen, och att den levererar en stabil applikation utan större brister. Ingen programvara är helt felfri, och tester kan visa förekomsten av defekter men aldrig deras frånvaro.
Dynamiska tester säkerställer också konsekvens i hela programvaran, vilket det här exemplet visar.
I en bankapplikation finns det flera skärmar, till exempel Mina konton, Pengöverföringar och Bill Betala. Alla innehåller ett beloppsfält.
Anta att fältet Mina konton visar beloppet som 25 000, överföring av medel visar 25 000 USD och Bill Löneskärmen visar 25 000 dollar. Beloppet är detsamma, men sättet det visas på är det inte, vilket gör programvaran inkonsekvent.
Konsekvens är inte begränsat till funktionalitet. Det omfattar även standarder som prestanda, användbarhet och kompatibilitet, vilket är anledningen till att dynamisk testning är så viktig.
Typer av dynamisk testning
Dynamisk testning delas in i två kategorier.
- Vit Box Testning
- Svart Box Testning
Diagrammet nedan jämför de två kategorierna med de testnivåer som ligger under dem.
Varje typ och dess avsedda syfte beskrivs nedan.
Vit Box Testning — en metod för mjukvarutestning där den interna strukturen och designen är känd för testaren. Dess huvudsakliga syfte är att kontrollera hur systemet presterar baserat på koden. Den utförs huvudsakligen av utvecklare eller white box-testare som har programmeringskunskaper.
Svart Box Testning — en testmetod där den interna strukturen, koden och designen INTE är kända för testaren. Dess huvudsyfte är att verifiera funktionaliteten hos det testade systemet. Denna typ av testning kräver att hela testsviten körs, utförs huvudsakligen av testare och kräver inga programmeringskunskaper.
Black box-testning klassificeras återigen i två typer.
- funktions~~POS=TRUNC
- Icke-funktionell testning
funktions~~POS=TRUNC
Funktionell testning utförs för att verifiera att alla utvecklade funktioner matchar de funktionella specifikationerna. Det utförs genom att exekvera den funktionella testfall skriven av QA-teamet. I den här fasen testas systemet genom att ge input, verifiera utdata och jämföra de faktiska resultaten med de förväntade resultaten.
Det finns olika nivåer av funktionstestning, varav de viktigaste är de fyra nedan.
- Enhetstestning — en enhet är en liten, testbar kodbit. Enhetstestning utförs på en enskild programvaruenhet och utförs av utvecklare.
- Integrationstestning — utförs efter enhetstestning, genom att kombinera de individuella testbara enheterna. Det utförs antingen av utvecklare eller av testare.
- Kravhantering — utförs för att säkerställa att systemet fungerar enligt kraven. Det utförs vanligtvis av testare när hela systemet är klart, så snart bygget har släppts till QA-teamet.
- Acceptantestning — utförs för att verifiera om systemet uppfyller affärskraven och är klart för användning eller driftsättning. Det utförs vanligtvis av slutanvändarna.
Icke-funktionell testning
Icke-funktionell testning är en testteknik som inte fokuserar på funktionella aspekter utan istället koncentrerar sig på systemets icke-funktionella attribut, såsom minnesläckor, prestanda eller robusthet. Icke-funktionell testning utförs på alla testnivåer.
Det finns många icke-funktionella testtekniker, av vilka de viktigaste är de fem nedan.
- Prestandatester — kontrollerar om systemets svarstid är normal, enligt kraven, under önskad nätverksbelastning.
- Återhämtningstestning — verifierar hur väl ett system återhämtar sig från krascher och hårdvarufel.
- Test av kompatibilitet — verifierar hur systemet beter sig i olika miljöer.
- Säkerhetstestning — verifierar applikationens robusthet och säkerställer att endast behöriga användare och roller har åtkomst till systemet.
- Användbarhetstestning — verifierar systemets användbarhet för slutanvändarna och hur bekväma dessa användare är med det.
Dynamiska testtekniker
När typerna är avgjorda är nästa fråga hur en dynamisk testcykel faktiskt körs.
Dynamiska testtekniker inom STLC bestå av uppgifter som kravanalys för testerna, testplanering, design och implementering av testfall, uppsättning av testmiljö, exekvering av testfall, felrapportering och slutligen testavslutning. Varje uppgift i dynamisk testning är beroende av att den föregående uppgiften i testprocessen slutförs.
Inom STLC börjar den faktiska dynamiska testprocessen med testfallsdesign. Diagrammet nedan visar sekvensen av aktiviteter, som var och en beskrivs efteråt.
Innan processen påbörjas måste man komma överens om vilken strategi som ska följas för dynamisk testning.
En teststrategi bör huvudsakligen fokusera på tillgängliga resurser och tidsram. Baserat på dessa två faktorer måste testningens syfte, testningens omfattning, testningens faser eller cykler, typen av miljö, de antaganden eller utmaningar som kan uppstå och riskerna dokumenteras.
När strategin har definierats och accepterats av ledningen börjar den faktiska testfallsdesignprocessen.
Testdesign och implementering
I den här fasen identifierar teamet följande.
- Funktioner som ska testas
- Testförhållanden härledda från dessa egenskaper
- Täckningsposter härledda från testförhållandena
- Testfall härledda från täckningsposterna
Svart låda testdesigntekniker såsom ekvivalenspartitionering, randvärdesanalys, testning av beslutstabeller och testning av tillståndsövergångar är det som förvandlar ett testvillkor till en konkret uppsättning körbara fall.
Testmiljöinställningar
Ocuco-landskapet testmiljö bör alltid likna produktionsmiljön. I den här fasen installeras bygget och testmaskinerna hanteras och konfigureras.
Testa utförandet
Under denna fas körs testfallen faktiskt, antingen manuellt eller via automatisering, och de faktiska resultaten redovisas mot de förväntade resultaten.
Buggrapport fångad
Baserat på exekveringen, om de förväntade och faktiska resultaten inte är desamma, måste testfallet markeras som Misslyckat och en bugg loggas i felhantering processen.
Fördelar med dynamisk testning
- Dynamisk testning avslöjar defekter som anses vara för svåra eller komplicerade att upptäcka, och som statisk analys inte kan täcka alls.
- Programvaran exekveras från början till slut, vilket höjer kvaliteten på både produkten och projektet.
- Dynamisk testning är ett viktigt sätt att upptäcka säkerhetshot i ett system som körs.
- Runtime-fel som minnesläckor, timingproblem och integrationsfel dyker upp här och ingen annanstans.
Nackdelar med dynamisk testning
- Dynamisk testning är tidskrävande eftersom det kräver stora resurser att köra applikationen eller koden.
- Det ökar projektets kostnad, eftersom det inte börjar tidigt i programvarans livscykel och problem som åtgärdas i senare skeden kostar mer att reparera.
- En produktionsliknande miljö och realistisk testdata är förutsättningar, och båda kräver ansträngning att bygga och underhålla.
