complete functional testing guide with its types
Un tutorial de testare funcțională cuprinzător în profunzime cu tipuri, tehnici și exemple:
Ce este testarea funcțională?
Testarea funcțională este un fel de testare cu cutie neagră care se efectuează pentru a confirma că funcționalitatea unei aplicații sau a unui sistem se comportă conform așteptărilor.
Se face pentru a verifica toate funcționalitățile unei aplicații.
LISTA tutorialelor acoperite în această serie:
Tutorial nr. 1: Ce este testarea funcțională (acest tutorial)
Tutorial nr. 2: Întrebări de interviu pentru testarea funcționalității
Tutorial nr. 3: Cele mai bune instrumente de testare a automatizării funcționale
Tutorial # 4: Ce este testarea nefuncțională?
Tutorial # 5: Diferența dintre unitate, funcțional și Integrare Testarea
Tutorial # 6 : De ce ar trebui efectuate simultan testele funcționale și de performanță
Instrumente:
Tutorial nr. 7: Automatizare funcțională a testului cu Ranorex Studio
Tutorial # 8: UFT Functional Tool Noi caracteristici
Tutorial # 9: Automatizare funcțională a browserului încrucișat folosind instrumentul Parrot QA
Tutorial # 10: Tutorial Jubula Open Source Tool pentru testarea funcționalității
Ce veți învăța:
- Introducere în testarea funcțională
Introducere în testarea funcțională
Trebuie să existe ceva care definește ceea ce este un comportament acceptabil și ce nu.
Acest lucru este specificat într-o specificație funcțională sau de cerință. Este un document care descrie ceea ce unui utilizator i se permite să facă, astfel încât să poată determina conformitatea aplicației sau a sistemului cu aceasta. În plus, uneori, acest lucru ar putea implica validarea scenariilor reale din partea companiei.
Prin urmare, testarea funcționalității poate fi efectuată prin două tehnici populare :
- Testare bazată pe cerințe: Conține toate specificațiile funcționale care stau la baza tuturor testelor care trebuie efectuate.
- Testare bazată pe scenarii de afaceri: Conține informații despre modul în care sistemul va fi perceput din perspectiva procesului de afaceri.
Testarea și asigurarea calității sunt o parte importantă a procesului SDLC. În calitate de tester, trebuie să fim conștienți de toate tipurile de testare, chiar dacă nu suntem implicați în mod direct cu ei zilnic.
Deoarece testarea este un ocean, scopul acesteia este într-adevăr atât de vast și avem testeri dedicați care performează diferite tipuri de testare . Probabil că toți trebuie să fim familiarizați cu majoritatea conceptelor, dar nu va strica să organizăm totul aici.
Tipuri de testare funcțională
Testarea funcțională are multe categorii și acestea pot fi utilizate pe baza scenariului.
Cele mai proeminente tipuri sunt discutate pe scurt mai jos:
Testarea unității este de obicei efectuată de un dezvoltator care scrie diferite unități de cod care ar putea fi legate sau fără legătură pentru a realiza o anumită funcționalitate. Al său, aceasta implică de obicei scrierea testelor unitare care ar apela metodele din fiecare unitate și le va valida atunci când parametrii solicitați sunt trecuți, iar valoarea de returnare a acestuia este așa cum era de așteptat.
Acoperirea codului este o parte importantă a testării unitare în care cazurile de testare trebuie să existe pentru a acoperi următoarele trei:
i) Acoperirea liniei
ii) Acoperirea căii de cod
iii) Acoperirea metodei
Testarea sănătății : Testarea care se face pentru a se asigura că toate funcționalitățile majore și vitale ale aplicației / sistemului funcționează corect. Acest lucru se face în general după un test de fum.
Testarea fumului : Testarea care se face după lansarea fiecărei construcții pentru a asigura stabilitatea construcției. Este, de asemenea, numit testarea verificării construcției.
Teste de regresie : Testarea efectuată pentru a se asigura că adăugarea unui nou cod, îmbunătățiri, remedierea erorilor nu încalcă funcționalitatea existentă sau nu provoacă nicio instabilitate și funcționează în continuare conform specificațiilor.
Testele de regresie nu trebuie să fie la fel de extinse ca testele funcționale efective, dar ar trebui să asigure doar cantitatea de acoperire care să certifice faptul că funcționalitatea este stabilă.
Teste de integrare : Atunci când sistemul se bazează pe mai multe module funcționale care ar putea funcționa individual perfect, dar care trebuie să funcționeze coerent atunci când se leagă împreună pentru a realiza un scenariu cap la cap, validarea unor astfel de scenarii se numește testarea integrării.
Testarea beta / utilizare : Produsul este expus clientului real într-o producție precum un mediu și testează produsul. Confortul utilizatorului este derivat din aceasta și feedback-ul este luat. Acest lucru este similar cu cel al testării acceptării utilizatorilor.
Să reprezentăm acest lucru într-o diagramă simplă:
Testarea funcțională a sistemului:
Testarea sistemului este o testare care se efectuează pe un sistem complet pentru a verifica dacă funcționează conform așteptărilor odată ce toate modulele sau componentele sunt integrate.
Testarea cap la cap se efectuează pentru a verifica funcționalitatea produsului. Această testare se efectuează numai atunci când testarea integrării sistemului este completă, incluzând atât cerințele funcționale, cât și cele nefuncționale.
=> Diferența dintre testarea unității, funcțională și de integrare
Proces
Acest proces de testare are trei pași principali:
Abordare, tehnici și exemple
Testarea funcțională sau comportamentală generează o ieșire bazată pe intrările date și determină dacă sistemul funcționează corect conform specificațiilor.
Prin urmare, reprezentarea picturală va arăta așa cum se arată mai jos:
Criterii de intrare / ieșire
Criterii de intrare:
- Documentul cu specificațiile cerințelor este definit și aprobat.
- Au fost pregătite cazuri de testare.
- Datele de testare au fost create.
- Mediul pentru testare este gata, toate instrumentele necesare sunt disponibile și gata.
- Aplicația completă sau parțială este dezvoltată și testată pe unitate și este pregătită pentru testare.
Criterii de ieșire:
- Executarea tuturor cazurilor de testare funcțională a fost finalizată.
- Nu sunt deschise erori critice sau P1, P2.
- Bugurile raportate au fost recunoscute.
Pași implicați
Diferitii pași implicați în această testare sunt menționați mai jos:
- Primul pas implicat este determinarea funcționalității produsului care trebuie testat și include testarea principalelor funcționalități, starea de eroare și a mesajelor, testarea utilizabilității, adică dacă produsul este ușor de utilizat sau nu etc.
- Următorul pas este crearea datelor de intrare pentru funcționalitatea care urmează să fie testată conform specificației cerințelor.
- Ulterior, din specificațiile cerințelor, ieșirea este determinată pentru funcționalitatea testată.
- Sunt executate cazuri de testare pregătite.
- Ieșirea reală, adică ieșirea după executarea cazului de testare și ieșirea așteptată (determinată din specificațiile cerințelor) sunt comparate pentru a afla dacă funcționalitatea funcționează conform așteptărilor sau nu.
Abordare
Diferite tipuri de scenarii pot fi gândite și create sub forma „cazurilor de testare”. În calitate de oameni de calitate, știm cu toții cum arată scheletul unui caz de testare.
În principal are patru părți:
- Rezumatul testului
- Condiții prealabile
- Etape de testare și
- Rezultate asteptate.
Încercarea de a crea orice tip de test este nu numai imposibilă, ci și consumatoare de timp și costisitoare.
De obicei, am dori să descoperim bug-urile maxime fără a scăpa cu testele existente. Prin urmare, QA trebuie să utilizeze tehnici de optimizare și să strategizeze modul în care ar aborda testarea.
Să explicăm acest lucru cu un exemplu.
Exemple de cazuri de testare funcțională:
Luați un portal HRMS online, unde angajatul se conectează cu contul său de utilizator și parola. Pe pagina de autentificare, există două câmpuri de text pentru numele de utilizator și parola și două butoane: Autentificare și Anulare. Conectarea cu succes duce utilizatorul la pagina principală HRMS și anularea va anula autentificarea.
Specificațiile sunt cele prezentate mai jos:
# 1) Câmpul de identificare a utilizatorului ia minimum 6 caractere, maximum 10 caractere, cifre (0-9), litere (a-z, A-z), caractere speciale (numai subliniere, punct, liniuță permisă) și nu poate fi lăsat necompletat. ID-ul utilizatorului trebuie să înceapă cu un caracter sau un număr și nu cu caractere speciale.
#Două) Câmpul de parolă are cel puțin 6 caractere, maximum 8 caractere, cifre (0-9), litere (a-z, A-Z), caractere speciale (toate) și nu poate fi necompletat.
Abordarea de bază a testării acestui scenariu poate fi clasificată în două mari categorii:
- Testarea pozitivă și
- Testarea negativă
Desigur, fiecare dintre aceste categorii are sub-secțiunea sa de teste care vor fi efectuate.
Teste pozitive sunt teste de parcurs fericit care se fac pentru a se asigura că produsul îndeplinește - cel puțin cerințele de bază care sunt vitale pentru utilizarea clienților.
Scenarii negative asigurați-vă că produsul se comportă corect chiar și atunci când este supus unor date neașteptate.
Citire sugerată => Ce este testarea negativă și cum se scriu cazuri de testare negative
Acum, permiteți-mi să încerc să structurez tehnicile de testare folosind un diagramă de mai jos. Vom intra în detaliile fiecăruia dintre aceste teste.
Tehnici de testare funcțională
# 1) Utilizatori finali / Teste de sistem
Sistemul supus testării poate avea multe componente care, atunci când sunt cuplate, realizează scenariul utilizatorului.
În Exemplu , un scenariu pentru clienți ar include sarcini precum încărcarea aplicației HRMS, introducerea acreditărilor corecte, accesarea paginii de pornire, efectuarea unor acțiuni și deconectarea din sistem. Acest flux special trebuie să funcționeze fără erori pentru un scenariu de afaceri de bază.
asigurarea calității software-ului în ingineria software-ului
Unele mostre sunt prezentate mai jos:
Sl Nu | rezumat | Cerință prealabilă | Caz de testare | Rezultate asteptate. |
---|---|---|---|---|
1. | Utilizatorul complet privilegiat poate efectua modificări de cont | 1) Contul de utilizator trebuie să existe 2) Utilizatorul trebuie să aibă privilegiile necesare | 1) Utilizatorul introduce codul de utilizator și parola 2) Utilizatorul vede permisiuni de editare pentru a modifica contul însuși 3) Utilizatorul modifică informațiile contului și salvează. 4) Utilizatorul se deconectează. | 1) Utilizatorul este conectat la pagina de pornire 2) Ecranul de editare este prezentat utilizatorului. 3) Informațiile despre cont sunt salvate 4) Utilizatorul este readus la pagina de autentificare |
Două. | Un alt utilizator valid fără privilegii depline | 1) Contul de utilizator trebuie să existe 2) Utilizatorul trebuie să aibă privilegiile minime | 1) Utilizatorul introduce codul de utilizator și parola 2) Utilizatorul vede permisiuni de editare pentru a modifica doar anumite câmpuri. 3) Utilizatorul modifică numai acele câmpuri și salvează. 4) Utilizatorul se deconectează. | 1) Utilizatorul este conectat la pagina de pornire 2) Ecranul de editare este prezentat utilizatorului numai în anumite câmpuri. Câmpurile contului sunt gri. 3) Câmpurile modificate sunt salvate 4) Utilizatorul este readus la pagina de autentificare |
Acesta este un exemplu de bază al modului în care cazurile de testare sunt create pentru situații. Formatul de mai sus se va aplica și tuturor testelor de mai jos. De dragul fundamentării conceptuale puternice, am introdus doar câteva teste simple deasupra și dedesubt.
# 2) Teste de echivalență
În Partiționarea echivalenței , datele de testare sunt separate în diferite partiții numite clase de date de echivalență. Datele din fiecare partiție trebuie să se comporte în același mod, de aceea trebuie testată o singură condiție. În mod similar, dacă o condiție dintr-o partiție nu funcționează, atunci niciuna dintre celelalte nu va funcționa.
De exemplu , în scenariul de mai sus, câmpul de identificare a utilizatorului poate avea maximum 10 caractere, astfel încât introducerea datelor> 10 ar trebui să se comporte în același mod.
# 3) Testele valorii limită
Testele limită implică limite de date pentru aplicație și validează modul în care se comportă.
Prin urmare, dacă intrările sunt furnizate dincolo de valorile limită, atunci se consideră că este o testare negativă. Deci, un minim de 6 caractere pentru utilizator stabilește limita limită. Teste scrise pentru a avea id-ul de utilizator<6 characters are boundary analysis tests.
# 4) Teste bazate pe decizii
Testele bazate pe decizie sunt centrate în jurul ideologiei posibilelor rezultate ale sistemului atunci când este îndeplinită o anumită condiție.
În scenariul de mai sus dat, următoarele teste bazate pe decizie pot fi imediat derivate:
- Dacă sunt introduse acreditările greșite, acesta ar trebui să indice acest lucru utilizatorului și să reîncarce pagina de autentificare.
- Dacă utilizatorul introduce acreditările corecte, acesta ar trebui să îl ducă la următoarea interfață de utilizare.
- Dacă utilizatorul introduce acreditările corecte, dar dorește să anuleze datele de conectare, atunci nu ar trebui să-l ducă pe utilizator la următoarea interfață de utilizare și să reîncarce pagina de conectare.
# 5) Teste alternative de flux
Testele de cale alternativă sunt executate pentru a valida toate modalitățile posibile care există, altele decât fluxul principal pentru a îndeplini o funcție.
# 6) Teste ad-hoc
Când majoritatea erorilor sunt descoperite prin tehnicile de mai sus, teste ad-hoc sunt o modalitate excelentă de a descoperi discrepanțele care nu au fost observate anterior. Acestea sunt realizate cu mentalitatea de a sparge sistemul și a vedea dacă acesta răspunde cu grație.
De exemplu , un exemplu de testare ar fi:
- Un utilizator este conectat, dar administratorul șterge contul de utilizator în timp ce efectuează unele operațiuni. Ar fi interesant să vedem cum se descurcă aplicația cu grație.
Testare funcțională vs testare nefuncțională:
Teste nefuncționale concentrați-vă pe calitatea aplicației / sistemului în ansamblu. Prin urmare, încearcă să deducă cât de bine funcționează sistemul conform cerințelor clientului, spre deosebire de funcția pe care o îndeplinește.
=> Citiți diferența exactă aici
Automatizarea testului funcțional
Putem automatiza testele funcționale?
Cu Automation efortul manual poate fi redus, timpul poate fi economisit, alunecarea erorilor poate fi evitată și eficiența poate fi crescută.
Cu toate acestea, nu este posibil să automatizăm fiecare. Această testare poate fi automatizată, dar utilizatorul trebuie să se antreneze pentru cazurile de testare pentru automatizare. Este important să găsiți cazurile de testare adecvate care să fie automatizate împreună cu un instrument adecvat.
Automatizarea cazurilor funcționale poate avea dezavantaje, cum ar fi dacă numărul cazurilor de testare este mult mai mare și sunt regresate din nou și din nou (ceea ce trebuie făcut), atunci dezvoltatorul s-ar putea confrunta cu o problemă la comiterea modificărilor codului.
De multe ori în timp ce se efectuează analiza evadării defectelor, cauza proeminentă și perenă a evadărilor pare să aibă o lipsă de acoperire a testului într-o anumită funcție.
Din nou, există mai multe cauze pentru ca acest lucru să se întâmple, cum ar fi lipsa mediilor, lipsa testerelor, livrarea a prea multe funcții, mai puțin timp pentru a acoperi toate aspectele de testare și, uneori, pur și simplu trecerea cu vederea.
În timp ce echipele de testare dedicate ar putea face teste detaliate pe fiecare sprint sau pe fiecare ciclu de testare, vor exista întotdeauna defecte și vor exista întotdeauna defecte care ar putea fi ratate. Aceasta este una dintre nevoile fundamentale pentru a avea la dispoziție automatizarea testelor, având astfel o îmbunătățire semnificativă a eficienței procesului general de testare și a acoperirii cazurilor de testare.
Deși testarea automată nu poate înlocui niciodată testele manuale, un amestec ideal dintre cele două se va dovedi vital pentru a avea calitatea dorită în proiectele software.
Considerații privind automatizarea:
# 1) Selectați instrumentul de automatizare corect : Există mai multe instrumente disponibile pe piață, alegerea unui instrument de automatizare este o adevărată sarcină descurajantă! Cu toate acestea, ați putea face o listă de cerințe, pe baza căreia puteți selecta ce instrument de automatizare să utilizați.
Câteva aspecte principale care trebuie luate în considerare includ:
- Selectați un instrument care va fi ușor de utilizat de către toți membrii QA ai echipei, dacă nu au deja abilitățile necesare.
- Instrumentul poate fi utilizat în diferite medii. Pentru Exemplu : Scripturile pot fi create pe o platformă de sistem de operare și pot rula pe alta? Aveți nevoie de automatizarea CLI, automatizarea UI, automatizarea aplicațiilor mobile sau toate?
- Instrumentul trebuie să aibă toate caracteristicile de care aveți nevoie. Pentru Exemplu : Dacă unii testeri nu sunt bine versați cu un limbaj de scriptare, instrumentul ar trebui să aibă o funcție de înregistrare și redare și apoi să accepte conversia scriptului înregistrat în limbajul de scriptare dorit. În mod similar, dacă aveți nevoie și de instrumentul care să susțină teste automate de construcție, raportare specifică și jurnalizare, atunci trebuie să poată face și acest lucru.
- Instrumentul trebuie să fie capabil să susțină reutilizarea cazurilor de test în cazul modificărilor UI.
Instrumente de automatizare : Există destul de multe instrumente disponibile pentru automatizarea funcțională. Seleniul este probabil un favorit fierbinte, dar există și alte instrumente open-source, precum Sahi, Watir, Robotium, AutoIt etc.
Mai multe instrumente de automatizare a testelor sunt disponibile pe piață. Alegerea instrumentului adecvat este însă foarte importantă pentru organizație. S-ar putea depinde de cerința, ușurința de utilizare, iar costul joacă un rol major aici.
Mai jos sunt câteva dintre instrumentele de testare funcționale de top:
- Seleniu
- QTP
- Junit
- Loadrunner
- SoapUI
- TestComplete
=> Verificați această listă completă a instrumentelor de automatizare funcționale de top
#Două) Alegeți cazurile de testare potrivite pentru automatizare : Dacă doriți să profitați la maximum de automatizare, atunci este vital să fiți inteligent cu privire la tipul de teste pe care alegeți să le automatizați. Dacă există teste care necesită unele setări și configurații activate și oprite în timpul executării testului, atunci acestea sunt cel mai bine lăsate neautomatizate.
Prin urmare, puteți automatiza teste care:
- Trebuie rulat în mod repetat.
- Rulați cu diferite tipuri de date.
- Unele cazuri de testare P1, P2 necesită mult efort și timp.
- Teste care sunt predispuse la erori.
- Set de teste care trebuie rulate în diferite medii, browsere etc.
# 3) Echipa dedicată de automatizare : Acest lucru este probabil trecut cu vederea în majoritatea organizațiilor și automatizarea este impusă tuturor membrilor echipei QA.
Fiecare membru al echipei are diferite niveluri de experiență, seturi de abilități, niveluri de interes, lățime de bandă pentru a sprijini automatizarea, etc. Unele persoane sunt mai bine calificate în executarea testelor manuale, în timp ce altele pot cunoaște instrumente de scriptare și automatizare.
În astfel de situații, este o practică bună să luați o analiză a tuturor membrilor echipei și să aveți unii membri dedicați numai automatizării.
Activitatea de automatizare necesită timp, efort, cunoștințe și o echipă dedicată care va ajuta la obținerea rezultatelor solicitate în loc să suprasolicite toți membrii echipei atât cu testarea manuală, cât și cu cea de automatizare.
# 4) Teste bazate pe date: Cazurile de test automatizate care necesită mai multe seturi de date ar trebui să fie bine scrise, astfel încât să poată fi reutilizate. Datele pot fi scrise în surse precum text sau fișier de proprietăți, fișiere XML sau citite dintr-o bază de date.
Oricare ar fi sursa de date, crearea unei date de automatizare bine structurate face ca cadrul să fie mai ușor de întreținut și face ca scripturile de testare existente să fie utilizate la întregul lor potențial.
# 5) Modificările UI nu trebuie să întrerupă testele: Cazurile de test pe care le creați folosind instrumentul selectat trebuie să poată face față modificărilor potențiale ale interfeței. De exemplu, versiunile anterioare ale seleniului foloseau o locație pentru a identifica elementele paginii.
Prin urmare, dacă interfața de utilizare s-a schimbat, aceste elemente nu au mai fost găsite în acele locații și vor duce, la rândul lor, la eșecul masiv al testelor.
Prin urmare, este important să înțelegeți în prealabil deficiențele instrumentului și să creați cazurile de testare astfel încât să fie necesare doar modificări minime în cazul modificărilor UI.
# 6) Testarea frecventă: După ce ați pregătit o cupă de test de automatizare de bază, planificați să executați mai frecvent această cupă. Acest lucru are un avantaj bidirecțional: unul este că puteți îmbunătăți cadrul de automatizare și îl puteți face mai robust, iar al doilea este că veți prinde mai multe erori în proces.
Avantaje
Mai jos sunt prezentate diferitele avantaje ale testării funcționale:
- Această testare reproduce sau este o replică a ceea ce este sistemul real, adică este o replică a ceea ce este produsul în mediul viu. Testarea se concentrează pe specificațiile conform utilizării clienților, adică specificațiile sistemului, sistemul de operare, browserele etc.
- Nu funcționează pe niciun fel de ipoteză și niciun fel de presupuneri cu privire la structura sistemului.
- Aceste teste asigură livrarea unui produs de înaltă calitate, care îndeplinește cerințele clientului și asigură faptul că acesta este mulțumit de rezultatele finale.
- Acesta asigură livrarea unui produs fără erori care are toate funcționalitățile care funcționează conform cerințelor clientului.
- Testarea bazată pe risc se face pentru a reduce șansele de orice fel de risc în produs.
Limitări
Această testare se face pentru a vă asigura că produsul funcționează conform așteptărilor și că întreaga cerință este implementată și că produsul este exact conform cerințelor clientului.
Cu toate acestea, nu ia în considerare ceilalți factori, cum ar fi performanța produsului, adică răspunsul, timpul de transfer etc., care sunt importanți și foarte necesari pentru a face parte din testare înainte de a elibera produsul.
Dezavantaje
- Există multe șanse de a efectua teste redundante.
- Erorile logice pot fi ratate în produs.
- Această testare se bazează pe cerință, în cazul în care cerința nu este completă sau este complicată sau nu este clară, efectuarea acestei testări într-un astfel de scenariu devine dificilă și poate consuma mult timp.
Prin urmare, practic, ambele tipuri de testare sunt necesare pentru un produs de calitate.
Concluzie
Acest tutorial a discutat în detaliu tot ce trebuie să știți despre testarea funcțională, chiar de la elementele de bază.
Testarea funcțională este unul dintre procesele importante de testare, deoarece verifică funcționalitatea unui produs care este cel mai cerut și într-adevăr aspectul important al oricărui produs sau aplicație.
Despre autor: Sanjay Zalavadia - în calitate de vicepreședinte al serviciului pentru clienți Zephyr , aduce peste 15 ani de experiență în leadership în IT și servicii de asistență tehnică.
Sper că unele dintre tehnicile pe care le-am sugerat vor fi utile pentru toți cititorii. Spuneți-ne părerile dvs. în comentariile de mai jos.
Citire sugerată => Tutorial pentru testarea caracteristicilor
Lectură recomandată
- Testarea funcțională Vs testarea nefuncțională
- Testarea alfa și testarea beta (un ghid complet)
- Cele mai bune instrumente de testare software 2021 (Instrumente de automatizare a testelor de calitate)
- Diferențele dintre testarea unitară, testarea integrării și testarea funcțională
- Tipuri de testare software: diferite tipuri de testare cu detalii
- Spock pentru integrare și testare funcțională cu seleniu
- Test de verificare a construcției (testare BVT) Ghid complet
- Un ghid complet de testare nefuncțională pentru începători