LoadRunneri testimistööriist – komponendid ja Architektuur
Mis on LoadRunner?
LoadRunner on jõudluse testimise tööriist, mille teerajajaks oli Mercury 1999. aastal. LoadRunner omandas hiljem 2006. aastal HPE. 2016. aastal ostis LoadRunner MicroFocus.
LoadRunner toetab erinevaid arendustööriistu, tehnoloogiaid ja sideprotokolle. Tegelikult on see turul ainus tööriist, mis toetab nii suurt hulka protokolle Jõudluse testimine. Tarkvara LoadRunner loodud jõudlustesti tulemusi kasutatakse võrdlusalusena teiste tööriistade suhtes
LoadRunneri video
Miks LoadRunner?
LoadRunner ei ole mitte ainult toimivustestimise teerajaja tööriist, vaid on endiselt turuliider jõudluskontrolli paradigmas. Hiljutise hinnangu kohaselt on LoadRunneril jõudlustestimise valdkonnas umbes 85% turuosa.
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 Pistikupesa. Turul pole ühtegi konkureerivat tööriista, mis pakuks nii suurt valikut ühele tööriistale omistatud protokolle.
Tarkvara testimisel LoadRunneri valimisel on veenvam selle tööriista usaldusväärsus. LoadRunneri tööriist on pikka aega loonud maine, nagu sageli leiate kliendid kontrollivad teie toimivuse võrdlusaluseid LoadRunneri abil. Leevendust leiate, kui kasutate juba LoadRunnerit oma jõudluse testimiseks.
Tarkvara LoadRunner on tihedalt integreeritud teiste HP tööriistadega, nagu ühtne funktsionaalne test (QTP) ja ALM (rakenduse elutsükli haldamine), mis annab teile võimaluse viia läbi testimisprotsesse lõpuni.
LoadRunner töötab virtuaalsete kasutajate simuleerimise põhimõttel teemarakenduses. Neid virtuaalseid kasutajaid nimetatakse ka sõidukiüksuse kasutajateks, nad kordavad kliendi taotlusi ja ootavad vastavat vastust tehingu edastamisel.
Miks on vaja jõudluskontrolli?
Hinnanguliselt 4.4 miljardit tulu kaotamist registreeritakse igal aastal kehva veebi jõudluse tõttu.
Tänasel Web 2.0 ajastul klõpsavad kasutajad, kui veebisait ei reageeri 8 sekundi jooksul. Kujutage ette, et ootate 5 sekundit Google'i otsimisel või Facebookis sõbrakutse esitamisel. Tööseisakute tagajärjed on sageli laastavamad, kui kunagi ette kujutati. Meil on näiteid, näiteks need, mis hiljuti tabasid Bank of America Interneti-pangandust, Amazon Veebiteenused, Intuit või Blackberry.
Dunn & Bradstreeti andmetel kogeb 59% Fortune 500 ettevõtetest igal nädalal hinnanguliselt 1.6 tundi seisakuid. Arvestades, et keskmine Fortune 500 vähemalt 10,000 56 töötajaga ettevõte maksab 896,000 dollarit tunnis, oleks sellise organisatsiooni seisakukulude tööjõu osa 46 XNUMX dollarit nädalas, mis tähendab rohkem kui XNUMX miljonit dollarit aastas.
Ainult 5-minutiline Google.com-i seisakuaeg (19. august 13.) läheb otsinguhiiglasele hinnanguliselt maksma 545,000 XNUMX dollarit.
Hinnanguliselt kaotasid ettevõtted hiljutise müügi tõttu 1100 dollari väärtuses müüki sekundis Amazon Veebiteenuse 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
- varasemaga võrreldes suurem arv kasutajaid korraga süsteemile juurdepääsuks
Mis on LoadRunner Architektuur?
Laias laastus on HP LoadRunneri arhitektuur keeruline, kuid samas kergesti mõistetav.
Oletame, et teile on määratud toimivust kontrollida Amazon.com 5000 kasutajale
Reaalses olukorras ei asu need kõik 5000 kasutajat mitte avalehel, vaid veebisaitide teises jaotises. Kuidas saame simuleerida erinevalt.
VUGen
VUGen või virtuaalne kasutaja Generator on IDE (integreeritud arenduskeskkond) või rikkalik kodeerimisredaktor. VUGeni kasutatakse süsteemi koormuse all (SUL) käitumise kopeerimiseks. VUGen pakub "salvestamise" funktsiooni, mis salvestab side kliendi ja serveriga ning nende vahelt kodeeritud skripti kujul – mida nimetatakse ka VUser skriptiks.
Võttes arvesse ülaltoodud näidet, saab VUGen salvestada, et simuleerida järgmisi äriprotsesse:
- Surfamine toodete lehel AmazonCom
- Vormista ost
- Makse töötlemine
- Minu konto lehe kontrollimine
kontroller
Kui VUser skript on lõplikult vormistatud, on kontroller üks peamisi LoadRunneri komponente, mis juhib laadimise simulatsiooni, haldades 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.
Võttes analoogia meie näidiskontrollerilt, lisatakse VUGeni skriptile järgmine parameeter
1) 3500 kasutajat Surfamine toodete lehel AmazonCom
2) 750 kasutajat on sisse lülitatud Vormista ost
3) 500 kasutajat maksete töötlemise teostamine
4) 250 kasutajat Minu konto lehe kontrollimine AINULT pärast seda, kui 500 kasutajat on makse töötlemise teinud
Võimalikud on ka keerulisemad 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 VUS-i
- 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
HP LoadRunner Controller vastutab tuhandete sõidukite kasutajate simuleerimise eest – need sõidukiüksused tarbivad riistvararessursse, näiteks protsessorit ja mälu – seega seab piirangu neid simuleerivale masinale. Peale selle simuleerib kontroller neid VU kasutajaid samast masinast (kus kontroller asub) ja seetõttu ei pruugi tulemused olla täpsed. Selle probleemi lahendamiseks on kõik sõidukiüksused jaotatud erinevate masinate vahel, nn Koormus 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.
Võttes meie analoogia Amazon Näiteks selle komponendi väljund on
Analüüs
Kui laadimisstsenaariumid on ellu viidud, on roll "Analüüs” LoadRunneri komponendid tulevad 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 juurdepääsu andmebaas, nimega, output.mdb. Komponent "Analüüs" loeb seda andmebaasifaili, et teha erinevat tüüpi analüüse ja genereerib 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 kitsaskoha. Oletame, et veebiserveri võimsus on 1 GBps, samas kui andmeliiklus ületab selle võimsuse, põhjustades järgmistele kasutajatele kahju. Süsteemi selliste vajaduste rahuldamise kindlakstegemiseks peab Performance Engineer analüüsima rakenduse käitumist ebanormaalse koormuse korral. Allpool on graafik, mille LoadRunner ribalaiuse esilekutsumiseks genereerib.
Kuidas jõudlustesti teha
Toimivustestimise tegevuskava võib laias laastus jagada viieks etapiks:
- Koormustesti planeerimine
- Looge VUGeni skripte
- Stsenaariumi loomine
- Stsenaariumi täitmine
- Tulemuste analüüs (millele järgneb süsteemi kohandamine)
Nüüd, kui olete LoadRunneri installinud, mõistame ükshaaval protsessiga seotud etappe.
Toimivustestimise protsessi etapid
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
LoadRunner Testingiga alustades on kõige parem dokumenteerida, kes igast protsessi kaasatud meeskonnast tegevuses osalevad.
Projektijuht:
Määrake projektijuht, kes on selle tegevuse omanik ja kes on eskalatsiooni juht.
Funktsiooniekspert/ ärianalüütik:
Esitage SUL-i kasutamise analüüs ja pakub teadmisi veebisaidi/SUL-i ärifunktsioonide kohta
Jõudluskontrolli ekspert:
Loob automatiseeritud jõudlustestid ja täidab laadimisstsenaariume
süsteem Architect:
Pakub SUL-i kavandit
Veebiarendaja ja VKE:
- Hoiab veebisaiti ja pakub jälgimisaspekte
- Arendab veebisaiti ja parandab vigu
Süsteemi administraator:
- Hoiab kaasatud servereid kogu testimisprojekti vältel
Kaasatud rakenduste ja äriprotsesside ülevaade:
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 on joonistel märgitud rakendusega (SUL) ühendatud kasutajate arv antud tunnil. Saame eraldada äriprotsessiga ühendatud kasutajate maksimaalse arvu igal kellaajal, mis arvutatakse kõige parempoolsemates 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 finantslepingu ja esitab selle ülevaatamiseks.
- Teine kasutaja "B" kinnitab 200 lepingut päevas, mille on loonud kasutaja "A"
- Teine kasutaja "C" maksab umbes 150 lepingut päevas, mille on heaks kiitnud kasutaja "B"
Sellises olukorras peab kasutaja B süsteemis looma 200 lepingut. Pealegi vajab kasutaja C 150 "kinnitatud" lepingut, et simuleerida 150 kasutaja koormust.
See tähendab kaudselt, et peate looma vähemalt 200+150=350 lepingut.
Pärast seda kinnitage 150 lepingut kasutaja C testandmetena – ülejäänud 200 lepingut kasutatakse kasutaja B testandmetena.
Ülevaade monitorid
Spekuleerige kõik tegurid, mis võivad süsteemi jõudlust mõjutada. Näiteks võib riistvara vähendamine potentsiaalselt mõjutada SUL-i (System Under Load) 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)
- Andmevoog (arvutage, kui palju andmeid liigub klienti ja serverisse ja sealt tagasi – seejärel arvutage, kas võrguühenduse võimsus on piisav X kasutajate arvu simuleerimiseks)
Samm 2) Looge VUGeni skriptid
Järgmine samm pärast planeerimist on loomine VUser skriptid.
3. samm) Stsenaariumi loomine
Järgmine samm on laadimisstsenaariumi loomine
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 täitmine võib põhjustada serveri stressi ja ebanormaalse käitumise. See on jõudluse testimise eesmärk. Seejärel kasutatakse saadud tulemusi üksikasjalikuks analüüsiks ja algpõhjuste tuvastamiseks.
5. samm) tulemuste analüüs (millele järgneb süsteemi kohandamine)
Stsenaariumi täitmise ajal salvestab LoadRunner rakenduse jõudluse erinevatel koormustel. Testi täitmisest kogutud statistika salvestatakse ja teostatakse detailide analüüs. Tööriist „HP Analysis” genereerib erinevaid graafikuid, mis aitavad tuvastada süsteemi jõudluse mahajäämuse ja süsteemitõrgete algpõhjuseid.
Mõned saadud graafikud hõlmavad järgmist:
- Aeg esimese puhvrini
- Tehingu reageerimisaeg
- Keskmine tehingule reageerimise aeg
- Tabamust sekundis
- Windows Vahendid
- Vigade statistika
- Tehingu kokkuvõte