how classify positive
Nešto možete učiniti na lakši ili teži način - važno je da to učinite. Postoji nekoliko jednostavnih svakodnevnih stvari, ali bez samopouzdanja nešto u vezi s njima ne stoji nam sasvim u glavi i opseg uspjeha je pogodak ili promašaj.
Uzmimo danas jedan jednostavan primjer i pronađite prečace koji će ne samo razjasniti koncepte već i osigurati da ćete ih uvijek ispravno shvatiti.
Pozitivna ili negativna klasifikacija testnih scenarija / slučajeva
Postupak dizajna testa je trostruki:
- Utvrdite zahtjeve
- Napišite scenarije testiranja (pokazivači u jednom retku što testirati)
- Dizajnirajte detaljne upute o načinu testiranja (test slučajevi)
Pri pisanju testnih scenarija klasificiramo ih u pozitivne i negativne uvjete. (Kad malo bolje razmislite, je li zaista važno napraviti ovu klasifikaciju? Ako da, kojoj svrsi služi? Sve ih ionako moramo testirati, zar ne?) I mene većinom tuče. Ali mislim da je to pokušaj uspostavljanja odgovarajuće pokrivenosti i pomaže utvrditi da testiramo i sretne i alternativne putove koje bi sustav trebao podnijeti. Molimo komentirajte u nastavku ako znate iz bilo kojih drugih razloga zašto je to učinjeno.
Pogledajmo sada nekoliko zahtjeva, napišite testne scenarije i izvedite klasifikaciju.
# 1) Prijava :Korisnik koji unese ispravne vjerodajnice ulazi u sustav. Ako su vjerodajnice netočne, pristup je odbijen i prikazuje se poruka o pogrešci.
# 2) Pogledajte proizvode: Pretpostavimo da postoji mrežni katalog svih proizvoda dostupnih u sustavu i on ih sve prikazuje na popisu kada se klikne na vezu 'Pregled proizvoda'.
# 3) Odjava: Kada se klikne na ovu vezu, korisnik se odjavi.
Napisat ću nekoliko scenarija ispitivanja za ove zahtjeve.
Tablica A:Pravi put
ID scenarija testa | Opis scenarija ispitivanja | Pozitivno negativno |
---|---|---|
TS_login_01 | Potvrdite ako se korisnik uspješno prijavi ako su unijete vjerodajnice točne | Pozitivan |
TS_login_02 | Potvrdite ako korisnik nema dozvolu pristupa kada su unesene vjerodajnice netočne | Negativan |
TS_ViewProduct_01 | Potvrdite jesu li sve stavke navedene kada se klikne na vezu Prikaži proizvode | Pozitivan |
TS_logout_01 | Potvrdite ako je već prijavljeni korisnik odjavljen iz sustava kad se klikne na odjavu | Pozitivan |
Međutim, ponekad vidim testni scenarij napisan ovako.
Tablica B: Označeni unosiNetosu nevaljani testni scenariji.
ID scenarija testa | Opis scenarija ispitivanja | Pozitivno negativno |
---|---|---|
TS_login_01 | Potvrdite ako se korisnik uspješno prijavi ako su unijete vjerodajnice točne | Pozitivan |
TS_login_02 | Potvrdite ako korisnik nema dozvolu pristupa kada su unesene vjerodajnice netočne | Negativan |
TS_ViewProduct_01 | Potvrdite jesu li sve stavke navedene kada se klikne na vezu Prikaži proizvode | Pozitivan |
TS_ViewProduct_02 | Potvrdite ako sve stavke nisu na popisu kada se klikne veza za pregled proizvoda | Negativan |
TS_logout_01 | Potvrdite ako je već prijavljeni korisnik odjavljen iz sustava kad se klikne na odjavu | Pozitivan |
TS_logout_02 | Potvrdite ako se korisnik ne odjavi kad se klikne na vezu za odjavu | Negativan |
Za uspješan slučaj prijave postoji jednak i suprotan slučaj kada neće biti uspješan. Ne bi trebali svi zahtjevi biti takvi i za njih zapravo ne postoji prisiljavanje na pisanje negativnog scenarija.
Dno crta: Ne bi svaki zahtjev trebao imati negativne slučajeve.
Ako u ovom trenutku razmišljate 'Kako ću znati' ili 'još uvijek nisam siguran', evo jednostavnog varalica koje će vam pomoći.
koji je etl alat najbolji na tržištu
Ako postoji jedna generalizacija koju možemo primijeniti u vezi s aplikacijama, jest da su dinamične. Unos (podaci, klikovi itd.) Koji pružamo uzrokovat će da aplikacija bude na određeni način i generira određeni izlaz.
Jednostavna korelacija između ulaznih i izlaznih varijabli olakšat će ovo razumijevanje.
Isprobajmo sljedeće za prijavu:
Ulazni | Izlaz | Pozitivno negativno |
---|---|---|
Točno (točni podaci za prijavu) | Točno (korisnik prijavljen) | Pozitivan |
Netočno (netočni podaci za prijavu) | Točno (poruka o pogrešci) | Negativan |
Točno (točni podaci za prijavu) | Netočno - prijava ne uspijeva | Bug / Defekt |
Netočno (netočni podaci za prijavu) | Netočno (sustav ih prijavljuje) - 'Oh, užas!' :) | Bug / kvar |
Dakle, vidite iz gornje tablice, možemo reći da primarni protok kategoriziramo kao pozitivan, a zamjenski protok (također ispravno ponašanje aplikacije) označen je kao negativan.
Posljednja dva slučaja u crvenoj boji zapravo su greške. Testiranje se odnosi na provjeru valjanosti zahtjeva i kad oni ne rade kako je predviđeno, pronalazimo pogreške. Budući da ne provjeravamo nedostatke, posljednja dva slučaja nisu valjana.
Slijedeći isti smisao razmišljanja i primjenjujući ga na odjavi i prikazivanju proizvoda, evo što ćete dobiti.
Ulazni | Izlaz | Pozitivno negativno |
---|---|---|
Odjava (klik) | Točno - odjava | Pozitivan |
Odjava (klik) | Netočno - ostaje prijavljen | Bug / kvar |
Pogledajte proizvode (kliknite) | Ispravno - prikazuje proizvode | Pozitivan |
Pogledajte proizvode (kliknite) | Netočno (nije popis ili netočan prikaz popisa) | Bug / kvar |
Kao što vidite, za ove zahtjeve ne postoji mogućnost davanja netočnog unosa. Stoga ne moraju biti napisani negativni scenariji / slučajevi ispitivanja.
Zaključne misli:
Sustav može biti izložen pozitivnom ili negativnom inputu. U svakom slučaju, sustav bi trebao generirati ispravan izlaz. Slučajevi koji se teže baviti ispravnim unosom su pozitivni. Oni koji su približno točni, ali negativni unosi su negativni.
Nekoliko uputa:
# 1) Kad an slučajevi od kraja do kraja su napisani za UAT ili čak testiranje sustava, uvijek pozitivni testni slučajevi uđu u tok.
#dva) Klasifikacija je ponekad subjektivna.Na primjer, ako brišem nešto na web mjestu i primim poruku potvrde koja me pita 'Jeste li sigurni da želite izbrisati ovaj unos?' s opcijama OK i Cancel - po meni je klik na odustajanje pozitivan slučaj. Ali neki misle da je negativan jer je primarna namjera opcije 'Izbriši' brisanje, a ne otkazivanje operacije. Dakle, prosudba ispitivača također igra ulogu u klasifikaciji.
# 3) Za svaki pozitivan slučaj ne postoji uvijek jednak i suprotan negativni slučaj.
Gornja metoda uvijek jamči ispravnu klasifikaciju. Pokušajte sami i recite mi ako ne. :) „Prečac je često pogrešan rez.“ - Ali u tom slučaju to možda nije slučaj!
Za formalnije objašnjenje negativnog testiranja, provjerite => Što je negativno testiranje i kako pisati negativne test slučajeve?
O autoru: Ovaj članak napisala je članica STH tima Swati S. Pridružite se njenom QA tečaju uživo ovdje: “ Najbolji trening za testiranje softvera koji ćete ikad dobiti! '
Obavijestite nas ako vam se svidio ovaj članak i želite li vidjeti takve osnovne pojmove koji će se lako objasniti u narednim člancima.
Ovdje u STH cijenimo i cijenimo vaše komentare, pitanja, povratne informacije i čitateljstvo. Sretno testiranje!
Preporučena literatura
- Pozitivno testiranje: značenje i zasluge objašnjeni stvarnim scenarijima ispitivanja
- Kako napisati test slučajeve za stranicu za prijavu (primjeri scenarija)
- Što je negativno testiranje i kako pisati negativne test slučajeve?
- Kako napisati test slučajeve za bankomat (primjeri scenarija)
- Učinkoviti scenariji za skriptiranje i rješavanje problema sa selenijem - Vodič za selenij br. 27
- Vrste testiranja migracije: sa scenarijima ispitivanja za svaku vrstu
- QTP vodič # 24 - Korištenje virtualnih objekata i scenarija oporavka u QTP testovima
- Testiranje zdravstvenih aplikacija - Savjeti i važni scenariji ispitivanja (2. dio)