Što je HP LoadRunner alat za testiranje? Arhitektura, komponente

Što je LoadRunner?

LoadRunner je alat za testiranje performansi koji je Mercury pionir 1999. godine. LoadRunner je kasnije kupio HPE 2006. godine. 2016. LoadRunner kupio je MicroFocus.

LoadRunner podržava razne razvojne alate, tehnologije i komunikacijske protokole. Zapravo je ovo jedini alat na tržištu koji podržava tako velik broj protokola za provođenje ispitivanja performansi. Rezultati ispitivanja performansi koje proizvodi softver LoadRunner koriste se kao mjerilo u odnosu na druge alate

U ovom vodiču naučit ćete-

• Zašto LoadRunner?
• Zašto vam je potrebno testiranje performansi?
• Što je LoadRunner Architecture?
• Plan testiranja izvedbe: detaljni koraci
• Pitanja

Zašto LoadRunner?

LoadRunner nije samo pionirski alat u ispitivanju performansi, već je i dalje tržišni lider u paradigmi ispitivanja performansi. U nedavnoj procjeni, LoadRunner ima oko 85% tržišnog udjela u industriji ispitivanja performansi.

Alat LoadRunner široko podržava RIA (bogate internetske aplikacije), Web 2.0 (HTTP / HTML, Ajax, Flex i Silverlight itd.), Mobile, SAP, Oracle, MS SQL Server, Citrix, RTE, Mail i prije svega Windows Socket. Na tržištu ne postoji niti jedan konkurentski alat koji bi mogao ponuditi tako široku paletu protokola koji su povezani s jednim alatom.

Ono što je uvjerljivije odabrati LoadRunner u testiranju softvera je vjerodostojnost ovog alata. Alat LoadRunner odavno je stekao reputaciju jer ćete često naći klijente kako unakrsno provjeravaju vaše performanse pomoću LoadRunnera. Olakšanje ćete pronaći ako već upotrebljavate LoadRunner za potrebe testiranja performansi.

Softver LoadRunner usko je integriran s ostalim HP alatima poput Unified Functional Test (QTP) i ALM (Application Lifecycle Management) koji vam omogućuje da izvršite svoje postupke testiranja od kraja do kraja.

LoadRunner radi na principu simulacije virtualnih korisnika na predmetnoj aplikaciji. Ovi virtualni korisnici također se nazivaju VUsers, repliciraju zahtjeve klijenta i očekuju odgovarajući odgovor na prosljeđivanje transakcije.

Zašto vam je potrebno testiranje performansi?

Procijenjeni gubitak prihoda od 4,4 milijarde godišnje bilježi se zbog loših web performansi.

U današnje doba Weba 2.0 korisnici kliknu ako web mjesto ne odgovori u roku od 8 sekundi. Zamislite kako čekate 5 sekundi dok tražite Google ili postavljate zahtjev za prijateljstvo na Facebooku. Posljedice zastoja u izvedbi često su poražavajuće nego što su ikad zamišljali. Imamo primjere poput onih koji su nedavno došli na internetsko bankarstvo Bank of America, Amazon Web Services, Intuit ili Blackberry.

Prema Dunn & Bradstreetu, 59% tvrtki iz Fortune 500 doživljava procijenjeno 1,6 sati zastoja svaki tjedan. Uzimajući u obzir da prosječna tvrtka Fortune 500 s minimalno 10.000 zaposlenih plaća 56 dolara na sat, dio troškova zastoja radne snage takve organizacije iznosio bi 896.000 američkih dolara tjedno, što znači više od 46 milijuna američkih dolara godišnje.

Procjenjuje se da bi samo 5-minutni zastoj Google.com (19. kolovoza 13.) koštao pretraživačkog giganta čak 545.000 američkih dolara.

Procjenjuje se da su tvrtke izgubile prodaju u vrijednosti od 1100 USD u sekundi zbog nedavnog prekida rada Amazon Web Servicea.

Kada organizacija implementira softverski sustav, ona može naići na mnogo scenarija koji mogu rezultirati kašnjenjem izvedbe. Brojni čimbenici uzrokuju usporavanje izvedbe, nekoliko primjera može uključivati:

• Povećan broj zapisa prisutnih u bazi podataka
• Povećan broj istodobnih zahtjeva upućenih sustavu
• veći broj korisnika koji istovremeno pristupaju sustavu u odnosu na prošlost

Što je LoadRunner Architecture?

Široko govoreći, arhitektura HP LoadRunnera je složena, ali lako razumljiva.

Pretpostavimo da ste zaduženi za provjeru performansi Amazon.com za 5000 korisnika

U stvarnoj situaciji, svih ovih 5000 korisnika neće biti na početnoj stranici, već u drugom dijelu web stranica. Kako možemo drugačije simulirati

VUGen:

VUGen ili Virtual User Generator je IDE (Integrirano razvojno okruženje) ili bogati uređivač kodiranja. VUGen se koristi za kopiranje ponašanja sustava pod opterećenjem (SUL). VUGen nudi značajku "snimanja" koja bilježi komunikaciju s klijenta i poslužitelja i od njega u obliku kodirane skripte - koja se također naziva VUser skripta.

Dakle, uzimajući u obzir gornji primjer, VUGen može snimati kako bi simulirao sljedeće poslovne procese:

1. Surfanje stranicama proizvoda Amazon.com
2. Provjeri
3. Obrada plaćanja
4. Provjeravanje stranice MyAccount

Kontroler

Jednom kada je skripta VUser finalizirana, Controller je jedna od glavnih komponenata LoadRunnera koja upravlja simulacijom učitavanja upravljajući, na primjer:

• Koliko korisnika mora simulirati protiv svakog poslovnog procesa ili grupe korisnika
• Ponašanje korisnika korisnika (povećavanje, smanjivanje, simultana ili istodobna priroda itd.)
• Scenarij prirode opterećenja, npr. Stvarni život ili cilj ili provjera SLA-a
• Koje mlaznice koristiti, koliko VUser-a protiv pojedine mlaznice
• Povremeno sakupljajte rezultate
• IP prijevara
• Prijava pogreške
• Izvještavanje o transakcijama itd.

Uzimajući analogiju iz našeg primjera kontrolera, u VUGen Script dodat će se sljedeći parametar

1) 3500 korisnika pregledava stranicu proizvoda Amazon.com

2) 750 korisnika je na blagajni

3) 500 korisnika vrši obradu plaćanja

4) 250 korisnika provjerava stranicu mog računa SAMO nakon što 500 korisnika izvrši obradu plaćanja

Mogući su i složeniji scenariji

1. Pokrenite 5 korisnika tijekom 2 sekunde dok se ne postigne opterećenje od 3500 korisnika (surfanje Amazonovom stranicom proizvoda).
2. Ponavljajte 30 minuta
3. Obustavite iteraciju za 25 korisnika
4. Ponovo pokrenite 20 korisnika
5. Pokrenite 2 korisnika (na blagajni, Obrada plaćanja, Stranica Moji računi) svake sekunde.
6. Na stroju A generirat će se 2500 korisnika
7. 2500 korisnika će se generirati na stroju B

Agenti Strojevi / Generatori opterećenja / Injektori

HP LoadRunner Controller odgovoran je za simulaciju tisuća VUser-a - ti VUsers troše hardverske resurse, na primjer procesor i memoriju - stoga postavljajući ograničenje stroju koji ih simulira. Osim toga, Controller simulira ove VUsere s istog stroja (gdje Controller boravi), pa rezultati možda neće biti precizni. Kako bi se pozabavili ovom zabrinutošću, svi su korisnici VU-a raspoređeni na različitim strojevima, koji se nazivaju generatorima opterećenja ili injektorima opterećenja.

Kao opća praksa, Controller se nalazi na drugom stroju i opterećenje se simulira od drugih strojeva. Ovisno o protokolu VUser skripti i specifikacijama stroja, za potpunu simulaciju može biti potreban određeni broj injektora opterećenja. Na primjer, VUsers za HTTP skriptu zahtijevat će 2-4 MB po VUser-u za simulaciju, stoga će za simulaciju opterećenja od 10.000 VUsers-a biti potrebna 4 stroja s po 4 GB RAM-a.

Uzimajući Analogiju iz našeg Amazonovog primjera, izlaz ove komponente bit će

Analiza:

Jednom kada se izvrše scenariji učitavanja, dolazi uloga komponenti " Analiza " LoadRunnera.

Tijekom izvršavanja Controller stvara izvatke rezultata u sirovom obliku i sadrži informacije poput toga koja je verzija LoadRunnera izradila ovo izbacivanje rezultata i koje su bile konfiguracije.

Sve se pogreške i iznimke zapisuju u Microsoftovu pristupnu bazu podataka, pod nazivom output.mdb. Komponenta "Analiza" čita ovu datoteku baze podataka za obavljanje različitih vrsta analiza i generira grafikone.

Ovi grafikoni prikazuju različite trendove da bi se razumjelo obrazloženje pogrešaka i neuspjeha pod opterećenjem; na taj način pomažu utvrditi je li potrebna optimizacija u SUL-u, poslužitelju (npr. JBoss, Oracle) ili infrastrukturi.

Ispod je primjer gdje propusnost može stvoriti usko grlo. Recimo da web poslužitelj ima kapacitet od 1 GBps, dok podatkovni promet premašuje taj kapacitet što uzrokuje patnju sljedećih korisnika. Da bi utvrdio da sustav zadovoljava takve potrebe, Performance Engineer mora analizirati ponašanje aplikacije s nenormalnim opterećenjem. Ispod je grafikon koji LoadRunner generira kako bi izazvao širinu pojasa.

Plan testiranja izvedbe: detaljni koraci

Plan testiranja izvedbe može se široko podijeliti u 5 koraka:

• Planiranje ispitivanja opterećenja
• Stvorite VUGen skripte
• Stvaranje scenarija
• Izvršenje scenarija
• Analiza rezultata (nakon čega slijedi dorađivanje sustava)

Sad kad ste instalirali LoadRunner, shvatimo korake koji su uključeni u postupak jedan po jedan.

Koraci uključeni u postupak ispitivanja performansi

Planiranje ispitivanja opterećenja

Planiranje ispitivanja izvedbe razlikuje se od planiranja SIT-a (testiranje integracije sustava) ili UAT-a (ispitivanje prihvaćanja korisnika). Planiranje se dalje može podijeliti u male faze kako je opisano u nastavku:

Okupite svoj tim

Kad započnete s LoadRunner testiranjem, najbolje je dokumentirati tko će sudjelovati u aktivnosti od svakog tima koji je sudjelovao u procesu.

Voditelj projekta:

Nominirajte voditelja projekta koji će biti vlasnik ove aktivnosti i služiti kao glavna osoba za eskalaciju.

Stručnjak za funkcije / poslovni analitičar:

Pružite analizu upotrebe SUL-a i pružate stručnost u poslovnoj funkcionalnosti web stranice / SUL-a

Stručnjak za ispitivanje performansi:

Stvara automatizirane testove performansi i izvršava scenarije učitavanja

Arhitekt sustava:

Pruža nacrt SUL-a

Web programer i MSP:

• Održava web stranicu i pruža aspekte praćenja
• Izrađuje web stranicu i ispravlja pogreške

Administrator sustava:

• Održava uključene poslužitelje tijekom cijelog projekta testiranja

Okvirne aplikacije i uključeni poslovni procesi:

Uspješno ispitivanje opterećenja zahtijeva da planirate provesti određeni poslovni proces. Poslovni proces sastoji se od jasno definiranih koraka u skladu sa željenim poslovnim transakcijama - kako bi se postigli vaši ciljevi ispitivanja opterećenja.

Može se pripremiti mjerni podatak za izazivanje korisničkog opterećenja na sustavu. Ispod je primjer sustava pohađanja tvrtke:

U gornjem primjeru brojke spominju broj korisnika povezanih s aplikacijom (SUL) u određenom satu. U bilo kojem satu dana možemo izračunati maksimalan broj korisnika povezanih s poslovnim procesom koji se izračunava u najdesnijim stupcima.

Slično tome, možemo zaključiti ukupan broj korisnika povezanih s aplikacijom (SUL) u bilo kojem satu dana. To se izračunava u zadnjem redu.

Gore navedene 2 činjenice daju nam ukupan broj korisnika s kojima moramo testirati sustav na učinkovitost.

Definirajte postupke upravljanja testnim podacima

Na statistiku i zapažanja izvedena ispitivanjem učinka uvelike utječu brojni čimbenici kako je prethodno rečeno. Od presudne je važnosti pripremiti podatke o ispitivanju za ispitivanje performansi. Ponekad određeni poslovni proces troši skup podataka i stvara drugačiji skup podataka. Uzmite donji primjer:

• Korisnik 'A' kreira financijski ugovor i predaje ga na uvid.
• Drugi korisnik 'B' odobrava 200 ugovora dnevno koje kreira korisnik 'A'
• Drugi korisnik 'C' plaća oko 150 ugovora dnevno koje odobrava korisnik 'B'

U ovoj situaciji, korisnik B mora imati 200 'stvorenih' ugovora u sustavu. Osim toga, korisniku C treba 150 ugovora kao "odobrenih" kako bi simulirao opterećenje od 150 korisnika.

To implicitno znači da morate stvoriti najmanje 200 + 150 = 350 ugovora.

Nakon toga odobrite 150 ugovora koji će služiti kao test podaci za korisnika C - preostalih 200 ugovora poslužit će kao test podaci za korisnika B.

Monitori obrisa

Nagađajte svaki faktor koji bi mogao utjecati na performanse sustava. Na primjer, smanjenje hardvera imat će potencijalni utjecaj na izvedbu SUL-a (System Under Load).

Navedite sve čimbenike i postavite monitore kako biste ih mogli mjeriti. Evo nekoliko primjera:

• Procesor (za web poslužitelj, poslužitelj aplikacija, poslužitelj baze podataka i brizgalice)
• RAM (za web poslužitelj, poslužitelj aplikacija, poslužitelj baze podataka i brizgalice)
• Web / poslužitelj aplikacija (na primjer IIS, JBoss, Jaguar Server, Tomcat itd.)
• DB poslužitelj (veličina PGA i SGA u slučaju Oracle i MSSQL poslužitelja, SP-ova itd.)
• Korištenje mrežne propusnosti
• Unutarnji i vanjski NIC u slučaju grupiranja
• Load Balancer (i da ravnomjerno raspoređuje opterećenje na svim čvorovima klastera)
• Protok podataka (izračunajte koliko se podataka kreće prema klijentu i poslužitelju i od njega - zatim izračunajte je li kapacitet NIC-a dovoljan za simulaciju X broja korisnika)

Stvorite VUGen skripte

Sljedeći korak nakon planiranja je stvaranje VUser skripti.

Stvaranje scenarija

Sljedeći je korak stvaranje vašeg scenarija učitavanja

Izvršenje scenarija

Izvršenje scenarija je mjesto gdje oponašate opterećenje korisnika na poslužitelju upućujući više korisnika da istovremeno izvršavaju zadatke.

Možete postaviti razinu opterećenja povećavanjem i smanjenjem broja korisnika koji istovremeno izvršavaju zadatke.

Ovo izvršavanje može dovesti do toga da poslužitelj padne pod stres i ponaša se neobično. To je sama svrha testiranja izvedbe. Izvučeni rezultati zatim se koriste za detaljnu analizu i utvrđivanje osnovnog uzroka.

Analiza rezultata (nakon čega slijedi dorađivanje sustava)

Tijekom izvršavanja scenarija, LoadRunner bilježi izvedbu aplikacije pod različitim opterećenjima. Statistika izvučena iz izvršavanja testa sprema se i provodi se analiza detalja. Alat "HP analiza" generira razne grafikone koji pomažu u prepoznavanju temeljnih uzroka zaostajanja performansi sustava, kao i kvara sustava.

Neki od dobivenih grafova uključuju:

• Vrijeme je do prvog međuspremnika
• Vrijeme reakcije transakcije
• Prosječno vrijeme odziva transakcije
• Hitova u sekundi
• Resursi za Windows
• Statistika pogrešaka
• Sažetak transakcije

Pitanja

Koje bismo programe trebali testirati?

Testiranje izvedbe uvijek se provodi samo za sustave zasnovane na klijent-poslužitelju. To znači da bilo koja aplikacija koja nije arhitektura zasnovana na klijentu i poslužitelju ne smije zahtijevati testiranje izvedbe.

Na primjer, Microsoft Kalkulator nije zasnovan na klijent-poslužitelju niti pokreće više korisnika; stoga nije kandidat za testiranje izvedbe.

Koja je razlika između ispitivanja performansi i izvedbenog inženjerstva

Važno je razumjeti razliku između ispitivanja performansi i izvedbenog inženjerstva. U nastavku se dijeli razumijevanje:

Ispitivanje izvedbe disciplina je koja se bavi ispitivanjem i izvještavanjem o trenutnim performansama softverske aplikacije pod različitim parametrima.

Izvedbeni inženjering postupak je kojim se softver testira i podešava s namjerom ostvarenja potrebnih performansi. Cilj ovog postupka je optimiziranje najvažnijeg svojstva izvedbe aplikacije, tj. Korisničkog iskustva.

Povijesno gledano, testiranje i podešavanje bili su izrazito odvojeni i često se nadmeću. U posljednjih nekoliko godina, međutim, nekoliko džepova testera i programera neovisno je surađivalo na stvaranju timova za podešavanje. Budući da su ti timovi postigli značajan uspjeh, koncept spajanja ispitivanja performansi s podešavanjem performansi se uhvatio, a sada to nazivamo izvedbenim inženjeringom.