destructive testing
Forskjellen mellom destruktiv testing og ikke-destruktiv testing med dens typer og metoder:
I denne artikkelen skal vi diskutere detaljer om destruktiv testing og ikke-destruktiv programvaretesting.
Vi vil lære om dem en etter en, og vil også se forskjellene mellom disse to testtypene på slutten av artikkelen.
Hva du vil lære:
- Hva er destruktiv testing og hva er fordelene med?
- Hva er ikke-destruktiv testing, og hva er fordelene?
- Forskjellen mellom destruktiv og ikke-destruktiv testing
Hva er destruktiv testing og hva er fordelene med?
Destruktiv programvaretesting (DST) er en slags programvaretesting som prøver å få en del av programvaren til å mislykkes på en ukontrollert måte, for å teste dens robusthet og oppdage feilpunktet.
I motsetning til andre vanlige programvaretestmetoder som sjekker programvarens funksjonalitet, inspiserer denne metoden den uforutsigbare brukeradferden i programvaren. Så det gjør det mulig for oss å avdekke programvaredefekter som vanligvis ikke oppleves av gjennomsnittlige brukere.
Vær oppmerksom på at destruktiv programvaretesting (DST) er en alternativ tilnærming til konvensjonell programvaretesting (CST), men ikke erstatning. Det er effektivt å utføre sommertid i tillegg til CST.
Destruktiv testing utføres under de strengeste driftsforholdene, og det fortsetter til applikasjonen går i stykker. Hovedideen til denne testingen er ikke bare å avdekke svakhetene i designet, hvis noen som muligens ikke vil bli avslørt under normale arbeidsforhold, men også å oppdage programvareproduktets levetid.
Denne typen testing deler likheter med Monkey Testing, Ad hoc Testing og Exploratory Testing.
Fordeler med destruktiv programvaretesting
hvile api intervju spørsmål og svar
- Det hjelper å måle applikasjonens robusthet, utvinnbarhet og levetid.
- Avdekker feilpunktene i tilfelle upassende eller misbruk av programvaren.
- Den setter riktig kontekst for testeren, da den ignorerer skjevhetene i brukerhistoriene under testing.
- Det gjør det mulig for oss å avdekke programvaredefekter som vanligvis ikke oppleves av gjennomsnittlige brukere.
- Denne typen tester er unik når det gjelder å oppdage feil i applikasjonen som når adressert vil fremme programvarens rangering til nybegynnerfast status.
Fremgangsmåte for å utføre denne testen
- Ved begynnelsen av den destruktive programvaretestsyklusen sender klienten en applikasjonskopi eller tilgangsinformasjon og brukerkrav.
- Kunden presenterer deretter kravene og demonstrerer applikasjonen til en QA-analytiker.
- Deretter etablerer QA-analytikeren funksjonen til grenser i applikasjonen og skaper bruksgrensene for applikasjonen innenfor grensene.
- Nå vil QA-testeren tilfeldig teste applikasjonen innenfor disse grensene ved hjelp av stokastiske teknikker. QA-testens arbeidsflyter og mangler registreres.
- Til slutt deles mangelkatalogen med klienten.
- Hvis det er behov, kan den destruktive testsyklusen gjentas basert på kundens krav.
For denne testingen er det bra å ha litt kunnskap om de opprinnelige kravene til programvaren. Dette hjelper med å komme opp med en god teststrategi.
Hva bekrefter du i Destructive Test?
- Feil og riktig oppførsel av programvaren.
- Gyldige og ugyldige inndata.
- Feil bruk av programvaren.
Destruktive programvaretestmetoder og strategier
Det er flere måter destruktiv testing kan utføres på:
1) Metode for analyse av feilpunkt:
I denne metoden blir applikasjonen gjennomgått og undersøkt for å få tilgang til alle stier og hjørner av den. Det bestemmes hva som kan mislykkes på forskjellige punkter. For denne metoden kan du ta hjelp fra forretningsanalytikere til å få en gjennomgang av applikasjonen.
2) Peer review:
Få applikasjonen vurdert av en testtester som ikke er kjent med programvaren. Dette vil hjelpe deg med å finne noen skjulte feilpunkter som ikke var synlige for deg som tester.
3) Få testsaker gjennomgått av virksomheten:
Sluttbrukerne og andre interessenter kan noen ganger tenke på gyldige testscenarier som en tester kan ha savnet. Så å få testsakene vurdert av virksomheten kan øke testdekningen din.
4) Utforskende testing:
Utfør utforskende testing ved hjelp av løpeark. Det vil hjelpe deg å vite hva som er testet, gjenta testene og kontrollere testdekningen.
5) Gi systemet feil data:
Du kan levere ugyldige inndata til applikasjonen. Dette kan omfatte korrupte data, feil sekvens av trinn på brukergrensesnittet, etc.
6) Bruk andre kilder:
Du kan også bruke andre kilder eller måter å bryte systemet og analysere for forskjellige scenarier. Det som er bra er at brukerhistorien om destruktiv programvaretesting ikke nødvendigvis ber om 'krav' og 'spesifikasjoner', så du kan prøve en hvilken som helst passende måte å utføre denne testen på.
Destruktive testteknikker
Destruktiv programvaretesting kan utføres gjennom forskjellige teknikker som:
- Akseptprøving
- Sløyfetesting
- Regresjonstesting
- Ekvivalenspartisjonering
- Grenseverditesting
- Grensesnitt testing
- Alpha / Beta testing
- Systemtesting
- Testing ovenfra og ned
- Black box testing
Få nyttige tips for destruktiv programvaretesting
- Få så mye kunnskap om produktet du kan. Sett deg inn i skoene til kunden og tenk deretter på produktet fra hans perspektiv.
- Slett all partisk informasjon fra brukerhistorien. Glem brukerbeskrivelsen og akseptkriteriene, og prøv å bryte applikasjonen som en gal kunde.
- Se etter unntaksstiene, ikke de glade stiene. Husk at ved å ignorere akseptkriteriene, vil du ikke vite den forventede eller normale arbeidsflyten.
- Ikke forvent et positivt svar fra søknaden din. Hva om noe mislykkes? Prøv å simulere og ødelegge alt du kan.
- Demp nettverksforholdene dine til et mer realistisk oppsett, fordi alle de virkelige brukerne ikke vil ha førsteklasses maskiner og nettverksforhold.
Hva er ikke-destruktiv testing, og hva er fordelene?
Non-Destructive Testing (NDT) er beskrevet som en programvarevurderingsteknikk som innebærer å samhandle med programvare riktig. I motsetning til destruktiv programvaretesting der vi ser etter unntaksstier, i ikke-destruktiv testing ser vi etter glade stier eller gyldne stier. NDT er også kjent som positiv testing.
For eksempel, hvis det er en inndataboks som aksepterer et tall innen 1-999, vil en positiv testtilfelle være å angi et tall innenfor dette området og verifisere funksjonen til inndataboksen.
binær treimplementering i c ++ kildekode
I NDT har vi en veldefinert testtilfelle ved hjelp av et kjent krav, som utføres uten feil eller unntak og produserer ønsket utdata. Det gir forventede resultater og verifiserer at programvaren fungerer som forventet.
fordeler av ikke-destruktiv programvaretesting
- Forbedret programvarekvalitet og problemer løses i hovedflyten i applikasjonen.
- Nyttig for å demonstrere at programvaren fungerer i samsvar med de nødvendige spesifikasjonene.
- Bekrefter at kundens forventninger er oppfylt.
- Sikrer at ytelseskravene blir oppfylt.
- Sparer både tid og penger i produktevaluering og feilsøking.
Når skal du utføre denne testen
- Det bør være den første testformen og må gjøres i den innledende fasen av SDLC fordi den lykkelige banen er hovedflyten i applikasjonen, og hvis den ikke fungerer bra, blir resten av testingen blokkert.
- Det kan raskt og enkelt gjøres når vi ikke har nok tid og budsjett til å teste. Dette sikrer i det minste at programvarekrav og akseptkriterier blir oppfylt.
Strategi for ikke-destruktiv programvaretesting
- Den positive testtilnærmingen bør brukes for å gjennomføre den ikke-destruktive testen.
- Mens testingen utføres, bør testeren huske at målet med den ikke-destruktive testen er å verifisere at applikasjonen fungerer bra med å gi gyldige inndata. Så målet er å verifisere applikasjonsatferden for det positive datasettet.
- Den beste fremgangsmåten er å sjekke om systemet gjør det det er ment å gjøre.
Forskjellen mellom destruktiv og ikke-destruktiv testing
Destruktiv testing | Ikke-destruktiv testing |
---|---|
Fokuserer på svakhetene i design, men ikke funksjonalitet. | Fokuserer på svakheter i funksjonalitet, men ikke design. |
Trenger ikke nødvendigvis forretningskrav. Destruktiv testing gjøres uten å bli kjent med forhåndsbestemte krav. | Testing gjøres for å verifisere funksjonalitetene mot forretningskrav og akseptkriterier. |
Hensikten er å bryte programvaren ved å levere uvanlige innganger for å oppdage feilpunkter. | Hensikten er å samhandle med programvaren riktig for å verifisere positive resultater. |
Konklusjon
I destruktiv testing blir applikasjonen med vilje krasje for å undersøke robustheten til applikasjonen. Den oppdager feilpunktene i programvaren som kan oppstå på grunn av feil håndtering av applikasjonen fra kunden.
Den oppdager de svake punktene som ikke kan spores ved hjelp av konvensjonell programvaretesting. For bedre testdekning er det foretrukket å gjennomføre destruktiv programvaretesting sammen med konvensjonell programvaretesting.
Ikke-destruktiv testing utføres med positiv testing eller happy path testing tilnærming for å verifisere at programvarefunksjonaliteten oppfyller kundens krav. Det innebærer å samhandle med programvaren riktig.
Anbefalt lesing
- Beste verktøy for testing av programvare 2021 [QA Test Automation Tools]
- Programvaretesting QA Assistant Job
- Programvare Testing Course: Hvilket programvare Testing Institute skal jeg delta?
- Velge programvaretesting som din karriere
- Programvaretesting Teknisk innhold Writer Freelancer Jobb
- Testing Primer eBook Download
- Noen interessante spørsmål om intervjuer med programvaretesting
- Programvaretestkurs Tilbakemelding og anmeldelser