Ce este testarea de scalabilitate? Învață cu Exemplu
Thomas Hamilton
⚡ Rezumat inteligent
Testarea scalabilității măsoară modul în care se comportă o aplicație atunci când sarcina utilizatorului, volumul de date sau rata tranzacțiilor cresc sau scad, dezvăluind punctul exact în care performanța se oprește scalarea și identificând blocajul responsabil.
Ce este testarea de scalabilitate?
Testare de scalabilitate este o metodă de testare nefuncțională care măsoară performanța unui sistem sau a unei rețele atunci când numărul de solicitări ale utilizatorilor este scalat în sus sau în jos. Scopul testării scalabilității este de a se asigura că sistemul poate gestiona o creștere preconizată a traficului utilizatorilor, a volumului de date și a frecvenței tranzacțiilor. Aceasta testează capacitatea sistemului de a satisface cererea în creștere.
Testarea scalabilității este un subtip de test de performanta, deci se concentrează pe comportamentul unei aplicații atunci când este implementată pe un sistem mai mare sau este exercitată sub sarcină excesivă. În Inginerie SoftwareTestarea scalabilității măsoară punctul în care o aplicație se oprește din scalare și identifică motivul din spatele acestui lucru.
De ce se face testarea scalabilității?
Problemele de capacitate apar rareori în timpul testării funcționale. Acestea ies la iveală în cea mai aglomerată zi de tranzacționare a anului, când începe o campanie de marketing sau când un set de date care a crescut în liniște timp de doi ani încetinește în cele din urmă fiecare interogare. Testarea scalabilității expune aceste limite mai întâi într-un mediu controlat. Mai exact, vă ajută să:
- Determinați cum se scalează aplicația pe măsură ce volumul de lucru crește și unde se aplatizează această curbă.
- Determinați limita de utilizatori simultani pentru aplicația web înainte ca timpii de răspuns să devină inacceptabili.
- Determinați degradarea la nivelul clientului și experiența utilizatorului final sub sarcină, cum ar fi randarea lentă a ecranului.
- Determinarea robusteții și degradării la nivelul serverului, inclusiv saturația procesorului, pierderile de memorie și epuizarea pool-ului de conexiuni.
Relația este cel mai ușor de imaginat sub forma unei curbe: debitul crește odată cu sarcina adăugată până când o resursă se saturează, după care utilizatorii suplimentari nu fac decât să prelungească coada.
Tipuri de testare a scalabilității
Scalabilitatea nu este o proprietate singulară, așa că un plan de testare acoperă de obicei mai mult de o dimensiune. Cele patru tipuri de mai jos sunt cele pe care le măsoară majoritatea echipelor, iar primele două decid forma mediului de testare în sine.
| Tip | Ce este scalat | Ce dovedește testul |
|---|---|---|
| Scalabilitate verticală (creștere) | CPU, memorie sau stocare adăugate la un singur server | Câtă sarcină suplimentară absoarbe o mașină modernizată și unde se află plafonul cu un singur nod |
| Scalabilitate orizontală (scalare laterală) | Servere, containere sau noduri suplimentare în spatele unui echilibrator de încărcare | Dacă debitul crește aproximativ proporțional cu nodurile adăugate sau dacă resursele partajate îl limitează |
| Scalabilitate funcțională | Funcții, module sau servicii noi | Dacă funcționalitatea adăugată poate fi absorbită fără a degrada tranzacțiile existente |
| Scalabilitate administrativă | Utilizatori, entități găzduite, echipe sau medii de gestionat | Indiferent dacă procesul de integrare, permisiunile și monitorizarea rămân funcționale pe măsură ce organizația crește |
Scalarea verticală este mai simplă deoarece arhitectura se schimbă rar, dar o singură mașină are întotdeauna un plafon. Scalarea orizontală elimină acest plafon și îmbunătățește toleranța la erori, cu prețul latenței rețelei, consistenței datelor și cheltuielilor generale de coordonare - toate acestea pe care testul trebuie să le măsoare, nu să le presupună.
Ce trebuie testat în testarea scalabilității
Scalabilitatea se evaluează în funcție de măsurători, nu de afișări. Înregistrați următoarele atribute la fiecare etapă de încărcare, astfel încât tendința, și nu doar numărul final, să fie vizibilă.
| Atribut | Ce iti spune |
|---|---|
| Timp de raspuns | Timpul dintre o solicitare a utilizatorului și răspunsul sistemului; acesta ar trebui să rămână constant pe măsură ce concurența crește |
| Tranziția ecranului | Cât de repede o pagină sau o vizualizare cedează locul următoarei sub sarcină |
| tranzitată | Volumul de cereri procesate pe unitatea de timp; un platou marchează limita de scalabilitate |
| Măsurători de timp | Timpul sesiunii, timpul de repornire, timpul de imprimare, timpul tranzacției și timpul de execuție a sarcinii |
| Performanță în raport cu numărul de utilizatori | Cum se modifică fiecare metrică pe măsură ce utilizatorii concurenți sunt adăugați în trepte |
| Solicitați tarife | Cereri pe secundă, tranzacții pe secundă și accesări pe secundă |
| Utilizarea rețelei | Lățimea de bandă consumată și latența pachetelor între niveluri |
| Utilizarea procesorului și a memoriei | Costul resurselor per tranzacție; o cifră în continuă creștere semnalează adesea o scurgere de informații |
| Contoare de servere web | Cereri și răspunsuri pe secundă, adâncimea cozii și conexiuni respinse |
| Performanță sub sarcină | Comportament combinat odată ce fiecare metrică este citită împreună la vârf |
Strategie de testare pentru testarea scalabilității
Strategia de testare pentru testarea scalabilității diferă în funcție de tipul de aplicație testată. Dacă o aplicație accesează un Baza de date, parametrii de testare vor include dimensiunea bazei de date în raport cu numărul de utilizatori și așa mai departe.
Cerințe preliminare pentru testarea scalabilității
- Capacitatea de distribuție a încărcăturii — Verificați dacă instrumentul de testare a sarcinii permite generarea sarcinii de la mai multe mașini și controlul acesteia dintr-un punct central.
- Operating System — Verifică ce sisteme de operare agenții de generare a încărcării și masterul de testare a încărcării rulează sub.
- procesor — Verificați ce tip de CPU este necesar pentru agentul utilizator virtual și masterul de testare a încărcării.
- Memorie — Verificați câtă memorie ar fi suficientă pentru agentul utilizator virtual și masterul de testare a încărcării.
- Mediu de testare — Verificați dacă mediu de testare oglindește producția suficient de îndeaproape pentru ca rezultatele să fie transferate.
Cum se face testarea de scalabilitate
- Definiți un proces repetabil pentru executarea testelor de scalabilitate pe tot parcursul ciclului de viață al aplicației
- Determinați criteriile de scalabilitate
- Lista scurtă a instrumentelor software necesare pentru a rula testul de încărcare
- Setați mediul de testare și configurați hardware-ul necesar pentru a executa testele de scalabilitate
- Planificați scenariile de testare, precum și testele de scalabilitate
- Creați și verificați scriptul utilizatorului virtual
- Creați și verificați scenariile de testare a sarcinii
- Executați testele
- Evaluează rezultatele
- Generați rapoartele necesare
Planul de testare a scalabilitatii
Înainte de a crea efectiv testele, dezvoltați un plan de testare detaliat. Este un pas important pentru a vă asigura că testul este conform cerințelor aplicației.
Următoarele sunt atributele pentru a crea un bine definit Planul de testare pentru testarea scalabilității.
- Pași pentru ScripturiScriptul de testare ar trebui să conțină pași detaliați care să determine acțiunile exacte pe care le-ar efectua un utilizator.
- Date de rularePlanul de testare ar trebui să determine orice date de execuție necesare pentru interacțiunea cu aplicația.
- Teste bazate pe dateDacă scripturile necesită date variabile în timpul execuției, trebuie să înțelegeți toate câmpurile care necesită aceste date.
Exemplu de testare a scalabilității
Să luăm în considerare un magazin online care așteaptă 2,000 de cumpărători simultani în timpul unei reduceri sezoniere. Echipa convine mai întâi asupra unui criteriu de trecere: tranzacția de finalizare a comenzii trebuie să se finalizeze în mai puțin de trei secunde pentru 95% dintre utilizatori, cu o rată de eroare sub un procent.
Testul rulează apoi același script browse-search-cart-checkout la 250, 500, 1,000, 1,500 și 2,000 de utilizatori virtuali. Timpul de răspuns se menține în apropierea a două secunde până la 1,000 de utilizatori, scade la 2.8 secunde la 1,500 și ajunge la nouă secunde la 2,000, în timp ce CPU-ul bazei de date este la 98%. Prin urmare, limita de scalabilitate este de aproximativ 1,500 de utilizatori, iar blocajul este nivelul bazei de date - nu serverele de aplicații pe care echipa plănuise să le adauge.
Instrumente de testare a scalabilității
Testarea scalabilității necesită un instrument care poate genera încărcare de pe mai multe mașini simultan și poate raporta rezultatele centralizat. Alegerea se face de obicei în funcție de limbajul principal al echipei și de protocoalele testate.
| Instrument | scripting | Cel mai potrivit pentru |
|---|---|---|
| Apache JMeter | Planuri de testare GUI plus XML, Java bazat | Acoperire largă de protocoale, inclusiv JDBC, JMS, LDAP și SOAP |
| Grafana k6 | JavaScript sau TypeScript | Teste API și microservicii conectate la o conductă CI/CD |
| gatling | Java, Kotlin sau Scala DSL | Număr mare de utilizatori virtuali per injector, cu rapoarte HTML detaliate |
| roșcov | Simplu Python | Python echipe care trebuie să extindă clientul dincolo de HTTP |
| LoadRunner | Scripturi de tip C înregistrate în VuGen | Sisteme de operare de dimensiuni mari, cu aplicații vechi și pachete |
Alergători găzduiți în cloud, cum ar fi BlazeMeterLoadView și Gatling Enterprise se află pe lângă mai multe dintre aceste motoare și merită luate în considerare atunci când un test are nevoie de zeci de mii de utilizatori virtuali sau trafic din mai multe regiuni geografice. O analiză mai amplă a categoriei este disponibilă în ghidul pentru instrumente de testare a performanței.
Provocări și cele mai bune practici în testarea scalabilității
Cele mai dezamăgitoare rezultate de scalabilitate tracRevenim la configurația de testare, nu la aplicație. Acestea sunt problemele care reapar și obiceiurile care le previn.
Provocări comune
- Medii subdimensionate — Un banc de testare cu jumătate din memoria de producție raportează un blocaj care nu există în producție.
- Modele de sarcină de lucru nerealiste — Scripturile fără timp de gândire sau variație a datelor accesează memorii cache pe care utilizatorii reali le-ar rata.
- Rezultate zgomotoase — Scalarea automată, colectarea gunoiului și hardware-ul cloud partajat fac ca două rulări identice să fie în contradicție.
- Observabilitate subțire — Fără valori măsurabile pe server, un rezultat lent arată că ceva s-a stricat, dar nu și ce anume.
- Costat — Generarea unei concurențe foarte mari necesită propria flotă de generatoare de sarcină, ceea ce este ușor de subestimat în buget.
Cele mai bune practici
- Stabiliți criteriile de trecere, cum ar fi o percentilă a timpului de răspuns și un plafon al ratei de eroare, înainte de prima rulare.
- Măriți sarcina în etapele planificate și mențineți fiecare etapă suficient de mult timp pentru ca sistemul să se stabilizeze.
- Variați datele de testare pentru fiecare utilizator virtual, astfel încât memorarea în cache să nu influențeze negativ rezultatele.
- Colectați indicatori de aplicație, bază de date și infrastructură, alături de cifrele de pe partea clientului.
- Stocați scripturile de testare în controlul versiunilor și rulați o scurtă verificare a scalabilității la fiecare compilare, apoi o rulare completă înainte de lansare.
- Comparați tendințele între versiuni, în loc să judecați un singur raport în mod izolat.
Testarea scalabilității vs. testarea încărcării
Cele două sunt adesea confundate deoarece ambele aplică sarcină. Diferența constă în întrebarea la care răspunde fiecare: Testarea Scalabilității întreabă cât de mult poate crește sistemul, în timp ce testarea sarcinii întreabă dacă face față încărcăturii deja așteptate.
| Bază | Testare de scalabilitate | Încărcarea testelor |
|---|---|---|
| Focus | Se concentrează pe performanța site-urilor web, software-ului, hardware-ului și aplicațiilor dvs. atunci când se fac modificări la dimensiunea sau volumul sistemului pentru a satisface o nevoie tot mai mare. | Testarea încărcării se concentrează pe testarea unei aplicații sub sarcini mari, pentru a determina în ce punct timpul de răspuns al sistemului eșuează. |
| Model de încărcare | Sarcina este crescută în etape, iar resursele pot fi adăugate între etape | Sarcina este menținută la un vârf așteptat pentru o durată fixă |
| Întrebare răspunsă | Cât de mult poate crește acest sistem și ce îl limitează? | Își îndeplinește acest sistem obiectivele convenite astăzi? |
| Ieșire tipică | O limită de scalabilitate, un blocaj și un plan de capacitate | O evaluare de succes sau eșec în funcție de timpul de răspuns și obiectivele de debit |
Amândoi stau sub testarea nefuncțională umbrelă alături testare stresanta, testarea vârfurilor, testare de anduranță și testarea volumului...iar o strategie de performanță matură rulează de obicei mai multe dintre ele pe aceleași scripturi.
