Instrumentul de testare LoadRunner: ArchiDiagramă și componente

Ce este LoadRunner?

LoadRunner este un Test de performanta instrument care a fost pionierat de Mercury Interactive în 1999. LoadRunner a fost ulterior achiziționată de HP în 2006, iar divizia de software HP a fuzionat cu Micro Focus într-o tranzacție anunțată în 2016 și finalizată în 2017.

Notă despre marcă: OpenText a finalizat achiziția Micro Focus în ianuarie 2023Instrumentul nu se mai vinde ca HP sau Micro Focus LoadRunnerLoadRunner Professional este acum OpenText Inginerie profesională de performanță, LoadRunner Enterprise este OpenText Ingineria performanței întreprinderii, iar LoadRunner Cloud este OpenText Ingineria performanței de bază. Numele componentelor de mai jos — VuGen, Controller, generatoare de sarcină și Analiză — rămân neschimbate.

LoadRunner acceptă diverse instrumente de dezvoltare, tehnologii și protocoale de comunicare. Acesta oferă una dintre cele mai ample biblioteci de protocoale de pe piață pentru efectuarea testelor de performanță. Rezultatele testelor de performanță produse de software-ul LoadRunner sunt utilizate ca punct de referință față de alte instrumente.

LoadRunner Video

Urmăriți videoclipul de mai jos pentru o scurtă introducere în LoadRunner înainte de a parcurge componentele.

De ce LoadRunner?

LoadRunner nu este doar un instrument de pionier în testarea performanței, ci rămâne unul dintre liderii de piață în paradigma testării performanței și este încă punctul de referință față de care multe companii se bazează.

Acoperirea protocolului este cel mai clar motiv pentru care echipele îl aleg, așa cum arată harta componentelor de mai jos.

Î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 Socket. Puține instrumente concurente oferă o varietate atât de largă de protocoale învestite într-un singur instrument, așa cum ilustrează lista de protocoale de mai jos.

Ceea ce este și mai convingător pentru a alege LoadRunner în testarea software este credibilitatea acestui instrument. Instrumentul LoadRunner și-a construit de mult timp o reputație, deoarece veți găsi adesea clienți care verifică încrucișat testele dvs. de performanță folosind LoadRunner. Veți găsi o ușurare dacă utilizați deja LoadRunner pentru nevoile dvs. de testare a performanței.

Software-ul LoadRunner este strâns integrat cu instrumentele similare din aceeași suită — Unified Functional Testing (fostul QTP, acum vândut ca OpenText Testare funcțională) și ALM (Application Lifecycle Management, acum OpenText ALM/Centru de calitate) — care vă permite să efectuați procesele de testare complete.

LoadRunner funcționează pe principiul simulării Utilizatorilor Virtuali în aplicația respectivă. Acești Utilizatori Virtuali, numiți și Utilizatori Virtuali, replică cererile clientului și așteaptă un răspuns corespunzător pentru a finaliza o tranzacție.

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

Estimările de mai jos despre industrie sunt citate pe scară largă și datează de la începutul anilor 2010, însă modelul pe care îl descriu nu s-a schimbat: paginile lente costă bani.

O pierdere estimată de 4.4 miliarde de dolari în venituri este înregistrată anual din cauza performanței slabe a site-ului web.

În era Web 2.0 de astăzi, utilizatorii dau clic pentru a renunța dacă un site web nu răspunde în 8 secunde. Imaginează-ți că aștepți 5 secunde când cauți... Google sau trimiterea unei cereri de prietenie pe Facebook. Repercusiunile perioadelor de nefuncționare sunt adesea mai devastatoare decât s-a imaginat vreodată. Există exemple binecunoscute, cum ar fi cele care au afectat serviciile bancare online Bank of America, Amazon Servicii web, Intuit și Blackberry.

Conform Dun & 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 Fortune 500 medie cu minimum 10,000 de angajați plătește 56 de dolari pe oră, costurile legate de forța de muncă pentru o astfel de organizație ar fi de 896,000 de dolari săptămânal, ceea ce se traduce în peste 46 de milioane de dolari pe an.

Doar 5 minute de nefuncționare GoogleSe estimează că .com în august 2013 a costat gigantul căutării până la 545,000 de dolari.

Se estimează că firmele au pierdut vânzări în valoare de 1,100 de dolari pe secundă în ultimul an. Amazon Întrerupere a serviciilor 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 în același timp, comparativ cu trecutul

Totuși, nu orice aplicație este un candidat. Încărcarea testelor vizează sistemele client-server, multi-utilizator, așadar un utilitar desktop pentru un singur utilizator precum cel de mai jos nu merită testat pentru performanță.

Ce este LoadRunner Architectură?

În linii mari, arhitectura LoadRunner este complexă, dar ușor de înțeles. Diagrama arhitecturii LoadRunner de mai jos arată cum cele patru componente funcționează împreună.

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

Într-o situație reală, toți acești 5000 de utilizatori nu vor sta pe pagina principală - vor fi răspândiți în diferite secțiuni ale site-ului web. Deci, cum simulăm această diferență?

VuGen

VuGen sau utilizator virtual Generator este un IDE (Integrated Development Environment) sau un editor de codare complexă. 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 Scriptul VUser.

Așadar, având în vedere exemplul de mai sus, VuGen poate înregistra pentru a simula următoarele procese de business:

• Navigarea pe pagina de produse a Amazon.com
• Finalizeaza comanda
• Procesarea plății
• Verificarea paginii MyAccount

Odată ce scriptul se redă corect, valorile dinamice ale serverului trebuie de obicei capturate cu corelație înainte de a putea fi extins la scară largă.

operator de date cu caracter personal,

Odată ce un script VUser este finalizat, operator de date cu caracter personal, este una dintre principalele componente LoadRunner care controlează simularea încărcării 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, Controller-ul va adăuga următorii parametri scriptului VuGen:

1. 3500 de utilizatori navighează pe pagina de produse a Amazon.com
2. 750 de utilizatori sunt în procesul de finalizare a comenzii
3. 500 de utilizatori efectuează procesarea plăților
4. 250 de utilizatori verifică pagina Contul meu DOAR după ce 500 de utilizatori au finalizat procesarea plății.

Sunt posibile scenarii chiar mai complexe:

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

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

Controlerul LoadRunner este responsabil pentru simularea a mii de utilizatori virtuali (VUsers) – acești utilizatori virtuali consumă resurse hardware, de exemplu procesor și memorie – impunând astfel o limită mașinii care îi simulează. În plus, Controlerul simulează acești utilizatori virtuali de pe aceeași mașină (unde se află Controlerul) și, prin urmare, rezultatele pot să nu fie precise. Pentru a rezolva această problemă, toți utilizatorii virtuali sunt răspândiți pe diverse mașini, numite LoadRunner. 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 analogia de la noi Amazon De exemplu, rezultatul acestei componente este reprezentat de cei 5000 de utilizatori virtuali (VUsers) împărțiți pe două injectoare: 2500 de utilizatori virtuali generați pe mașina A și 2500 pe mașina B.

Analiză

Odată ce scenariile de încărcare au fost executate, rolul Analiză componentă a LoadRunner intră în joc.

Î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 Baza de date Access numită output.mdb. Componenta Analysis citește acest fișier de bază de date pentru a efectua diverse 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, cauzând suferințe utilizatorilor ulteriori. Pentru a determina dacă sistemul răspunde acestor nevoi, inginerul de performanță trebuie să analizeze comportamentul aplicației cu o încărcare anormală. Mai jos este un grafic generat de LoadRunner pentru a identifica lățimea de bandă.

Cum se face testarea performanței

Foaia de parcurs pentru testarea performanței poate fi împărțită în linii mari în 5 etape, rezumate în foaia de parcurs de mai jos:

1. Planificarea testului de sarcină
2. Creați scripturi VuGen
3. Crearea scenariului
4. Executarea scenariului
5. Analiza rezultatelor (urmată de ajustarea sistemului)

Odată ce LoadRunner este instalat, haideți să înțelegem pașii implicați în proces, unul câte unul.

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 testarea LoadRunner, este recomandat să documentați cine va participa la activitate din fiecare echipă implicată în timpul procesului, așa cum este prezentat în diagrama de echipă de mai jos.

• Manager de proiect: Numiți managerul de proiect care va deține această activitate și va servi ca persoană de referință pentru escaladare.
• Expert Funcțional / Analist de Afaceri: Oferă o analiză a utilizării SUL-ului și expertiză privind funcționalitatea de business a site-ului web sau a SUL-ului.
• Expert în testarea performanței: Creează teste de performanță automate și execută scenarii de încărcare.
• Sistem și Architect: Oferă planul SUL.
• Dezvoltator web și IMM: Întreține site-ul web, asigură monitorizarea, dezvoltă site-ul web și remediază erorile.
• Administrator de sistem: Întreține serverele implicate pe parcursul unui proiect de testare.

Descrieț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 exemplificatract numărul maxim de utilizatori conectați la un proces de business 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ă 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ă o escrocherie financiarătract și îl trimite spre revizuire.
• Un alt utilizator „B” aprobă 200 de con-uritracts pe zi creat de utilizatorul „A”
• Un alt utilizator „C” plătește aproximativ 150 de conturi.tracts pe zi aprobat de utilizatorul „B”

În această situație, utilizatorul B trebuie să aibă 200 contracts „creat” în sistem. În plus, utilizatorul C are nevoie de 150 contracts ca „aprobate” pentru a simula o încărcătură de 150 de utilizatori.

Aceasta înseamnă implicit că trebuie să creați cel puțin 200 + 150 = 350 contracts.

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

Monitoare Outline

Specificați fiecare factor care ar putea afecta performanța unui sistem. De exemplu, reducerea numărului de componente hardware va avea un impact potențial asupra performanței SUL (System Under Load - Sistem sub sarcină).

Î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)
• Date flux (calculați câte date se transferă către și de la client și server – apoi calculați dacă o capacitate a plăcii de rețea este suficientă pentru a simula numărul X de utilizatori)

Pasul 2) Creați scripturi VuGen

Următorul pas după planificare este crearea de scripturi VUser, adăugând parametrizare, tranzacții și setări în timpul execuției pe măsură ce scenariul se maturizează.

Pasul 3) Crearea scenariului

Următorul pas este să creați scenariul de încărcare în Controller, alegând între un scenariu manual și unul orientat spre obiective.

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 duce la intrarea în funcțiune a serverului stres și comportându-se anormal. Acesta este chiar scopul testării performanței. Rezultatele obținute sunt apoi utilizate pentru analize detaliate ș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 sarcini. Statisticile extrase din execuția testelor sunt salvate și se efectuează o analiză detaliată. Instrumentul de analiză (denumit „HP Analysis” în versiunile pentru care a fost scris acest ghid) generează diverse grafice care ajută la identificarea cauzelor principale 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