what is test scenario
Acest tutorial explică ce este scenariul de testare împreună cu importanța, implementarea, exemple și șabloane ale scenariului de testare:
Se spune că orice funcționalitate / caracteristică software care poate fi testată este un scenariu de testare. Perspectiva utilizatorului final este luată în considerare la scrierea oricăror scenarii de testare.
Acest tutorial vă va ajuta să răspundeți la întrebări: de ce sunt necesare scenarii de testare, când sunt scrise scenarii de testare și cum să scrieți scenariile de testare.
Ce veți învăța:
Ce este un scenariu de testare?
Luați în considerare o situație ipotetică: Există un ocean vast. Trebuie să călătorești peste ocean de la o țărm la alta. De exemplu, de la Mumbai, India Seashore la Colombo, Srilanka seashore.
Modul de călătorie pe care îl puteți opta sunt:
(i) Căi aeriene: Luați un zbor spre Colombo
(ii) Căi navigabile:Preferă o navă pentru a călători la Colombo
(iii) Căile ferate:Luați un tren spre Srilanka
Acum pentru scenariile de testare: Călătoria de la malul mării Mumbai la litoralul Colombo este o funcționalitate care urmează să fie testată.
Scenariile de testare includ:
- Călătorind pe căile aeriene,
- Călătorind pe căi navigabile sau
- Călătorind cu căile ferate.
Aceste scenarii de testare vor avea cazuri de testare.
Testele care pot fi scrise pentru scenariile de test de mai sus includ:
Scenariu de testare: Călătorind pe căile aeriene
Testele pot include scenarii precum:
- Zborul este conform orei programate.
- Zborul nu este conform orei programate.
- A urmat o situație de urgență (precipitații abundente și furtună).
În același mod, se poate scrie un set separat de cazuri de testare pentru alte scenarii rămase.
Acum, să trecem la scenariile de testare tehnologică.
Orice lucru care poate fi testat este un scenariu de testare. Astfel, putem afirma că orice funcționalitate software aflată sub test și care poate fi împărțită în mai multe funcționalități mai mici și poate fi denumită „Scenariu de testare”.
Înainte de a livra orice produs către client, calitatea produsului trebuie evaluată și evaluată. Scenariul de testare ajută la evaluarea calității funcționale a unei aplicații software care este în conformitate cu cerințele sale de afaceri.
Scenariul Tester este un proces în care testerul testează aplicația software dintr-o perspectivă a utilizatorului final. Performanța și calitatea aplicației software sunt evaluate cu atenție înainte de implementarea în mediul de producție.
Importanța scenariului de testare
- Un scenariu de test poate avea mai multe „cazuri de testare”. Poate fi imaginat ca o imagine panoramică mare, iar cazurile de testare sunt părțile mici care sunt importante pentru a completa panorama.
- Este o declarație cu o singură linie și cazurile de testare cuprind o descriere pas cu pas pentru a completa scopul declarației scenariului de testare.
- Exemplu:
Scenariu de testare: Efectuați plata pentru serviciul de taxi disponibil.
Aceasta va avea mai multe cazuri de testare, după cum se menționează mai jos:
(i) Metoda de plată utilizată: PayPal, Paytm, Card de credit / debit.
(ii) Platafăcut este de succes.
(iii) Plata efectuată este nereușită.
(iv) Plataproces întrerupt.
(v) Nu pot accesa metodele de plată.
(noi) Aplicațiase strică între ele.
- Scenariile de testare ajută astfel la evaluarea aplicației software conform situațiilor din lumea reală.
- Testarea scenariilor atunci când este determinată, ajută la bifurcarea sferei testării.
- Această bifurcație este denumită prioritizare, care ajută la determinarea funcționalităților importante ale aplicației software.
- Testarea prioritară a funcționalităților, ajută într-o mare măsură la implementarea cu succes a aplicației software.
- Pe măsură ce scenariile de testare sunt prioritizate, cele mai importante funcționalități pot fi ușor identificate și testate cu prioritate. Acest lucru asigură faptul că majoritatea funcționalităților cruciale funcționează bine și că defectele legate de aceasta sunt surprinse și corectate în mod corespunzător.
- Scenariile de testare determină fluxul procesului de afaceri al software-ului și, prin urmare, este posibilă testarea end-to-end a aplicației.
Diferența dintre scenariul de testare și cazul de testare
rol de analist de afaceri în scrum agil
Scenariu de testare | Cazuri de testare |
---|---|
Sunt necesare documentații scurte. | Este necesară documentația detaliată. |
Scenariul de testare este un concept. | Testele sunt soluțiile pentru a verifica acest concept. |
Test Scenario este o funcționalitate de nivel înalt. | Testele sunt o procedură detaliată pentru a testa funcționalitatea la nivel înalt. |
Scenariile de testare sunt derivate din cerințe / povești de utilizator. | Cazurile de testare sunt derivate din scenarii de testare. |
Scenariul de testare este „Ce funcționalitate urmează să fie testată” | Cazurile de testare sunt „Cum se testează funcționalitatea”. |
Scenariile de testare au mai multe cazuri de testare. | Cazul de testare poate fi sau nu asociat cu mai multe scenarii de testare. |
Scenariile de testare unică nu se repetă niciodată. | Un singur caz de testare poate fi utilizat de mai multe ori în diferite scenarii. |
Pentru finalizarea unui scenariu de testare sunt necesare sesiuni de brainstorming. | Este necesară cunoașterea tehnică detaliată a aplicației software |
Economisirea timpului, deoarece detaliile minute nu sunt necesare. | Consumatoare de timp, deoarece fiecare detaliu minut trebuie să fie îngrijit. |
Costul întreținerii este redus, deoarece resursele necesare sunt reduse. | Costul întreținerii este ridicat, deoarece resursele necesare sunt mari |
De ce este indispensabil scenariile de testare?
Scenariile de testare sunt derivate din cerințe sau din poveștile utilizatorilor.
- Luați exemplul unui scenariu de testare pentru rezervarea Cabinei.
- Scenariile ar putea fi cum ar fi opțiunile de rezervare a cabinei, metodele de plată, urmărirea GPS, harta rutieră afișată corect sau nu, detaliile cabinei și șoferului afișate corect sau nu, etc. toate sunt enumerate în șablonul scenariului de testare.
- Acum, presupuneți că scenariul de testare este să verificați dacă serviciile de localizare sunt activate, dacă nu sunt activate, afișați mesajul „Activați serviciile de localizare”. Acest scenariu este ratat și nu este listat în șablonul de scenarii de testare.
- Scenariul „Serviciu de localizare” dă naștere la alte scenarii de testare legate de acesta. Acestea pot fi:
- Serviciul de localizare a devenit gri.
- Serviciul de localizare a fost activat, dar nu are internet.
- Restricții pentru serviciile de localizare.
- Este afișată locația greșită.
- Lipsește un singur scenariu poate însemna să pierzi multe altele scenarii cruciale sau cazuri de testare . Acest lucru poate avea un mare impact negativ în timp ce implementați aplicația software. Acest lucru are ca rezultat o pierdere puternică de resurse (termene).
- Scenariile de testare ajută în mare măsură în evitând testarea exhaustivă . Se asigură că toate fluxurile de afaceri cruciale și așteptate sunt testate, ceea ce ajută în continuare la testarea finală a aplicației.
- Acestea sunt economii de timp. De asemenea, nu este necesară o descriere mult mai detaliată conform cazurilor de testare. O descriere cu o linie este specificată despre ceea ce trebuie testat.
- Scenariile de testare sunt scrise după sesiuni de brainstorming a membrilor echipei. Prin urmare, probabilitatea de a pierde orice scenariu (crucial sau minor) este minimă. Acest lucru se face ținând cont de punctele tehnice și, de asemenea, de fluxul de afaceri al aplicației software.
- Mai mult, scenariile de testare pot fi aprobate fie de Business Analyst, fie de Client sau de ambii care au cunoștințele explicite ale aplicației supuse testului.
Scenariile de testare sunt astfel o parte indispensabilă a SDLC.
Implementarea scenariilor de testare
Să vedem implementarea scenariilor de testare sau cum să scriem scenarii de testare-
- Sunt formate cerințe despre epopee / afaceri.
- Exemplu de Epic : Creați un cont Gmail. Epic poate fi caracteristica majoră a unei aplicații sau a unei cerințe de afaceri.
- Epopeile sunt împărțite în povești mai mici ale utilizatorilor pe sprinturi.
- Poveștile utilizatorilor sunt derivate din Epics. Aceste povești ale utilizatorilor trebuie să fie bazate și aprobate de părțile interesate.
- Scenariile de testare sunt derivate din poveștile utilizatorilor sau BRS (Business Requirement Document), SRS (Document Requirement Specification Document) sau FRS (Functional Requirement Document) care este finalizat și bazat.
- Testerii scriu scenariile de testare.
- Aceste scenarii de testare sunt aprobate de șeful de echipă, analistul de afaceri sau managerul de proiect, în funcție de organizație.
- Fiecare scenariu de testare trebuie să fie legat de cel puțin o poveste de utilizator.
- Trebuie identificate scenarii pozitive, precum și negative.
- Poveștile utilizatorilor cuprind Criterii de acceptare precum :
- Criteriile de acceptare sunt o listă de condiții sau starea de intenție pentru cerințele clientului. Așteptările clientului și, de asemenea, neînțelegerile sunt luate în considerare la scrierea criteriilor de acceptare.
- Acestea sunt unice pentru o poveste de utilizator și fiecare poveste de utilizator trebuie să aibă cel puțin un criteriu de acceptare care ar trebui să poată fi testat independent.
- Criteriile de acceptare ajută la determinarea caracteristicilor care intră în domeniul de aplicare și a celor care nu intră în domeniul de aplicare al unui proiect. Aceste criterii ar trebui să includă caracteristici funcționale și nefuncționale.
- Analistii de afaceri scriu criteriile de acceptare, iar proprietarul de produs le aprobă.
- Sau, în unele cazuri, proprietarul produsului poate scrie el însuși criteriile.
- Scenariile de testare pot fi obținute din criteriile de acceptare.
Exemple de scenarii de testare
# 1) Scenarii de testare pentru aplicația Kindle
Kindle este aplicația care permite cititorilor săi electronici să caute cărți electronice online, să le descarce și să le cumpere. Amazon Kindle oferă cititorului de cărți electronice experiența reală de a ține o carte în mână și a o citi. Chiar și întoarcerea paginilor este simulată frumos în aplicație.
Acum să notăm scenariile de testare. ( Notă: Scenariile limitate sunt enumerate mai jos pentru a obține o idee generală pentru scrierea scenariului de testare. Pot exista mai multe cazuri de testare derivate din acesta).
Testează scenarii # | Testează scenarii |
---|---|
7 | Verificați funcționalitatea de descărcare funcționează corect. |
1 | Verificați dacă aplicația Kindle se lansează corect. |
Două | Verificați ajustarea rezoluției ecranului în funcție de diferite dispozitive, după lansarea aplicației. |
3 | Verificați că textul afișat este lizibil. |
4 | Verificați că opțiunile de mărire și micșorare funcționează. |
5 | Verificați dacă fișierele compatibile importate în aplicația Kindle sunt lizibile. |
6 | Verificați capacitatea de stocare a aplicației Kindle. |
8 | Verificați Simularea întoarcerii de pagină funcționează corect |
9 | Verificați compatibilitatea formatelor de cărți electronice cu aplicația Kindle. |
10 | Verificați fonturile acceptate de aplicația Kindle. |
unsprezece | Verificați durata de viață a bateriei utilizată de aplicația Kindle. |
12 | Verificați performanța Kindle în funcție de conectivitatea la rețea (Wi-Fi, 3G sau 4G). |
Mai multe cazuri de testare pot fi derivate din fiecare scenariu de testare menționat mai sus.
# 2) Criterii de acceptare pentru Google Docs
„Google docs” este o aplicație bazată pe web pentru a crea, edita și partaja documente Word, foi de calcul, diapozitive și formulare. Toate fișierele pot fi accesate online folosind un browser web care are conexiune la internet.
Documentele create pot fi partajate ca o pagină web sau un document pregătit pentru imprimare. Utilizatorul poate seta restricții cu privire la cine poate vizualiza și edita documentele. Un singur document poate fi partajat și lucrat în colaborare de către diverse persoane din diferite locații geografice.
Scenariile de testare limitate sunt menționate mai jos pentru înțelegere generală. Scenariile de testare aprofundată pentru documentele Google pot fi cu totul un subiect separat.
Criteriul de acceptare # | Criteriul de acceptare |
---|---|
7 | Mai mulți utilizatori pot lucra pe un singur document. |
1 | Word, Foi de calcul sau Formulare pot fi deschise cu succes fără erori. |
Două | Șabloanele sunt disponibile pentru documente, foi și diapozitive. |
3 | Șabloanele disponibile sunt accesibile pentru utilizatori. |
4 | Șablonul utilizat este editabil (de exemplu: fonturi, dimensiunea fontului, adăugarea de text, ștergerea textului, inserarea diapozitivului). |
5 | Dacă conexiunea la internet nu este disponibilă temporar, fișierul poate fi stocat local și încărcat în funcție de disponibilitatea conexiunii la internet. |
6 | Modificările efectuate de mai mulți utilizatori nu sunt suprascrise. |
8 | Munca efectuată este stocată dacă conexiunea la internet se pierde în timpul încărcării unui fișier. |
9 | Restricțiile de partajare sunt aplicate corect. |
10 | Utilizatorii cu restricții de vizualizare nu pot face modificări asupra documentelor. |
unsprezece | Documentele pot fi publicate pe internet pentru publicul larg. |
12 | Modificările făcute documentelor sunt salvate cu ștampila de timp și detaliile autorului. |
Numărul scenariilor de testare va fi multiplu și foarte mare pentru Google Docs. În astfel de cazuri, în general, numai criteriile de acceptare sunt stabilite și aprobate de părțile interesate, iar membrii echipei lucrează la aceste criterii de acceptare. Scrierea de cazuri de testare pentru sau mai degrabă scenarii de testare poate fi sarcina exhaustivă pentru aplicații uriașe.
Aceste criterii de acceptare joacă un rol major în planificarea procesului iterativ și nu trebuie niciodată trecute cu vederea. Definirea lor în prealabil și în față evită surprize sau șocuri la sfârșitul sprinturilor sau lansărilor
Dat o condiție prealabilă.
Când a face o acțiune.
Atunci rezultatul așteptat.
Formatele Date, Când și Apoi sunt utile pentru specificarea criteriilor de acceptare.
Exemplu de șablon de scenariu de testare
Folosiți ID-ul poveștii | ID scenariu de testare nr. | Versiunea # | Testează scenarii | # Nr. De cazuri de testare | Importanţă |
---|---|---|---|---|---|
USID12.1 | TSID12.1.1 | Kin 12.4 | Verificați dacă aplicația Kindle se lansează corect. | 4 | Înalt |
USID12.1 | TSID12.1.2 | Kin 12.4 | Verificați capacitatea de stocare a aplicației Kindle. | 3 | Mediu |
Concluzie
În orice software de testare a ciclului de viață, înțelegerea și stabilirea scenariilor de testare este un element foarte semnificativ. Calitatea software-ului poate fi îmbunătățită având o bază bună pentru scenariile de testare. În mod frecvent, utilizarea cazurilor de testare și a scenariilor de testare poate fi schimbată.
Cu toate acestea, regula degetului mare este că scenariul de testare este utilizat pentru a scrie mai multe cazuri de testare sau putem spune că cazurile de testare sunt derivate din scenarii de testare. Scenariile de testare bine definite asigură software de bună calitate.
Lectură recomandată
- Exemplu de șablon de plan de testare software cu format și conținut
- Exemplu de șablon de caz de testare cu exemple de cazuri de testare (Descărcare)
- Exemplu de șablon pentru raportul testului de acceptare cu exemple
- Șabloane în C ++ cu exemple
- Tutorial Python DateTime cu exemple
- Tăiați comanda în Unix cu exemple
- Scenariu de testare vs. caz de testare: Care este diferența dintre acestea?
- Plugin Blazemeter și șablon Jmeter