Hvad er dynamisk test? Typer, teknikker og amp; Eksempel

Indholdsfortegnelse:

Anonim

Dynamisk test

Dynamisk test er en softwaretestmetode, der bruges til at teste softwarekodens dynamiske opførsel. Hovedformålet med dynamisk test er at teste softwareadfærd med dynamiske variabler eller variabler, der ikke er konstante, og finde svage områder i softwarekørselstid. Koden skal udføres for at teste den dynamiske adfærd.

Vi ved alle, at test er verifikation og validering, og det tager 2 Vs at gøre testen komplet. Ud af de 2 V'er kaldes Verifikation en Statisk test, og den anden "V" er Validering kendt som Dynamisk test.

Eksempel på dynamisk test

Lad os forstå, hvordan man laver dynamisk test med et eksempel:

Antag, at vi tester en login-side, hvor vi har to felter, der siger "Brugernavn" og "Adgangskode", og brugernavnet er begrænset til alfanumerisk.

Når brugeren indtaster brugernavn som "Guru99", accepterer systemet det samme. Hvor som når brugeren går ind som Guru99 @ 123 så kaster applikationen en fejlmeddelelse. Dette resultat viser, at koden fungerer dynamisk baseret på brugerinput.

Dynamisk test er, når du arbejder med det aktuelle system ved at levere et input og sammenligne applikationens faktiske opførsel med den forventede adfærd. Med andre ord at arbejde med systemet med det formål at finde fejl.

Så baseret på ovenstående udsagn kan vi sige eller konkludere, at dynamisk test er en proces til validering af softwareapplikationer som slutbruger under forskellige miljøer for at opbygge den rigtige software.

Hvad gør dynamisk test?

Hovedformålet med de dynamiske tests er at sikre, at software fungerer korrekt under og efter installationen af ​​softwaren, der sikrer en stabil applikation uden større fejl (denne erklæring er lavet, fordi ingen software er fejlfri, kun test kan vise tilstedeværelse af mangler og ikke fravær)

Hovedformålet med den dynamiske test er at sikre konsistens i softwaren; lad os diskutere dette med et eksempel.

I en bankapplikation finder vi forskellige skærme som My Accounts Section, Funds Transfer, Bill Pay osv ... Alle disse skærmbilleder indeholder beløbsfelt, der accepterer nogle tegn.

Lad os sige, at Mine konti-felt viser beløb som 25.000 og pengeoverførsel som $ 25.000, og Bill-betalingsskærm som $ 25.000, selvom beløbet er det samme, men det beløb, der vises, er ikke det samme, hvilket gør softwaren ikke-konsistent.

Konsistens er ikke kun begrænset til funktionaliteten, det henviser også til forskellige standarder som ydeevne, brugervenlighed, kompatibilitet osv. Derfor bliver det meget vigtigt at udføre dynamisk test.

Typer af dynamisk test

Dynamisk test er klassificeret i to kategorier

  • Test af hvid boks
  • Black Box Testing

Den nedenstående billedlige gengivelse giver os en idé om typer af dynamisk test, niveauer af test osv.

Lad os kort diskutere hver type test, og det tilsigtede formål

White Box Testing - White Box Testing er en softwaretestmetode, hvor den interne struktur / design er kendt af testeren. Hovedformålet med White Box-test er at kontrollere, hvordan systemet fungerer ud fra koden. Det udføres hovedsageligt af udviklere eller White Box Testers, der har viden om programmeringen.

Black Box Testing - Black Box Testing er en testmetode, hvor den interne struktur / kode / design IKKE er kendt af testeren. Hovedformålet med denne test for at verificere funktionaliteten af ​​det testede system og denne type test kræver at udføre den komplette testpakke og udføres hovedsageligt af testerne, og der er ikke behov for nogen programmeringsviden.

Den Black Box Testing igen inddeles i to typer.

De er

  • Funktionel testning
  • Ikke-funktionel test

Funktionel testning:

Funktionel test udføres for at verificere, at alle de udviklede funktioner er i overensstemmelse med de funktionelle specifikationer, og det udføres ved at udføre de funktionelle testtilfælde skrevet af QA-teamet, i funktionel testfase testes systemet ved at levere input, verificere output og sammenligning af de faktiske resultater med de forventede resultater.

Der er forskellige niveauer af funktionstest, hvoraf de vigtigste er

  • Enhedstest - Generelt er Enhed et lille stykke kode, der kan testes, Enhedstest udføres på den enkelte enhed af software og udføres af udviklere
  • Integration Testing - Integration Testing er den test, der udføres efter Unit Testing og udføres ved at kombinere alle de enkelte enheder, der kan testes og udføres enten af ​​udviklere eller testere
  • Systemtest - Systemtest udføres for at sikre, om systemet fungerer efter kravene og generelt udføres, når det komplette system er klar, det udføres af testere, når Build eller koden frigives til QA-teamet
  • Acceptantestning - Acceptantest udføres for at kontrollere, om systemet har opfyldt forretningskravene og er klar til brug eller klar til implementering og generelt udføres af slutbrugerne.

Ikke-funktionel test : Ikke-funktionel test er en testteknik, der ikke fokuserer på funktionelle aspekter og hovedsageligt koncentrerer sig om systemets ikke-funktionelle egenskaber såsom hukommelseslækage, systemets ydeevne eller robusthed. Ikke-funktionel test udføres på alle testniveauer.

Der er mange ikke-funktionelle testteknikker, hvoraf de vigtigste er

  • Performance Testing - Performance Testing udføres for at kontrollere, om systemets responstid er normal i henhold til kravene under den ønskede netværksbelastning.
  • Recovery Testing - Recovery test er en metode til at kontrollere, hvor godt et system er i stand til at gendanne efter nedbrud og hardwarefejl.
  • Kompatibilitetstest - Kompatibilitetstest udføres for at kontrollere, hvordan systemet opfører sig i forskellige miljøer.
  • Sikkerhedstest - Sikkerhedstest udføres for at verificere applikationens robusthed, dvs. for at sikre at kun de autoriserede brugere / roller har adgang til systemet
  • Usability testing - Usability testing er en metode til at verificere systemets anvendelighed af slutbrugerne for at kontrollere, hvor behagelige brugerne er med systemet.

Dynamiske testteknikker

Dynamiske testteknikker i STLC består af forskellige opgaver som Kravsanalyse til testene, Testplanlægning, Test case design og implementering, Test miljø opsætning, Test case udførelse, Bug rapportering og endelig Test lukning. Alle opgaver i dynamiske testteknikker er afhængige af afslutningen af ​​den tidligere opgave i testprocessen.

I STLC kan vi sige, at den faktiske dynamiske testproces starter fra Test Case Design, lad os diskutere hver aktivitet i detaljer.

Lad os diskutere den strategi, der skal følges for dynamisk test, inden vi går ind i processen.

Teststrategi bør primært fokusere på de tilgængelige ressourcer og tidsrammen. Baseret på disse faktorer skal testets mål, testomfanget, testets faser eller cyklusser, miljøtype, antagelser eller udfordringer, der kan blive udsat for, risici osv. Dokumenteres.

Når strategien er defineret og er accepteret af ledelsen, starter den egentlige proces test sag design

Hvad er testdesign og implementering

I denne fase identificerer vi,

  • Funktioner, der skal testes
  • Udled testbetingelserne
  • Udled dækningselementerne
  • Udled testsagerne

Opsætning af testmiljø

Vi er nødt til at sikre, at testmiljø altid skal svare til produktionsmiljøet. I denne fase skal vi installere build og administrere testmaskinerne.

Testudførelse

I løbet af denne fase udføres testsager faktisk.

Fejlrapport fanget

Baseret på udførelsen, hvis de forventede og faktiske resultater ikke er de samme, skal testsagen markeres som Mislykket, og en fejl skal logges.

Fordele ved dynamisk test

  • Dynamisk test kan afsløre de afdækkede mangler, der anses for at være for vanskelige eller komplicerede, og som ikke kan dækkes gennem statisk analyse
  • I dynamisk test udfører vi softwaren, ende til ende, hvilket sikrer fejlfri software, som igen øger kvaliteten af ​​et produkt og projekt.
  • Dynamisk testning bliver et vigtigt værktøj til at opdage eventuelle sikkerhedstrusler

Ulemper ved dynamisk test

  • Dynamisk test er tidskrævende, fordi den udfører applikationen / softwaren eller koden, som kræver enorme mængder ressourcer
  • Dynamisk test øger omkostningerne ved projekt / produkt, fordi det ikke starter tidligt i softwarelevecyklussen, og derfor kan eventuelle problemer, der er løst i senere faser, resultere i en stigning i omkostningerne.

Konklusion:

I softwareteknik er verifikation og validering to målinger, der bruges til at kontrollere, om softwareproduktet opfylder kravene. Statisk test involverer verifikation, mens dynamisk test involverer validering. Sammen hjælper de med at levere en omkostningseffektiv kvalitetssoftware.

Denne artikel er bidraget af Radhika Renamala