Statisk testing og dynamisk testing - Forskjellen mellom disse to viktige testteknikkene

static testing dynamic testing difference between these two important testing techniques

Testing er Verifisering og validering . Vi vet alle at det tar 2 Vs å gjøre testingen fullført.

I dagens artikkel skal vi belyse noe Statisk testing . Det kalles også Verifisering. Vi vil lære alt om det og legge spesiell vekt på dette fordi Dynamisk testing får ofte maksimal oppmerksomhet og har utallige artikler som beskriver det.

Imidlertid ville ingen diskusjoner om statisk testing være fullstendig uten en forklaring på hva dens motstykke, dynamiske testing betyr. Dynamisk testing er validering, den andre “V”.

Dynamisk testing er når du jobber med det faktiske systemet (ikke noe artefakt eller modell som representerer systemet), som gir en inngang, mottar utgang og sammenligner utdata med forventet oppførsel. Det er praktisk å jobbe med systemet med den hensikt å finne feil.

I løpet av denne prosessen vil vi forstå hvordan følgende to vanlige misoppfatninger om testing ikke stemmer:

1. Testing er en aktivitet som kommer på slutten
2. Det utføres bare av testere, og resten av dem har ingenting å gjøre

La oss starte med en rask referanse til v-modell :

• På venstre side av V-modellen har vi aktiviteter som ikke utføres av QA-teamet.
• På høyre side , vi har noen av dem som blir tatt hånd om av Dev-teamet, noen av testerne og noen av brukerne.

La oss begynne med - Kravsamling . Det utføres av forretningsanalytikeren og annen ledelse på høyere nivå - utgangsdokumentet for denne fasen er forretningskravdokumentet, BRD.

hvordan ser en wep-tast ut

Den neste fasen er System design . Systemdesign er en fase der forretningskravene oversettes til Funksjonskravene, i FRD (Funksjonskravdokument).

Når oversettelsen skjer, vil Dev-teamet (som er hovedaktør i dette trinnet) gå over BRD-dokumentet trinn for trinn, side for side og linje for linje. Selv om hovedmålet er å konsumere forretningskravene av hensyn til oversettelsen, blir BRD-dokumentet gjennomgått etter tur.

Et eksempel: Si at dette er BRD for et bankside som er stort på sikkerhet. Det er en seksjon i BRD som snakker om passordreglene for de forskjellige brukerne som oppretter en konto hos nettbanken. En av reglene er: En bruker kan ikke bruke et passord som han / hun bruker til andre kontoer.

Dette er ikke gjennomførbart. Fordi et nettsted bare kan foreslå hvordan brukeren skal angi påloggingsinformasjon, men det ikke er noen måte, kan denne begrensningen pålegges. Så dette kravet er ikke gjennomførbart - med andre ord, det kan ikke oppnås gjennom programvaren.

La oss nå se på følgende punkter basert på dette eksemplet:

1. Hvordan blir det bestemt at dette kravet ikke kan bygges og ikke kan testes (med andre ord ikke gjennomførbart)? Har vi bankens side, og setter vi inn pålogging og passord - og innser at dette ikke er mulig? Nei, vi baserer rett og slett dette på vår gjennomgang av BRD og selvfølgelig en sunn forretningsforståelse.
2. Tester vi dette kravet? Visst, men bare basert på den teoretiske, konseptuelle sansen, men ikke på den faktiske AUT (Application under Test).
3. Hva er den fysiske formen for denne testen? -En enkel lesing eller en formell gjennomgang av BRD eller en enda mer formell gjennomførbarhetsanalyse av forretningskravene.

Kommer tilbake til våre misforståelser:

4. Hvem utfører denne gjennomgangen av BRD? - For det meste dev teamet og andre tekniske team som er ansvarlige for å lage produktet. Ikke testere.
5. Skjer denne gjennomgangen på slutten av produktopprettelsen? Nei, helt i begynnelsen av prosjektutviklingen. Derfor ikke bare slutten.

Statiske testteknikker:

For å oppsummere er statisk testing verifiseringsdelen av programvaretesting som følger metodene for:

• Dokumentanmeldelser
• Gjennomganger
• Undersøkelse
• Mulighetsanalyse eller annen form for analyse for å avgjøre om programvaren er som den skal eller ikke
• Kode anmeldelse

For å sitere CSTE CBOK, 'Bekreftelse svarer på spørsmålet:' Bygde vi riktig system? ' mens valideringene adresserer: 'Byggte vi systemet riktig?'

Følgende er alle de statiske testaktivitetene som skjer på venstre side av V-modellen.

Merk: Denne informasjonen kan ekstrapoleres for prosjekter som følger utviklingsmetoder, da trinnene vil være mer eller mindre like.

På høyre side av V-modellen er validering.

Dynamiske testteknikker:

• Enhetstesting
• Integrasjonstesting
• Systemtesting

Enhets-, integrasjons-, system- og UAT-fasene handler om å lage tester som skal utføres på AUT i forskjellige stadier av utviklingen. Selv om testene er målrettet mot å validere ulike typer krav, er de alle like.

Så, enhver form for testing der vi har en test som må utføres på en AUT og dens utdata er nødvendig for å bestemme resultatet av testen (vellykket eller ikke) - det er validering.

Nå, ville det være greit å generalisere at det på høyre side (RHS) av V-modellen ikke er noen bekreftelse i det hele tatt? Svaret er nei.

Alle testene som blir opprettet på hvert trinn på RHS blir gjennomgått flere ganger i løpet av testopprettelsen / sluttfasen. Den detaljerte prosessen med testdokumentasjonsgjennomgang er kl https://www.softwaretestinghelp.com/test-documentation-reviews/

På RHS:

• Tester og kode blir gjennomgått i utviklingsstadiet for enhet / integrasjon av utviklerne.
• Systemtester gjennomgår en fagfellevurdering under dokumentasjonen og gjennomgår en gjennomgang av dev-teamet og forretningsanalytikeren.
• UAT-tester gjennomgår både QA-teamet og brukerne før UAT begynner.

Konklusjon

Avslutningsvis er statisk testing en viktig testteknikk som tar form av gjennomgang av forretningskrav, funksjonskravgjennomgang, designanmeldelser, gjennomgang av kode og gjennomgang av testdokumentasjon. Det er en kontinuerlig aktivitet og ikke bare utført av testere.

Validering, den dynamiske testdelen er mer praktisk og skjer på selve produktet og ikke på en gjenstand eller en representasjon av produktet. En mye formell prosess med testsak / tilstandsidentifikasjon, dekningshensyn, utførelse og rapportering av mangler markerer alle de dynamiske testmetodene.

Om forfatter: Denne artikkelen er skrevet av STH-teammedlem Swati S.

Del dine kommentarer, spørsmål og erfaringer om det statiske og dynamiske testemnet.

Anbefalt lesing

• Forskjellen mellom Desktop, Client Server Testing og Web Testing
• Agile Estimation Techniques: En sann estimering i et smidig prosjekt
• Black Box Testing: En grundig opplæring med eksempler og teknikker
• Hva er Compliance Testing (Conformance testing)?
• Hva er forskjellen mellom SIT Vs UAT Testing?
• Alpha Testing og Beta Testing (En komplett guide)
• Viktige forskjeller mellom Black Box Testing og White Box Testing
• Forskjellene mellom enhetstesting, integrasjonstesting og funksjonstesting