Ce este LoadRunner?
LoadRunner este un instrument de testare a performanței care a fost inițiat de Mercury în 1999. LoadRunner a fost achiziționat ulterior de HPE în 2006. În 2016, LoadRunner a fost achiziționat de MicroFocus.
LoadRunner acceptă diverse instrumente de dezvoltare, tehnologii și protocoale de comunicații. De fapt, acesta este singurul instrument de pe piață care acceptă un număr atât de mare de protocoale pentru efectuarea testării performanței. Rezultatele testelor de performanță produse de software-ul LoadRunner sunt utilizate ca punct de referință față de alte instrumente
În acest tutorial, veți învăța-
- De ce LoadRunner?
- De ce aveți nevoie de testarea performanței?
- Ce este LoadRunner Architecture?
- Foaia de parcurs pentru testarea performanței: pași detaliați
- FAQ
De ce LoadRunner?
LoadRunner nu este doar un instrument de pionierat în testarea performanței, ci este încă un lider de piață în paradigma testării performanței. Într-o evaluare recentă, LoadRunner are cota de piață de aproximativ 85% în industria de testare a performanței.
În linii mari, instrumentul LoadRunner acceptă RIA (Rich Internet Applications), Web 2.0 (HTTP / HTML, Ajax, Flex și Silverlight etc.), Mobile, SAP, Oracle, MS SQL Server, Citrix, RTE, Mail și, mai presus de toate, Windows Socket. Nu există niciun instrument concurent pe piață care să ofere o varietate atât de mare de protocoale învestite unui singur instrument.
Ceea ce este mai convingător să alegeți LoadRunner în testarea software-ului este credibilitatea acestui instrument. Instrumentul LoadRunner și-a stabilit de multă vreme o reputație, deoarece de multe ori veți găsi clienți care își verifică criteriile de performanță folosind LoadRunner. Veți găsi ușurare dacă utilizați deja LoadRunner pentru nevoile dvs. de testare a performanței.
Software-ul LoadRunner este strâns integrat cu alte instrumente HP, cum ar fi Unified Functional Test (QTP) și ALM (Application Lifecycle Management), care vă permite să efectuați procesele de testare de la cap la cap.
LoadRunner funcționează pe principiul simulării utilizatorilor virtuali pe aplicația în cauză. Acești utilizatori virtuali denumiți, de asemenea, ca VUsers, replică cererile clientului și așteaptă un răspuns corespunzător la trecerea unei tranzacții.
De ce aveți nevoie de testarea performanței?
Se înregistrează anual o pierdere estimată de 4,4 miliarde de venituri din cauza performanței slabe pe web.
În epoca actuală a Web 2.0, utilizatorii dau clic dacă un site web nu răspunde în 8 secunde. Imaginați-vă că așteptați 5 secunde când căutați Google sau faceți o cerere de prietenie pe Facebook. Repercusiunile timpilor de nefuncționare a performanței sunt adesea mai devastatoare decât ne-am imaginat vreodată. Avem exemple precum cele care au lovit recent Bank of America Online Banking, Amazon Web Services, Intuit sau Blackberry.
Potrivit Dunn & Bradstreet, 59% din companiile Fortune 500 experimentează aproximativ 1,6 ore de nefuncționare în fiecare săptămână. Având în vedere că compania medie Fortune 500 cu un minim de 10.000 de angajați plătește 56 USD pe oră, partea forței de muncă din costurile de nefuncționare pentru o astfel de organizație ar fi de 896.000 USD săptămânal, ceea ce se traduce prin peste 46 milioane USD pe an.
Se estimează că doar un timp de nefuncționare de 5 minute pentru Google.com (19 august-13) va costa gigantul căutării până la 545.000 de dolari.
Se estimează că companiile au pierdut vânzări în valoare de 1100 de dolari pe secundă din cauza unei întreruperi recente a serviciului web Amazon.
Atunci când un sistem software este implementat de o organizație, acesta poate întâlni multe scenarii care pot duce la o latență a performanței. O serie de factori determină performanțe decelerante, câteva exemple pot include:
- Număr crescut de înregistrări prezente în baza de date
- Număr crescut de solicitări simultane adresate sistemului
- un număr mai mare de utilizatori care accesează sistemul simultan în comparație cu trecutul
Ce este LoadRunner Architecture?
În linii mari, arhitectura HP LoadRunner este complexă, dar ușor de înțeles.
Să presupunem că ați fost desemnat să verificați performanța Amazon.com pentru 5000 de utilizatori
Într-o situație din viața reală, toți acești 5000 de utilizatori nu vor fi pe pagina principală, ci într-o altă secțiune a site-urilor web. Cum putem simula diferit
VUGen:
VUGen sau Virtual User Generator este un IDE (mediu de dezvoltare integrat) sau un editor de codare bogat. VUGen este utilizat pentru a reproduce comportamentul sistemului sub încărcare (SUL). VUGen oferă o caracteristică de „înregistrare” care înregistrează comunicarea către și de la client și server sub forma unui script codat - numit și script VUser.
Deci, având în vedere exemplul de mai sus, VUGen poate înregistra pentru a simula următoarele procese de afaceri:
- Navigarea pe pagina Produselor de pe Amazon.com
- Verifică
- Procesarea plății
- Verificarea paginii Contul meu
Controlor
Odată ce un script VUser este finalizat, Controller este una dintre componentele principale LoadRunner care controlează simularea încărcării gestionând, de exemplu:
- Câți utilizatori VU pentru a simula împotriva fiecărui proces de afaceri sau grup VUser
- Comportamentul utilizatorilor (rampă în sus, rampă în jos, natura simultană sau simultană etc.)
- Scenariul naturii încărcării, de exemplu, viața reală sau orientat spre obiective sau verificarea SLA
- Ce injectoare să utilizați, câte VU-uri împotriva fiecărui injector
- Asociați periodic rezultatele
- Spoofing IP
- Raportarea erorii
- Raportarea tranzacțiilor etc.
Luând o analogie din exemplul nostru de controler, se va adăuga următorul parametru în Scriptul VUGen
1) 3500 de utilizatori navighează pe pagina Produselor de pe Amazon.com
2) 750 de utilizatori sunt în plată
3) 500 de utilizatori efectuează procesarea plăților
4) 250 de utilizatori verifică pagina MyAccount DOAR după ce 500 de utilizatori au efectuat Procesarea plăților
Sunt posibile chiar scenarii mai complexe
- Lansați 5 VU-uri la fiecare 2 secunde până când se atinge o încărcare de 3500 V-uri (navigarea pe pagina produsului Amazon).
- Iterează 30 de minute
- Suspendați iterația pentru 25 VU-uri
- Reporniți 20 de VUS-uri
- Începeți 2 utilizatori (în Checkout, Procesare plăți, Pagina Conturile mele) în fiecare secundă.
- 2500 VU-uri vor fi generate la Mașina A
- 2500 VU-uri vor fi generate la Mașina B
Agenți Generatori de mașini / încărcătoare / injectoare
Controlerul HP LoadRunner este responsabil pentru a simula mii de VU-uri - acești VU-uri consumă resurse hardware, de exemplu procesor și memorie - punând astfel o limită mașinii care le simulează. În plus, Controller simulează aceste VU-uri de la aceeași mașină (unde se află Controller) și, prin urmare, este posibil ca rezultatele să nu fie precise. Pentru a rezolva această problemă, toți VU-urile sunt răspândite pe diverse mașini, numite Generatoare de încărcare sau Injectoare de încărcare.
Ca practică generală, controlerul se află pe o altă mașină și sarcina este simulată de alte mașini. În funcție de protocolul scripturilor VUser și specificațiile mașinii, este posibil să fie necesare mai multe injectoare de încărcare pentru simulare completă. De exemplu, VU-urile pentru un script HTTP vor necesita 2-4 MB per VUser pentru simulare, prin urmare 4 mașini cu 4 GB RAM fiecare vor fi necesare pentru a simula o încărcare de 10.000 VU-uri.
Luând analogia din exemplul nostru Amazon, rezultatul acestei componente va fi
Analiză:
Odată ce scenariile de încărcare au fost executate, intră rolul componentelor „ Analiză ” ale LoadRunner.
În timpul execuției, Controller creează o descărcare de rezultate în formă brută și conține informații precum, ce versiune de LoadRunner a creat această descărcare de rezultate și ce au fost configurațiile.
Toate erorile și excepțiile sunt înregistrate într-o bază de date de acces Microsoft, denumită output.mdb. Componenta „Analiză” citește acest fișier de bază de date pentru a efectua diferite tipuri de analize și generează grafice.
Aceste grafice arată diverse tendințe pentru a înțelege raționamentul din spatele erorilor și eșecului sub sarcină; ajută astfel la stabilirea faptului dacă este necesară optimizarea în SUL, Server (de ex. JBoss, Oracle) sau infrastructură.
Mai jos este un exemplu în care lățimea de bandă ar putea crea un blocaj. Să presupunem că serverul web are o capacitate de 1 GBps, în timp ce traficul de date depășește această capacitate, cauzând suferința utilizatorilor ulteriori. Pentru a determina sistemul să răspundă unor astfel de nevoi, inginerul de performanță trebuie să analizeze comportamentul aplicației cu o sarcină anormală. Mai jos este un grafic pe care LoadRunner îl generează pentru a obține lățimea de bandă.
Foaia de parcurs pentru testarea performanței: pași detaliați
Foaia de parcurs pentru testarea performanței poate fi împărțită în general în 5 pași:
- Planificarea testului de încărcare
- Creați scripturi VUGen
- Crearea scenariului
- Executarea scenariului
- Analiza rezultatelor (urmată de ajustarea sistemului)
Acum că ați instalat LoadRunner, să înțelegem pașii implicați în proces unul câte unul.
Pașii implicați în procesul de testare a performanței
Planificarea testului de încărcare
Planificarea pentru testarea performanței este diferită de planificarea unui SIT (Test de integrare a sistemului) sau UAT (Test de acceptare a utilizatorului). Planificarea poate fi împărțită în etape mici, după cum este descris mai jos:
Adunați-vă echipa
Când începeți cu Testarea LoadRunner, cel mai bine este să documentați cine va participa la activitate de la fiecare echipă implicată în timpul procesului.
Manager de proiect:
Desemnați managerul de proiect care va deține această activitate și va servi ca persoană punct pentru escaladare.
Expert în funcții / Analist de afaceri:
Furnizați analiza de utilizare a SUL și oferă expertiză cu privire la funcționalitatea de afaceri a site-ului web / SUL
Expert în testarea performanței:
Creează teste automate de performanță și execută scenarii de încărcare
Arhitect de sistem:
Oferă planul SUL
Dezvoltator web și IMM-uri:
- Menține site-ul web și oferă aspecte de monitorizare
- Dezvoltă site-ul web și remediază erorile
Administrator de sistem:
- Menține serverele implicate pe tot parcursul unui proiect de testare
Descrieți aplicațiile și procesele de afaceri implicate:
Testarea cu succes a sarcinii necesită planificarea realizării anumitor procese de afaceri. Un proces de afaceri constă din pași clar definiți în conformitate cu tranzacțiile comerciale dorite - astfel încât să vă îndepliniți obiectivele de testare a sarcinii.
Se poate pregăti o valoare a cerințelor pentru a obține încărcarea utilizatorului pe sistem. Mai jos este un exemplu de sistem de participare într-o companie:
În exemplul de mai sus, cifrele menționează numărul de utilizatori conectați la aplicație (SUL) la o anumită oră. Putem extrage numărul maxim de utilizatori conectați la un proces de afaceri la orice oră a zilei, calculată în coloanele din dreapta.
În mod similar, putem concluziona numărul total de utilizatori conectați la aplicație (SUL) la orice oră a zilei. Aceasta este calculată în ultimul rând.
Cele 2 fapte de mai sus combinate ne oferă numărul total de utilizatori cu care trebuie să testăm performanța sistemului.
Definiți procedurile de gestionare a datelor de testare
Statisticile și observațiile extrase din testarea performanței sunt influențate în mare măsură de numeroși factori, așa cum s-a prezentat anterior. Este de o importanță critică pregătirea datelor de testare pentru testarea performanței. Uneori, un anumit proces de afaceri consumă un set de date și produce un set de date diferit. Luați exemplul de mai jos:
- Un utilizator „A” creează un contract financiar și îl supune spre examinare.
- Un alt utilizator „B” aprobă 200 de contracte pe zi create de utilizatorul „A”
- Un alt utilizator „C” plătește aproximativ 150 de contracte pe zi aprobat de utilizatorul „B”
În această situație, utilizatorul B trebuie să aibă 200 de contracte „create” în sistem. În plus, utilizatorul C are nevoie de 150 de contracte ca „aprobate” pentru a simula o încărcare de 150 de utilizatori.
Acest lucru înseamnă implicit că trebuie să creați cel puțin 200 + 150 = 350 de contracte.
După aceea, aprobați 150 de contracte pentru a servi drept date de test pentru utilizatorul C - restul de 200 de contracte vor servi ca date de test pentru utilizatorul B.
Monitoare de schiță
Speculați fiecare factor care ar putea afecta performanța unui sistem. De exemplu, reducerea hardware-ului va avea un impact potențial asupra performanței SUL (System Under Load).
Înscrieți toți factorii și configurați monitoare pentru a le putea măsura. Iată câteva exemple:
- Procesor (pentru server web, server de aplicații, server de baze de date și injectoare)
- RAM (pentru server web, server de aplicații, server de baze de date și injectoare)
- Server Web / App (de exemplu IIS, JBoss, Jaguar Server, Tomcat etc.)
- Server DB (dimensiunea PGA și SGA în cazul serverelor Oracle și MSSQL, SP etc.)
- Utilizarea lățimii de bandă a rețelei
- NIC internă și externă în caz de grupare
- Load Balancer (și că distribuie sarcina uniform pe toate nodurile de clustere)
- Flux de date (calculați cât de multe date se deplasează către și de la client și server - apoi calculați dacă o capacitate de NIC este suficientă pentru a simula numărul X de utilizatori)
Creați scripturi VUGen
Următorul pas după planificare este crearea de scripturi VUser.
Crearea scenariului
Următorul pas este să vă creați scenariul de încărcare
Executarea scenariului
Execuția scenariului este locul în care emulați încărcarea utilizatorului pe server, instruind mai mulți utilizatori virtuali să efectueze sarcini simultan.
Puteți seta nivelul unei încărcări mărind și micșorând numărul de VU-uri care efectuează sarcini în același timp.
Această execuție poate determina ca serverul să fie supus stresului și să se comporte anormal. Acesta este chiar scopul testării performanței. Rezultatele trase sunt apoi utilizate pentru analize detaliate și identificarea cauzei radiculare.
Analiza rezultatelor (urmată de ajustarea sistemului)
În timpul execuției scenariului, LoadRunner înregistrează performanța aplicației sub diferite încărcări. Statisticile extrase din execuția testului sunt salvate și se efectuează analiza detaliilor. Instrumentul „Analiza HP” generează diferite grafice care ajută la identificarea cauzelor profunde din spatele unui decalaj al performanței sistemului, precum și a unei defecțiuni a sistemului.
Unele dintre graficele obținute includ:
- Timp pentru primul buffer
- Timp de răspuns la tranzacție
- Timpul mediu de răspuns la tranzacție
- Afisari pe secunda
- Resurse Windows
- Statistici despre erori
- Rezumatul tranzacțiilor
FAQ
Ce aplicații ar trebui să testăm performanța?
Testarea performanței se face întotdeauna numai pentru sistemele bazate pe client-server. Aceasta înseamnă că orice aplicație care nu este o arhitectură bazată pe client-server, nu trebuie să necesite testarea performanței.
De exemplu, Microsoft Calculator nu este nici bazat pe client-server și nici nu rulează mai mulți utilizatori; prin urmare, nu este un candidat pentru testarea performanței.
Care este diferența dintre testarea performanței și ingineria performanței
Este important să înțelegem diferența dintre testarea performanței și ingineria performanței. O înțelegere este împărtășită mai jos:
Testarea performanței este o disciplină preocupată de testarea și raportarea performanței actuale a unei aplicații software sub diferiți parametri.
Ingineria performanței este procesul prin care software-ul este testat și reglat cu intenția de a realiza performanța necesară. Acest proces își propune să optimizeze cea mai importantă trăsătură de performanță a aplicației, adică experiența utilizatorului.
Din punct de vedere istoric, testarea și reglarea au fost tărâmuri distincte și adesea concurente. Cu toate acestea, în ultimii ani, câteva buzunare de testeri și dezvoltatori au colaborat independent pentru a crea echipe de tuning. Deoarece aceste echipe s-au confruntat cu un succes semnificativ, conceptul de cuplare a testelor de performanță cu reglarea performanței a prins, iar acum îl numim inginerie de performanță.