Mis on HP LoadRunneri testimistööriist? Arhitektuur, komponendid

Mis on LoadRunner?

LoadRunner on jõudlustestimise tööriist, mille Mercury pani aluse 1999. aastal. LoadRunneri omandas hiljem HPE 2006. aastal. 2016. aastal omandas LoadRunneri MicroFocus.

LoadRunner toetab erinevaid arendustööriistu, tehnoloogiaid ja sideprotokolle. Tegelikult on see ainus vahend turul, mis toetab jõudluskontrolli läbiviimiseks nii suurt hulka protokolle. LoadRunner tarkvara toodetud jõudlustesti tulemusi kasutatakse teiste tööriistade võrdlusalusena

Selles õpetuses saate teada

• Miks LoadRunner?
• Miks vajate jõudlustesti?
• Mis on LoadRunneri arhitektuur?
• Toimivuse testimise tegevuskava: üksikasjalikud sammud
• KKK

Miks LoadRunner?

LoadRunner pole mitte ainult jõudlustestimise teerajaja, vaid on ka jõudlustestimise paradigmas turuliider. Värske hinnangu kohaselt on LoadRunneri jõudlustestide valdkonnas umbes 85% turuosa.

Laias laastus toetab LoadRunneri tööriist RIA-d (rikkalikud Interneti-rakendused), Web 2.0 (HTTP / HTML, Ajax, Flex ja Silverlight jne), mobiilsidet, SAP-i, Oracle'i, MS SQL Serveri, Citrixit, RTE-d, Maili ja ennekõike Windows Socketit. Turul pole ühtegi konkurendi tööriista, mis suudaks pakkuda nii palju erinevaid tööriistu sisaldavaid protokolle.

Veenduvam on tarkvara testimisel valida LoadRunner, selle tööriista usaldusväärsus. Tööriistaga LoadRunner on juba ammu maine loodud, sest sageli leiate klientidelt, et nad kontrolliksid teie toimivuse võrdlusaluseid LoadRunneri abil. Leiate leevendust, kui kasutate juba jõudlustestimise jaoks LoadRunnerit.

LoadRunneri tarkvara on tihedalt integreeritud teiste HP tööriistadega, nagu ühtne funktsionaalne test (QTP) ja ALM (rakenduse elutsükli haldamine), mis annab teile võimaluse lõpptestimisprotsesse läbi viia.

LoadRunner töötab põhirakenduses, mis simuleerib virtuaalseid kasutajaid antud rakenduses. Neid virtuaalseid kasutajaid nimetatakse ka sõidukiüksusteks, nad kordavad kliendi taotlusi ja ootavad vastavat vastust tehingu edastamisele.

Miks vajate jõudlustesti?

Halva veebitulemuse tõttu registreeritakse igal aastal hinnanguliselt 4,4 miljardit tulu kaotust .

Tänapäeva Web 2.0 ajastul klõpsavad kasutajad eemale, kui veebisait ei reageeri 8 sekundi jooksul. Kujutage ette, et ootate 5 sekundit, kui otsite Google'i või esitate Facebookis sõbrasoovi. Esinemiste seisakute tagajärjed on sageli hävitavamad, kui iial osatakse arvata. Meil on näiteid, näiteks hiljuti avaldatud Bank of America veebipanga, Amazoni veebiteenuste, Intuiti või Blackberry tabamust.

Dunn & Bradstreet andmetel kogeb 59% Fortune 500 ettevõtetest hinnanguliselt 1,6 tundi seisakuid igal nädalal. Arvestades, et keskmine Fortune 500 ettevõte, kus töötab vähemalt 10 000 töötajat, maksab 56 dollarit tunnis, oleks sellise organisatsiooni seisakukulude tööjõuosa 896 000 dollarit nädalas, mis tähendab aastas üle 46 miljoni dollari.

Hinnanguliselt maksab Google.com-i ainult 5-minutiline seisak (19. august-13) otsinguhiiglasele koguni 545 000 dollarit.

Hinnanguliselt kaotasid ettevõtted hiljutise Amazoni veebiteenuste katkestuse tõttu 1100 dollarit sekundis.

Kui organisatsioon juurutab tarkvarasüsteemi, võib see ette tulla paljude stsenaariumidega, mis võivad põhjustada jõudluse viivituse. Toimivust aeglustavad mitmed tegurid, mõned näited võivad hõlmata järgmist:

• Suurenenud andmebaasis olevate kirjete arv
• Suurenenud süsteemile samaaegsete taotluste arv
• varasemaga võrreldes on korraga süsteemile juurde pääsenud suurem arv kasutajaid

Mis on LoadRunneri arhitektuur?

Laias laastus on HP LoadRunneri arhitektuur keeruline, kuid hõlpsasti mõistetav.

Oletame, et olete määratud kontrollima Amazon.com-i toimivust 5000 kasutaja jaoks

Reaalses olukorras ei asu need kõik 5000 kasutajat avalehel, vaid veebisaitide teises jaotises. Kuidas saame simuleerida erinevalt

VUGen:

VUGen ehk Virtual User Generator on IDE (integreeritud arenduskeskkond) või rikkaliku kodeerimise redaktor. VUGenit kasutatakse süsteemi koormuse all (SUL) käitumise kopeerimiseks. VUGen pakub "salvestamise" funktsiooni, mis salvestab suhtluse kliendi ja serveriga ning kliendilt ja serverilt kodeeritud skripti kujul - seda nimetatakse ka VUseri skriptiks.

Seega, arvestades ülaltoodud näidet, saab VUGen salvestada järgmiste äriprotsesside simuleerimiseks:

1. Amazon.com-i toodete lehel surfamine
2. Kassas
3. Maksete töötlemine
4. Minu konto kontrollimine

Kontroller

Kui VUseri skript on lõplikult vormistatud, on kontroller üks peamisi LoadRunneri komponente, mis juhib koormuse simulatsiooni, hallates näiteks järgmist:

• Mitu VU-kasutajat simuleerida iga äriprotsessi või VUseri rühma suhtes
• Sõidukiüksuste käitumine (kaldtee üles, alla kalduvus, samaaegne või samaaegne olemus jne)
• Laadimise stsenaariumi laad, nt tegelikule elule või eesmärgile orienteeritud või SLA kontrollimine
• Milliseid injektoreid kasutada, mitu VU-d iga pihusti vastu
• Koguge tulemusi perioodiliselt
• IP võltsimine
• Viga teatamisel
• Tehingute aruandlus jne

Analoogia võtmine meie kontrollerist lisab VUGeni skripti järgmise parameetri

1) 3500 kasutajat surfavad Amazon.comi toodete lehel

2) Checkoutis on 750 kasutajat

3) Maksetöötlust teostab 500 kasutajat

4) 250 kasutajat kontrollivad MyAccount lehte AINULT pärast seda, kui 500 kasutajat on maksetöötluse teinud

Võimalikud on veelgi keerukamad stsenaariumid

1. Algatage 5 VU-kasutajat iga 2 sekundi järel, kuni saavutatakse 3500 VU-kasutaja koormus (surfates Amazoni tootelehel).
2. Kordus 30 minutit
3. Peatage iteratsioon 25 VU-kasutaja jaoks
4. Taaskäivitage 20 VUSerit
5. Algatage iga sekund 2 kasutajat (Checkoutis, maksete töötlemisel, lehel Minu kontod).
6. A-masinas luuakse 2500 sõiduki kasutajat
7. Masinas B luuakse 2500 sõidukiüksust

Agendid masina- / koormageneraatorid / pihustid

HP LoadRunner Controller vastutab tuhandete sõidukiüksuste simuleerimise eest - need sõidukiüksused tarbivad riistvararessursse, näiteks protsessorit ja mälu, seades seega piirangud neid simuleerivale masinale. Pealegi simuleerib kontroller neid sõidukiüksusi samast masinast (kus kontroller elab) ja seetõttu ei pruugi tulemused olla täpsed. Selle probleemi lahendamiseks on kõik sõidukiüksused jaotatud erinevatele masinatele, mida nimetatakse koormageneraatoriteks või koormuspritsideks .

Üldiselt elab kontroller teisel masinal ja koormust simuleeritakse teistest masinatest. Sõltuvalt VUseri skriptide protokollist ja masina spetsifikatsioonidest võib täieliku simulatsiooni jaoks vaja minna mitut laadimispihustit. Näiteks vajavad HTTP-skripti VU-d simulatsiooniks 2–4 MB VUseri kohta, seega on 10 000 VU-kasutaja koormuse simuleerimiseks vaja 4 masinat 4 GB RAM-iga.

Võttes analoogia meie Amazoni näitest, on selle komponendi väljund

Analüüs:

Kui laadimisstsenaariumid on täidetud, saabub LoadRunneri komponentide " Analüüs " roll .

Käivitamise ajal loob Controller töötlemata kujul tulemuste väljavõtte ja sisaldab teavet, näiteks see, milline LoadRunneri versioon selle tulemuste dumpingu lõi ja mis olid konfiguratsioonid.

Kõik vead ja erandid registreeritakse Microsofti juurdepääsude andmebaasis nimega output.mdb. Komponent "Analüüs" loeb seda andmebaasifaili erinevat tüüpi analüüside tegemiseks ja genereerib graafikuid.

Need graafikud näitavad erinevaid suundumusi, et mõista vigade ja ebaõnnestumiste põhjuseid koormuse all; aitavad seega välja mõelda, kas optimeerimine on vajalik SUL-is, Serveris (nt JBoss, Oracle) või infrastruktuuris.

Allpool on näide, kus ribalaius võib tekitada kitsaskoha. Oletame, et veebiserveri maht on 1 GB / s, samas kui andmeliiklus ületab selle võimsuse, põhjustades järgmistele kasutajatele kannatusi. Selliste vajaduste rahuldamiseks peab Performance Engineer analüüsima rakenduse käitumist ebahariliku koormusega. Allpool on graafik, mille LoadRunner genereerib ribalaiuse saamiseks.

Toimivuse testimise tegevuskava: üksikasjalikud sammud

Toimivuse testimise tegevuskava võib üldjoontes jagada viieks etapiks:

• Koormustestide kavandamine
• Looge VUGeni skriptid
• Stsenaariumi loomine
• Stsenaariumi täitmine
• Tulemuste analüüs (millele järgneb süsteemi kohandamine)

Nüüd, kui olete LoadRunneri installinud, mõistame ükshaaval protsessi kaasatud samme.

Jõudluskontrolli protsessi etapid

Koormustestide kavandamine

Jõudluskontrolli kavandamine erineb SIT (süsteemiintegratsiooni testimine) või UAT (kasutajate aktsepteerimise testimine) kavandamisest. Planeerimist saab jaotada väikesteks etappideks, nagu allpool kirjeldatud:

Pange kokku oma meeskond

LoadRunneri testimisega alustamisel on kõige parem dokumenteerida, kes osalevad tegevuses igast protsessi käigus kaasatud meeskonnast.

Projektijuht:

Nimetage projektijuht, kellele see tegevus kuulub, ja on eskalatsiooni esimees.

Funktsiooniekspert / ärianalüütik:

Andke SUL-i kasutusanalüüs ja annab teadmisi veebisaidi / SUL-i ärifunktsionaalsuse kohta

Jõudluskontrolli ekspert:

Loob automatiseeritud jõudlustestid ja täidab laadimisstsenaariume

Süsteemiarhitekt:

Pakub SUL-i projekti

Veebiarendaja ja VKE:

• Haldab veebisaiti ja pakub seire aspekte
• Arendab veebisaiti ja parandab vigu

Süsteemiadministraator:

• Haldab testimisprojekti vältel kaasatud servereid

Esitage rakendused ja kaasatud äriprotsessid:

Edukas koormustestimine eeldab, et plaanite läbi viia teatud äriprotsessi. Äriprotsess koosneb soovitud äritehingute järgimiseks selgelt määratletud etappidest, et täita teie koormuse testimise eesmärke.

Nõudemõõdiku saab koostada süsteemi kasutajakoormuse esilekutsumiseks. Allpool on toodud näide ettevõtte osalemissüsteemist:

Ülaltoodud näites mainitakse joonistel rakendusega ühendatud kasutajate arvu (SUL) antud tunnis. Saame eraldada maksimaalse arvu äriprotsessiga seotud kasutajaid igal kellaajal, mis arvutatakse kõige paremas veerus.

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

Eeltoodud kaks fakti kokku annavad meile kasutajate koguarvu, kellega peame süsteemi jõudlust testima.

Määratlege testandmete haldamise protseduurid

Jõudluskontrolli põhjal saadud statistikat ja tähelepanekuid mõjutavad suuresti mitmed varem lühidalt kirjeldatud tegurid. Testandmete ettevalmistamine jõudlustestimiseks on kriitilise tähtsusega. Mõnikord kulutab konkreetne äriprotsess andmekogumit ja toodab teistsuguse andmekogumi. Võtke näide allpool:

• Kasutaja A loob finantslepingu ja esitab selle ülevaatamiseks.
• Teine kasutaja B kiidab heaks kasutaja A poolt loodud 200 lepingut päevas
• Teine kasutaja C maksab umbes 150 lepingut päevas, mille on heaks kiitnud kasutaja B

Sellises olukorras peab kasutajal B olema süsteemis 200 loodud lepingut. Pealegi vajab kasutaja C 150 lepingut "heakskiidetud" kujul, et simuleerida 150 kasutaja koormust.

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

Pärast seda kinnitage 150 lepingut, et kasutada kasutaja C testandmeid - ülejäänud 200 lepingut kasutatakse kasutaja B testandmetena.

Kontuurmonitorid

Mõelge välja kõik tegurid, mis võivad süsteemi toimimist mõjutada. Näiteks võib riistvara vähendamine potentsiaalselt mõjutada SUL (System Under Load) jõudlust.

Loendage kõik tegurid ja seadistage monitorid, et saaksite neid mõõta. Siin on mõned näited:

• Protsessor (veebiserveri, rakendusserveri, andmebaasiserveri ja pihustite jaoks)
• RAM (veebiserveri, rakendusserveri, andmebaasiserveri ja pihustite jaoks)
• Veebi- / rakendusserver (näiteks IIS, JBoss, Jaguar Server, Tomcat jne)
• DB Server (PGA ja SGA suurus Oracle'i ja MSSQL Serveri, SP-de jms korral)
• Võrgu ribalaiuse kasutamine
• Klastrite korral sise- ja välisvõrk
• Koormuse tasakaalustaja (ja see jaotab koormuse ühtlaselt kõigile klastrite sõlmedele)
• Andmevoog (arvutage, kui palju andmeid klienti ja serverisse liigub ja sealt tagasi - siis arvutage, kas XIC-i kasutajate arvu simuleerimiseks on NIC-i maht piisav)

Looge VUGeni skriptid

Järgmine samm pärast planeerimist on VUseri skriptide loomine.

Stsenaariumi loomine

Järgmine samm on oma laadimisstsenaariumi loomine

Stsenaariumi täitmine

Stsenaariumi täitmine on koht, kus jäljendate kasutajate kasutajakoormust, käskides mitmel sõidukiüksusel samaaegselt ülesandeid täita.

Koormuse taseme saate seada, suurendades ja vähendades samaaegselt ülesandeid täitvate sõidukiüksuste arvu.

Selle käivitamise tulemusel võib server sattuda stressi ja ebaharilikult käituda. See on jõudlustestimise eesmärk. Seejärel kasutatakse saadud tulemusi üksikasjalikuks analüüsiks ja algpõhjuste tuvastamiseks.

Tulemuste analüüs (millele järgneb süsteemi kohandamine)

Stsenaariumi täitmise ajal salvestab LoadRunner rakenduse jõudluse erinevate koormuste korral. Katse täitmisel kogutud statistika salvestatakse ja viiakse läbi detailide analüüs. Tööriist „HP analüüs” genereerib erinevaid graafikuid, mis aitavad tuvastada süsteemi jõudluse mahajäämuse algpõhjusi ja süsteemi tõrkeid.

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

• Aeg esimese puhvrini
• Tehingu reageerimisaeg
• Tehingu keskmine reageerimisaeg
• Hitte sekundis
• Windowsi ressursid
• Vigade statistika
• Tehingu kokkuvõte

KKK

Milliseid rakendusi peaksime jõudlust testima?

Jõudluskontrolli tehakse alati ainult kliendi-serveri põhistes süsteemides. See tähendab, et ükski rakendus, mis ei ole kliendi-serveri põhine arhitektuur, ei tohi nõuda jõudlustesti.

Näiteks ei ole Microsofti kalkulaator klient-serveripõhine ega käita mitut kasutajat; seega ei kuulu ta jõudluskontrolli kandidaadiks.

Mis vahe on jõudluskontrolli ja jõudlustehnika vahel

On oluline mõista erinevust jõudlustesti ja jõudlustehnika vahel. Allpool jagatakse arusaama:

Jõudluskontroll on distsipliin , mis on seotud tarkvararakenduse praeguse toimivuse testimise ja aruandlusega erinevate parameetrite all.

Jõudlustehnika on protsess, mille käigus tarkvara testitakse ja häälestatakse eesmärgiga realiseerida vajalik jõudlus. Selle protsessi eesmärk on optimeerida rakenduse kõige olulisem omadus, st kasutuskogemus.

Ajalooliselt on testimine ja häälestamine olnud selgelt eraldiseisvad ja sageli konkureerivad valdkonnad. Viimaste aastate jooksul on aga mitu testijate ja arendajate tasku teinud häälestustiimide loomiseks iseseisvat koostööd. Kuna need meeskonnad on saavutanud märkimisväärset edu, on jõudluskontrolli ühendamine kontseptsiooniga jõudluse häälestunud ja nüüd nimetame seda jõudlustehnikaks.