how classify positive
Nekaj lahko naredite na preprost ali težji način - pomembno je, da to storite. Preprostih vsakdanjih stvari je malo, toda brez samozavesti nekaj o njih ne ustreza povsem našim miselim in obseg uspeha je zadetek ali pogreška.
Vzemimo danes en preprost primer in poiščimo bližnjice, ki ne bodo le razjasnile konceptov, temveč tudi poskrbele, da boste vedno prišli prav.
Pozitivna ali negativna klasifikacija testnih scenarijev / primerov
Postopek zasnove testa je 3-krat:
- Ugotovite zahteve
- Napišite testne scenarije (enovrstični kazalci, kaj preizkusiti)
- Oblikujte podrobna navodila za testiranje (testni primeri)
Pri pisanju testnih scenarijev jih razvrstimo v pozitivne in negativne pogoje. (Ko pomislite, je res pomembno, da naredite to razvrstitev? Če je odgovor pritrdilen, kateremu namenu služi? Vsekakor jih moramo vse preizkusiti, kajne?) Večinoma tudi mene premaga. Mislim pa, da gre za poskus vzpostavitve ustrezne pokritosti in pomaga ugotoviti, da preizkušamo tako srečno kot nadomestno pot, ki naj bi jo sistem obvladal. Prosimo, komentirajte spodaj, če poznate druge razloge, zakaj je to storjeno.
Zdaj pa si oglejmo nekaj zahtev, napišite testne scenarije in izvedite razvrstitev.
# 1) Prijava :Uporabnik, ki vnese pravilne poverilnice, vstopi v sistem. Če poverilnice niso pravilne, se dostop zavrne in prikaže se sporočilo o napaki.
# 2) Oglejte si izdelke: Predpostavimo, da obstaja spletni katalog vseh izdelkov, ki so na voljo v sistemu, in jih prikaže na seznamu, ko kliknete povezavo »Ogled izdelkov«.
# 3) Odjava: Ko klikne to povezavo, se uporabnik odjavi.
Za te zahteve bom napisal nekaj testnih scenarijev.
Tabela A:Prava pot
ID scenarija preskusa | Opis testnega scenarija | Pozitivno / negativno |
---|---|---|
TS_login_01 | Preverite, ali se uporabnik uspešno prijavi, če so vnesene poverilnice pravilne | Pozitivno |
TS_login_02 | Preverite, če uporabnik nima dovoljenja za dostop, če so vnesene poverilnice napačne | Negativno |
TS_ViewProduct_01 | Potrdite, če so na seznamu vsi izdelki navedeni, ko kliknete povezavo Ogled izdelkov | Pozitivno |
TS_logout_01 | Preverite, ali je že prijavljeni uporabnik odjavljen iz sistema, ko kliknete odjavo | Pozitivno |
Vendar včasih vidim testni scenarij, napisan tako.
Tabela B: Vnosi označeniMrežaso neveljavni testni scenariji.
ID scenarija preskusa | Opis testnega scenarija | Pozitivno / negativno |
---|---|---|
TS_login_01 | Preverite, ali se uporabnik uspešno prijavi, če so vnesene poverilnice pravilne | Pozitivno |
TS_login_02 | Preverite, če uporabnik nima dovoljenja za dostop, če so vnesene poverilnice napačne | Negativno |
TS_ViewProduct_01 | Potrdite, če so na seznamu vsi izdelki navedeni, ko kliknete povezavo Ogled izdelkov | Pozitivno |
TS_ViewProduct_02 | Potrdite, če vsi elementi niso navedeni, ko kliknete povezavo za ogled izdelkov | Negativno |
TS_logout_01 | Preverite, ali je že prijavljeni uporabnik odjavljen iz sistema, ko kliknete odjavo | Pozitivno |
TS_logout_02 | Preverite, če se uporabnik ne odjavi, ko klikne povezavo za odjavo | Negativno |
Za uspešen primer prijave obstaja enak in nasproten primer, ko ne bo uspešen. Vse zahteve naj ne bi bile takšne in zanje res ni prisiljevanja pisati negativnega scenarija.
Bottom line: Vsaka zahteva ne sme imeti negativnih primerov.
Na tem mestu, če razmišljate »Kako bom vedel« ali »še vedno nisem prepričan«, je tukaj preprosta goljufanja, ki vam bo v pomoč.
brezplačna spletna mesta za pretakanje anime v angleškem jeziku sinhronizirana
Če obstaja ena posplošitev glede aplikacij, je ta, da so dinamične. Vnos (podatki, kliki itd.), Ki ga zagotovimo, bo povzročil, da bo aplikacija določena in bo ustvarila določen izhod.
Preprosta korelacija med vhodnimi in izhodnimi spremenljivkami bo to olajšala za razumevanje.
Poskusimo naslednje za prijavo:
Vhod | Izhod | Pozitivno / negativno |
---|---|---|
Pravilno (pravilni podatki za prijavo) | Pravilno (uporabnik prijavljen) | Pozitivno |
Napačno (napačni podatki za prijavo) | Pravilno (sporočilo o napaki) | Negativno |
Pravilno (pravilni podatki za prijavo) | Napačno - prijava ne uspe | Napaka / napaka |
Napačno (napačni podatki za prijavo) | Napačno (sistem jih prijavi) - 'Oh, groza!' :) | Napaka / napaka |
Torej, kot vidite iz zgornje tabele, lahko rečemo, da primarni pretok kategoriziramo kot pozitiven, nadomestni pretok (tudi pravilno vedenje aplikacije) pa označimo kot negativnega.
Zadnja dva primera v rdeči barvi sta pravzaprav hrošča. Testiranje se nanaša na potrjevanje zahtev in kadar ne delujejo, kot je bilo predvideno, najdemo napake. Ker ne gremo za preverjanje napak, zadnja dva primera sta neveljavna.
Če sledite istemu razmišljanju in ga uporabite za odjavo in ogled izdelkov, boste dobili naslednje.
Vhod | Izhod | Pozitivno / negativno |
---|---|---|
Odjava (klik) | Pravilno - Odjava | Pozitivno |
Odjava (klik) | Napačno - ostane prijavljen | Napaka / napaka |
Ogled izdelkov (klik) | Pravilno - prikaže izdelke | Pozitivno |
Ogled izdelkov (klik) | Napačno (ni seznama ali napačen prikaz seznama) | Napaka / napaka |
Kot lahko vidite, za te zahteve ni možnosti napačnega vnosa. Zato ni treba pisati negativnih testnih scenarijev / primerov.
Zaključne misli:
Sistem je lahko izpostavljen pozitivnemu ali negativnemu vnosu. Kakor koli že, sistem bi moral ustvarjati pravilne rezultate. Primeri, ki se navadno ukvarjajo s pravilnim vnosom, so pozitivni. Tisti, ki so približno pravilni, a negativni, so negativni.
Nekaj napotkov:
# 1) Ko se primeri od konca do konca so napisani za UAT ali celo sistemsko testiranje, so vedno pozitivni testni primeri tisti, ki pridejo v tok.
#two) Včasih je klasifikacija subjektivna.Na primer, če nekaj brišem na spletnem mestu in prejmem potrditveno sporočilo, ki me vpraša 'Ali ste prepričani, da želite izbrisati ta vnos?' z možnostmi OK in Cancel - po mojem kliku na Cancel je pozitiven primer. Toda nekateri menijo, da je negativno, saj je glavni namen možnosti »Izbriši« izbrisati in ne preklicati operacije. Torej presodni preizkus tudi igra vlogo pri razvrščanju.
# 3) Za vsak pozitiven primer ni vedno enakega in nasprotnega negativnega primera.
Zgornja metoda vedno zagotavlja pravilno razvrstitev. Poskusite sami in mi povejte, če ne. :) »Bližnjica je pogosto napačen rez.« - Toda v tem primeru morda ne bo!
Za bolj formalno razlago negativnega testiranja preverite => Kaj je negativno testiranje in kako pisati negativne testne primere?
O avtorju: Ta članek je napisala članica ekipe STH Swati S. Pridružite se njenemu tečaju QA v živo tukaj: “ Najboljše usposabljanje za testiranje programske opreme, ki ste ga kdaj prejeli! '
Sporočite nam, ali vam je ta članek všeč in želite v naslednjih člankih videti takšne osnovne koncepte, ki so zlahka razloženi.
Vaši komentarji, vprašanja, povratne informacije in bralstvo so tukaj na STH zelo cenjeni in cenjeni. Srečno testiranje!
Priporočeno branje
- Pozitivno testiranje: pomen in zasluge razloženi z resničnimi testnimi scenariji
- Kako napisati testne primere za prijavno stran (vzorčni scenariji)
- Kaj je negativno testiranje in kako pisati negativne testne primere?
- Kako napisati testne primere za bankomat (vzorčni scenariji)
- Učinkoviti scenariji za skriptiranje in odpravljanje težav s selenijem - Vadnica za selenij št. 27
- Vrste preskušanja selitev: s preskusnimi scenariji za vsako vrsto
- Vadnica QTP # 24 - Uporaba navideznih predmetov in scenarijev obnovitve v preskusih QTP
- Testiranje aplikacij v zdravstvu - nasveti in pomembni testni scenariji (2. del)