Planificarea Testării de Performanţă

În acest articol aş dori să vă prezint o scurtă introducere în planificarea Testării de Performanţă, precum și în planificărea colectării și analizării rezultatelor prin prisma experienţei mele în acest domeniu. Voi porni de la prezumţia că cititorul are cunoştinţe despre terminologia folosită în Testarea de Performanţă. În cadrul articolului voi face referire la unele metrici folosite, cerinţe Non-funcţionale pe care le voi folosi ca exemple.

Ce este testarea de performanţă și de ce avem nevoie de ea?

Definiţia ISTQB pentru Testarea de Performanţă este "procesul de testare prin care se determină performanţa unui produs". Cu alte cuvinte scopul nostru este de a afla cât de bun este un produs software, cât de rapid, câţi useri poate să susţină precum și timpul de răspuns pentru fiecare dintre ei, sau care sunt limitele produsului.

Rezultatele obţinute în urma testelor de performanţă vor ajuta factorii de decizie din Business să ia o decizie informată cu privire la lansarea unui produs.

Testarea de performanţă va oferi informaţii despre cum se va comporta produsul în utilizarea zilnică, cu acces concurent din partea utilizatorilor. Rezultatele vor folosi în estimarea resurselor hardware necesare pentru a susține un anumit număr de utilizatori.

Există câteva categorii de Teste de Performanţă, fiecare având particularităţi în ceea ce priveşte scopul, planificarea și execuţia:

• Load - al cărui scop este de a vedea comportamentul sistemului când un anumit număr de utilizatori îl foloseşte simultan
• Stress - al cărui scop este de a determina limitele și robusteţea sistemului
• Soak - al cărui scop este de a determina comportamentul sistemului pe o perioadă mai mare timp în care un anumit număr de utilizatori îl foloseşte

Cum planificăm Testarea de Performanţă?

Ca orice fel de testare, Testarea de Performanţă trebuie planificată cu grijă. Cerinţele, resursele necesare, crearea scenariilor și rularea lor, colectarea și analiza rezultatelor, raportarea rezultatelor, tool-urile necesare sunt câteva dintre artefactele de luat în considerare.

Planificarea Testării de Performanţă se poate face într-un document separat sau într-un capitol ca parte a Test Plan-ului proiectului.

De obicei se iau în considerare următoarele aspecte în planificarea Testării de Performanţă:

Cerinţele

Este cel mai important aspect alături de tehnologia folosită în dezvoltarea produsului. Necesarul de tool-uri este de asemenea determinat pe baza cerinţelor şi a tehnologiei folosite. Cerinţele Non-funcționale vor conţine cifrele exacte pentru timpul de răspuns, număr de acţiuni concurente.

Resursele umane necesare

Skill-urile necesare pentru designul, scrierea și executarea testelor de performanţă trebuie analizate cu grijă. Consider Testarea de Performanţă ca un efort de echipa în care trebuie sa fie implicaţi arhitecţii și programatorii. Expertiza arhitecţilor în arhitectura produsului este de folos în design-ultestelor care vor descoperi vulnerabilităţile sistemului, pe când expertiza developerilor este folositoare în scrierea script-urilor. De asemenea trebuie să participe în analiza rezultatelor pentru o mai bună înţelegere a comportamentului sistemului şi a acţiunilor coercitive ?.

Design-ultestelor și execuţia lor

A. Testele de performanţă sunt concepute să acopere cerinţele non-funcționale cu scenarii reflectând situaţii reale. Scenariile folosite de mine au ca părți componente importante următoarele:

• Ramp-up - este timpul necesar ca toți utilizatorii să fie gata pentru a executa acţiunile testului (de exemplu să fie logati şi să înceapă să ruleze acţiunile)
• Distribuţia încărcării şi a acţiunilor în timp - scenariile apropiate de realitate vor fi create având în vedere tipurile de utilizatori ai aplicaţiei şi acţiunile pe care le pot face fiecare dintre ei
• Ramp-down - este timpul necesar utilizatorilor să termine acţiunile şi încărcarea serverului să înceteze

B. Momentul rulării testelor de performanţă în timpul dezvoltării produsului este important. Rularea testelor de performanță e bine să fie făcută când majoritatea funcţionalităţilor sunt implementate şi sunt stabile (un procent de 80% minim). Dacă funcţionalitatea nu este finalizată în mare parte, rezultatele testelor pot fi irelevante. Orice schimbare majoră a codului va afecta rezultatele testelor de performanţă şi compararea rezultatelor rulărilor succesive a testelor de performanţă nu va putea fi făcută. Se pot rula teste de performanţă pe funcţionalităţi separate sau servicii atunci când acea funcţionalitate se poate testa independent. Astfel, rezultatele oferă un feedback continuu și relevant asupra performanţei sistemului. E bine să se planifice testarea de performanţă în mod continuu, mai ales în contextul Agile, când se livrează funcţionalitate completă în fiecare Sprint sau un număr relative mic de Sprint-uri.

În timpul unui release, testele de performanţă se rulează de un număr limitat de ori datorită timpului necesar rulării lor și resurselor hardware necesare. Rularea testelor, analiza rezultatelor și fixurile sunt realizate într-un ciclu iterativ.

O altă abordare în obținerea informaţiilor despre performanţa unui sistem este de a adăuga listener-i în Unit test şi în testele de API. Astfel se vor obține informaţii despre cât de performante sunt anumite metode/fluxuri.

C. Colectarea rezultatelor și raportarea

Setul de rezultate colectate în cursul testelor de performanţă trebuie definit cu grijă şi să fie minimalist pentru

• a colecta rezultatele relevante. Tool-urile pentru teste de performanţă oferă o larga varietate de rezultate ce pot fi colectate în special în ceea ce priveşte timpul de răspuns. Resursele hardware pot fi monitorizate prin intermediul acestor tool-uri sau instalând tool-uri de monitorizare direct pe sistemul aflat în test
• a nu colecta prea multe rezultate. Colectarea prea multor rezultate va avea impact atât asupra maşinii pe care rulează tool-ul de testare, consumând din resursele necesare susţinerii load-ului cât şi a resurselor de pe sistemul aflat în test afectând numărul de acţiuni executate

Voi prezenta o lista cu rezultatele pe care obişnuiesc să le colectez:

• Timpul de răspuns. Analizând timpii de răspuns se pot observa spre exemplu peak-urile, care pot fi corelate cu gradul de utilizare a resurselor hardware ale sistemului aflat în teste
• Timpul de răspuns minim și maxim
• Timpul de răspuns mediu. Pe lângă timpul de răspuns mediu este relevant să se vadă câte acţiuni au fost realizate în mai puţin timp sau mai mult decât timpul mediu de răspuns. Este important câţi timpi de răspuns au fost foarte lungi. Procentele (90, 95, 99) sunt folosite pentru a afla numărul de acţiuni ale căror timp de răspuns au fost 90%, 95%, 99% cele mai încete pe o scara de la cel mai mic la cel mai mare timp de răspuns
• Throughput: câte acţiuni concurente poate să susţină sistemul. Acest rezultat este important și ajută în determinarea resurselor hardware ale sistemul de producţie
• Erori: rata de eroare va arăta câte acţiuni şi din ce cauza nu s-au încheiat cu succes. Analiza erorilor va releva dacă sistemul nu poate susţine o anumită încărcare şi dă time-out.
• Consumul resurselor hardware (CPU, memorie, disk, retea). Load-ul trebuie făcut până la un consum de 85% din resursele hardware ale sistemului testat astfel încât să se poată interveni şi opri testul de performanţă înainte ca sistemul să devine inoperabil.

D. Raportarea: Rapoartele testelor de performanţă vor prezenta eficienţa sistemului cu privire la cerinţele Non-funcţionale.

Următoarele detalii, dar nu şi singurele, sunt parte ale raportului asupra testelor de performanţă:

• Detaliile legate de sistemul testat, IP, detalii despre hardware-ul folosit, Sistemul de Operare, topologia de reţea, build-ul folosit, data;
• Scenariile rulate și scopul fiecăruia dintre ele;
• Tool-urile de performanţă folosite;
• Măsurătorile efective.

Tool-uri

Alegerea tool-urilor folosite pentru testarea de performanţă va avea în vedere următoarele criterii:

• Suportul oferit în rularea scenariilor complexe;
• Capacitatea de distribuire a incărcării şi profilurilor utilizatorilor;
• Rapoartele oferite.

Evaluarea tool-urilor gratuite sau ale celor oferite de producătorii de tool-uri de performanţă trebuie făcută având în vedere contextul proiectului şi a cunoştinţelor existente în echipa. Pentru anumite tool-uri va fi nevoie de cunoştinţe de programare pentru a rula scenarii complexe (cum ar fi JMeter), pe când alte tool-uri (cum ar fi LoadRunner) oferă aceasta funcţionalitate.

Concluzii

Voi prezenta câteva concluzii din experienţa mea utile unei planificari cât mai eficientă a testării de performanţă:

• Planificarea și execuţia testării de performanţă ar trebui să fie un efort comun al echipei de proiect incluzând software arhitecţi și developeri.
• Importanţa capabilităţilor tool-urilor şi a skill-urilor necesare nu trebuie neglijată