Što je destruktivno testiranje u softveru?

⚡ Pametni sažetak

Destruktivno testiranje namjerno forsira softversku aplikaciju dok ne zakaže, otkrivajući točne točke gdje robusnost narušava zbog nepravilne upotrebe, nevažećih unosa i nepredvidivog ponašanja do kojih obične funkcionalne provjere nikada ne dosežu.

  • 💥 Osnovna ideja: Aplikacija je namjerno napravljena da ne uspije kako bi njezine točke kvara postale vidljive i mjerljive.
  • 🔎 Nisu potrebni zahtjevi: Prethodno poznavanje specifikacije nije obavezno, iako poboljšava strategiju testiranja.
  • ⚖️ Suprotni par: Nerazorna ispitivanja hodaju sretnim putem; destruktivna ispitivanja ga napadaju iz svakog pogrešnog kuta.
  • 🧰 Pristupi: Analiza točaka kvara, međusobna ocjena testera, pregled poslovanja i istraživački radovi s radnim listovima.
  • 🧪 Ponovno korištene metode: Regresija, sučelje, particioniranje ekvivalencije, testiranje petlje i prihvaćanja služe destruktivnim ciljevima.
  • 📉 Iskrene granice: Teško je jamčiti pokrivenost, trud je velik, a nalaze može biti teško reproducirati.

Što je destruktivno testiranje u softveru s metodama i tehnikama

Što je destruktivno testiranje?

Destruktivno ispitivanje je metoda testiranja softvera koja se koristi za pronalaženje točaka kvara u softverskom programu. Kod ove tehnike aplikacija se namjerno stvara da ne uspije, kako bi se mogla provjeriti njezina robusnost i identificirati točke kvara. Za razliku od metoda testiranja koje provjeravaju što bi aplikacija trebala raditi, destruktivno testiranje ispituje nepredvidivo ponašanje korisnika unutar aplikacije.

Poznavanje izvornih zahtjeva nije potrebno za destruktivna ispitivanja. Međutim, određeno znanje pomaže u razvojuping dobra strategija testiranja.

Donja ilustracija prikazuje ideju - tester radi protiv proizvoda, a ne s njim.

Koncept destruktivnog ispitivanja: aplikacija namjerno dovedena do točke kvara

Zašto provoditi destruktivna ispitivanja?

  • Pomaže u razumijevanju predvidljivog ponašanja softvera kada se softver nepravilno koristi.
  • Pomaže provjeriti robusnost softverskog proizvoda.
  • Otkriva rijetke nedostatke koje obični korisnici nikada ne aktiviraju, ali se pojavljuju kasnije u proizvodnji.

Destruktivno ispitivanje u odnosu na nerazorno ispitivanje

Ta dva pristupa se nadopunjuju, a ne suparnici. Ispitivanje bez razaranja - također se naziva pozitivno ili testiranje sretnog puta - ispravno komunicira sa softverom i ostavlja konstrukciju netaknutom. Destruktivno testiranje čini suprotno: unosi nevažeće podatke i pogrešne sekvence dok se nešto ne pokvari.

Aspekt Destruktivno ispitivanje Ispitivanje bez razaranja
Namjera Prisilno prekidanje aplikacije Potvrdite da aplikacija radi kako je navedeno
Korišteni unos Nevažeće, neispravno oblikovano, izvan raspona, izvan redoslijeda Valjani podaci unutar očekivanog raspona
Odgovoreno na pitanje Gdje i kako se lomi? Radi li ono što bi trebalo?
Znanje o zahtjevima Izborni osnovni
Tipični trošak Viša — istraživačka i otvorenog tipa Donje — skriptirano i ponovljivo
Ishod Točke kvara, ograničenja raspona, ponašanje pri oporavku Prolazi ili ne zadovoljava specifikacije

Što se provjerava destruktivnim ispitivanjem?

Destruktivno ispitivanje promatra obje strane granice ponašanja:

  • Ispravno ponašanje softvera
  • Nepravilno ponašanje softvera
  • Nepravilna uporaba
  • Neispravni ulazni podaci
  • Pravilni izlazni podaci

Dva uvjeta moraju biti ispunjena tijekom cijele vježbe:

  • Softver nikada ne smije obrađivati ​​ili prihvaćati nevažeće ulazne podatke.
  • Bez obzira na valjanost ili ispravnost ulaznih podataka, softver bi uvijek trebao proizvesti ispravne izlazne podatke.

Kako napraviti destruktivno testiranje?

Destruktivno testiranje uključuje mnoge aktivnosti, kao što su dizajniranje skupa testnih skripti, izvršavanje tih skripti, prijavljivanje grešaka, zatvaranje grešaka i pružanje metrike prolaza ili neuspjeha dionicima na kraju iteracije.

Postoje brojni načini za njegovo pokretanje. Slijede neki primjeri.

  • Metoda analize točke kvara: pregled sustava koji procjenjuje što bi moglo poći po zlu u raznim trenucima. Pomoć od Poslovni analitičar mogu se uzeti za ovu strategiju.
  • Recenzija testera: uzmi svoj test slučajevi analiziran ili pregledan od strane kolege testera koji je manje upoznat sa sustavom ili funkcijom.
  • Poslovni pregled testnih slučajeva: Krajnji korisnici ili stručnjaci često razmišljaju o valjanim scenarijima koje testeri propuštaju, jer se testeri usredotočuju na navedene zahtjeve.
  • Provedite istraživačko testiranje koristeći radne listove: istraživačko testiranje S radnim listovima bilježi što je testirano, omogućuje ponavljanje testova i drži pokrivenost testovima pod kontrolom.
  • Koristite drugi izvor: zamolite nekoga drugog da razbije softverski proizvod i analizira scenarije koje pronađe.

Primjer destruktivnog ispitivanja

Razmotrite ekrane za prijavu i profil bankarske aplikacije. Destruktivni pristup bi funkcionirao u slučajevima poput ovih:

  • Zalijepite niz od 5,000 znakova u polje ograničeno na 50 znakova i potvrdite da ga polje odbacuje umjesto da ga tiho skraćuje.
  • U polje za numerički iznos unesite slova, simbole i negativne vrijednosti.
  • Prekinite očekivani slijed - otvorite stranicu za potvrdu plaćanja izravno bez dovršavanja prethodnog koraka.
  • Više puta pritisnite tipku za slanje u brzom slijedu kako biste vidjeli jesu li stvoreni duplicirani zapisi.
  • Prekinite vezu s mrežom usred transakcije i provjerite oporavlja li se aplikacija bez problema ili ostavlja djelomičan zapis.

Svaki slučaj ima definirano očekivanje: jasna poruka o validaciji, bez oštećenja podataka i bez neobrađenih iznimki. Sve ostalo je točka kvara koju vrijedi istaknuti kao nedostatak.

Destruktivne metode ispitivanja

Sljedeće metode se koriste u softverskom inženjerstvu za postizanje ciljeva destruktivnog testiranja:

Tehnike razornog ispitivanja

Sljedeće tehnike mogu se koristiti s modifikacijama:

Susjedna tehnika koju vrijedi dodati kada je cilj robusnost je negativno testiranje, testiranje otpornosti na stres, testiranje oporavka i testiranje nejasnoća.

Prednosti i nedostaci destruktivnog ispitivanja

Kompromis je vrijedno jasno navesti prije nego što se tehnika planira uvesti u prodaju.

Prednosti

  • Revotkriva točke kvara do kojih testiranje vođeno specifikacijama nikada ne dolazi.
  • Utvrđuje stvarna ograničenja dometa, tako da se proizvod može s pouzdanjem koristiti unutar njih.
  • Otkriva rijetke nedostatke koji se pojavljuju u proizvodnji dugo nakon puštanja u prodaju.
  • Provjerava trajnost, mogućnost oporavka i rješavanje grešaka u slučaju zloupotrebe.

Nedostaci

  • Otvorene prirode, tako da se pokrivenost ne može lako jamčiti ili mjeriti.
  • Dugotrajan i ovisi o iskustvu i kreativnosti testera.
  • Nalaze može biti teško reproducirati bez pažljivog bilježenja korištenih koraka.
  • Loše kontrolirani radovi mogu oštetiti dijeljene testne podatke, stoga je potrebno izolirano okruženje.

Pitanja i odgovori

Preklapaju se, ali se razlikuju po opsegu. Negativno testiranje provjerava definirane nevažeće ulaze u odnosu na očekivano rukovanje pogreškama. Destruktivno testiranje je šire i otvoreno, tražeći bilo koji uvjet koji uzrokuje neuspjeh aplikacije.

Obično iskusni inženjeri za osiguranje kvalitete, uz podršku kolega koji nisu upoznati s modulom i poslovnih korisnika. Vanjski pogled je važan, jer ljudi koji su izradili značajku obično je testiraju onako kako je dizajnirana.

Nakon što je funkcionalni paket stabilan, kvarovi ukazuju na robusnost, a ne na nedovršene značajke. Mnogi timovi to planiraju tijekom testiranja sustava i ponavljaju prije većih izdanja u životni ciklus testiranja.

Modeli generiraju deformirane korisne terete, granične vrijednosti i neobične nizove akcija u količini koju nijedan tester ne može dostići, a zatim rangiraju koji su proizveli anomalije. Strojno učenje na podacima o prošlim nedostacima također predviđa koji moduli zaslužuju najstroži tretman.

GitHub kopilot brzo izrađuje generatore ulaznih podataka, granične slučajeve i rutine rastavljanja. Ispitivač i dalje odlučuje koji su načini kvara važni i računa li se uočeno ponašanje kao prihvatljiv ishod.

Točan unos ili korišteni slijed, uočeni kvar, zapisnici i snimke zaslona, ​​okruženje i ozbiljnost utjecaja. Metrike prolaza ili neuspjeha za iteraciju idu dionicima uz zapisi o nedostacima.

Nikada ne bi smio doći u produkciju. Pokrenite ga u izoliranom okruženju s podacima koji se mogu oporaviti, jer namjerno nevažeći unosi i prisilni rušenja mogu ostaviti djelomične zapise čije je čišćenje skupo.

Tijekom sesije vodite evidenciju bilježeći svaku radnju i unos redom. Ponovno preslušajte evidenciju iz čistog stanja, a zatim je skratite na najkraći niz koji i dalje uzrokuje kvar.

Sažmite ovu objavu uz: