use case use case testing complete tutorial
Pentru început, să înțelegem „Ce este cazul de utilizare?” și mai târziu vom discuta „Ce este testarea cazului de utilizare?” .
Un caz de utilizare este un instrument pentru definirea interacțiunii necesare a utilizatorului. Dacă încercați să creați o aplicație nouă sau să modificați o aplicație existentă, se fac mai multe discuții. Una dintre discuțiile critice pe care trebuie să le faceți este modul în care veți reprezenta cerința pentru soluția software.
Experții în afaceri și dezvoltatorii trebuie să aibă o înțelegere reciprocă asupra cerinței, deoarece este foarte dificil de atins. Orice metodă standard de structurare a comunicării dintre ei va fi cu adevărat o binecuvântare. La rândul său, va reduce greșelile de comunicare și iată locul în care cazul de utilizare intră în imagine.
Acest tutorial vă va oferi o imagine clară despre conceptul de caz de utilizare și testare, acoperind astfel diferitele aspecte implicate cu exemple practice pentru înțelegerea ușoară a oricui este complet nou în concept.
Ce veți învăța:
- Utilizare caz
- Cine folosește documentele „Utilizare caz”?
- Tipuri de cazuri de utilizare
- Elemente în cazuri de utilizare
- Reprezentare
- Cum se scrie un caz de utilizare?
- Utilizați diagrama de cazuri
- Acțiuni ale utilizatorului
- Ce este testarea cazului de utilizare?
- Concluzie
- Lectură recomandată
Utilizare caz
Utilizarea cazurilor joacă un rol semnificativ în fazele distincte ale ciclului de viață al dezvoltării software-ului. Cazul de utilizare depinde de „Acțiunile utilizatorului” și „Răspunsul sistemului” la acțiunile utilizatorului.
Este documentația „Acțiunilor” efectuate de Actor / Utilizator și „Comportamentul” corespunzător al sistemului „Acțiunilor” utilizatorului. Cazuri de utilizare poate duce sau nu la realizarea unui obiectiv de către „Actor / Utilizator” privind interacțiunile cu sistemul.
În cazul de utilizare, vom descrie „Cum va răspunde un sistem la un anumit scenariu?” . Este „orientat către utilizator”, nu „orientat spre sistem”.
Este „orientat către utilizator”: Vom specifica „care sunt acțiunile întreprinse de utilizator?” Și „Ce văd actorii într-un sistem?”.
Nu este „orientat spre sistem”: Nu vom specifica „Care sunt intrările date sistemului?” Și „Care sunt rezultatele produse de sistem?”.
Echipa de dezvoltare trebuie să scrie „cazuri de utilizare”, deoarece faza de dezvoltare depinde foarte mult de acestea.
Utilizați scriitorul de cazuri, membrii echipei și clienții vor contribui la crearea acestor cazuri. Pentru crearea acestora, trebuie să avem o echipă de dezvoltare reunită și echipa ar trebui să fie foarte conștientă de conceptele proiectului.
După implementarea cazului, documentul este testat și comportamentul sistemului este verificat în consecință. Într-un caz, litera majusculă „A” denotă „actor”, litera „S” denotă „sistem”.
Cine folosește documentele „Utilizare caz”?
Această documentație oferă o prezentare completă a modurilor distincte în care utilizatorul interacționează cu un sistem pentru a atinge obiectivul. O documentare mai bună poate ajuta la identificarea cerinței pentru un sistem software într-un mod mult mai ușor.
Această documentație poate fi utilizată de dezvoltatorii de software, testerii de software, precum și de părțile interesate.
Utilizări ale documentelor:
- Dezvoltatorii folosesc documentele pentru implementarea și proiectarea codului.
- Testerii le folosesc pentru crearea cazuri de testare .
- Părțile interesate din afaceri utilizează documentul pentru înțelegerea cerințelor software.
Tipuri de cazuri de utilizare
Există 2 tipuri.
Sunt:
- Zi insorita
- Zi ploioasa
# 1) Cazuri de utilizare în ziua însorită
Acestea sunt cazurile primare care sunt cel mai probabil să se întâmple atunci când totul merge bine. Acestora li se acordă o prioritate ridicată decât celelalte cazuri. Odată ce am finalizat cazurile, le oferim echipei de proiect pentru examinare și ne asigurăm că am acoperit toate cazurile necesare.
cum se deschide fișierul .key pe Windows 10
# 2) Cazuri de utilizare pentru ziua ploioasă
Acestea pot fi definite ca lista de cazuri marginale. Prioritatea acestor cazuri va veni după „Sunny Use Cases”. Putem solicita ajutorul părților interesate și managerilor de produse pentru a acorda prioritate cazurilor.
Elemente în cazuri de utilizare
Mai jos sunt prezentate diferitele elemente:
1) Scurt Descriere : O scurtă descriere care explică cazul.
2) Actor : Utilizatori care sunt implicați în acțiuni privind cazurile de utilizare.
3) Condiție prealabilă : Condiții care trebuie satisfăcute înainte de începerea cazului.
4) De bază curgere : „Flux de bază” sau „Scenariu principal” este fluxul normal de lucru din sistem. Este fluxul de tranzacții efectuate de actori la îndeplinirea obiectivelor lor. Când actorii interacționează cu sistemul, deoarece este fluxul normal de lucru, nu va exista nicio eroare și actorii vor obține rezultatul scontat.
5) Alternativ curgere : În afară de fluxul de lucru normal, un sistem poate avea și un „flux de lucru alternativ”. Aceasta este interacțiunea mai puțin frecventă efectuată de un utilizator cu sistemul.
6) Excepție curgere : Fluxul care împiedică un utilizator să atingă obiectivul.
7) Post Condiții : Condițiile care trebuie verificate după finalizarea cazului.
Reprezentare
Un caz este adesea reprezentat într-un text simplu sau într-o diagramă. Datorită simplității diagramei de utilizare, este considerată opțională de orice organizație
Exemplu de caz de utilizare:
Aici voi explica cazul „Conectare” la un „Sistem de management al școlii”.
Utilizați numele cazului | Logare | |
---|---|---|
3b | Cod de student nevalid introdus de 4 ori. S: Aplicația se închide | |
Descrierea cazului de utilizare | Un utilizator se conectează la Sistem pentru a accesa funcționalitatea sistemului. | |
Actori | Părinți, studenți, profesor, administrator | |
Pre-condiție | Sistemul trebuie să fie conectat la rețea. | |
Post-Condiție | După o autentificare reușită, un e-mail de notificare este trimis la ID-ul de e-mail al utilizatorului |
Scenarii principale | Nr. De serie | Pași |
---|---|---|
Actori / utilizatori | 1 | Introduceti numele de utilizator Introdu parola |
Două | Validați numele de utilizator și parola | |
3 | Permiteți accesul la sistem | |
Extensii | 1a | Nume de utilizator invalid Sistemul afișează un mesaj de eroare |
2b | Parolă Invalidă Sistemul afișează un mesaj de eroare | |
3c | Parolă nevalidă de 4 ori Cererea a fost închisă |
Puncte de remarcat
- Greșelile obișnuite pe care le fac participanții cu cazul de utilizare este că fie conține prea multe detalii despre un anumit caz, fie nu există deloc suficiente detalii.
- Acestea sunt modele textuale, dacă este necesar, putem adăuga o diagramă vizuală sau nu.
- Determinați condiția prealabilă aplicabilă.
- Scrieți pașii procesului în ordinea corectă.
- Specificați cerința de calitate pentru proces.
Cum se scrie un caz de utilizare?
Punctele rezumate mai jos vă vor ajuta să scrieți următoarele:
=> Când încercăm să scriem un caz, prima întrebare care ar trebui să fie ridicată este „Care este principala utilizare pentru client?” Această întrebare vă va face să scrieți cazurile dvs. din perspectiva utilizatorului.
=> Trebuie să fi obținut un șablon pentru acestea.
=> Trebuie să fie productiv, simplu și puternic. Un caz de utilizare puternic poate impresiona publicul chiar dacă are greșeli minore.
=> Ar trebui să o numărăm.
=> Ar trebui să scriem Etapa procesului în ordinea sa.
=> Dați numele propriu scenariilor, numirea trebuie făcută în funcție de scop.
=> Acesta este un proces iterativ, ceea ce înseamnă că atunci când le scrieți pentru prima dată nu va fi perfect.
=> Identificați actorii din sistem. S-ar putea să găsiți o grămadă de actori în sistem.
Exemplu ,dacă luați în considerare un site de comerț electronic precum Amazon, acolo putem găsi actori precum cumpărători, vânzători, dealeri angro, auditori, furnizori, distribuitori, asistență pentru clienți etc.
Inițial, să luăm în considerare primii actori. Putem avea mai mulți actori care au același comportament.
De exemplu , atât Cumpărătorul / Vânzătorul pot „crea un cont”. La fel, atât „Cumpărător, cât și Vânzătorul” pot „Căuta un articol”. Deci, acestea sunt comportamente duplicate și trebuie eliminate. În afară de utilizarea cazurilor duplicat, trebuie să avem cazuri mai generale. Prin urmare, trebuie să generalizăm cazurile pentru a evita duplicarea.
=> Trebuie să stabilim condiția prealabilă aplicabilă.
Utilizați diagrama de cazuri
Diagrama cazului de utilizare este o reprezentare picturală a acțiunilor unui utilizator (utilizatorilor) într-un sistem. Oferă un instrument excelent în acest context, dacă diagrama conține o mulțime de actori, atunci este foarte ușor de înțeles. Dacă este o diagramă la nivel înalt, nu va împărtăși multe detalii. Prezintă idei complexe într-un mod destul de simplu.
Fig nr: UC 01
După cum se arată în Fig nr: UC 01 reprezintă o diagramă în care dreptunghiul reprezintă un „sistem”, ovalul reprezintă un „caz de utilizare”, săgeata reprezintă o „relație” și omul reprezintă un „utilizator / actor”. Afișează un sistem / aplicație, apoi arată organizația / oamenii care interacționează cu acesta și arată fluxul de bază „Ce face sistemul?”
Fig nr: UC 02
Fig nr: UC 03 - Schema de caz de utilizare pentru autentificare
Aceasta este diagrama cazului de utilizare a cazului „Conectare”. Aici avem mai mulți actori, toți sunt plasați în afara sistemului. Elevii, profesorii și părinții sunt considerați actori primari. De aceea, toate sunt plasate pe partea stângă a dreptunghiului.
Administratorul și personalul sunt considerați actori secundari, așa că îi așezăm pe partea dreaptă a dreptunghiului. Actorii se pot conecta la sistem, astfel încât să conectăm actorii și caseta de conectare cu un conector.
Alte funcționalități găsite în sistem sunt Resetare parolă și Parolă uitată. Toate sunt legate de cazul de conectare, așa că le conectăm la conector.
Acțiuni ale utilizatorului
Acestea sunt acțiunile efectuate de utilizator într-un sistem.
De exemplu: Căutarea pe site, Adăugarea unui articol la favorite, încercarea de a contacta etc.
Notă:
- Un sistem este „orice ai dezvolta”. Poate fi un site web, o aplicație sau orice altă componentă software. În general este reprezentat de un dreptunghi. Conține cazuri de utilizare. Utilizatorii sunt plasați în afara „dreptunghiului”.
- Cazuri de utilizare sunt în general reprezentate prin forme ovale care specifică acțiunile din interiorul acestuia.
- Actori / utilizatori sunt oamenii care folosesc sistemul. Dar uneori pot fi alte sisteme, persoane sau orice altă organizație.
Ce este testarea cazului de utilizare?
Se încadrează în tehnica de testare funcțională Black Box. Deoarece este o testare a cutiei negre, nu va exista nicio inspecție a codurilor. Mai multe fapte interesante despre acest lucru sunt prezentate în această secțiune.
Acesta asigură dacă calea utilizată de utilizator funcționează conform intenției sau nu. Se asigură că utilizatorul poate îndeplini sarcina cu succes.
Unele fapte
- Testarea nu este efectuată pentru a decide calitatea software-ului.
- Chiar dacă este un tip de testare de la un capăt la altul, nu va asigura întreaga acoperire a aplicației utilizatorului.
- Pe baza rezultatului testului cunoscut din testarea cazului de utilizare, nu putem decide implementarea mediului de producție.
- Acesta va afla defectele testării integrării.
Exemplu de testare a cazului de utilizare:
Luați în considerare un scenariu în care un utilizator cumpără un articol de pe un site de cumpărături online. Utilizatorul se va conecta mai întâi la sistem și va începe să efectueze o căutare. Utilizatorul va selecta unul sau mai multe articole afișate în rezultatele căutării și le va adăuga în coș.
După toate acestea, el va verifica. Deci, acesta este un exemplu de serie de pași conectați logic pe care utilizatorul îi va efectua într-un sistem pentru a îndeplini sarcina.
Fluxul de tranzacții în întregul sistem de la un capăt la altul este testat în acest test. Cazurile de utilizare sunt, în general, calea pe care utilizatorii sunt cel mai probabil să o utilizeze, pentru a realiza o sarcină specifică.
Deci, acest lucru face ca cazurile de utilizare să fie ușor de găsit defectele, deoarece include calea pe care utilizatorii sunt mai susceptibili să o întâlnească atunci când utilizatorul folosește aplicația pentru prima dată.
Pasul 1: Primul pas este revizuirea documentelor de caz de utilizare.
Trebuie să examinăm și să ne asigurăm că cerințele funcționale sunt complete și corecte.
Pasul 2: Trebuie să ne asigurăm că cazurile de utilizare sunt atomice.
De exemplu: Luați în considerare un „Sistem de gestionare a școlii care are multe funcționalități, cum ar fi„ Conectare ”,„ Afișați detaliile elevilor ”,„ Afișați notele ”,„ Afișați prezența ”,„ Contactați personalul ”,„ Trimiteți taxe ”etc. Pentru acest exemplu, încercăm să pregătiți cazurile de utilizare pentru funcționalitatea „Conectare”.
Trebuie să ne asigurăm că niciunul dintre fluxurile de lucru normale nu trebuie să se amestece cu nicio altă funcționalitate. Trebuie să fie complet legat doar de funcționalitatea „Conectare”.
Pasul 3: Trebuie să inspectăm fluxul normal de lucru din sistem.
După inspectarea fluxului de lucru, trebuie să ne asigurăm că acesta este complet. Pe baza cunoașterii sistemului sau chiar a domeniului, putem afla pașii lipsă din fluxul de lucru.
Pasul 4: Asigurați-vă dacă fluxul de lucru alternativ din sistem este complet.
Pasul 5: Ar trebui să ne asigurăm că fiecare pas din cazul de utilizare este testabil.
Fiecare pas explicat în testarea cazului de utilizare este testabil.
De exemplu, unele tranzacții cu cardul de credit din sistem nu sunt testabile din motive de securitate.
Pasul 6: Odată ce am reînviat aceste cazuri, putem scrie cazurile de testare.
Trebuie să scriem cazuri de testare pentru fiecare debit normal și alternativ.
De exemplu , Luați în considerare cazul „Afișați notele elevilor”, într-un sistem de management al școlii.
Numele cazului de utilizare: Afișați notele studenților
Actori: Studenți, profesori, părinți
Pre-condiție:
1) Sistemul trebuie să fie conectat la rețea.
Două) Actorii trebuie să aibă un „ID de student”.
Utilizați cazul pentru „Afișați notele elevilor”:
Scenariul principal | Număr de serie | Pași |
---|---|---|
A: Actor / S: Sistem | 1 | Introduceți numele studentului |
Două | Sistemul validează numele studentului | |
3 | Introduceți codul de student | |
4 | Sistemul validează ID-ul studentului | |
5 | Sistemul afișează notele studenților | |
Extensii | 3a | ID de student nevalid S: Afișează un mesaj de eroare |
Caz de test corespunzător pentru cazul „Arată mărcile studenților”:
Cazuri de testare | Pași | rezultat asteptat |
---|---|---|
LA | Vizualizați lista de note 1 a studentului - Flux normal | |
1 | Introduceți numele studentului | Utilizatorul poate introduce numele studentului |
Două | Introduceți codul de student | Utilizatorul poate introduce ID-ul de student |
3 | Faceți clic pe View Mark | Sistemul afișează notele studenților |
B | Vizualizați lista de marcaje pentru studenți 2-ID nevalid | |
---|---|---|
1 | Repetați pașii 1 și 2 din Vizualizarea listei de notare 1 a elevilor | |
Două | Introduceți codul de student | Sistemul afișează mesajul de eroare |
Vă rugăm să rețineți că tabelul Test Case prezentat aici conține doar informațiile de bază. „Cum se creează un șablon de caz de testare” este explicat în detaliu mai jos.
Tabelul afișează „Test Case” corespunzător cazului „Show Student Mark”, așa cum se arată mai sus.
Cel mai bun mod de a scrie cazuri de testare este să scrieți mai întâi cazurile de testare pentru „scenariul principal”, apoi să le scrieți pentru „Pași alternativi”. „ Pași în cazurile de testare se obțin din documentele cazului de utilizare. Primul „ Etapa' în cazul „Show Student Mark”, „Introduceți numele studentului” va deveni primul Etapa în „Test Case”.
Utilizatorul / Actorul trebuie să poată să-l introducă. Aceasta devine rezultat asteptat .
Putem căuta ajutorul tehnicii de proiectare a testelor precum „ analiza valorii la graniță ” , „Partiționarea echivalenței” în timp ce pregătim cazurile de testare. Tehnica de proiectare a testului va ajuta la reducerea numărului de cazuri de testare și, prin urmare, la reducerea timpului necesar testării.
Cum se creează un șablon de caz de testare?
Când pregătim cazurile de testare, trebuie să ne gândim și să acționăm ca utilizatorul final, adică să vă puneți în locul utilizatorului final.
Există mai multe instrumente disponibile pe piață pentru a ajuta în acest context. ' TestLodge ’este unul dintre ele, dar nu este un instrument gratuit. Trebuie să-l achiziționăm.
Avem nevoie de un șablon pentru documentarea cazului de testare. Să luăm în considerare un scenariu comun, „FLIPKART login”, pe care îl cunoaștem cu toții. Foaia de calcul Google poate fi utilizată pentru a crea tabelul cazului de testare și a-l partaja cu membrii echipei. Deocamdată folosesc un document Excel.
Iată un exemplu
=> DESCĂRCAȚI aici acest șablon de tabel pentru cazurile de testare
În primul rând, denumiți foaia de testare cu un nume corespunzător. Scriem cazuri de testare pentru un anumit modul dintr-un proiect. Deci, trebuie să adăugăm 'Denumirea proiectului' si ‘Modulul proiectului ’Coloane din tabelul cazului de testare. Documentul trebuie să includă numele creatorului cazurilor de testare.
Prin urmare, adăugați 'Creat de' și 'Data creata' coloane. Documentul trebuie revizuit de către cineva (șef de echipă, manager de proiect etc.), așa că adăugați 'Revizuite de' coloană și „Data revizuirii” .
Următoarea coloană este „Scenariu de testare” , aici am furnizat Exemplul de scenariu de testare „Verificați autentificarea Facebook” . Adăugați coloanele „Testarea ID-ului scenariului” și „Descrierea cazului de testare” .
Pentru fiecare scenariu de testare vom scrie 'Cazuri de testare '. Așadar, adăugați coloanele „Test Case ID” și ‘Descrierea cazului de testare '. Pentru fiecare scenariu de test, va exista „Post Condition” și „Pre-condiție” . Adăugați coloanele „Post-Condition” și „Pre-Condition”.
O altă coloană importantă este „Date de testare” . Acesta va conține datele pe care le folosim pentru testare. Un scenariu de testare trebuie să asume un rezultat așteptat și rezultatul real. Adăugați coloana 'Rezultat asteptat' și „Rezultat real”. 'Stare' arată rezultatul execuției scenariului de testare. Poate fi fie trecere / eșuare.
Testerii vor executa cazurile de testare. Trebuie să-l includem ca 'Executat de' și „Data executării” . Vom adăuga „Comenzi” dacă există.
Concluzie
Sper că ați avea o idee clară despre cazurile de utilizare și testarea cazurilor de utilizare.
Scrierea acestor cazuri este un proces iterativ. Aveți nevoie doar de puțină practică și de o bună cunoaștere a unui sistem pentru a scrie aceste cazuri.
Pe scurt, putem folosi „Testarea cazurilor de utilizare” într-o aplicație pentru a găsi linkurile lipsă, cerințele incomplete etc. Găsirea acestora și modificarea sistemului vor atinge eficiența și acuratețea sistemului.
Aveți experiențe anterioare cu cazuri de utilizare și testare? Simțiți-vă liber să ne împărtășiți cu noi în secțiunea de comentarii de mai jos.
Lectură recomandată
- Testarea funcțională Vs testarea non-funcțională
- Tutoriale detaliate pentru eclipsă pentru începători
- Testarea alfa și testarea beta (un ghid complet)
- Tutorial DevOps Testing: Cum va afecta DevOps testarea QA?
- Cele mai bune instrumente de testare software 2021 (Instrumente de automatizare a testelor de calitate)
- Tutorial de testare a utilizabilității: un ghid introductiv complet
- Tutorial de testare GUI: un ghid complet de testare a interfeței de utilizator (UI)
- Tutorial de testare distructivă și testare nedistructivă