Hva er destruktiv testing i programvare?
Thomas Hamilton
⚡ Smart oppsummering
Destruktiv testing presser bevisst et program til det feiler, og avslører de nøyaktige punktene der robustheten bryter sammen under feil bruk, ugyldig input og uforutsigbar oppførsel som vanlige funksjonskontroller aldri når.
Hva er destruktiv testing?
Destruktiv testing er en metode for programvaretesting som brukes til å finne feilpunkter i et program. I denne teknikken blir et program med vilje gjort til å feile, slik at robustheten kan kontrolleres og feilpunktene identifiseres. I motsetning til testmetoder som verifiserer hva programmet skal gjøre, undersøker destruktiv testing uforutsigbar brukeratferd inne i programmet.
Kunnskap om de opprinnelige kravene er ikke nødvendig for destruktiv testing. Litt kunnskap hjelper imidlertid i utviklingenping en god teststrategi.
Illustrasjonen nedenfor fanger opp ideen – testeren jobber mot produktet i stedet for med det.
Hvorfor utføre destruktiv testing?
- Det hjelper å forstå forutsigbar programvareoppførsel når programvaren brukes feil.
- Det hjelper å sjekke robustheten til et programvareprodukt.
- Den avdekker sjeldne feil som vanlige brukere aldri utløser, men som dukker opp senere i produksjonen.
Destruktiv testing vs. ikke-destruktiv testing
De to tilnærmingene er komplementer, ikke rivaler. Ikke-destruktiv testing – også kalt positiv testing eller happy-path-testing – samhandler med programvaren på riktig måte og lar bygget være intakt. Destruktiv testing gjør det motsatte: den mater ugyldige data og feil sekvenser inntil noe går i stykker.
| Aspekt | Destruktiv testing | Ikke-destruktiv testing |
| Intent | Tving applikasjonen til å mislykkes | Bekreft at applikasjonen fungerer som spesifisert |
| Inndata brukt | Ugyldig, feilformet, utenfor rekkevidde, utenfor sekvens | Gyldige data innenfor forventet område |
| Spørsmål besvart | Hvor og hvordan går det i stykker? | Gjør den det den skal? |
| Kravkunnskap | Valgfritt | Viktig |
| Typisk kostnad | Høyere — utforskende og åpent | Nedre – skrevet og repeterbar |
| Utfallet | Feilpunkter, rekkeviddegrenser, gjenopprettingsatferd | Bestått eller ikke bestått i henhold til spesifikasjonen |
Hva sjekker du i destruktiv testing?
Destruktiv testing ser på begge sider av atferdsgrensen:
- Riktig programvareoppførsel
- Feil programvareoppførsel
- Feil bruk
- Feil inndata
- Riktige utdata
To betingelser må være oppfylt gjennom hele øvelsen:
- Programvaren skal aldri behandle eller godta ugyldige inndata.
- Uavhengig av gyldigheten eller korrektheten til inndataene, bør programvaren alltid produsere riktige utdata.
Hvordan utføre destruktiv testing?
Destruktiv testing involverer mange aktiviteter, som å designe et sett med testskript, kjøre disse skriptene, rapportere feil, lukke feil og gi bestått- eller ikke-bestått-målinger til interessenter på slutten av iterasjonen.
Det finnes mange måter å kjøre det på. Noen eksempler følger.
- Metode for analyse av feilpunkt: en gjennomgang av systemet som vurderer hva som kan gå galt på ulike punkter. Hjelp fra en forretningsanalytiker kan tas for denne strategien.
- Fagfellevurdering av tester: få din test tilfeller analysert eller gjennomgått av en medtester som er mindre kjent med systemet eller funksjonen.
- Forretningsgjennomgang av testtilfeller: Sluttbrukere eller eksperter tenker ofte på gyldige scenarier som testere overser, fordi testernes fokus ligger på de angitte kravene.
- Utfør utforskende testing ved hjelp av kjøreskjemaer: utforskende testing Med kjøreskjemaer registreres hva som ble testet, det er mulig å gjenta testene og testdekningen holdes under kontroll.
- Bruk en annen kilde: be noen andre om å ødelegge programvareproduktet og analysere scenariene de finner.
Eksempel på destruktiv testing
Tenk på innloggings- og profilskjermene i en bankapplikasjon. En destruktiv passasje ville fungere gjennom tilfeller som disse:
- Lim inn en streng på 5,000 tegn i et felt som er begrenset til 50 tegn, og bekreft at feltet avviser den i stedet for å avkortes stille.
- Send inn bokstaver, symboler og negative verdier i et numerisk beløpsfelt.
- Bryt den forventede sekvensen – åpne betalingsbekreftelsessiden direkte uten å fullføre det foregående trinnet.
- Trykk send gjentatte ganger og i rask rekkefølge for å se om det opprettes dupliserte poster.
- Koble fra nettverket midt i en transaksjon og sjekk om applikasjonen gjenoppretter seg uten problemer eller om den etterlater en delvis oppføring.
Hvert tilfelle har en definert forventning: en tydelig valideringsmelding, ingen datakorrupsjon og ingen ubehandlede unntak. Alt annet er et feilpunkt som er verdt å nevne som en mangel.
Destruktive testmetoder
Følgende metoder brukes i programvareteknikk for å oppnå mål for destruktiv testing:
- Alfa-/betatesting
- Regresjonstesting
- Testing av grensesnitt
- Ekvivalenspartisjonering
- Sløyfetesting
- Aksepttesting, og så videre
Destruktive testteknikker
Teknikkene nedenfor kan brukes med modifikasjoner:
- Testing av hvit boks
- Sikkerhetstesting
- Feiltesting
- Røykprøving, og så videre
Tilstøtende teknikker som er verdt å legge til når robusthet er målet er negativ testing, stresstesting, gjenopprettingstesting og fuzz testing.
Fordeler og ulemper med destruktiv testing
Avveiningen er verdt å si tydelig før teknikken planlegges utgitt.
Fordeler
- Revavdekker feilpunkter som spesifikasjonsdrevet testing aldri når.
- Etablerer reelle rekkeviddegrenser, slik at produktet kan brukes inni dem med trygghet.
- Avslører sjeldne feil som dukker opp i produksjonen lenge etter lansering.
- Kontrollerer holdbarhet, gjenopprettingsevne og feilhåndtering under misbruk.
Ulemper
- Åpen av natur, så dekning kan ikke garanteres eller måles enkelt.
- Tidkrevende og avhengig av testerens erfaring og kreativitet.
- Funn kan være vanskelig å reprodusere uten nøye loggføring av trinnene som er brukt.
- Dårlig kontrollerte kjøringer kan ødelegge delte testdata, så et isolert miljø er nødvendig.
