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.

LoadRunner

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.

LoadRunner

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.

LoadRunner Architektuur
LoadRunner Architektuuri diagramm

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:

  1. Surfamine toodete lehel AmazonCom
  2. Vormista ost
  3. Makse töötlemine
  4. 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

  1. Käivitage 5 VU kasutajat iga 2 sekundi järel kuni 3500 VU kasutajani (surfamine Amazon tooteleht) on saavutatud.
  2. Korrake 30 minutit
  3. Peatage iteratsioon 25 VU kasutaja jaoks
  4. Taaskäivitage 20 VUS-i
  5. Iga sekund käivitage 2 kasutajat (kassas, maksete töötlemisel, lehel MyAccounts).
  6. Masinas A luuakse 2500 VU kasutajat
  7. 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.

Analüüs

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.

Jõudluse testimine

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

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:

Kaasatud rakenduste ja äriprotsesside ülevaade

Ü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

FAQ

Jõudlustesti tehakse alati ainult klient-serveripõhiste süsteemide jaoks. See tähendab, et ükski rakendus, mis ei ole kliendi-serveripõhine arhitektuur, ei tohi jõudluse testimist nõuda.

Näiteks Microsoft Kalkulaator ei ole kliendi-serveripõhine ega käitata mitut kasutajat; seega ei ole see jõudluskontrolli kandidaat.

Jõudluse testimine

On oluline mõista jõudluse testimise ja jõudlustehnoloogia erinevust. Allpool on jagatud arusaamine:

Jõudluse testimine on distsipliin, millega tegeletakse testimine ja aruandlus tarkvararakenduse praegune jõudlus erinevate parameetrite juures.

Jõudlustehnika on protsess, mille käigus tarkvara testitakse ja häälestatakse eesmärgiga saavutada vajalik jõudlus. Selle protsessi eesmärk on optimeerida rakenduse kõige olulisemat jõudlust, st kasutajakogemust.

Ajalooliselt on testimine ja häälestamine olnud selgelt eraldiseisvad ja sageli konkureerivad valdkonnad. Viimastel aastatel on aga mitmed testijad ja arendajad teinud tuunimismeeskondade loomisel iseseisvat koostööd. Kuna need meeskonnad on saavutanud märkimisväärset edu, on jõudluse testimise ja jõudluse häälestamise kontseptsioon levinud ja nüüd kutsume seda jõudlustehnoloogiaks.