Kas yra „HP LoadRunner“ testavimo įrankis? Architektūra, komponentai

Kas yra „LoadRunner“?

„LoadRunner“ yra našumo tikrinimo įrankis, kurį 1999 m. Pradėjo „Mercury“. Vėliau „LoadRunner“ įsigijo 2006 m. HPE. 2016 m. „LoadRunner“ įsigijo „MicroFocus“.

„LoadRunner“ palaiko įvairius kūrimo įrankius, technologijas ir ryšio protokolus. Tiesą sakant, tai yra vienintelis įrankis rinkoje, palaikantis tiek daug protokolų, kad būtų galima atlikti našumo testavimą. „LoadRunner“ programinės įrangos rezultatai yra naudojami kaip etalonas, palyginti su kitais įrankiais

Šioje pamokoje sužinosite

• Kodėl „LoadRunner“?
• Kodėl jums reikia našumo testavimo?
• Kas yra „LoadRunner“ architektūra?
• Veiklos tikrinimo planas: išsamūs žingsniai
• DUK

Kodėl „LoadRunner“?

„LoadRunner“ yra ne tik našumo testavimo pradinis įrankis, bet ir vis dar yra „Performance Testing“ paradigmos rinkos lyderis. Neseniai atlikus vertinimą, „LoadRunner“ našumo testavimo pramonėje yra apie 85% rinkos.

Apskritai „LoadRunner“ įrankis palaiko RIA (turtingos interneto programos), „Web 2.0“ (HTTP / HTML, „Ajax“, „Flex“ ir „Silverlight“ ir kt.), Mobiliuosius, SAP, „Oracle“, „MS SQL Server“, „Citrix“, RTE, „Mail“ ir visų pirma „Windows Socket“. Rinkoje nėra konkurento įrankio, kuris galėtų pasiūlyti tokį platų protokolų, priklausančių vienam įrankiui, įvairovę.

Įtikinamiau pasirinkti „LoadRunner“ programinės įrangos testavime yra šio įrankio patikimumas. „LoadRunner“ įrankis jau seniai turi reputaciją, nes dažnai rasite klientų, kurie patikrina jūsų našumo etalonus naudodami „LoadRunner“. Rasite palengvėjimą, jei jau naudojate „LoadRunner“ savo našumo testavimo poreikiams.

„LoadRunner“ programinė įranga yra glaudžiai integruota su kitais HP įrankiais, tokiais kaip „Unified Functional Test“ (QTP) ir ALM („Application Lifecycle Management“), suteikdama galimybę atlikti testavimo procesus.

„LoadRunner“ dirba su virtualių vartotojų imitavimo dalyku programoje. Šie virtualūs vartotojai taip pat vadinami TPB, pakartoja kliento užklausas ir tikisi atitinkamo atsakymo į operacijos įvykdymą.

Kodėl jums reikia našumo testavimo?

Apskaičiuota, kad dėl blogo interneto veikimo kasmet prarandama 4,4 mlrd. Pajamų .

Šiandieniniame „Web 2.0“ amžiuje vartotojai spusteli, jei svetainė neatsako per 8 sekundes. Įsivaizduokite, kad laukiate 5 sekundes ieškodami „Google“ ar pateikdami draugo užklausą „Facebook“. Veiklos prastovos padariniai dažnai yra pražūtingesni, nei kada nors buvo įsivaizduota. Mes turime tokių pavyzdžių, kaip neseniai „Bank of America“ internetinė bankininkystė, „Amazon Web Services“, „Intuit“ ar „Blackberry“.

Anot „Dunn & Bradstreet“, 59% „Fortune 500“ kompanijų kiekvieną savaitę apytiksliai praleidžia 1,6 valandos. Atsižvelgiant į tai, kad vidutinė „Fortune 500“ įmonė, kurioje dirba ne mažiau kaip 10 000 darbuotojų, moka 56 USD per valandą, tokios organizacijos prastovos išlaidų darbo jėgos dalis būtų 896 000 USD per savaitę, o tai reiškia daugiau nei 46 mln. USD per metus.

Apskaičiuota, kad tik 5 minučių Google.com prastova (rugpjūčio 19, 13) paieškos milžinui kainuoja net 545 000 USD.

Apskaičiuota, kad bendrovės neseniai prarado 1100 USD per sekundę pardavimus dėl neseniai įvykusio „Amazon“ interneto paslaugų nutraukimo.

Kai organizacija diegia programinės įrangos sistemą, ji gali susidurti su daugybe scenarijų, kurie galbūt lemia našumą. Daugybė veiksnių lemia našumą, keli pavyzdžiai gali būti šie:

• Padidėjęs duomenų bazėje esančių įrašų skaičius
• Padidėjęs vienu metu pateiktų užklausų į sistemą skaičius
• vienu metu prie sistemos prisijungia daugiau vartotojų, palyginti su praeitimi

Kas yra „LoadRunner“ architektūra?

Apskritai, „HP LoadRunner“ architektūra yra sudėtinga, tačiau lengvai suprantama.

Tarkime, kad esate paskirtas patikrinti „Amazon.com“ našumą 5000 vartotojų

Realioje situacijoje visi šie 5000 vartotojų bus ne pagrindiniame puslapyje, o kitoje svetainių skiltyje. Kaip mes galime imituoti kitaip

VUGen:

„VUGen“ arba „Virtual User Generator“ yra IDE (integruota kūrimo aplinka) arba turtingo kodavimo redaktorius. VUGen naudojamas pakartoti sistemos apkrovos (SUL) elgesį. „VUGen“ teikia „įrašymo“ funkciją, kuri įrašo ryšį su klientais ir iš serverio ir iš jų užkoduoto scenarijaus, dar vadinamo „VUser“ scenarijumi, forma.

Taigi, atsižvelgiant į pirmiau pateiktą pavyzdį, VUGen gali įrašyti, kad imituotų šiuos verslo procesus:

1. Naršote „Amazon.com“ produktų puslapyje
2. Atsiskaitymas
3. Mokėjimo apdorojimas
4. „MyAccount“ puslapio tikrinimas

Valdiklis

Užbaigus „VUser“ scenarijų, valdiklis yra vienas iš pagrindinių „LoadRunner“ komponentų, kuris valdo apkrovos modeliavimą, valdydamas, pavyzdžiui:

• Kiek VU naudotojų imituoti pagal kiekvieną verslo procesą ar „VUser“ grupę
• VU vartotojų elgesys (pakilimas į viršų, žemyn nusileidimas, tuo pačiu metu arba kartu) ir pan.
• Apkrovos scenarijaus pobūdis, pvz., Realus gyvenimas arba tikslas arba SLA tikrinimas
• Kuriuos purkštukus naudoti, kiek VU naudotojų prieš kiekvieną purkštuką
• Periodiškai palyginkite rezultatus
• IP apsimetimas
• Pranešant apie klaidas
• Sandorių ataskaitos ir kt.

Paėmus analogiją iš mūsų valdiklio pavyzdžio, šis parametras bus pridėtas prie VUGen scenarijaus

1) 3500 vartotojų naršo „Amazon.com“ produktų puslapyje

2) „ Checkout“ yra 750 vartotojų

3) 500 vartotojų atlieka mokėjimo apdorojimą

4) 250 vartotojų tikrina „MyAccount“ puslapį TIK po to, kai 500 vartotojų atliko mokėjimo tvarkymą

Galimi dar sudėtingesni scenarijai

1. Inicijuokite 5 VU vartotojus kas 2 sekundes, kol pasieksite 3500 VU vartotojų (naršydami „Amazon“ produkto puslapyje) apkrovą.
2. Kartokite 30 minučių
3. Sustabdykite iteravimą 25 VU vartotojams
4. Paleiskite iš naujo 20 „VUSers“
5. Kiekvieną sekundę inicijuokite 2 vartotojus („Checkout“, „Payment Processing“, „MyAccounts“ puslapyje).
6. Mašinoje A bus sukurta 2500 VU vartotojų
7. Mašinoje B bus sukurta 2500 VU vartotojų

Agentai mašinų / apkrovos generatoriai / purkštukai

„HP LoadRunner“ valdiklis yra atsakingas už tai, kad imituojami tūkstančiai VU vartotojų - šie VU vartotojai sunaudoja aparatūros išteklius, pavyzdžiui, procesorių ir atmintį, todėl apriboja juos imituojančią mašiną. Be to, valdiklis imituoja šiuos TPB įrenginius iš tos pačios mašinos (kur gyvena valdiklis), todėl rezultatai gali būti netikslūs. Norėdami išspręsti šį susirūpinimą, visi TPB įrenginiai pasiskirstę po įvairias mašinas, vadinamus apkrovos generatoriais arba apkrovos purkštukais.

Kaip įprasta, valdiklis gyvena kitoje mašinoje, o apkrova imituojama iš kitų mašinų. Atsižvelgiant į „VUser“ scenarijų protokolą ir mašinos specifikacijas, visiškam modeliavimui gali prireikti kelių apkrovos purkštukų. Pvz., HTTP scenarijaus VU vartotojams modeliavimui reikės 2–4 MB vienam VUser vartotojui, taigi reikės 4 mašinų su 4 GB RAM, kad būtų galima imituoti 10 000 VU vartotojų.

Atsižvelgiant į analogiją iš mūsų „Amazon“ pavyzdžio, šio komponento išvestis bus

Analizė:

Vykdžius įkėlimo scenarijus, atsiranda „LoadRunner“ komponentų „ Analizė “ vaidmuo.

Vykdymo metu valdiklis sukuria neapdorotų rezultatų sąvartyną ir pateikia informaciją, pvz., Kuri „LoadRunner“ versija sukūrė šį rezultatų sąvartyną ir kokios buvo konfigūracijos.

Visos klaidos ir išimtys registruojamos „Microsoft“ prieigos duomenų bazėje, pavadinimu „output.mdb“. Komponentas „Analizė“ nuskaito šį duomenų bazės failą, kad atliktų įvairias analizes, ir sukuria grafikus.

Šie grafikai rodo įvairias tendencijas, kad būtų galima suprasti klaidų ir nesėkmių samprotavimus esant apkrovai; taip padėsite išsiaiškinti, ar reikia optimizuoti SUL, serverį (pvz., „JBoss“, „Oracle“) ar infrastruktūrą.

Žemiau pateikiamas pavyzdys, kai pralaidumas galėtų sukurti kliūtį. Tarkime, kad tinklo serverio talpa yra 1 GB / s, o duomenų srautas viršija šį pajėgumą, todėl kiti vartotojai kenčia. Norėdamas nustatyti, ar sistema tenkina tokius poreikius, „Performance Engineer“ turi išanalizuoti nenormalios apkrovos programos veikimą. Žemiau pateikiamas grafikas, kurį generuoja „LoadRunner“, kad gautų pralaidumą.

Veiklos tikrinimo planas: išsamūs žingsniai

Veiklos tikrinimo planą galima suskirstyti į 5 etapus:

• Apkrovos bandymo planavimas
• Kurkite „VUGen“ scenarijus
• Scenarijaus kūrimas
• Scenarijaus vykdymas
• Rezultatų analizė (po kurios atliekamas sistemos pritaikymas)

Dabar, kai įdiegėte „LoadRunner“, supraskime po žingsnį proceso veiksmus.

Veiksmų testavimo proceso etapai

Apkrovos bandymo planavimas

Veiklos testavimo planavimas skiriasi nuo SIT (sistemos integravimo testavimas) arba UAT (vartotojo priėmimo testavimas) planavimo. Planavimą galima toliau suskirstyti į mažus etapus, kaip aprašyta toliau:

Surink savo komandą

Pradėjus naudoti „LoadRunner“ testavimą, geriausia dokumentuoti, kas dalyvaus veikloje iš kiekvienos procese dalyvaujančios komandos.

Projekto vadovas:

Paskirkite projekto vadovą, kuriam priklausys ši veikla, ir jis bus eskalavimo taškas.

Funkcijų ekspertas / verslo analitikas:

Pateikite SUL naudojimo analizę ir teikia žinių apie svetainės / SUL verslo funkcionalumą

Našumo testavimo ekspertas:

Sukuria automatinius našumo testus ir vykdo apkrovos scenarijus

Sistemos architektas:

Pateikia SUL projektą

Žiniatinklio kūrėjas ir MVĮ:

• Tvarko svetainę ir teikia stebėjimo aspektus
• Kuria svetainę ir taiso klaidas

Sistemos administratorius:

• Tvarko susijusius serverius viso bandymo projekto metu

Apibūdinkite programas ir susijusius verslo procesus:

Norint sėkmingai atlikti apkrovos testavimą, reikia planuoti atlikti tam tikrą verslo procesą. Verslo procesą sudaro aiškiai apibrėžti žingsniai, siekiant laikytis norimų verslo operacijų, kad būtų pasiekti jūsų apkrovos tikrinimo tikslai.

Reikalavimų metrika gali būti parengta siekiant sukelti vartotojo apkrovą sistemoje. Žemiau pateikiamas lankomumo įmonėje pavyzdys:

Pirmiau pateiktame pavyzdyje skaičiai nurodo vartotojų, prisijungusių prie programos (SUL), skaičių tam tikrą valandą. Mes galime išgauti maksimalų vartotojų, susietų su verslo procesu, bet kurią dienos valandą skaičių, kuris apskaičiuojamas dešiniajame kampe.

Panašiai galime nustatyti bendrą prie programos prisijungusių vartotojų skaičių (SUL) bet kurią dienos valandą. Tai apskaičiuojama paskutinėje eilutėje.

Pirmiau nurodyti 2 faktai suteikia mums bendrą vartotojų, su kuriais turime išbandyti sistemos našumą, skaičių.

Apibrėžkite bandymo duomenų valdymo procedūras

Našumo testavimo statistikai ir stebėjimams daug įtakos turi daugybė anksčiau aprašytų veiksnių. Itin svarbu rengti bandymo duomenis našumo testavimui. Kartais konkretus verslo procesas sunaudoja duomenų rinkinį ir sukuria kitą duomenų rinkinį. Paimkite žemiau pateiktą pavyzdį:

• Vartotojas „A“ sukuria finansinę sutartį ir pateikia ją peržiūrėti.
• Kitas vartotojas „B“ patvirtina 200 sutarčių per dieną, kurias sukūrė vartotojas „A“
• Kitas „C“ vartotojas per dieną moka apie 150 sutarčių, kurias patvirtino „B“ vartotojas.

Tokiu atveju vartotojui B sistemoje reikia „sukurti“ 200 sutarčių. Be to, C vartotojui reikia 150 sutarčių, kaip „patvirtintų“, kad imituotų 150 vartotojų apkrovą.

Tai netiesiogiai reiškia, kad turite sukurti mažiausiai 200 + 150 = 350 sutarčių.

Po to patvirtinkite 150 sutarčių, kurios bus naudojamos kaip vartotojo C bandomieji duomenys - likusios 200 sutarčių bus naudojamos kaip vartotojo B bandomieji duomenys.

Kontūrų monitoriai

Spekuliuokite kiekvieną veiksnį, kuris galėtų turėti įtakos sistemos veikimui. Pavyzdžiui, sumažėjus aparatinei įrangai, tai gali turėti įtakos SUL (sistemos apkrovai) našumui.

Surašykite visus veiksnius ir nustatykite monitorius, kad galėtumėte juos įvertinti. Štai keli pavyzdžiai:

• Procesorius (žiniatinklio serveriui, programų serveriui, duomenų bazių serveriui ir purkštukams)
• RAM (žiniatinklio serveriui, programų serveriui, duomenų bazių serveriui ir purkštukams)
• Žiniatinklio / programų serveris (pvz., IIS, „JBoss“, „Jaguar Server“, „Tomcat“ ir kt.)
• DB serveris (PGA ir SGA dydis „Oracle“ ir „MSSQL Server“, SP ir kt. Atveju)
• Tinklo pralaidumo naudojimas
• Vidaus ir išorės NIC grupių atveju
• „Load Balancer“ (ir kad jis tolygiai paskirsto apkrovą visiems grupių mazgams)
• Duomenų srautas (apskaičiuokite, kiek duomenų juda iš kliento ir serverio ir iš jo, tada apskaičiuokite, ar NIC pajėgumų pakanka X vartotojų skaičiui imituoti)

Kurkite „VUGen“ scenarijus

Kitas žingsnis po planavimo yra sukurti „VUser“ scenarijus.

Scenarijaus kūrimas

Kitas žingsnis - sukurti apkrovos scenarijų

Scenarijaus vykdymas

Scenarijų vykdymas yra tas, kur mėgdžioji vartotojo apkrovą serveryje, nurodydamas keliems TPB atlikti užduotis vienu metu.

Galite nustatyti apkrovos lygį, padidindami ir sumažindami TPB, atliekančių užduotis tuo pačiu metu, skaičių.

Tai gali sukelti serverio stresą ir nenormalų elgesį. Tai yra pats „Performance Testing“ tikslas. Tada gauti rezultatai naudojami išsamiai analizei ir pagrindinėms priežastims nustatyti.

Rezultatų analizė (po kurios atliekamas sistemos pritaikymas)

Vykdant scenarijų, „LoadRunner“ įrašo programos našumą esant skirtingoms apkrovoms. Iš testo vykdymo surinkta statistika yra išsaugoma ir atliekama išsami analizė. „HP analizės“ įrankis sukuria įvairius grafikus, kurie padeda nustatyti pagrindines sistemos našumo atsilikimo priežastis ir sistemos gedimą.

Kai kurie gauti grafikai apima:

• Laikas iki pirmo buferio
• Operacijos atsako laikas
• Vidutinis operacijos atsako laikas
• Rezultatai per sekundę
• „Windows“ ištekliai
• Klaidų statistika
• Operacijų suvestinė

DUK

Kurias programas turėtume išbandyti?

Našumo testavimas visada atliekamas tik kliento-serverio sistemose. Tai reiškia, kad bet kuriai programai, kuri nėra kliento-serverio architektūra, nereikia atlikti našumo testavimo.

Pvz., „Microsoft“ skaičiuoklė nėra pagrįsta kliento-serverio funkcija ir joje nėra kelių vartotojų; taigi jis nėra kandidatas į našumo testavimą.

Kuo skiriasi našumo testavimas ir našumo inžinerija

Labai svarbu suprasti skirtumą tarp našumo testavimo ir našumo inžinerijos. Žemiau yra bendras supratimas:

Našumo testavimas yra disciplina, susijusi su dabartinės programinės įrangos našumo testavimu ir ataskaitų teikimu pagal įvairius parametrus.

Veiklos inžinerija yra procesas, kurio metu programinė įranga yra išbandoma ir derinama siekiant realizuoti reikiamą našumą. Šiuo procesu siekiama optimizuoti svarbiausias programos našumo savybes, ty vartotojo patirtį.

Istoriškai bandymai ir derinimas buvo aiškiai atskirti ir dažnai konkuruojantys. Tačiau per pastaruosius kelerius metus kelios testuotojų ir kūrėjų kišenės savarankiškai bendradarbiavo kurdamos derinimo komandas. Kadangi šios komandos sulaukė didelio pasisekimo, veiklos testavimo ir našumo derinimo koncepcija įsitvirtino, ir dabar mes tai vadiname veiklos inžinerija.