Što je negativno testiranje? Test slučajevi s primjerom

⚡ Pametni sažetak

Negativno testiranje provjerava kako se softverska aplikacija ponaša kada primi neočekivane ulazne podatke ili radne uvjete, tako da se proizvod elegantno degradira umjesto da se ruši, oštećuje podatke ili otkriva sigurnosnu rupu.

  • ???? Svrha: Potvrdite da aplikacija bez problema odbacuje nevažeće podatke umjesto da se ruši ili zakaže.
  • ⚖️ Kontrast: Pozitivno testiranje dokazuje sretan put; negativno testiranje ispituje sve izvan njega.
  • 🛗 Analogija: Dizalo mora izdržati preopterećenje, požar i gubitak struje, ne samo uobičajena putovanja putnika.
  • 🔒 Sigurnost: Nevažeći prijenosi i pokušaji SQL injekcije klasični su scenariji negativnog testiranja.
  • 🧪 Dizajn: Granične vrijednosti, klase ekvivalencije, pogađanje pogrešaka i fuzzing generiraju slučajeve.
  • 📊 Prioritet: Rangirajte nevažeće unose prema utjecaju, jer je iscrpno negativno izvještavanje nedostupno.
  • ⚠️ Kompromis: Prekomjerno negativno testiranje troši proračun koji bi pozitivnim rezultatima moglo trebati više.

Negativno testiranje u testiranju softvera s nevažećim primjerima unosa

Negativno testiranje

Negativno testiranje je vrsta testiranja softvera koja se koristi za provjeru softverske aplikacije u odnosu na neočekivane ulazne podatke i uvjete. Neočekivani podaci ili uvjeti kreću se od pogrešnog tipa podataka u jednostavnom polju obrasca do namjernog hakerskog napada. Svrha negativnog testiranja je spriječiti rušenje aplikacije zbog nevažećeg unosa i poboljšati kvalitetu i stabilnost proizvoda.

Samo pozitivno testiranje dokazuje da sustav radi u normalnim uvjetima. Negativno testiranje potvrđuje da isti sustav rješava i abnormalne uvjete, što je ono što je potrebno za proizvod otporan na greške.

Primjer negativnog testiranja

Dizalo je primjer koji se najčešće koristi za objašnjenje negativnog testiranja, jer je lako zamisliti i njegovo normalno ponašanje i ponašanje pri kvaru.

Zahtjevi za dizalo su poznati: pritiskom na broj kata dizalo se šalje na taj kat, a vrata se automatski otvaraju kada dizalo dosegne određeni kat.

Neki negativni scenariji za isti porast navedeni su u nastavku, uz pretpostavku koju umjesto toga donose pozitivni testovi.

Negativno testiranje Pozitivno testiranje
Što se događa ako broj osoba (težina) premaši navedeno ograničenje? Pretpostavlja se da će u lift ući samo određeni broj osoba
Što se događa ako netko puši ili izazove požar unutar dizala? Pretpostavlja se da neće biti dima ili vatre unutar dizala
Što se događa ako tijekom rada nestane struje? Pretpostavlja se da neće biti nestanka struje dok lift radi

Svi ovi slučajevi spadaju pod negativne testove. Ni za jedan od njih ne može se jamčiti da se nikada neće dogoditi, stoga svaki od njih mora biti obuzdan.

Pretpostavimo da se stanje prekomjernog opterećenja nikada ne provjerava i da se dizalo ponaša abnormalno nakon što je preopterećeno. Taj jedan prekid šteti pouzdanosti sustava i može čak ugroziti život. To je ono što negativno testiranje znači u praksi i zašto je važno.

Softver se ponaša na isti način. Negativan test namjerno odstupa od normalnog operativnog postupka. Razmotrite obrazac za registraciju.

Negativno testiranje Pozitivno testiranje
Unesite nevažeći ID e-pošte u polje za e-poštu U polje za e-poštu unose se samo valjane adrese e-pošte
Unesite nevažeći telefonski broj, kao što su znakovi, u polje za telefonski broj U polje za brojeve unose se samo brojevi
Prenesite sliku veličine izvan navedene granice Prenose se samo slike unutar navedene granice veličine
Prenesite nevažeće datoteke kao što su XML or SQL datoteke u polju za prijenos slike Prenose se samo valjani formati slika kao što su .jpg ili .png

Svaki od ovih negativnih slučajeva ipak mora omogućiti sustavu da radi. Ako se znak upiše u polje za broj, aplikacija ne može obraditi neočekivane podatke koje nikada nije očekivala i može se srušiti. Još gore, SQL injekcija Niz u istom polju mogao bi izbrisati sadržaj baze podataka. Gubici te vrste su razlog zašto postoje negativni testovi.

Zašto raditi negativan test?

Testiranje troši vrijeme i novac, stoga je važno odlučiti što, kako i koliko testirati. Argumenti za trošenje dijela tog proračuna na negativno testiranje izgledaju drugačije s obje strane projekta.

Organizacijska perspektiva

Isporuka kvalitetnog proizvoda klijentu odgovornost je organizacije, a negativno testiranje dio je te obveze. To je ujedno i dokaz organizacije da je učinila sve razumno kako bi spriječila kvar, iako nijedan sustav nije potpuno bez grešaka.

Utjecaj je odlučujući faktor. Web-mjesto za e-trgovinu može proći svaki pozitivan test, a ipak sadržavati rupu u zakonu koja napadaču omogućuje pokretanje SQL injekcije i brisanje podataka iza nje. To je ozbiljno kršenje sigurnosti i samo negativno testiranje ga traži.

Javno dostupne aplikacije, posebno web stranice, gotovo da ne nude kontrolu nad načinom na koji ih posjetitelji koriste, pa je negativno testiranje jedini način da se potvrdi da je neuobičajena upotreba pokrivena i obuzdana. Isto vrijedi i za zlonamjerne korisnike: napadači aktivno traže priliku za probijanje sustava, a scenariji hakiranja svakako spadaju u pokrivenost negativnim testiranjem.

Perspektiva klijenta

Klijenti očekuju proizvod bez ikakvih ranjivosti, a negativno testiranje je ono što podržava to očekivanje. Za osjetljive proizvode poput e-trgovine ili online trgovanja dionicama, testiranje sigurnosti i negativni testovi su obvezni, a ne izborni.

Klijentova jedina stvarna briga su troškovi. Nakon što se analizira utjecaj kvara, klijent je u poziciji odlučiti koliko daleko treba ići napor negativnog testiranja.

Kako napraviti negativno testiranje

Negativno testiranje započinje razmatranjem svakog ulaza koji aplikacija fizički može primiti, ne samo ulaza koje bi trebala primiti. Svaki od njih pripada u Testni slučaj čak i kada je očito pogrešan način korištenja značajke. Polje e-pošte testira se sa svime što nije valjana adresa e-pošte, a kontrola prijenosa slike testira se sa svakom vrstom datoteke koja nije slika.

Popis mogućih nevažećih unosa je zapravo beskonačan, pa negativni testni slučajevi moraju imati prioritet. Za polje slike koje prihvaća samo .png datoteke, kandidati za prijenos uključuju .jpeg, .xml, .xls i mnoge druge. XML ili SQL datoteka ima daleko veći potencijalni utjecaj od .jpeg datoteke, pa se ti slučajevi izvršavaju prvi. Rangiranje slučajeva prema utjecaju prije izvršavanja ono je što negativno testiranje održava pristupačnim.

Većina negativnih testnih slučajeva dolazi iz malog skupa utvrđenih tehnika dizajna, a ne iz improvizacije:

  • Granične vrijednosti: primijenite vrijednosti neposredno izvan valjanog raspona, kao što su 0 i 101 za polje koje prihvaća vrijednosti od 1 do 100.
  • Nevažeće klase ekvivalencije: odaberite jednog predstavnika iz svake klase odbačenih ulaznih podataka, na primjer slova u numeričkom polju.
  • Greška u pogađanju: iskoristite iskustvo prošlih nedostataka kako biste ciljali ulazne podatke koji najvjerojatnije mogu oštetiti ovu vrstu značajke.
  • Neispravni i neprijateljski podaci: oznake skripti, SQL fragmenti i preveliki korisni sadržaji koji ispituju validaciju i sigurnosnu obradu.
  • Fuzz testiranje: automatski generirati velike količine slučajnih ili mutiranih ulaznih podataka kako bi se pronašli neobrađeni padovi sustava.
  • Prekinuti tokovi: otkazivanje, osvježavanje, istek vremena ili gubitak veze tijekom transakcije.

Bez obzira na tehniku ​​koja rezultira slučajem, očekivani rezultat mora se zapisati kao kontrolirani, čitljivi neuspjeh - poruka o validaciji, odbijeni prijenos, čisto vraćanje na prethodnu verziju - a nikada samo kao "sustav se ne ruši".

Prednosti i nedostaci negativnog testiranja

Kao i svaka druga tehnika testiranja, negativno testiranje ima prednosti i nedostatke koji ovise o tome gdje, kada i koliko se primjenjuje.

Prednosti negativnog testiranja

  • Izravno štiti kvalitetu proizvoda, jer je kvalitetan proizvod onaj bez ranjivosti koje se mogu iskoristiti.
  • Proširuje pokrivenost. Nevažeći unosi dospijevaju u aktivni sustav namjerno ili slučajno, pa negativni slučajevi moraju se pojavljivati ​​uz pozitivne da bi pokrivenost bila smislena.
  • To povećava povjerenje klijenata prije nego što se izdanje objavi.
  • Otkriva nedostatke koje pozitivno testiranje strukturno ne može dosegnuti, kao što su neobrađeni iznimci i slaba validacija ulaza.

Nedostaci negativnog testiranja

  • U nekim situacijama to je gubljenje vremena i energije. Ako je aplikacija izgrađena za jednog korisnika, slučaj sa 100 istovremenih korisnika se ne isplati testirati, stoga je odabir pravih uvjeta važan i nekim sustavima je uopće potrebno vrlo malo negativnih testova.
  • Za dizajniranje kućišta potrebni su vješti i iskusni ljudi.
  • S gledišta klijenta to povećava troškove i može odgoditi objavu.
  • Natječe se za trud. Tim koji mnogo troši na negativno testiranje može na kraju nedovoljno ulagati u pozitivno testiranje.

Pitanja i odgovori

Pozitivno testiranje daje valjane podatke i potvrđuje očekivani rezultat. Negativno testiranje daje nevažeće podatke, pogrešne formate i oštećene sekvence te potvrđuje da ih aplikacija odbacuje kontroliranom porukom umjesto da označi neuspjeh.

Prazne vjerodajnice, valjani korisnik s pogrešnom lozinkom, SQL fragmenti u korisničkom imenu, predugi nizovi znakova, početni ili završni razmaci, onemogućeni računi i ponovljeni neuspjeli pokušaji potvrde funkcioniranja zaključavanja.

Ne. Preklapaju se tamo gdje je uključen nevažeći ili neprijateljski unos, ali sigurnosno testiranje također obuhvaća autentifikaciju, autorizaciju, šifriranje i rukovanje sesijama. Negativno testiranje je šira tehnika unosa i uvjeta.

Obično ih pišu testeri i inženjeri osiguranja kvalitete, često uz programera koji pregledava putanje pogrešaka i poslovnog analitičara koji potvrđuje koje nevažeće uvjete zahtjevi zapravo zabranjuju.

Dovoljno da pokrije svaku odbačenu ulaznu klasu, svaku granicu i svaki put kvara s velikim utjecajem. Osim toga, dodani slučajevi vraćaju malu vrijednost, pa rizik i utjecaj postavljaju kraj.ping točka.

Da. Slučajevi nevažećeg unosa se često ponavljaju, pa su prikladni ispitivanje automatizacije i regresijske pakete. Alati za fuzzing automatiziraju generiranje slučajnih ulaza, dok tvrdnje provjeravaju pojavljuju li se poruke validacije.

Modeli čitaju zahtjeve ili shemu obrasca i predlažu nevažeće vrijednosti, granične uvjete i neprijateljske nizove koje tester ne smije ručno navesti. Recenzent i dalje potvrđuje da svaki očekivani rezultat odgovara specifikaciji.

Da, izrađuje kod tvrdnje, postavke nevažećih podataka i parametrizirane slučajeve iz postojeće testne datoteke. Generirana očekivanja treba pregledati jer tvrdnja koja izgleda uvjerljivo može kodirati pogrešno ponašanje.

Sažmite ovu objavu uz: