Kaj je orodje za testiranje HP LoadRunner? Arhitektura, Sestavni deli

Kaj je LoadRunner?

LoadRunner je orodje za testiranje zmogljivosti, ki ga je Mercury uvedel leta 1999. LoadRunner je kasneje HPE prevzel leta 2006. Leta 2016 je LoadRunner prevzel MicroFocus.

LoadRunner podpira različna razvojna orodja, tehnologije in komunikacijske protokole. Pravzaprav je to edino orodje na trgu, ki podpira tako veliko število protokolov za izvajanje preizkušanja učinkovitosti. Rezultati preizkusa učinkovitosti, ki jih proizvaja programska oprema LoadRunner, se uporabljajo kot primerjalno merilo za druga orodja

V tej vadnici boste izvedeli-

• Zakaj LoadRunner?
• Zakaj potrebujete testiranje učinkovitosti?
• Kaj je LoadRunner Architecture?
• Načrt testiranja učinkovitosti: podrobni koraki
• Pogosta vprašanja

Zakaj LoadRunner?

LoadRunner ni samo pionirsko orodje pri preizkušanju zmogljivosti, ampak je še vedno vodilni na trgu v paradigmi preizkušanja zmogljivosti. Po nedavni oceni ima LoadRunner približno 85-odstotni tržni delež v industriji za testiranje zmogljivosti.

Na splošno orodje LoadRunner podpira RIA (Rich Internet Applications), Web 2.0 (HTTP / HTML, Ajax, Flex in Silverlight itd.), Mobile, SAP, Oracle, MS SQL Server, Citrix, RTE, Mail in predvsem Windows Socket. Na trgu ni nobenega konkurenčnega orodja, ki bi lahko ponudilo tako široko paleto protokolov, ki jih ima eno samo orodje.

Prepričljivejša izbira LoadRunnerja pri preizkušanju programske opreme je verodostojnost tega orodja. Orodje LoadRunner si je že dolgo ustvarilo sloves, saj boste pogosto našli stranke, ki navzkrižno preverjajo merila uspešnosti z LoadRunnerjem. Olajšanje boste našli, če že uporabljate LoadRunner za potrebe testiranja učinkovitosti.

Programska oprema LoadRunner je tesno integrirana z drugimi HP-jevimi orodji, kot sta Unified Functional Test (QTP) in ALM (Application Lifecycle Management), kar vam omogoča izvajanje preskusnih postopkov od konca do konca.

LoadRunner deluje na principu simulacije navideznih uporabnikov v predmetni aplikaciji. Ti navidezni uporabniki so imenovani tudi uporabniki, podvajajo zahteve strank in pričakujejo ustrezen odgovor na posredovanje transakcije.

Zakaj potrebujete testiranje učinkovitosti?

Zaradi slabe spletne učinkovitosti letno zabeležijo 4,4 milijarde prihodkov .

V današnji dobi spleta 2.0 uporabniki kliknejo stran, če se spletno mesto ne odzove v 8 sekundah. Predstavljajte si, da med iskanjem Googla ali prošnjo za prijateljstvo na Facebooku čakate 5 sekund. Posledice izpadov uspešnosti so pogosto bolj uničujoče kot kdaj koli prej. Imamo primere, kot so tisti, ki so pred kratkim dosegli spletno bančništvo Bank of America, Amazon Web Services, Intuit ali Blackberry.

Po navedbah Dunn & Bradstreet 59% podjetij Fortune 500 vsak teden doživi približno 1,6 ure zastoja. Glede na to, da povprečno podjetje Fortune 500 z najmanj 10.000 zaposlenimi plačuje 56 dolarjev na uro, bi stroški dela zaradi izpadov takšne organizacije znašali 896.000 dolarjev na teden, kar pomeni več kot 46 milijonov dolarjev na leto.

Samo 5-minutni izpad storitve Google.com (19. avgust 13) naj bi iskalnega giganta stal kar 545.000 USD.

Ocenjujejo, da so podjetja zaradi nedavnega izpada Amazon Web Service izgubila prodajo v vrednosti 1100 USD na sekundo.

Ko organizacija uvede sistem programske opreme, lahko naleti na številne scenarije, ki lahko povzročijo zakasnitev delovanja. Številni dejavniki povzročajo upočasnitev delovanja, nekaj primerov lahko vključuje:

• Povečano število zapisov v bazi podatkov
• Povečano število hkratnih zahtevkov v sistem
• večje število uporabnikov, ki hkrati dostopajo do sistema v primerjavi s preteklostjo

Kaj je LoadRunner Architecture?

Na splošno je arhitektura HP LoadRunner zapletena, a enostavna za razumevanje.

Recimo, da ste pooblaščeni za preverjanje delovanja Amazon.com za 5000 uporabnikov

Vseh teh 5000 uporabnikov v resničnem življenju ne bo na domači strani, temveč v drugem delu spletnih strani. Kako lahko simuliramo drugače

VUGen:

VUGen ali Virtual User Generator je IDE (integrirano razvojno okolje) ali bogat urejevalnik kodiranja. VUGen se uporablja za kopiranje obnašanja sistema pod obremenitvijo (SUL). VUGen ponuja funkcijo "snemanja", ki snema komunikacijo do odjemalca in strežnika v obliki kodiranega skripta - imenovanega tudi skript VUser.

Ob upoštevanju zgornjega primera lahko VUGen snema za simulacijo naslednjih poslovnih procesov:

1. Brskanje po strani z izdelki Amazon.com
2. Preveri
3. Obdelava plačil
4. Preverjanje strani MyAccount

Krmilnik

Ko je skript VUser dokončan, je Controller ena glavnih komponent LoadRunner, ki nadzoruje simulacijo obremenitve z upravljanjem, na primer:

• Koliko uporabnikov uporabiti za simulacijo posameznega poslovnega procesa ali skupine uporabnikov
• Vedenje uporabnikov (ramp up, ramp down, sočasna ali sočasna narava itd.)
• Narava scenarija obremenitve, npr. Resnično življenje ali cilj ali preverjanje SLA
• Katere injektorje uporabiti, koliko uporabnikov proti posamezni injektorji
• Redno zbirajte rezultate
• Prevara IP
• Prijava napake
• Poročanje o transakcijah itd.

Analogija z našim primernim krmilnikom bo dodala naslednji parameter v skriptu VUGen

1) 3500 uporabnikov brska po spletni strani Amazon.com

2) 750 uporabnikov je na blagajni

3) 500 uporabnikov izvaja obdelavo plačil

4) 250 uporabnikov preveri stran MyAccount ŠE po tem, ko 500 uporabnikov opravi obdelavo plačil

Možni so tudi bolj zapleteni scenariji

1. Zaženite 5 uporabnikov vsaki 2 sekundi, dokler ne dosežete obremenitve 3500 uporabnikov (brskanje po Amazonovi strani izdelkov).
2. Ponavljajte 30 minut
3. Prekini iteracijo za 25 uporabnikov
4. Znova zaženite 20 VUSerjev
5. Zaženite 2 uporabnika (v blagajni, obdelavi plačil, strani Moji računi) vsako sekundo.
6. Na stroju A bo ustvarjenih 2500 uporabnikov
7. Na stroju B bo ustvarjenih 2500 uporabnikov

Agents Stroji / Tovorni generatorji / Injektorji

HP LoadRunner Controller je odgovoren za simulacijo tisočev uporabnikov - ti uporabniki porabljajo strojne vire, na primer procesor in pomnilnik - in s tem postavljajo stroje, ki jih simulirajo. Poleg tega Controller simulira te uporabnike iz iste naprave (kjer je Controller), zato rezultati morda niso natančni. Da bi rešili to težavo, so vsi uporabniki VU razpršeni po različnih strojih, imenovanih Load Generators ali Load Injectors.

Kot splošna praksa je Controller na drugem stroju in obremenitev je simulirana od drugih strojev. Glede na protokol skriptov VUser in specifikacije stroja bodo za popolno simulacijo morda potrebne številne injektorje obremenitve. Na primer, uporabniki za skript HTTP bodo za simulacijo potrebovali 2-4 MB na uporabnika, zato bodo za simulacijo obremenitve 10.000 uporabnikov potrebni 4 stroji s po 4 GB RAM-a.

Če vzamemo analogijo iz našega Amazonovega primera, bo rezultat te komponente

Analiza:

Po izvedbi scenarijev nalaganja nastopi vloga komponent " Analysis " v LoadRunnerju.

Med izvajanjem Controller ustvari izpis rezultatov v surovi obliki in vsebuje informacije, na primer, katera različica LoadRunner je ustvarila izpis rezultatov in kakšne so bile konfiguracije.

Vse napake in izjeme so zabeležene v Microsoftovi dostopni zbirki podatkov z imenom output.mdb. Komponenta "Analiza" bere to datoteko baze podatkov za izvajanje različnih vrst analiz in generira grafe.

Ti grafi prikazujejo različne trende za razumevanje razlogov za napake in okvare pod obremenitvijo; tako pomaga ugotoviti, ali je za optimizacijo potrebna SUL, strežnik (npr. JBoss, Oracle) ali infrastruktura.

Spodaj je primer, ko pasovna širina lahko ustvarja ozko grlo. Recimo, da ima spletni strežnik kapaciteto 1 GBps, medtem ko podatkovni promet presega to zmogljivost, kar povzroči trpljenje naslednjih uporabnikov. Če želite določiti sistem, ki ustreza takim potrebam, mora Performance Engineer analizirati vedenje aplikacij z neobičajno obremenitvijo. Spodaj je graf, ki ga ustvari LoadRunner za pridobivanje pasovne širine.

Načrt testiranja učinkovitosti: podrobni koraki

Načrt preizkušanja učinkovitosti lahko na splošno razdelimo na 5 korakov:

• Načrtovanje preskusa obremenitve
• Ustvari VUGen skripte
• Ustvarjanje scenarija
• Izvedba scenarija
• Analiza rezultatov (sledi popravljanje sistema)

Zdaj, ko ste namestili LoadRunner, si oglejmo korake, vključene v postopek, enega za drugim.

Koraki, vključeni v postopek preizkušanja učinkovitosti

Načrtovanje preskusa obremenitve

Načrtovanje preizkušanja učinkovitosti se razlikuje od načrtovanja SIT (preskušanje sistemske integracije) ali UAT (preskus sprejemljivosti uporabnika). Načrtovanje lahko nadalje razdelimo na majhne stopnje, kot je opisano spodaj:

Sestavite svojo ekipo

Ko začnete s testiranjem LoadRunner, je najbolje, da dokumentirate, kdo bo sodeloval v aktivnosti od vsake ekipe, ki je med postopkom sodelovala.

Vodja projekta:

Imenovati vodjo projekta, ki bo lastnik te dejavnosti in bo služil kot pomembna oseba za stopnjevanje.

Strokovnjak za funkcije / poslovni analitik:

Zagotovite analizo uporabe SUL in zagotovite strokovno znanje o poslovni funkcionalnosti spletnega mesta / SUL

Strokovnjak za preizkušanje zmogljivosti:

Ustvari avtomatizirane teste učinkovitosti in izvede scenarije nalaganja

Sistemski arhitekt:

Zagotavlja načrt SUL

Spletni razvijalec in MSP:

• Vzdržuje spletno stran in zagotavlja vidike spremljanja
• Razvija spletno mesto in odpravlja napake

Sistemski administrator:

• Vzdržuje vključene strežnike v celotnem preskusnem projektu

Okvirne aplikacije in vključeni poslovni procesi:

Uspešno testiranje obremenitve zahteva, da nameravate izvesti določen poslovni postopek. Poslovni proces je sestavljen iz jasno opredeljenih korakov v skladu z želenimi poslovnimi transakcijami, da lahko dosežete svoje cilje testiranja obremenitve.

Za pridobitev uporabniške obremenitve sistema je mogoče pripraviti metriko zahtev. Spodaj je primer sistema prisotnosti v podjetju:

V zgornjem primeru številke omenjajo število uporabnikov, povezanih z aplikacijo (SUL) v določeni uri. Izločimo lahko največje število uporabnikov, povezanih s poslovnim procesom, v kateri koli uri dneva, ki se izračuna v skrajnih desnih stolpcih.

Podobno lahko ugotovimo skupno število uporabnikov, povezanih z aplikacijo (SUL), kadar koli v dnevu. To se izračuna v zadnji vrstici.

Zgoraj navedeni dve dejstvi nam data skupno število uporabnikov, s katerimi moramo sistem preizkusiti.

Določite postopke za upravljanje testnih podatkov

Na statistiko in opažanja, pridobljena s preskušanjem učinkovitosti, v veliki meri vplivajo številni dejavniki, o katerih smo govorili že prej. Ključnega pomena je priprava testnih podatkov za preizkušanje učinkovitosti. Včasih določen poslovni proces porabi nabor podatkov in ustvari drugačen nabor podatkov. Vzemite spodnji primer:

• Uporabnik „A“ ustvari finančno pogodbo in jo predloži v pregled.
• Drugi uporabnik 'B' odobri 200 pogodb na dan, ki jih ustvari uporabnik 'A'
• Drugi uporabnik 'C' plača približno 150 pogodb na dan, ki ga odobri uporabnik 'B'

V tem primeru mora imeti uporabnik B v sistemu 'ustvarjenih' 200 pogodb. Poleg tega uporabnik C potrebuje 150 pogodb kot "odobrenih", da simulira obremenitev 150 uporabnikov.

To implicitno pomeni, da morate ustvariti vsaj 200 + 150 = 350 pogodb.

Po tem odobrite 150 pogodb, ki bodo uporabljene kot testni podatki za uporabnika C - preostalih 200 pogodb bo uporabljenih kot testni podatki za uporabnika B.

Orisni monitorji

Ugibajte o vseh dejavnikih, ki bi lahko vplivali na delovanje sistema. Zmanjšanje strojne opreme bo na primer potencialno vplivalo na zmogljivost SUL (sistem pod obremenitvijo).

Navedite vse dejavnike in nastavite monitorje, da jih boste lahko ocenili. Tu je nekaj primerov:

• Procesor (za spletni strežnik, strežnik aplikacij, strežnik baz podatkov in injektorje)
• RAM (za spletni strežnik, strežnik aplikacij, strežnik baz podatkov in injektorje)
• Spletni strežnik / strežnik aplikacij (na primer IIS, JBoss, Jaguar Server, Tomcat itd.)
• DB Server (velikost PGA in SGA v primeru Oracle in MSSQL Server, SP itd.)
• Izkoriščanje pasovne širine omrežja
• Notranji in zunanji NIC v primeru združevanja v skupine
• Load Balancer (in da enakomerno porazdeli obremenitev na vsa vozlišča grozdov)
• Pretok podatkov (izračunajte, koliko podatkov se premakne v odjemalca in strežnika ter iz njega - nato izračunajte, ali zmogljivost NIC zadostuje za simulacijo X števila uporabnikov)

Ustvari VUGen skripte

Naslednji korak po načrtovanju je ustvarjanje skriptov VUser.

Ustvarjanje scenarija

Naslednji korak je ustvariti scenarij nalaganja

Izvedba scenarija

Izvedba scenarija je tam, kjer posnemate obremenitev uporabnika na strežniku z navodili, da več uporabnikov hkrati izvaja naloge.

Raven obremenitve lahko nastavite tako, da povečate in zmanjšate število uporabnikov VU, ki hkrati izvajajo naloge.

Ta izvedba lahko povzroči, da bo strežnik pod stresom in se bo obnašal neobičajno. To je sam namen testiranja uspešnosti. Nato pridobljeni rezultati se uporabljajo za podrobno analizo in ugotavljanje vzroka.

Analiza rezultatov (sledi popravljanje sistema)

Med izvajanjem scenarija LoadRunner beleži delovanje aplikacije pri različnih obremenitvah. Statistični podatki, pridobljeni z izvajanjem preizkusa, se shranijo in izvede se podrobna analiza. Orodje »HP Analysis« ustvarja različne grafe, ki pomagajo prepoznati temeljne vzroke za zaostankom zmogljivosti sistema in tudi okvaro sistema.

Nekateri dobljeni grafi vključujejo:

• Čas do prvega medpomnilnika
• Odzivni čas transakcije
• Povprečni odzivni čas transakcije
• Zadetkov na sekundo
• Windows viri
• Statistika napak
• Povzetek transakcije

Pogosta vprašanja

Katere aplikacije naj preizkusimo?

Testiranje učinkovitosti se vedno izvaja samo za sisteme, ki temeljijo na odjemalsko-strežniškem sistemu. To pomeni, da vsaka aplikacija, ki ni arhitektura odjemalca in strežnika, ne sme zahtevati preizkušanja učinkovitosti.

Microsoft Kalkulator na primer ne temelji niti na odjemalsko-strežniškem niti ne izvaja več uporabnikov; zato ni kandidat za preizkušanje učinkovitosti.

Kakšna je razlika med preizkušanjem zmogljivosti in izvedbenim inženiringom

Pomembno je razumeti razliko med preizkušanjem zmogljivosti in izvedbenim inženiringom. Spodaj je predstavljeno razumevanje:

Testiranje učinkovitosti je disciplina, ki se ukvarja s testiranjem in poročanjem o trenutni učinkovitosti programske aplikacije pod različnimi parametri.

Performance Engineering je postopek, s katerim se programska oprema preizkuša in prilagaja z namenom uresničitve zahtevane zmogljivosti. Cilj tega postopka je optimizirati najpomembnejšo lastnost delovanja aplikacije, tj. Uporabniško izkušnjo.

V preteklosti sta bila testiranje in uglaševanje izrazito ločena in pogosto konkurenčna področja. V zadnjih nekaj letih pa je več žepov preizkuševalcev in razvijalcev samostojno sodelovalo pri ustvarjanju skupin za uglaševanje. Ker so te ekipe dosegle pomemben uspeh, se je koncept preskušanja zmogljivosti povezovanja z uglaševanjem zmogljivosti prijel in zdaj temu pravimo izvedbeni inženiring.