Testarea performanței ( ing . Testarea performanței ) în ingineria software este o testare care este efectuată pentru a determina cât de repede funcționează un sistem computerizat sau o parte a acestuia sub o anumită sarcină . De asemenea, poate servi la testarea și validarea altor atribute de calitate ale sistemului, cum ar fi scalabilitatea , fiabilitatea și consumul de resurse.
Testarea performanței este una dintre domeniile emergente ale ingineriei performanței în informatică, care încearcă să ia în considerare performanța în faza de modelare și proiectare a unui sistem, înainte de începerea fazei principale de codare .
În testarea performanței, se disting următoarele domenii:
Există două abordări ale testării performanței software-ului [1] :
Testarea de încărcare este cea mai simplă formă de testare a performanței. Testarea de sarcină este de obicei efectuată pentru a evalua comportamentul unei aplicații la o sarcină așteptată dată. Această încărcare poate fi, de exemplu, numărul așteptat de utilizatori concurenți ai aplicației care efectuează un anumit număr de tranzacții pe interval de timp. Acest tip de testare vă permite de obicei să obțineți timpul de răspuns al tuturor celor mai importante tranzacții comerciale. În cazul monitorizării unei baze de date, a unui server de aplicații , a unei rețele etc., acest tip de testare poate identifica și unele blocaje ale aplicațiilor.
Testarea de stres este folosită în mod obișnuit pentru a înțelege limitele de debit ale unei aplicații. Acest tip de testare este efectuat pentru a determina fiabilitatea sistemului în timpul sarcinilor extreme sau disproporționate și răspunde la întrebări despre performanța suficientă a sistemului în cazul în care sarcina curentă depășește cu mult maximul așteptat.
Testarea de stabilitate este efectuată pentru a se asigura că aplicația poate rezista sarcinii așteptate pe termen lung. Acest tip de testare monitorizează consumul de memorie al aplicației pentru a identifica eventualele scurgeri. În plus, o astfel de testare relevă o degradare a performanței, care se exprimă într-o scădere a vitezei de procesare a informațiilor și/sau o creștere a timpului de răspuns al aplicației după o perioadă lungă de timp față de începutul testului.
Testarea configurației este un alt tip de testare tradițională a performanței. În acest caz, în loc să se testeze performanța sistemului în ceea ce privește sarcina aplicată, este testat impactul asupra performanței al modificărilor configurației. Un bun exemplu de astfel de testare ar fi experimentarea cu diferite metode de echilibrare a sarcinii. Testarea configurației poate fi, de asemenea, combinată cu testarea de sarcină, stres sau stabilitate.
În cazuri generale , testarea performanței poate servi în scopuri diferite.
Multe teste de performanță sunt efectuate fără nicio încercare de a înțelege scopul lor real. Înainte de a începe testarea, trebuie pusă întotdeauna întrebarea de afaceri: „Care este obiectivul pe care îl urmărim cu testarea performanței?”. Răspunsurile la această întrebare fac parte din studiul de fezabilitate (sau cazul de afaceri ) al testării. Obiectivele pot varia în funcție de tehnologia utilizată de aplicație sau de scopul acesteia, cu toate acestea, ele includ întotdeauna unul dintre următoarele:
Dacă utilizatorii finali ai aplicației sunt considerați utilizatori care se conectează la sistem sub orice formă, atunci obținerea paralelismului este foarte de dorit în acest caz. Prin definiție, acesta este numărul maxim de utilizatori concurenți ai unei aplicații pe care se așteaptă ca aplicația să îi accepte la un moment dat. Modelul de comportament al utilizatorului poate afecta semnificativ capacitatea unei aplicații de a procesa cereri în paralel, mai ales dacă implică conectarea și deconectarea periodică din sistem.
Dacă conceptul aplicației nu este să funcționeze cu utilizatori finali specifici, atunci obiectivul de performanță urmărit se va baza pe debitul maxim sau pe numărul de tranzacții pe unitatea de timp. Un exemplu bun în acest caz ar fi navigarea pe web, de exemplu pe portalul Wikipedia.
Acest concept este construit în jurul timpului de răspuns al unui nod de aplicație la o solicitare trimisă altuia. Un exemplu simplu este o solicitare HTTP „GET” de la un browser de stație de lucru către un server web. Aproape toate aplicațiile dezvoltate pentru testarea sarcinii funcționează exact conform acestei scheme de măsurare. Uneori, este logic să setați ținte pentru a obține performanța timpului de răspuns al serverului în toate nodurile de aplicație.
Timpul de afișare este unul dintre cele mai dificile concepte pentru o aplicație de testare a încărcării, deoarece în general nu folosesc conceptul de lucru cu ceea ce se întâmplă pe nodurile individuale ale sistemului, limitându-se doar la recunoașterea unei perioade de timp în care nu există activitatea de rețea. Măsurarea timpului de afișare necesită, în general, includerea cazurilor de testare funcțională în testele de referință, dar majoritatea aplicațiilor de referință nu includ această capacitate.
Este foarte important să detaliezi cerințele de performanță și să le documentezi într-un fel de plan de testare a performanței. În mod ideal, acest lucru se face în timpul fazei de dezvoltare a cerințelor a dezvoltării sistemului, înainte ca detaliile de proiectare să fie elaborate. Vedeți ingineria performanței .
Cu toate acestea , testarea performanței nu este adesea efectuată conform specificațiilor, deoarece nu există o înțelegere fixă a timpului maxim de răspuns pentru un anumit număr de utilizatori. Testarea performanței este adesea folosită ca parte a procesului de profilare a performanței. Ideea lui este să găsească o „vergă slabă” - o astfel de parte a sistemului, prin optimizarea timpului de reacție al căruia, puteți îmbunătăți performanța generală a sistemului. Determinarea carei părți a sistemului se află pe această cale critică este uneori o sarcină foarte dificilă, așa că unele aplicații de testare includ (sau pot fi adăugate prin suplimente) instrumente care rulează pe server (agenți) care monitorizează timpul de execuție a tranzacțiilor, accesul la baza de date timpul, suprasarcinile de rețea și alți indicatori ai părții server a sistemului care pot fi analizați împreună cu alte statistici de performanță.
Testarea benchmark se poate face pe o rețea extinsă și chiar în locații îndepărtate geografic, având în vedere că viteza Internetului variază în funcție de locație. Poate fi realizat și local, dar în acest caz este necesar să configurați routerele de rețea în așa fel încât să existe o întârziere care este prezentă în toate rețelele publice. Sarcina aplicată sistemului trebuie să se potrivească cu starea reală a lucrurilor. Deci, de exemplu, dacă 50% dintre utilizatorii sistemului utilizează un canal de rețea de 56K pentru a accesa sistemul, iar cealaltă jumătate utilizează un canal optic, atunci computerele care creează o sarcină de testare pe sistem ar trebui să utilizeze aceleași conexiuni (ideal) sau să emuleze întârzierile conexiunilor de rețea de mai sus, în urma unor profiluri de utilizator date.
Cerințele de performanță ar trebui să abordeze, cel puțin, următoarele întrebări:
Există o neînțelegere comună conform căreia instrumentele de testare a încărcării sistemului sunt aceleași instrumente de înregistrare și redare ca instrumentele pentru automatizarea testării regresiei . Instrumentele de testare a încărcării funcționează folosind un protocol, în timp ce instrumentele pentru automatizarea testării regresiei funcționează atât folosind un protocol, cât și folosind obiecte GUI.
| Exemplul 1:
Există un browser de Internet standard care îndeplinește funcția de a urmări linkul specificat atunci când este apăsat un buton. În acest caz, pentru a automatiza testarea de regresie, trebuie să scrieți un script care trimite un clic de mouse și un clic de buton către browser, în timp ce pentru a crea un script pentru testarea încărcării, trebuie să scrieți o transmisie de hyperlink din browser către mai mulți utilizatori. , inclusiv un nume de utilizator și o parolă unice pentru fiecare dintre ele. |
Există diverse instrumente pentru detectarea și investigarea problemelor în diferite părți ale sistemului. Toate nodurile sistemului pot fi clasificate după cum urmează:
De remarcat, de asemenea, este apariția aplicațiilor în rețea Business-to-business (B2B) care utilizează un acord de nivel de servicii (sau SLA, Acord de nivel de serviciu). Popularitatea tot mai mare a aplicațiilor B2B a dus la faptul că tot mai multe aplicații trec la o arhitectură orientată spre servicii , în care schimbul de informații are loc fără participarea browserelor web. Un exemplu de astfel de interacțiune ar fi o agenție de turism care solicită informații despre un anumit zbor între Sankt Petersburg și Omsk, în timp ce compania aeriană trebuie să ofere un răspuns în 5 secunde. Adesea, încălcarea acordului SLA amenință cu o amendă mare.
Cele mai populare instrumente de testare a sarcinii sunt enumerate mai jos.
| PE | Numele producatorului | Comentarii |
|---|---|---|
| OpenSTA | „Arhitectura de testare a sistemului deschis” | Software gratuit pentru testarea de încărcare/stres, licențiat sub GNU GPL. Utilizează o arhitectură de aplicație distribuită bazată pe CORBA . Este disponibilă o versiune Windows, deși există probleme de compatibilitate cu Windows Vista. Sprijinul s-a încheiat în 2007. |
| IBM Rational Performance Tester | IBM | Bazat pe mediul de dezvoltare Eclipse , software care vă permite să creați o încărcare mare și să măsurați timpul de răspuns pentru aplicațiile cu arhitectură client-server. Necesită licență. |
| jmetru | Deschideți proiectul Apache Jakarta | Setul de instrumente multiplatformă bazat pe Java, care vă permite să efectuați teste de încărcare utilizând conexiuni JDBC / FTP / LDAP / SOAP / JMS / POP3 / HTTP / TCP. Vă permite să creați un număr mare de solicitări de la diferite computere și să controlați procesul de la unul dintre ele. |
| HP LoadRunner | Micro Focus (achizitionat de la HP) | Un instrument de testare a încărcării dezvoltat inițial pentru a emula munca unui număr mare de utilizatori concurenți. Poate fi folosit și pentru unitate sau integrare . |
| Silk_Performer | Micro Focus | |
| Test de încărcare Visual Studio | Microsoft | Visual Studio oferă un instrument de testare a performanței, inclusiv testarea încărcării/unității |
Unul dintre rezultatele obținute în timpul testării de sarcină și utilizat pentru analize ulterioare este indicatorii de performanță ai aplicației. Cele principale sunt discutate mai jos.
1. Consumul de resurse CPU (CPU, %)O valoare care arată cât de mult timp dintr-un anumit interval definit a fost petrecut de procesor pentru calculele pentru procesul selectat. În sistemele moderne, un factor important este capacitatea unui proces de a rula în mai multe fire, astfel încât procesorul să poată efectua calcule în paralel. Analiza istoricului consumului de resurse CPU poate explica impactul asupra performanței generale a sistemului de fluxuri de date procesate, configurația aplicației și a sistemului de operare, calculul cu mai multe fire și alți factori.
2. Utilizarea memoriei (Mb)O valoare care arată cantitatea de memorie utilizată de aplicație. Memoria folosită poate fi împărțită în trei categorii:
Când aplicația rulează, memoria este umplută cu referințe la obiecte, care, dacă nu sunt utilizate, pot fi șterse printr-un proces automat special numit „colector de gunoi” (ing. Garbage Collector ). Timpul necesar procesorului pentru a curăța memoria în acest fel poate fi semnificativ atunci când procesul a consumat toată memoria disponibilă (în Java, așa-numita „GC persistentă completă”) sau când procesului i-au fost alocate cantități mari de memorie care trebuie curățată. În timpul necesar pentru curățarea memoriei, accesul unui proces la paginile de memorie alocată poate fi blocat, ceea ce poate afecta timpul final de procesare a procesului respectiv.
3. Consumul de resurse de rețeaAceastă măsurătoare nu este direct legată de performanța aplicației, dar indicatorii săi pot indica limitele de performanță ale sistemului în ansamblu.
| Exemplul 2:
Aplicația server, procesând cererea utilizatorului, îi returnează un flux video folosind un canal de rețea de 2 megabiți. Cerința prevede că serverul trebuie să proceseze 5 solicitări de utilizator în același timp. Testarea de încărcare a arătat că serverul poate furniza în mod eficient date doar 4 utilizatori în același timp, deoarece fluxul multimedia are o rată de biți de 500 de kilobiți. Este evident că furnizarea acestui flux către 5 utilizatori în același timp este imposibilă din cauza excesului de lățime de bandă a canalului de rețea, ceea ce înseamnă că sistemul nu îndeplinește cerințele de performanță specificate, deși consumul său de resurse de procesor și memorie poate fi scăzut. |
Lucrul cu subsistemul de disc poate afecta semnificativ performanța sistemului, astfel încât colectarea de statistici despre lucrul cu discul poate ajuta la identificarea blocajelor în acest domeniu. Un număr mare de citiri sau scrieri poate face ca procesorul să rămână inactiv în timp ce se așteaptă ca datele să fie procesate de pe disc și, în consecință, poate crește consumul CPU și crește timpul de răspuns.
5. Timp de răspuns la cerere (ms)Timpul de executare a unei cereri de către o aplicație rămâne unul dintre cei mai importanți indicatori ai performanței unui sistem sau aplicație. Acest timp poate fi măsurat pe partea de server ca o măsură a timpului necesar pentru ca partea de server să proceseze o cerere; și asupra clientului, ca indicator al timpului total necesar serializării/dezerializarii , transmiterii și procesării cererii. Trebuie remarcat faptul că nu orice aplicație de testare a performanței poate măsura ambii acești timpi.
Unele dintre cele mai comune mituri sunt enumerate mai jos.
1. Testarea performanței se face pentru a sparge sistemul. Testarea la stres se face pentru a găsi punctul critic al puterii sistemului. În alte cazuri, testarea de sarcină obișnuită este efectuată pentru a investiga comportamentul sistemului sub sarcina așteptată. În funcție de alte cerințe, pot fi necesare teste de stabilitate, teste de configurare sau teste de stres.
2. Testarea benchmark ar trebui făcută numai după testarea benchmark-ului de integrare Deși aceasta este practic norma în industria dezvoltării software, testarea performanței poate fi făcută și în stadiul inițial de dezvoltare a aplicației. Această abordare se numește Testare timpurie a performanței . Promovează o abordare holistică a dezvoltării luând în considerare parametrii de performanță și astfel reduce nu numai șansa de a găsi o problemă de performanță chiar înainte de lansare, ci și costul remedierii unor astfel de probleme.
3. Testarea performanței constă numai în scrierea de scripturi și orice modificare a aplicației are ca rezultat o mică refactorizare a acestor scripturi. Testarea performanței în sine este o ramură în creștere a industriei software . Scripting-ul, deși important, este doar o parte a testării performanței. Cea mai dificilă sarcină pentru un tester este să determine testele care trebuie efectuate și să analizeze diferite metrici de performanță pentru a identifica blocajele sistemului.
Cealaltă parte a mitului despre micile modificări ale scripturilor nu este, de asemenea, adevărată, deoarece orice modificare a interfeței de utilizare, în special în protocolul de rețea, va duce la o rescrie completă a scripturilor de la bun început. Problema devine mai vizibilă atunci când se utilizează protocoale precum Web Services, Siebel, Citrix, SAP.
4. Testarea la stres, testarea sarcinii și testarea stabilității sunt una și aceeași. Unul dintre cele mai comune mituri asociate cu o înțelegere greșită a terminologiei. Testarea la stres și testarea sarcinii sunt două tipuri diferite de activități, care se numește termenul general de testare a performanței , și rezolvă diferite probleme. Sarcina testării la stres este de a găsi punctul critic al rezistenței sistemului la sarcini care sunt semnificativ mai mari decât cele așteptate sau disproporționate; Sarcina testării sarcinii este de a verifica dacă sistemul îndeplinește cerințele la sarcina așteptată.
| Dezvoltare de software | |
|---|---|
| Proces | |
Concepte de nivel înalt | |
| Directii |
|
| Metodologii de dezvoltare | |
| Modele |
|
Cifre notabile |
|