LoadRunneri testimise tööriist: ArchiTektsiooniskeem ja komponendid

Mis on LoadRunner?

LoadRunner on Jõudluse testimine tööriist, mille teerajajaks oli Mercury Interactive 1999. aastal. HP omandas LoadRunneri hiljem 2006. aastal ning HP tarkvaraäri ühines Micro Focusega 2016. aastal välja kuulutatud ja 2017. aastal lõpule viidud tehingus.

Brändi märkus: OpenText viis Micro Focuse omandamise lõpule 2023. aasta jaanuarisTööriista ei müüda enam HP ega Micro Focus LoadRunnerLoadRunner Professional on nüüd saadaval OpenText Professionaalne jõudlustehnika, LoadRunner Enterprise on OpenText Ettevõtte jõudluse inseneriteenused ja LoadRunner Cloud on OpenText Core Performance Engineering. Allpool olevad komponentide nimed – VuGen, Controller, koormusgeneraatorid ja Analysis – jäävad samaks.

LoadRunner toetab mitmesuguseid arendustööriistu, tehnoloogiaid ja sideprotokolle. See pakub üht turu laiemat protokolliteeki jõudlustestide tegemiseks. LoadRunneri tarkvara loodud jõudlustestide tulemusi kasutatakse võrdlusalusena teiste tööriistadega võrreldes.

LoadRunneri video

Enne komponentidega tutvumist vaadake allolevat videot LoadRunneri kiireks tutvustuseks.

Miks LoadRunner?

LoadRunner pole mitte ainult jõudlustestimise teerajaja tööriist, vaid on ka üks turuliidreid selles valdkonnas ja on endiselt paljude ettevõtete võrdlusalus.

Protokolli ulatus on selgeim põhjus, miks meeskonnad selle valivad, nagu näitab allolev komponentide kaart.

Laias laastus toetab LoadRunneri tööriist RIA-d (rikas Interneti-rakendused), Web 2.0 (HTTP/HTML, Ajax, Flex ja Silverlight jne), mobiili, SAP, Oracle, PRL SQL Server, Citrix, RTE, Mail ja ennekõike Windows Sokkel. Vähesed konkureerivad tööriistad pakuvad nii laia valikut protokolle ühes tööriistas, nagu allolev protokollide loend illustreerib.

Veenvam tegur tarkvara testimisel LoadRunneri valimisel on selle tööriista usaldusväärsus. LoadRunneril on juba ammu hea maine, kuna kliendid kontrollivad sageli teie jõudlusnäitajaid LoadRunneri abil. See on teile kergendus, kui kasutate juba LoadRunnerit oma jõudlustestimise vajadusteks.

LoadRunneri tarkvara on tihedalt integreeritud sama komplekti kuuluvate tööriistadega – Unified Functional Testing (endine QTP, nüüd müüakse kui OpenText Funktsionaalne testimine) ja ALM (rakenduse elutsükli haldus, nüüd OpenText ALM/kvaliteedikeskus) — mis annab teile võimaluse teostada oma otsast lõpuni testimisprotsesse.

LoadRunner töötab põhimõttel, et simuleerib virtuaalseid kasutajaid antud rakenduses. Need virtuaalsed kasutajad, mida nimetatakse ka VUseriteks, kopeerivad kliendi päringuid ja ootavad tehingu sooritamiseks vastavat vastust.

Miks on vaja jõudluskontrolli?

Allpool toodud valdkonna hinnanguid tsiteeritakse laialdaselt ja need pärinevad 2010. aastate algusest, kuid nendes kirjeldatud muster pole muutunud: aeglased lehed maksavad raha.

Hinnanguliselt kaotatakse igal aastal veebiteenuste kehva jõudluse tõttu 4.4 miljardit dollarit tulu.

Tänapäeva Web 2.0 ajastul lahkuvad kasutajad veebisaidilt, kui see 8 sekundi jooksul ei vasta. Kujutage ette, et ootate otsingu ajal 5 sekundit. Google või Facebookis sõbrakutse tegemisega. Jõudluse seisaku tagajärjed on sageli laastavamad, kui kunagi ette kujutada osatakse. On tuntud näiteid, näiteks need, mis tabasid Bank of America internetipangandust, Amazon Veebiteenused, Intuit ja Blackberry.

Dun & Bradstreeti andmetel kogeb 59% Fortune 500 ettevõtetest hinnanguliselt 1.6 tundi seisakuid nädalas. Arvestades, et keskmine Fortune 500 ettevõte, kus on vähemalt 10 000 töötajat, maksab 56 dollarit tunnis, oleks seisakukulude tööjõukulu sellise organisatsiooni jaoks 896 000 dollarit nädalas, mis teeb aastas üle 46 miljoni dollari.

Ainult 5-minutiline seisakuaeg GoogleHinnanguliselt läks .com 2013. aasta augustis otsinguhiiglasele maksma koguni 545 000 dollarit.

Hinnanguliselt kaotasid ettevõtted viimasel ajal müüki 1,100 dollari väärtuses sekundis. Amazon Veebiteenuste katkestus.

Kui organisatsioon juurutab tarkvarasüsteemi, võib sellel esineda palju stsenaariume, mis võivad põhjustada jõudluse latentsust. Toimivuse aeglustumist põhjustavad mitmed tegurid, mõned näited võivad hõlmata järgmist:

• Andmebaasis olevate kirjete arv on suurenenud
• Süsteemile tehtud samaaegsete päringute arv on suurenenud
• Võrreldes varasemaga kasutab süsteemi korraga rohkem kasutajaid

Mitte iga avaldus pole siiski kandidaat. Koormuse testimine on suunatud klient-serveri ja mitme kasutajaga süsteemidele, seega pole ühe kasutajaga töölaua utiliidi, nagu allpool näidatud, jõudluse testimine seda väärt.

Mis on LoadRunner Architektuur?

Üldiselt on LoadRunneri arhitektuur keeruline, kuid samas kergesti mõistetav. Allolev LoadRunneri arhitektuuri diagramm näitab, kuidas neli komponenti omavahel koostööd teevad.

Oletame, et teile on määratud toimivust kontrollida Amazon.com 5000 kasutajale.

Päriselus ei viibi kõik need 5000 kasutajat avalehel, vaid on hajutatud veebisaidi eri osadesse. Kuidas me seda erinevust simuleerime?

VuGen

VuGen või virtuaalne kasutaja Generator on IDE (integreeritud arenduskeskkond) ehk rikkaliku kodeerimisega redaktor. VuGenit kasutatakse süsteemi koormuse all (SUL) käitumise jäljendamiseks. VuGen pakub salvestusfunktsiooni, mis salvestab kliendi ja serveri vahelise suhtluse kodeeritud skripti kujul – mida nimetatakse ka ... VUser skript.

Seega, arvestades ülaltoodud näidet, saab VuGen salvestada, et simuleerida järgmisi äriprotsesse:

• Surfamine toodete lehel AmazonCom
• Vormista ost
• Makse töötlemine
• Minu konto lehe kontrollimine

Kui skript taasesitatakse korrektselt, tuleb dünaamilised serveri väärtused tavaliselt jäädvustada korrelatsioon enne kui seda saab suurendada.

kontroller

Kui VUser skript on valmis, siis kontroller on üks peamisi LoadRunneri komponente, mis juhib koormuse simulatsiooni, hallates näiteks:

• Kui palju VU kasutajaid simuleerida iga äriprotsessi või VUser Groupi suhtes
• VU-kasutajate käitumine (kaldtee üles, alla, samaaegne või samaaegne olemus jne)
• Koormusstsenaariumi olemus, nt tegelik elu või eesmärgipõhine või SLA kontrollimine
• Milliseid pihusteid kasutada, mitu VU-d iga pihusti vastu
• Võrrelge tulemusi perioodiliselt
• IP võltsimine
• Viga teatamisel
• Tehingute aruandlus jne.

Meie näite analoogiat kasutades lisab kontroller VuGeni skriptile järgmised parameetrid:

1. 3500 kasutajat sirvib tootelehte AmazonCom
2. 750 kasutajat on kassas
3. 500 kasutajat teostavad maksetöötlust
4. 250 kasutajat kontrollivad Minu Konto lehte ALLES pärast seda, kui 500 kasutajat on makse töödelnud.

Võimalikud on veelgi keerukamad stsenaariumid:

• Käivitage 5 VU kasutajat iga 2 sekundi järel kuni 3500 VU kasutajani (surfamine Amazon tooteleht) on saavutatud.
• Korrake 30 minutit
• Peatage iteratsioon 25 VU kasutaja jaoks
• Taaskäivitage 20 virtuaalset kasutajat
• Iga sekund käivitage 2 kasutajat (kassas, maksete töötlemisel, lehel MyAccounts).
• Masinas A luuakse 2500 VU kasutajat
• Masinas B luuakse 2500 VU-kasutajat

Agendid Machine/Load Generators/pihustid

LoadRunneri kontroller vastutab tuhandete V-kasutajate simuleerimise eest – need V-kasutajad tarbivad riistvararessursse, näiteks protsessorit ja mälu –, pannes seega piirangu neid simuleerivale masinale. Lisaks simuleerib kontroller neid V-kasutajaid samast masinast (kus kontroller asub) ja seetõttu ei pruugi tulemused olla täpsed. Selle probleemi lahendamiseks on kõik V-kasutajad jaotatud erinevate masinate vahel, mida nimetatakse LoadRunneriks. Generators või laadimispihustid.

Üldjuhul asub kontroller erineval masinal ja koormust simuleeritakse teistest masinatest. Olenevalt VUser skriptide protokollist ja masina spetsifikatsioonidest võib täielikuks simulatsiooniks vaja minna mitut laadimispihustit. Näiteks HTTP-skripti VU-kasutajad vajavad simuleerimiseks 2–4 MB iga sõidukiüksuse kasutaja kohta, seega on 4 4 VU-kasutaja koormuse simuleerimiseks vaja nelja 10,000 GB RAM-iga masinat.

Analoogia võtmine meie omast Amazon Näiteks on selle komponendi väljund 5000 VUserit, mis on jagatud kahe injektori vahel: 2500 VUserit genereeritakse masinas A ja 2500 masinas B.

Analüüs

Kui laadimisstsenaariumid on käivitatud, siis roll Analüüs LoadRunneri komponent tuleb sisse.

Täitmise ajal loob kontroller tulemuste väljavõtte toores vormis ja sisaldab teavet, näiteks, milline LoadRunneri versioon selle tulemuste väljavõtte lõi ja millised olid konfiguratsioonid.

Kõik vead ja erandid on sisse logitud a Microsoft Accessi andmebaas nimega output.mdb. Analüüsikomponent loeb seda andmebaasifaili, et teha erinevat tüüpi analüüse ja genereerida graafikuid.

Need graafikud näitavad erinevaid suundumusi, et mõista koormuse all esinevate vigade ja rikete põhjuseid; seega aitab välja selgitada, kas SUL-is, serveris (nt JBoss, Oracle) või infrastruktuuri.

Allpool on näide, kus ribalaius võib tekitada pudelikaela. Oletame, et veebiserveril on 1 GB/s maht, kuid andmeside ületab selle mahutavuse, põhjustades järgnevatele kasutajatele kannatusi. Et teha kindlaks, kas süsteem vastab sellistele vajadustele, peab jõudlusinsener analüüsima rakenduse käitumist ebanormaalse koormuse korral. Allpool on graafik, mille LoadRunner genereerib ribalaiuse leidmiseks.

Kuidas jõudlustesti teha

Jõudlustestimise tegevuskava saab laias laastus jagada viieks etapiks, mis on kokku võetud allpool olevas tegevuskavas:

1. Koormustesti planeerimine
2. Loo VuGeni skripte
3. Stsenaariumi loomine
4. Stsenaariumi täitmine
5. Tulemuste analüüs (millele järgneb süsteemi kohandamine)

Kui LoadRunner on installitud, mõistame protsessi samme ükshaaval.

1. samm) Koormustesti planeerimine

Toimivustesti planeerimine erineb planeerimisest a SIT (süsteemiintegratsiooni testimine) or UAT (kasutaja aktsepteerimise testimine). Planeerimise saab jagada väikesteks etappideks, nagu allpool kirjeldatud:

Pange oma meeskond kokku

LoadRunneri testimise alustamisel on kõige parem dokumenteerida, kes igast protsessi kaasatud meeskonnast tegevuses osaleb, nagu on näidatud allolevas meeskonna diagrammis.

• Projektijuht: Määrake projektijuht, kes on selle tegevuse omanik ja kes on eskalatsiooni juht.
• Funktsiooniekspert / Ärianalüütik: Pakub SUL-i kasutusanalüüsi ja ekspertiisi veebisaidi või SUL-i ärifunktsioonide kohta.
• Jõudluskontrolli ekspert: Loob automatiseeritud jõudlustestid ja käivitab koormusstsenaariume.
• süsteem Architect: Esitab SUL-i kavandi.
• Veebiarendaja ja VKE: Haldab veebilehte, pakub monitooringut, arendab veebilehte ja parandab vigu.
• Süsteemi administraator: Hooldab kaasatud servereid kogu testimisprojekti vältel.

Kirjeldage rakendusi ja äriprotsesse, mis on seotud

Edukas Koormuse testimine eeldab, et kavatsete läbi viia teatud äriprotsessi. Äriprotsess koosneb selgelt määratletud sammudest kooskõlas soovitud äritehingutega – selleks, et täita teie koormustestimise eesmärgid.

Kasutajate süsteemi koormuse esilekutsumiseks saab koostada nõuete mõõdiku. Allpool on näide kohalviibimise süsteemist ettevõttes:

Ülaltoodud näites näitavad arvud rakendusega ühendatud kasutajate arvu (SUL) antud tunnil. Me saame näitekstract mis tahes kellaajal äriprotsessiga ühendatud kasutajate maksimaalne arv, mis arvutatakse parempoolseimates veergudes.

Samamoodi saame järeldada rakendusega (SUL) ühendatud kasutajate koguarvu igal kellaajal. See arvutatakse viimases reas.

Ülaltoodud 2 fakti kokku annavad meile kasutajate koguarvu, kellega peame süsteemi jõudlust testima.

Määratlege testandmete haldamise protseduurid

Toimivustestimise statistikat ja tähelepanekuid mõjutavad suuresti mitmed tegurid, nagu varem kirjeldatud. Katseandmete ettevalmistamine jõudluskontrolli jaoks on ülioluline. Mõnikord kasutab konkreetne äriprotsess andmekogumit ja loob erineva andmekogumi. Võtke allpool näide:

• Kasutaja 'A' loob finantskonfliktitract ja esitab selle läbivaatamiseks.
• Teine kasutaja 'B' kiidab heaks 200 pettusttracKasutaja 'A' loodud ts päev
• Teine kasutaja 'C' maksab umbes 150 kontottracKasutaja 'B' poolt heaks kiidetud ts päev

Selles olukorras peab kasutajal B olema 200 kontot.tracsüsteemis loodud ts. Lisaks vajab kasutaja C 150 contracts kui „heakskiidetud“, et simuleerida 150 kasutaja koormust.

See tähendab kaudselt, et peate looma vähemalt 200 + 150 = 350 konsooli.tracts.

Pärast seda kinnitage 150 kontrackasutaja C testandmetena kasutatavad t-d – ülejäänud 200 kon-dtracts toimivad kasutaja B testandmetena.

Ülevaade monitorid

Spekuleerige iga teguriga, mis võib süsteemi jõudlust mõjutada. Näiteks riistvara vähendamine võib mõjutada SUL-i (süsteemi koormuse all) jõudlust.

Kasutage kõiki tegureid ja seadistage monitorid, et saaksite neid mõõta. Siin on mõned näited:

• Protsessor (veebiserveri, rakendusserveri, andmebaasiserveri ja injektorite jaoks)
• RAM (veebiserveri, rakendusserveri, andmebaasiserveri ja injektorite jaoks)
• Veebi-/rakendusserver (näiteks IIS, JBoss, Jaguari server, Tomcat jne)
• DB-server (PGA ja SGA suurus juhul Oracle ja MSSQL Server, SP-d jne)
• Võrgu ribalaiuse kasutamine
• Sisemine ja väline NIC klasterdamise korral
• Koormuse tasakaalustaja (ja et see jaotab koormuse ühtlaselt kõikidele klastrite sõlmedele)
• kuupäev flux (arvuta, kui palju andmeid kliendi ja serveri vahel liigub – seejärel arvuta, kas võrgukaardi mahust piisab X arvu kasutajate simuleerimiseks)

2. samm) Loo VuGeni skriptid

Järgmine samm pärast planeerimist on VUser-skriptide loomine, lisades parameetrite määramine, tehingud ja käitusaja seaded kui stsenaarium küpseb.

3. samm) Stsenaariumi loomine

Järgmine samm on koormusstsenaariumi loomine kontrolleris, valides käsitsi ja eesmärgipõhise stsenaariumi vahel.

4. samm) Stsenaariumi täitmine

Stsenaariumi täitmine on koht, kus emuleerite kasutaja koormust serveris, juhendades mitut sõidukiüksuse kasutajat ülesandeid üheaegselt täitma.

Saate määrata koormuse taseme, suurendades ja vähendades samaaegselt ülesandeid täitvate VU kasutajate arvu.

See käivitamine võib serveri alla jääda stress ja käituvad ebanormaalselt. See ongi jõudlustestimise eesmärk. Saadud tulemusi kasutatakse seejärel üksikasjalikuks analüüsiks ja algpõhjuse tuvastamiseks.

5. samm) tulemuste analüüs (millele järgneb süsteemi kohandamine)

Stsenaariumi täitmise ajal salvestab LoadRunner rakenduse jõudlust erinevate koormuste korral. Testi täitmisest saadud statistika salvestatakse ja tehakse üksikasjalik analüüs. Analüüsitööriist (käesoleva juhendi aluseks olevates versioonides kaubamärgiga „HP Analysis“) genereerib mitmesuguseid graafikuid, mis aitavad tuvastada süsteemi jõudluse mahajäämuse ja süsteemi rikke algpõhjuseid.

Mõned saadud graafikud hõlmavad järgmist:

• Aeg esimese puhvrini
• Tehingu reageerimisaeg
• Keskmine tehingule reageerimise aeg
• Tabamust sekundis
• Windows Ressursid
• Vigade statistika
• Tehingu kokkuvõte

KKK