Ce este testarea de performanta?

Inca din momentul in care se ia decizia de a testa o anumita aplicatie pentru a se vedea daca aceasta functioneaza, tipurile de testare pe care le putem aplica sunt extrem de variate. Asa cum putem sa verificam aspectele functionale, testarea poate merge si inspre partea non-functionala, unde sunt analizate detalii precum interfata de utilizare, de care am vorbit intr-un articol trecut. Un alt tip de testare in aceasta sfera este testarea de performanta.

Ce reprezinta testarea de performanta?

Dupa cum ne putem da seama din numele acesteia, testarea de performanta este acel tip de verificare non-functionala a unui produs software care vizeaza modul in care se comporta acesta in situatia accesarii de catre un anumit flux de utilizatori, pentru a vedea cum performeaza ea intr-un astfel de context cat mai realist.

Testarea de performanta (sau Performance testing) este foarte importanta deoarece vizeaza anumiti parametri in care functioneaza aplicatia respectiva, precum viteza de incarcare, stabilitatea ei cand e accesata de un numar variabil de useri sau scalabilitatea ei, determinata de numarul maxim de accesari posibile.

Procesul testarii de performanta. Sursa imaginii de pe Guru99

Atunci cand echipa de testare realizeaza verificarea performantei unui website sau a unei aplicatii, aceasta executa mai multe subtipuri ale acestei verificari generale, fiecare fiind axata pe un anumit mod de a testa comportamentul acelui produs, in baza unor conditii diferite.

Subtipuri ale testarii de performanta

1. Load testing

Primul tip al testarii de performanta care are de regula loc la inceputul acestui proces este Load testing. Prin aceasta se verifica cum se comporta aplicatia in cauza cu un numar prestabilit, asteptat de useri care o vor accesa simultan. Spre exemplu, daca ne referim la un magazin online, iar in documentatie este stabilit ca poate fi accesata de 200.000 oameni concomitent, atunci testerii o vor testa cu acest numar (+/- 10-15%), pentru a vedea daca rezista in conditii normale.

Daca in documentatia tehnica nu e trecut niciun interval orientativ, atunci limita pentru Load testing se poate stabili de comun acord cu clientul sau poate fi estimata in baza datelor din Google Analytics, unde putem vedea care a fost traficul mediu orar sau zilnic. Load testing-ul simuleaza deci un context normal de folosire al softului respectiv.

2. Stress testing

Urmatorul tip de testare a performantei unui produs care vine natural dupa Load testing este Stress testing. Aceasta presupune ca se simuleaza folosirea aplicatiei de catre un numar cat mai mare de useri pentru a determina care este limita sa maxima la care poate rezista, si care e momentul in care poate ceda din punct de vedere al folosirii.

Acest tip de testare este unul mai special, si se executa de regula doar in medii controlate de catre echipa de testare ce a fost insarcinata sa realizeze aceasta sarcina, si numai cu acordul clientului. In caz contrar, realizarea unui Stress testing pe un website ales la intamplare poate conduce la prejudicii grave si la daune financiare sau de imagine.

3. Spike testing

Un tip particular al performantei unui produs este ceea ce se cheama Spike testing. Acest tip de testare se refera la a verifica stabilitatea aplicatiei in cauza atunci cand fluctuatiile de utilizatori sunt extrem de mari si intr-un interval de timp relativ scurt.

De exemplu, avem un magazin online in ziua de Black Friday. La miezul noptii acceseaza magazinul foarte multi oameni ca sa vada ofertele, pe urma scade ca se duc la culcare. Dimineata il acceseaza iar foarte multi pentru a face cumparaturi, pe parcursul zilei mai scade, seara cand sunt liberi iar il acceseaza si tot asa. Spike testing-ul verifica aceste „socuri” la care poate fi supusa o aplicatie software, iar parametrii difera de la caz la caz.

4. Endurance testing

Testarea de anduranta (Endurance testing) presupune verificarea produsului cu un numar normal, prestabilit de useri, ca la Load testing, dar pe o perioada mai lunga de timp. Aceasta testare se desfasoara cu scopul de a verifica stabilitatea aplicatiei intr-un termen mai lung de folosire (zile sau chiar saptamani), pentru a fi siguri ca face fata unui stres acceptabil, dar continuu sub aspectul duratei.

5. Soak testing

Oarecum in oglinda cu testarea de anduranta, Soak testing-ul se bazeaza pe testarea produsului nostru software cu un numar mare, uneori chiar urias de date/ utilizatori, si desfasurat pe un interval lung de timp. Asemanator cu precedentul tip de testare, scopul unui Soak testing este acela de a forta limitele superioare ale functionarii si ale performantei unei aplicatii pentru a determina clar cand si in ce conditii ar putea ceda, si sa fie aduse imbunatatirile necesare.

6. Volume testing

Dupa cum putem intui din denumirea ei, testarea de volum constituie un nivel de solicitare si mai mare pentru aplicatia testata. Practic, in acest caz introducem extrem de multe date care au dimensiuni extrem de mari intr-o baza de date a aplicatiei sau website, pe o perioada cat mai lunga de timp.

Obiectivul este tot acela de a testa care sunt limitele superioare ale folosirii produsului. De exemplu, avem un website al unei universitati dedicat pentru admiterea la studii. In acest caz putem simula ca pe o perioada de cateva zile sau chiar saptamani, website-ul respectiv primeste extrem de multe aplicatii si dosare de la foarte multi candidati (viitorii studenti), in intervalul cat dureaza perioada de inscriere, care poate fi in zile sau saptamani.

Instrumente pentru testarea de performanta

Pentru a putea simula un trafic cat mai mare sau chiar imens in unele situatii, este necesar sa utilizam anumite tool-uri care ne ajuta in testarea de performanta. Fara acestea, ar fi aproape imposibil sa simulam un trafic de 500.000 de useri, spre exemplu, pe o perioada lunga.

Un prim instrument de lucru pentru testarea de performanta este JMeter. Acesta este un tool gratuit, open-source. Acesta e construit cu limbajul de programare Java, si poate simula destul de usor un trafic de sute sau chiar mii de utilizatori pe un website, ajutandu-ne sa depistam eventualele probleme de incarcare sau scalabilitate. De asemenea, poate fi folosit si pentru testarea performantei API-urilor, daca vrei sa inveti si aceasta parte a testarii de performanta.

Instrumentul JMeter

Un al doilea instrument de Performance testing este LoadNinja. Aceasta este o aplicatie platita care este construita in browser (web based) si poate simula un trafic de useri mai mic sau mai mare, in timp real, pe aplicatiile noastre, in functie de tipul de testare de performanta verificat. Are un perioada de 14 zile de utilizare gratuita, dupa trebuie platit pentru ea.

Un alt instrument de lucru pentru testarea de performanta este Kobiton. Fiind construit tot in browser, Kobiton poate fi folosit pentru testarea performantei site-urilor sau a aplicatiilor mobile, fiind capabil printre altele de a genera automat scripturi de test pe baza testelor manuale si sa le execute in mod automat si simultan de pe mai multe dispozitive odata. Si acesta dispune initial de o perioada de utilizare gratuita, dupa insa trebuie platit.

StressStimulus este un alt tool specific pentru aceasta categorie de testare non-functionala. Acesta poate sa testeze aplicatiile web, pe cele mobile, si chiar si pe cele mai mari si mai complexe de tip Enterprise, fiind folosit de catre companii precum Deloitte sau HP. StressStimulus poate lucra cu trei tipuri de limbaje de programare/ scripting diferite si ofera prin interfata sa foarte multe detalii si rapoarte legate de eventualele probleme descoperite. Si aceasta este tot o aplicatie platita.

De asemenea, un instrument interesant din aceasta categorie este si Tricentis NeoLoad. Si acesta este capabil sa testeze performanta website-urilor, a aplicatiilor mobile sau a API-urilor, fiind destul de bogat in servicii oferite. Poate genera si actualiza scripturile de test, si poate fi integrata continuu (CI) in cadrul diverselor metodologii de lucru. Ca majoritatea acestor instrumente (exceptand JMeter), si Tricentis NeoLoad este un serviciu platit.

Tipuri de buguri in Performance testing

Tinand cont ca testarea de performanta are obiectivele sale distincte si foloseste mai multe instrumente speciale, dupa cum am vazut anterior, si tipurile defectelor depistate sunt unele specifice acestei verificari.

Unul dintre cele mai intalnite bug-uri care se refera la partea de performanta a unui website este timpul mare alocat pentru incarcarea unei pagini, cunoscut drept Long Load Time. Daca unei pagini ii ia mai multe de 2-3 secunde sa se incarce, atunci e o problema care se rasfrange in interactiunea pe care o are utilizatorul cu pagina/ site-ul respectiv, si va fi tentat sa il paraseasca fara a fi multumit.

Mai jos e un astfel de exemplu de pe un site cu filme. Se poate observa ca atunci cand am accesat un anumit film, paginii respective i-a luat peste 5 secunde sa se incarce, ceea ce e putin cam mult. In general Long Load Time apare cand ne confruntam cu website-uri ce contin fisiere mari, precum poze sau videoclipuri.

Exemplu de Long Load Time

O alta problema ce poate aparea este Poor Response Time. Fiind oarecum asemanator cu Long Load Time, acesta se refera la durata prea lunga pana cand un API primeste si transmite un raspuns catre utilizator. In acest caz, durata ideala de raspuns nu ar trebui sa depaseasca aproximativ 1 secunda.

Scalabilitatea slaba, sau Poor Scalability este o alta problema specifica performantei aplicatiilor. Aceasta se manifesta atunci cand aplicatia noastra software, indiferent de ce tip este ea, nu face fata unui numar asteptat si predefinit de useri, asa cum era specificat in documentatie. Pentru exemplificare, avem un website de prezentare proiectat sa sustina 10.000 de utilizatori simultan, dar cedeaza cand ajungem la 1000. Aceasta problema trebuie depistata cu ajutorul Load testing-ului.

O alta defectiune semnificativa ce trebuie mentionata in aceasta sectiune este Bottlenecking-ul („gatul de sticla”). Acesta presupune existenta unei probleme care duce la incetinirea fluxului de interactiune al utilizatorului respectiv atunci cand executa o serie de pasi fireasca in aplicatie.

De exemplu, daca suntem logati intr-un magazin online, adaugam un produs in cos, ne ducem spre sectiunea de Purchasing, dam click pe butonul „Buy/ Cumpara”, si de aici dureaza 10 minute pana se termina executia acestui pas si primim confirmarea pe ecran. Acesta e un bug destul de specific, dar care perturba semnificativ activitatea clientilor.

Concluzii

In incheiere, testarea de performanta (Performance testing) este un tip de testare non-functionala extrem de necesar, ce trebuie realizata in cadrul procesului de testare. Importanta sa e determinata de faptul ca aproape orice aplicatie din ziua de astazi este folosita de numere mari si foarte mari de utilizatori. Nu ne putem limita la a testa un website doar pe un laptop, de catre un singur om, si sa admitem ca poate rezista astfel la un trafic urias in anumite contexte, sau ca poate suporta un flux mare de date.

Testarea de performanta se realizeaza cu instrumente speciale, iar defectiunile identificate sunt si ele caracteristice. Acestea trebuie luate in seama cand sunt identificate, pentru corectia lor, deoarece sunt imediat sesizate de catre utilizatorii care interactioneaza greu cu aplicatia respectiva si le ia mult timp sa execute anumiti pasi normali. Anumiti testeri ajung sa se specializeze extrem de mult in directia testarii de performanta, la fel ca in cazul celei de securitate.

Surse consultate si suplimentare

Despre testarea de performanta in general

Comparatie Performance vs. Stress vs. Load testing

Instrumente pentru testarea de performanta

Tipuri de testare ale performantei

Resurse ISTQB despre testarea de performanta

Despre bug-uri si bune practici in Performance testing

Un articol interesant despre realizarea manuala a testarii de performanta

Mircea-Gabriel Macarie

https://www.linkedin.com/in/mirceamacarie/

Tech enthusiast și QA engineer, membru al comunității Vlog De IT. Interesat de testare software (QA) în general, de User Experience și Web Development.

Related post

Leave a Reply

Your email address will not be published. Required fields are marked *