how classify positive
Puteți face ceva într-un mod ușor sau greu - important este să îl faceți. Există puține lucruri simple de zi cu zi, dar fără încredere, ceva despre ele nu se încadrează în mintea noastră, iar gradul de succes este un succes sau o dorință.
Să luăm un exemplu simplu astăzi și să găsim comenzi rapide care nu numai că vor clarifica conceptele, ci și că ne vom asigura că o vei înțelege întotdeauna.
Clasificarea pozitivă sau negativă a scenariilor / cazurilor de testare
Procesul de proiectare a testului este de 3 ori:
- Identificați cerințele
- Scrieți scenarii de testare (un indicii de linie a ceea ce trebuie testat)
- Proiectați instrucțiuni detaliate despre cum să testați (cazuri de testare)
Atunci când scriem scenarii de testare, le clasificăm în condiții pozitive și negative. (Când vă gândiți la asta, este cu adevărat important să faceți această clasificare? Dacă da, ce scop servește? Trebuie să le testăm oricum, nu-i așa?) Și pe mine mă bate, în mare parte. Dar cred că este o încercare de a stabili o acoperire adecvată și ajută la stabilirea faptului că testăm atât căile fericite, cât și cele alternative pe care sistemul ar trebui să le gestioneze. Vă rugăm să comentați mai jos, dacă cunoașteți orice alte motive pentru care se face acest lucru.
Acum, să analizăm câteva cerințe, să scriem scenarii de testare și să efectuăm clasificarea.
# 1) Autentificare :Un utilizator care introduce acreditări corecte intră în sistem. Dacă acreditările sunt incorecte, accesul este refuzat și se afișează un mesaj de eroare.
# 2) Vizualizați produsele: Să presupunem că există un catalog online cu toate produsele disponibile în sistem și le afișează pe toate într-o listă când se face clic pe linkul „Vizualizare produse”.
# 3) Deconectare: Când se face clic pe acest link, utilizatorul este deconectat.
Voi scrie câteva scenarii de testare pentru aceste cerințe.
Tabelul A:Calea cea buna
| ID scenariu de testare | Descrierea scenariului de testare | Pozitiv negativ |
|---|---|---|
| TS_login_01 | Validați dacă utilizatorul se conectează cu succes dacă acreditările introduse sunt corecte | Pozitiv |
| TS_login_02 | Validați dacă utilizatorului nu i se permite accesul atunci când acreditările introduse sunt incorecte | Negativ |
| TS_ViewProduct_01 | Validați dacă toate articolele sunt listate când se face clic pe linkul Vizualizare produse | Pozitiv |
| TS_logout_01 | Validați dacă utilizatorul deja conectat este deconectat din sistem atunci când faceți clic pe deconectare | Pozitiv |
Cu toate acestea, uneori văd scenariul Test scris astfel.
Tabelul B: Intrări marcateNetsunt scenarii de testare nevalide.
| ID scenariu de testare | Descrierea scenariului de testare | Pozitiv negativ |
|---|---|---|
| TS_login_01 | Validați dacă utilizatorul se conectează cu succes dacă acreditările introduse sunt corecte | Pozitiv |
| TS_login_02 | Validați dacă utilizatorului nu i se permite accesul atunci când acreditările introduse sunt incorecte | Negativ |
| TS_ViewProduct_01 | Validați dacă toate articolele sunt listate când se face clic pe linkul Vizualizare produse | Pozitiv |
| TS_ViewProduct_02 | Validați dacă toate articolele nu sunt listate când se face clic pe linkul pentru vizualizarea produselor | Negativ |
| TS_logout_01 | Validați dacă utilizatorul deja conectat este deconectat din sistem atunci când faceți clic pe deconectare | Pozitiv |
| TS_logout_02 | Validați dacă utilizatorul nu se deconectează când se face clic pe linkul de deconectare | Negativ |
Pentru cazul de succes al conectării, există un caz egal și opus, atunci când nu va avea succes. Nu se presupune că toate cerințele trebuie să fie așa și pentru ei, nu există într-adevăr o constrângere pentru a scrie un scenariu negativ.
Concluzie: nu fiecare cerință ar trebui să aibă cazuri negative.
În acest moment, dacă vă gândiți „Cum o să știu” sau „Încă nu sunt sigur”, iată o simplă foaie de trucuri care vă va ajuta.
cum se deschid fișierele bin Windows 10
Dacă există o generalizare pe care o putem face despre aplicații este că acestea sunt dinamice. Introducerea (date, clicuri etc.) pe care le furnizăm va face ca aplicația să fie într-un anumit mod și să genereze o anumită ieșire.
O simplă corelație între variabilele de intrare și ieșire va face acest lucru ușor de înțeles.
Să încercăm următoarele pentru autentificare:
| Intrare | Ieșire | Pozitiv negativ |
|---|---|---|
| Corect (informații de conectare corecte) | Corect (Utilizator conectat) | Pozitiv |
| Incorect (informații incorecte de autentificare) | Corect (un mesaj de eroare) | Negativ |
| Corect (informații de conectare corecte) | Incorect - Conectarea eșuează | Bug / Defect |
| Incorect (informații incorecte de autentificare) | Incorect (sistemul le conectează) - „Oh, groaza!” :) | Bug / defect |
Deci, vedeți din tabelul de mai sus, putem spune că clasificăm fluxul primar ca pozitiv și fluxul alternativ (de asemenea, comportamentul corect al aplicației) este marcat ca negativ.
Ultimele două cazuri în roșu sunt de fapt bug-uri. Testarea se referă la validarea cerințelor și atunci când acestea nu funcționează conform intenției, găsim erori. Deoarece nu mergem la validarea defectelor, ultimele două cazuri sunt nevalide.
Urmând aceeași linie de gândire și aplicându-l la deconectarea și vizualizarea produselor, iată ce veți obține.
| Intrare | Ieșire | Pozitiv negativ |
|---|---|---|
| Deconectare (clic) | Corect - Deconectează-te | Pozitiv |
| Deconectare (clic) | Incorect - Rămâne conectat | Bug / defect |
| Vizualizați produsele (faceți clic) | Corect - Afișează produsele | Pozitiv |
| Vizualizați produsele (faceți clic) | Incorect (nu listă sau afișare incorectă a listei) | Bug / defect |
După cum puteți vedea, pentru aceste cerințe, nu există posibilitatea de a furniza o intrare incorectă. Prin urmare, nu trebuie să existe scenarii / cazuri negative de testare scrise.
Gânduri de încheiere:
Sistemul ar putea fi supus intrărilor pozitive sau negative. Oricum ar fi, sistemul ar trebui să genereze o ieșire corectă. Cazurile care tind să se ocupe de o intrare corectă sunt pozitive. Cele care sunt corecte, dar negative, sunt negative.
Câteva indicații:
# 1) Când un cazuri de testare cap la cap sunt scrise pentru testarea UAT sau chiar a sistemului, întotdeauna cazurile de testare pozitive sunt cele care intră în flux.
#Două) Uneori, clasificarea este subiectivă.De exemplu, dacă șterg ceva pe un site și primesc un mesaj de confirmare care mă întreabă „Sigur doriți să ștergeți această intrare?” cu opțiunile OK și Anulare - după mine, clic pe anulare este un caz pozitiv. Dar unii cred că este negativ, deoarece intenția principală a opțiunii „Șterge” este de a șterge și nu anula operațiunea. Deci, judecata unui tester joacă, de asemenea, un rol în clasificare.
# 3) Pentru fiecare caz pozitiv, nu există întotdeauna un caz negativ egal și opus.
Metoda de mai sus garantează întotdeauna o clasificare corectă. Încercați-l singur și spuneți-mi, dacă nu. :) „O comandă rapidă este adesea o greșeală tăiată.” - Dar atunci, s-ar putea să nu fie în acest caz!
Pentru o explicație mai formală a testării negative, verificați => Ce este testarea negativă și cum se scriu cazuri de testare negative?
Despre autor: Acest articol este scris de Swati S., membru al echipei STH. Alăturați-vă cursului de instruire live QA aici: „ Cel mai bun training de testare software pe care îl veți primi vreodată! '
Vă rugăm să ne informați dacă v-a plăcut acest articol și doriți să vedeți astfel de concepte de bază explicate cu ușurință în articolele următoare.
Comentariile, întrebările, feedback-ul și citirea dvs. sunt foarte apreciate și apreciate aici la STH. Testare fericită!
Lectură recomandată
- Testare pozitivă: semnificație și merite explicate cu scenarii reale de testare
- Cum se scriu cazuri de testare pentru o pagină de conectare (exemple de scenarii)
- Ce este testarea negativă și cum se scriu cazuri de testare negative?
- Cum se scriu cazuri de testare pentru bancomat (exemple de scenarii)
- Scenarii eficiente cu scripturi și depanare Selenium - Tutorial Selenium # 27
- Tipuri de testare a migrării: cu scenarii de testare pentru fiecare tip
- QTP Tutorial # 24 - Utilizarea obiectelor virtuale și scenarii de recuperare în testele QTP
- Testarea aplicațiilor medicale - sfaturi și scenarii importante de testare (partea 2)