Statisk test og dynamisk test - Forskellen mellem disse to vigtige testteknikker

static testing dynamic testing difference between these two important testing techniques

Test er Verifikation og validering . Vi ved alle, at det tager 2 Vs at gøre testen komplet.

I dagens artikel vil vi kaste lys over det Statisk test . Det kaldes også Verifikation. Vi lærer alt om det og lægger særlig vægt på dette fordi Dynamisk test får ofte maksimal opmærksomhed og har utallige artikler, der beskriver det.

Imidlertid ville ingen diskussion om statisk test være komplet uden en forklaring på, hvad dens modstykke, dynamiske test betyder. Dynamisk test er validering, den anden “V”.

Dynamisk test er, når du arbejder med det faktiske system (ikke en artefakt eller model, der repræsenterer systemet), leverer et input, modtager output og sammenligner output med den forventede adfærd. Det er praktisk at arbejde med systemet med det formål at finde fejl.

Under denne proces vil vi forstå, hvordan følgende to almindelige misforståelser om test ikke er sande:

1. Test er en aktivitet, der kommer i slutningen
2. Det udføres kun af testere, og resten af ​​dem har intet at gøre

Lad os starte med en hurtig henvisning til v-model :

• På den venstre side af V-modellen har vi aktiviteter, der ikke udføres af QA-teamet.
• På den højre side , vi har nogle af dem, der bliver taget hånd om af Dev-teamet, nogle af testere og andre af brugere.

Lad os starte med - Krav indsamling . Det udføres af forretningsanalytikeren og anden ledelse på højere niveau - outputdokumentet for denne fase er forretningskravdokumentet, BRD.

Spil wow gratis privat server

Den næste fase er Systemdesign . Systemdesign er en fase, hvor forretningskravene oversættes til de funktionelle krav i FRD (dokument om funktionelle krav).

Når oversættelsen sker, vil Dev-teamet (som er hovedaktøren i dette trin) gå gennem BRD-dokumentet trin for trin, side for side og linje for linje. Selvom det primære mål er at forbruge forretningskravene af hensyn til oversættelsen, bliver BRD-dokumentet gennemgået igen.

Et eksempel: Sig dette er BRD for et bankside, der er stort med sikkerhed. Der er et afsnit i BRD, der taler om adgangskodereglerne for de forskellige brugere, der opretter en konto hos onlinebankwebstedet. En af reglerne er: En bruger kan ikke bruge en adgangskode, som han / hun bruger til andre konti.

Dette kan ikke gøres. Fordi et websted kun kan foreslå, hvordan brugeren skal angive loginoplysninger, men der ikke er nogen måde, kan denne begrænsning pålægges. Så dette krav er ikke gennemførligt - med andre ord kan det ikke gennemføres via softwaren.

Lad os nu overveje følgende punkter baseret på dette eksempel:

1. Hvordan bestemmes det, at dette krav ikke kan bygges og derfor ikke kan testes (med andre ord ikke muligt)? Har vi bankens websted, og derefter angiver vi login og adgangskode - og indser derefter, at dette ikke er muligt? Nej, vi baserer simpelthen dette på vores gennemgang af BRD og selvfølgelig en sund forretningsforståelse.
2. Tester vi dette krav? Sikker på, men udelukkende baseret på den teoretiske, konceptuelle sans, men ikke på den faktiske AUT (Application under Test).
3. Hvad er den fysiske form for denne test? -En simpel læsning eller en formel gennemgang af BRD eller en endnu mere formel gennemførlighedsanalyse af forretningskravene.

Vender tilbage til vores misforståelser:

4. Hvem udfører denne gennemgang af BRD? - For det meste dev-teamet og andre tekniske teams, der er ansvarlige for at skabe produktet. Ikke testere.
5. Fortsættes denne gennemgang i slutningen af ​​produktoprettelsen? Nej, i den allerførste fase af projektudviklingen. Derfor ikke kun slutningen.

Statiske testteknikker:

For at opsummere er statisk test verifikationsdelen af ​​softwaretest, der følger metoderne til:

• Dokumentanmeldelser
• Gennemgang
• Inspektion
• Feasibility-analyse eller enhver anden form for analyse for at afgøre, om softwaren er, hvad den skal være eller ej
• Kodegennemgang

For at citere CSTE CBOK, 'Bekræftelse besvarer spørgsmålet,' Har vi bygget det rigtige system? ' mens valideringer adresserer, 'Har vi bygget systemet rigtigt?'

Følgende er alle de statiske testaktiviteter, der sker på venstre side af V-modellen.

Bemærk: Denne information kan ekstrapoleres til projekter, der følger enhver udviklingsmetode, da trinnene vil være mere eller mindre ens.

På højre side af V-modellen er validering.

Dynamiske testteknikker:

• Enhedstest
• Integrationstest
• Systemtest

Enheds-, integrations-, system- og UAT-faser handler om at oprette tests, der skal udføres på AUT i forskellige faser af dens udvikling. Selvom testene er målrettet mod validering af forskellige slags krav, er de alle tests alle de samme.

Så enhver form for test, hvor vi har en test, der skal udføres på en AUT, og dens output er nødvendig for at bestemme resultatet af testen (vellykket eller ej) - det er validering.

Nu, ville det være ok at generalisere, at der på højre side (RHS) af V-modellen overhovedet ikke er nogen verifikation? Svaret er, nej.

Alle test, der oprettes i hvert trin på RHS, gennemgås flere gange i løbet af testoprettelses- / afslutningsfasen. Den detaljerede proces med gennemgang af testdokumentation er kl https://www.softwaretestinghelp.com/test-documentation-reviews/

På RHS:

• Tests og kode gennemgås i Enheds / Integration testfasen af ​​udviklerne.
• Systemtest gennemgår en peer review under deres dokumentation og gennemgår en gennemgang af dev-teamet og forretningsanalytikeren.
• UAT-tests gennemgår både QA-teamet og brugerne, før UAT begynder.

Konklusion

Afslutningsvis er statisk test en vigtig testteknik, der tager form af revision af forretningskrav, funktionskravvurdering, designanmeldelser, gennemgang af kode og gennemgang af testdokumentation. Det er en kontinuerlig aktivitet og ikke kun udført af testere.

Validering, den dynamiske testdel er mere praktisk og sker på selve produktet og ikke på en artefakt eller en repræsentation af produktet. En meget formel proces med identifikation af testsag / tilstand, dækningsovervejelser, udførelse og rapportering af mangler markerer alle de dynamiske testmetoder.

Om forfatter: Denne artikel er skrevet af STH-teammedlem Swati S.

Del dine kommentarer, spørgsmål og erfaringer om det statiske og dynamiske testemne.

Anbefalet læsning

• Forskel mellem Desktop, Client Server Testing og Web Testing
• Agile Estimation Techniques: En sand estimering i et smidigt projekt
• Black Box Testing: En grundig tutorial med eksempler og teknikker
• Hvad er overensstemmelsestest (overensstemmelsestest)?
• Hvad er forskellen mellem SIT Vs UAT-test?
• Alpha Testing og Beta Testing (En komplet guide)
• Nøgleforskelle mellem Black Box Testing og White Box Testing
• Forskellene mellem enhedstest, integrationstest og funktionstest