Știi senzația aia când deschizi JIRA dimineața și găsești un bug cu prioritate „Critical" ridicat de clientul cel mai nervos din portofoliu? Subiect: „Site‑ul merge greu. Fix ASAP." Niciun screenshot, niciun număr, nicio reproducere. Doar acea propoziție îngrozitor de vagă care îți strică cafeaua.
Problema reală nu e că site‑ul e lent. Problema e că nu știi *cât* de lent, *pentru câți utilizatori simultani*, *la ce endpoint* și *în ce condiții*. Și ca să răspunzi la toate astea ai nevoie de un test de performanță. Dacă n‑ai scris niciodată unul, k6 e cel mai bun prieten pe care îl poți găsi acum.
Shall we?
Ce este k6 și de ce îl alegi față de celelalte tool‑uri?
k6 este un tool open‑source de load testing creat de Grafana Labs, scris în Go și scriptuit în JavaScript. Nu ai nevoie de o interfață grafică, nu ai nevoie de un server separat pentru a‑l porni și nu ai nevoie de licență. Îl instalezi, scrii un fișier .js și dai run.
Față de JMeter – care există din 2000 și e venerabil, dar XML‑ul lui poate să-ți mănânce o jumătate de zi – k6 are o curbă de învățare mult mai blândă pentru cineva care a mai atins JavaScript sau TypeScript. Față de Locust (Python), dacă echipa ta e full JavaScript sau full QA‑automation‑cu‑Playwright/Cypress, rămâi în același ecosistem.
La DevTalks Cluj din 2024, un speaker de la o firmă de e‑commerce din România menționa că au migrat de la JMeter la k6 și au redus timpul de scriere a unui script de load cu ~60%. Nu e magie, e pur și simplu sintaxă mai curată.
Ce înseamnă, de fapt, „performanță"? Câteva numere de ținut minte
Înainte să scriem o linie de cod, trebuie să știm ce testăm. „Site‑ul merge greu" nu e un criteriu de acceptanță. Astea sunt:
- Timp de răspuns (response time): sub 200 ms pentru API‑uri interne, sub 2 secunde pentru pagini web încărcate de utilizatori reali – acesta e pragul de aur Google/Nielsen.
- Erori (error rate): sub 1% din cereri eșuate sub sarcină normală.
- Throughput: câte cereri pe secundă (RPS) poate servi aplicația fără să cadă.
- Utilizatori virtuali (VUs – Virtual Users): simularea utilizatorilor concurenți.
Dacă lucrezi în domeniul bancar sau retail, unde traficul poate exploda de 10x în Black Friday sau la lansarea unui produs nou, aceste numere devin critice. Un sistem care servește 50 de utilizatori simultani confortabil poate ceda la 500 dacă baza de date MySQL nu are indexurile corecte sau dacă conexiunile nu sunt pooled.
Instalare și primul script – pas cu pas, fără dramă
Instalarea k6 durează mai puțin decât să-ți faci un espresso
Pe macOS: brew install k6
Pe Windows: winget install k6
Pe Linux (Debian/Ubuntu): sudo apt install k6
Gata. Acum deschidem editorul preferat și scriem primul script. Îl numim smoke_test.js – pentru că un smoke test de performanță verifică că aplicația nu pică nici măcar sub o sarcină minimă.
import http from 'k6/http';
import { sleep, check } from 'k6';
export const options = {
vus: 5,
duration: '30s',
};
export default function () {
const res = http.get('https://site‑ul‑tau.ro/api/produse');
check(res, {
'status 200': (r) => r.status === 200,
'timp raspuns sub 500ms': (r) => r.timings.duration < 500,
});
sleep(1);
}
Ce face acest script? Pornește 5 utilizatori virtuali care timp de 30 de secunde fac câte un request GET la endpoint‑ul /api/produse, verifică statusul și timpul de răspuns, apoi așteaptă 1 secundă înainte de următorul request. Simplu. Curat. Rulabil imediat cu comanda: k6 run smoke_test.js
În terminal vei vedea în timp real: câte cereri s‑au făcut, câte au trecut check‑urile, care e media timpilor de răspuns și percentila p(95) – adică timpul sub care se încadrează 95% din cereri. Aceasta din urmă e metrica pe care o vei raporta în JIRA când ridici un bug de performanță.
De la smoke test la load test real – cum escaladezi treptat
Smoke test‑ul de mai sus e primul pas. Dar clientul vrea să știe ce se întâmplă când 500 de utilizatori se loghează simultan vinerea seara. Acolo intervine load test‑ul și conceptul de ramp‑up.
În loc de vus și duration fixe, k6 îți oferă stages
export const options = {
stages: [
{ duration: '2m', target: 100 },
{ duration: '5m', target: 500 },
{ duration: '2m', target: 0 },
],
};
Primele 2 minute crești treptat la 100 VUs (ramp‑up), 5 minute menții 500 VUs (platoul de sarcină), apoi cobori la 0 (ramp‑down). Dacă în platou observi că error rate‑ul trece de 1% sau p(95) explodează la 8 secunde, ai găsit pragul de rupere al sistemului. Felicitări, tocmai ai transformat un vag „merge greu" într‑un bug reproductibil cu date concrete.
Un sfat din practică: rulează întotdeauna testele de performanță pe un mediu dedicat (staging), nu pe producție. Sună evident, dar la un proiect de ospitalitate la care am contribuit, cineva a rulat un load test direct pe prod un marți după-amiaza. Au sunat 3 clienți în 20 de minute. N‑a fost frumos.
Ce faci cu rezultatele și cum le raportezi
k6 exportă rezultatele în JSON, CSV sau le trimite direct în Grafana, InfluxDB sau Prometheus. Dacă echipa ta folosește deja Grafana pentru monitorizare (cum fac multe firme din domeniile automotive și energie în România), integrarea e nativă și dashboardul e gata în câteva minute.
Când deschizi un bug de performanță în JIRA, include:
- Numărul de VUs la momentul degradării
- Metrica p(95) și p(99) din output‑ul k6
- Error rate‑ul exact (procente, nu „destul de mult")
- Endpoint‑ul afectat și metoda HTTP
- Mediul în care s‑a rulat testul
Asta e diferența dintre un raport de performanță care se închide cu „won't fix" și unul care ajunge în sprint‑ul următor cu prioritate înaltă. Datele concrete nu se ignoră.
Mindset‑ul corect: performanța nu e un task de final de proiect
Cel mai frecvent anti‑pattern pe care îl văd – și pe care îl discutăm mult în cadrul cursurilor Academia Testarii – e că testele de performanță sunt „ceva ce facem înainte de go‑live". Nu. Ele ar trebui să fie parte din pipeline‑ul de CI/CD, la fel ca testele automate de regresie cu Selenium sau Playwright.
k6 se integrează nativ cu GitHub Actions, GitLab CI și Jenkins. Un smoke test de performanță care rulează la fiecare Pull Request costă 30 de secunde și poate prinde o regresie de performanță înainte să ajungă pe producție. Aceasta e maturitatea la care aspirăm când vorbim de QA adevărat, nu de „testăm la sfârșit și vedem".
La A4Q Summit și la evenimentele unde Academia Testarii a fost prezentă, tema testării de performanță integrate în pipeline revenea constant în discuțiile dintre seniorii din sală. Nu mai e un subiect de nișă – e o competență de bază.
Dacă ai ajuns până aici și simți că vrei să mergi mai departe – să înveți despre thresholds, scenarios, browser testing cu k6, sau să înțelegi cum se corelează rezultatele k6 cu query‑urile lente din MySQL – atunci ești exact unde trebuie.
La Academia Testarii găsești cursuri hands‑on care acoperă testarea de performanță de la zero până la nivel avansat, construite pentru oameni reali, nu pentru manuale universitare. Cursanții noștri au plecat din roluri complet diferite și au ajuns să livreze rapoarte de load testing pentru aplicații din banking, retail și automotive. Tu ești următorul.
Intră pe academiatestarii.ro, uită-te la cursurile disponibile și alege‑l pe cel care te scoate din „site‑ul merge greu" și te duce în „am identificat bottleneck‑ul la p(95) = 3.2s sub 400 VUs". 🎯
#DeAziEstiTester #AcademiaTestarii #PerformanceTesting #LoadTesting #k6