Instrument de testare LoadRunner – Componente și Architectură

Ce este LoadRunner?

LoadRunner este un instrument de testare a performanței care a fost lansat de către 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 comunicare. De fapt, acesta este singurul instrument de pe piață care acceptă un număr atât de mare de protocoale de efectuat Test de performanta. Rezultatele testelor de performanță produse de software-ul LoadRunner sunt folosite ca etalon față de alte instrumente

LoadRunner Video

De ce LoadRunner?

LoadRunner nu este doar un instrument de pionier în testarea performanței, dar este încă un lider de piață în paradigma testării performanței. Într-o evaluare recentă, LoadRunner deține aproximativ 85% cotă de piață în industria de testare a performanței.

În linii mari, instrumentul LoadRunner acceptă RIA (Aplicații Internet bogate), Web 2.0 (HTTP/HTML, Ajax, Flex și Silverlight etc.), Mobile, SAP, Oracle, DOMNIȘOARĂ SQL Server, Citrix, RTE, Mail și pe deasupra, Windows Priză. Nu există niciun instrument concurent pe piață care ar putea oferi o varietate atât de mare de protocoale învestite într-un 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 o reputație așa cum veți găsi adesea clienții verifică încrucișarea benchmark-urilor dvs. 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), ceea ce vă permite să efectuați procesele de testare de la capăt la capăt.

LoadRunner funcționează pe principiul simulării utilizatorilor virtuali pe aplicația subiect. Acești Utilizatori Virtuali, denumiți și VUsers, reproduc cererile clientului și așteaptă un răspuns corespunzător la trecerea unei tranzacții.

De ce aveți nevoie de testarea performanței?

Un estimat pierdere de 4.4 miliarde de venituri este înregistrată anual din cauza performanței web slabe.

În epoca actuală a Web 2.0, utilizatorii fac clic departe dacă un site web nu răspunde în 8 secunde. Imaginează-ți că aștepți 5 secunde când cauți Google sau faci o cerere de prietenie pe Facebook. Repercusiunile perioadei 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 Servicii web, Intuit sau Blackberry.

Potrivit Dunn & Bradstreet, 59% dintre companiile Fortune 500 se confruntă cu aproximativ 1.6 ore de nefuncționare în fiecare săptămână. Având în vedere că o companie medie Fortune 500, cu minim 10,000 de angajați, plătește 56 USD pe oră, partea cu forța de muncă a costurilor de nefuncționare pentru o astfel de organizație ar fi de 896,000 USD pe săptămână, tradusă în peste 46 milioane USD pe an.

Se estimează că doar o perioadă de întrerupere de 5 minute a Google.com (19-aug-13) îl va costa pe gigantul căutării până la 545,000 USD.

Se estimează că companiile au pierdut vânzări în valoare de 1100 USD pe secundă din cauza unei recente Amazon Întreruperea serviciului web.

Atunci când un sistem software este implementat de o organizație, acesta poate întâlni multe scenarii care ar putea duce la latența performanței. O serie de factori cauzează scăderea performanței, câteva exemple pot include:

• Creșterea numărului de înregistrări prezente în baza de date
• Creșterea numărului de solicitări simultane făcute către sistem
• un număr mai mare de utilizatori care accesează sistemul la un moment dat în comparație cu trecutul

Ce este LoadRunner Architectură?

În linii mari, arhitectura HP LoadRunner este complexă, dar ușor de înțeles.

Să presupunem că ești desemnat să verifici performanța Amazon.com pentru 5000 de utilizatori

Într-o situație reală, acești 5000 de utilizatori nu vor fi pe pagina de pornire, ci într-o secțiune diferită a site-urilor web. Cum putem simula altfel.

VUGen

VUGen sau utilizator virtual Generator este un IDE (Integrated Development Environment) sau un editor de codare bogat. VUGen este utilizat pentru a replica comportamentul System Under Load (SUL). VUGen oferă o funcție de „înregistrare” care înregistrează comunicarea către și de la client și server sub forma unui script codificat – numit și script VUser.

Deci, luând în considerare exemplul de mai sus, VUGen poate înregistra pentru a simula următoarele procese de afaceri:

1. Navigarea pe pagina de produse a Amazon.com
2. Finalizeaza comanda
3. Procesarea plății
4. Verificarea paginii MyAccount

operator de date cu caracter personal,

Odată ce un script VUser este finalizat, Controller este una dintre componentele principale LoadRunner care controlează simularea Load prin gestionarea, de exemplu:

• Câți utilizatori VU de simulat pentru fiecare proces de afaceri sau grup de utilizatori VU
• Comportamentul utilizatorilor VU (scădere în sus, rampă, natură simultană sau concomitentă etc.)
• Scenariul naturii încărcării, de exemplu Viața reală sau Orientat spre obiectiv sau verificarea SLA
• Ce injectoare să folosiți, câți utilizatori V împotriva fiecărui injector
• Colectați periodic rezultatele
• Spoofing IP
• Raportarea erorii
• Raportarea tranzacțiilor etc.

Luând o analogie din exemplul nostru de controler va adăuga următorul parametru la Scriptul VUGen

1) 3500 de utilizatori sunt Navigarea pe pagina de produse a Amazon.com

2) 750 de utilizatori sunt în Finalizeaza comanda

3) 500 de utilizatori sunt efectuarea procesării plăților

4) 250 de utilizatori sunt Verificarea paginii MyAccount NUMAI după ce 500 de utilizatori au efectuat Procesarea plăților

Sunt posibile scenarii și mai complexe

1. Inițiază 5 VUsers la fiecare 2 secunde până la o încărcare de 3500 VUsers (surfing Amazon pagina produsului) este realizat.
2. Repetați timp de 30 de minute
3. Suspendați iterația pentru 25 de utilizatori V
4. Reporniți 20 VUSers
5. Inițiază 2 utilizatori (în Checkout, Procesare plăți, Pagina MyAccounts) în fiecare secundă.
6. 2500 de utilizatori V vor fi generați la Mașina A
7. 2500 de utilizatori V vor fi generați la Mașina B

Agenți Mașină/Încărcare Generators/Injectoare

HP LoadRunner Controller este responsabil să simuleze mii de utilizatori VU – acești utilizatori VU consumă resurse hardware, de exemplu, procesor și memorie – punând astfel o limită pentru mașina care le simulează. În plus, Controller simulează acești utilizatori V de pe aceeași mașină (unde se află Controller) și, prin urmare, rezultatele pot să nu fie precise. Pentru a rezolva această problemă, toți utilizatorii VU sunt răspândiți pe diferite mașini, numite A incarca Generators sau injectoare de sarcină.

Ca practică generală, controlerul se află pe o altă mașină și sarcina este simulată de la alte mașini. În funcție de protocolul de scripturi VUser și de specificațiile mașinii, poate fi necesar un număr de injectoare de sarcină pentru simularea completă. De exemplu, utilizatorii V pentru un script HTTP vor necesita 2-4MB per utilizator V pentru simulare, prin urmare vor fi necesare 4 mașini cu 4 GB RAM fiecare pentru a simula o încărcare de 10,000 de utilizatori V.

Luând analogie de la noi Amazon De exemplu, rezultatul acestei componente va fi

Analiză

Odată ce scenariile de încărcare au fost executate, rolul de „Analiză” intră componentele LoadRunner.

În timpul execuției, Controller creează un dump de rezultate în formă brută și conține informații precum, ce versiune de LoadRunner a creat acest dump de rezultate și care au fost configurațiile.

Toate erorile și excepțiile sunt înregistrate în a Microsoft accesează baza de date, numită, 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ă diferite tendințe pentru a înțelege raționamentul din spatele erorilor și defecțiunilor sub sarcină; astfel încât să ne dăm seama dacă optimizarea este necesară în SUL, Server (de exemplu, 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, ceea ce provoacă utilizatorii ulterioare să sufere. Pentru a determina că sistemul răspunde acestor nevoi, Performance Engineer 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ă.

Cum se face testarea performanței

Foaia de parcurs pentru testarea performanței poate fi împărțită în 5 pași:

• Planificarea testului de sarcină
• 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.

Etapele implicate în procesul de testare a performanței

Pasul 1) Planificarea testului de încărcare

Planificarea testării performanței este diferită de planificarea a SIT (testare de integrare a sistemului) or UAT (Testarea de acceptare a utilizatorilor). Planificarea poate fi împărțită în etape mici, după cum este descris mai jos:

Adună-ți echipa

Când începeți cu LoadRunner Testing, cel mai bine este să documentați cine va participa la activitate de la fiecare echipă implicată în timpul procesului.

Manager de proiect:

Numiți managerul de proiect care va deține această activitate și va servi ca persoană de referință pentru escaladare.

Expert în funcție/Analist de afaceri:

Oferă analiză de utilizare a SUL și oferă expertiză privind funcționalitatea de afaceri a site-ului web/SUL

Expert în testarea performanței:

Creează teste de performanță automate și execută scenarii de încărcare

Sistem Architect:

Oferă planul SUL

Dezvoltator web și IMM:

• Menține site-ul web și oferă aspecte de monitorizare
• Dezvoltă site-ul web și remediază erori

Administrator de sistem:

• Menține serverele implicate pe parcursul unui proiect de testare

Prezentați aplicațiile și procesele de afaceri implicate:

De succes Încărcarea testelor necesită ca intenționați să efectuați un anumit proces de afaceri. Un proces de afaceri constă în pași clar definiți în conformitate cu tranzacțiile de afaceri dorite – astfel încât să vă îndepliniți obiectivele de testare a sarcinii.

Poate fi pregătită o măsurătoare de cerințe pentru a determina încărcarea utilizatorului pe sistem. Mai jos este un exemplu de sistem de prezență într-o companie:

În exemplul de mai sus, cifrele menționează numărul de utilizatori conectați la aplicație (SUL) la o oră dată. Putem extrage numărul maxim de utilizatori conectați la un proces de afaceri la orice oră a zilei, care este calculat în coloanele din dreapta.

În mod similar, putem concluziona numărul total de utilizatori conectați la aplicație (SUL) la orice oră din zi. Acesta 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 sistemul pentru performanță.

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 am menționat mai devreme. 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 trimite 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 aprobate 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ărcătură de 150 de utilizatori.

Asta înseamnă implicit că trebuie să creezi cel puțin 200+150= 350 de contracte.

După aceea, aprobați 150 de contracte care să servească drept date de testare pentru utilizatorul C – restul de 200 de contracte vor servi drept date de testare pentru utilizatorul B.

Monitoare Outline

Speculați fiecare factor care ar putea afecta performanța unui sistem. De exemplu, un hardware redus va avea un impact potențial asupra performanței SUL (System Under Load).

Înregistrați toți factorii și configurați monitoare pentru a le putea evalua. Iată câteva exemple:

• Procesor (pentru Web Server, Application Server, Database Server și Injectoare)
• RAM (pentru Web Server, Application Server, Database Server și Injectoare)
• Server web/aplicație (de exemplu, IIS, JBoss, Jaguar Server, Tomcat etc.)
• Server DB (dimensiunea PGA și SGA în cazul Oracle și MSSQL Server, SP-uri etc.)
• Utilizarea lățimii de bandă a rețelei
• NIC intern și extern în caz de clustering
• Load Balancer (și că distribuie sarcina uniform pe toate nodurile clusterelor)
• Fluxul de date (calculați câte date se mută către și de la client și server - apoi calculați dacă o capacitate a NIC este suficientă pentru a simula numărul X de utilizatori)

Pasul 2) Creați scripturi VUGen

Următorul pas după planificare este crearea Scripturi VUser.

Pasul 3) Crearea scenariului

Următorul pas este să vă creați scenariul de încărcare

Pasul 4) Executarea scenariului

Execuția scenariului este în cazul în care emulați încărcarea utilizatorului pe server, instruind mai mulți utilizatori VU să efectueze sarcini simultan.

Puteți seta nivelul unei încărcări prin creșterea și scăderea numărului de utilizatori VU care efectuează sarcini în același timp.

Această execuție poate determina ca serverul să intre sub stres și să se comporte anormal. Acesta este chiar scopul Testării de performanță. Rezultatele extrase sunt apoi folosite pentru analiza detaliată și identificarea cauzei principale.

Pasul 5) 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 „HP Analysis” generează diferite grafice care ajută la identificarea cauzelor fundamentale din spatele unei întârzieri a performanței sistemului, precum și a unei defecțiuni a sistemului.

Unele dintre graficele obținute includ:

• Timp până la primul buffer
• Timpul de răspuns la tranzacție
• Timpul mediu de răspuns la tranzacție
• Lovituri pe secundă
• Windows Resurse
• Statistica erorilor
• Rezumatul tranzacției

Întrebări Frecvente