LoadRunner testverktyg – komponenter och Architecture

Vad är LoadRunner?

LoadRunner är ett prestationstestningsverktyg som togs fram av Mercury 1999. LoadRunner förvärvades senare av HPE 2006. 2016 förvärvades LoadRunner av MicroFocus.

LoadRunner stöder olika utvecklingsverktyg, teknologier och kommunikationsprotokoll. Detta är faktiskt det enda verktyget på marknaden som stöder ett så stort antal protokoll att genomföra Prestandatester. Prestandatestresultat producerade av LoadRunner-programvaran används som riktmärke mot andra verktyg

LoadRunner-video

Varför LoadRunner?

LoadRunner är inte bara pionjärverktyg inom prestationstestning, utan det är fortfarande marknadsledare inom prestationstestningsparadigmet. I en nyligen genomförd bedömning har LoadRunner cirka 85 % marknadsandel inom prestationstestningsbranschen.

I stort sett stöder LoadRunner-verktyget RIA (Rich Internet Applications), Web 2.0 (HTTP/HTML, Ajax, Flex och Silverlight etc.), Mobile, SAP, Oracle, FRÖKEN SQL Server, Citrix, RTE, Mail och över allt, Windows Uttag. Det finns inget konkurrentverktyg på marknaden som kan erbjuda ett så brett utbud av protokoll som finns i ett enda verktyg.

Vad som är mer övertygande att välja LoadRunner i mjukvarutestning är detta verktygs trovärdighet. LoadRunner-verktyget har länge etablerat ett rykte som du ofta hittar klienter korsverifierar dina prestandabenchmarks med LoadRunner. Du kommer att finna lättnad om du redan använder LoadRunner för dina prestationstestningsbehov.

LoadRunner-programvaran är tätt integrerad med andra HP-verktyg som Unified Functional Test (QTP) och ALM (Application Lifecycle Management) som ger dig möjlighet att utföra dina testprocesser från slut till slut.

LoadRunner arbetar med principen om att simulera virtuella användare på den aktuella applikationen. Dessa virtuella användare även kallade VUsers, replikerar klientens förfrågningar och förväntar sig ett motsvarande svar på att skicka en transaktion.

Varför behöver du prestationstestning?

En uppskattad förlust på 4.4 miljarder i intäkter registreras årligen på grund av dålig webbprestanda.

I dagens tid av Web 2.0 klickar användare iväg om en webbplats inte svarar inom 8 sekunder. Föreställ dig att du väntar i 5 sekunder när du söker på Google eller gör en vänförfrågan på Facebook. Konsekvenserna av driftstopp är ofta mer förödande än någonsin trott. Vi har exempel som de som nyligen drabbade Bank of America Online Banking, Amazon Webbtjänster, Intuit eller Blackberry.

Enligt Dunn & Bradstreet upplever 59 % av Fortune 500-företagen uppskattningsvis 1.6 timmars driftstopp varje vecka. Med tanke på att det genomsnittliga Fortune 500-företaget med minst 10,000 56 anställda betalar 896,000 USD per timme, skulle arbetsdelen av stilleståndskostnaderna för en sådan organisation vara 46 XNUMX USD per vecka, vilket motsvarar mer än XNUMX miljoner USD per år.

Endast en 5-minuters stilleståndstid för Google.com (19-aug-13) beräknas kosta sökjätten så mycket som $545,000 XNUMX.

Det är uppskattning att företag förlorade försäljning värda $1100 per sekund på grund av en nyligen genomförd Amazon Avbrott i webbtjänsten.

När ett mjukvarusystem distribueras av en organisation kan det stöta på många scenarier som kan leda till prestandafördröjning. Ett antal faktorer orsakar bromsande prestanda, några exempel kan vara:

• Ökat antal poster som finns i databasen
• Ökat antal samtidiga förfrågningar till systemet
• ett större antal användare som kommer åt systemet åt gången jämfört med tidigare

Vad är LoadRunner Architecture?

I stort sett är arkitekturen hos HP LoadRunner komplex, men ändå lätt att förstå.

Anta att du har i uppdrag att kontrollera prestandan för Amazon.com för 5000 användare

I en verklig situation kommer dessa alla dessa 5000 användare inte att vara på hemsidan utan i en annan del av webbplatserna. Hur kan vi simulera annorlunda.

VUGen

VUGen eller virtuell användare Generator är en IDE (Integrated Development Environment) eller en rik kodningsredigerare. VUGen används för att replikera System Under Load (SUL) beteende. VUGen tillhandahåller en "inspelnings"-funktion som registrerar kommunikation till och från klient och server i form av ett kodat skript – även kallat VUser-skript.

Så med tanke på exemplet ovan kan VUGen spela in för att simulera följande affärsprocesser:

1. Surfa på produktsidan för Amazon.com
2. Till kassan
3. Betalning Processing
4. Kontrollerar MyAccount-sidan

Regulator

När ett VUser-skript har slutförts är Controller en av de viktigaste LoadRunner-komponenterna som styr Load-simuleringen genom att hantera, till exempel:

• Hur många VUser som ska simuleras mot varje affärsprocess eller VUser Group
• VUsers beteende (ramp upp, ramp ner, samtidig eller samtidig karaktär etc.)
• Typ av belastning scenario t.ex. verkliga livet eller målorienterad eller verifierande SLA
• Vilka injektorer som ska användas, hur många VUsers mot varje injektor
• Samla resultat med jämna mellanrum
• IP Spoofing
• Felrapportering
• Transaktionsrapportering mm.

Att ta en analogi från vår exempelkontroller kommer att lägga till följande parameter till VUGen-skriptet

1) 3500 användare är Surfa på produktsidan för Amazon.com

2) 750 användare är med Till kassan

3) 500 användare är utföra betalningshantering

4) 250 användare är Kontrollerar MyAccount-sidan ENDAST efter att 500 användare har gjort betalningshantering

Ännu mer komplexa scenarier är möjliga

1. Initiera 5 VUsers varannan sekund tills en belastning på 2 VUsers (surfing) Amazon produktsida) uppnås.
2. Iterera i 30 minuter
3. Stäng av iteration för 25 VUsers
4. Starta om 20 VUSers
5. Initiera 2 användare (i kassan, betalningshantering, sidan Mina konton) varje sekund.
6. 2500 VUsers kommer att genereras vid Machine A
7. 2500 VUsers kommer att genereras vid Machine B

Agenter maskin/last Generators/Injektorer

HP LoadRunner Controller är ansvarig för att simulera tusentals VUser – dessa VUser förbrukar hårdvaruresurser som processor och minne – och sätter därför en gräns för maskinen som simulerar dem. Dessutom simulerar Controller dessa VUsers från samma maskin (där Controller finns) och därför kanske resultaten inte är exakta. För att komma till rätta med detta problem är alla VUsers utspridda på olika maskiner, så kallade Ladda Generators eller lastinjektorer.

Som en allmän praxis finns Controller på en annan maskin och lasten simuleras från andra maskiner. Beroende på protokollet för VUser-skript och maskinspecifikationer kan ett antal belastningsinjektorer behövas för fullständig simulering. Till exempel kommer VUsers för ett HTTP-skript att kräva 2-4MB per VUser för simulering, därför kommer det att krävas 4 maskiner med 4 GB RAM vardera för att simulera en belastning på 10,000 XNUMX VUser.

Tar analogi från vår Amazon Exempel, utdata från denna komponent kommer att vara

Analys

När laddningsscenarier har utförts, rollen som "Analys” komponenter i LoadRunner kommer in.

Under exekveringen skapar Controller en dump av resultat i rå form och innehåller information som vilken version av LoadRunner som skapade denna resultatdump och vad som var konfigurationer.

Alla fel och undantag loggas i en Microsoft åtkomstdatabas, namngiven, output.mdb. Komponenten "Analysis" läser denna databasfil för att utföra olika typer av analyser och genererar grafer.

Dessa grafer visar olika trender för att förstå resonemanget bakom fel och fel under belastning; hjälper alltså till att räkna ut om optimering krävs i SUL, Server (t.ex. JBoss, Oracle) eller infrastruktur.

Nedan är ett exempel där bandbredd kan skapa en flaskhals. Låt oss säga att webbservern har 1GBps kapacitet medan datatrafiken överstiger denna kapacitet vilket gör att efterföljande användare lider. För att fastställa att systemet tillgodoser sådana behov måste Performance Engineer analysera applikationsbeteende med onormal belastning. Nedan är en graf som LoadRunner genererar för att få fram bandbredd.

Hur man gör prestationstestning

Färdkarta för prestandatestning kan grovt delas in i 5 steg:

• Planering för belastningstest
• Skapa VUGen-skript
• Skapande av scenarier
• Utförande av scenarie
• Resultatanalys (följt av systemjusteringar)

Nu när du har installerat LoadRunner, låt oss förstå stegen som är involverade i processen en efter en.

Steg involverade i prestationstestningsprocessen

Steg 1) Planering för belastningstestet

Planering för prestationstestning skiljer sig från planering a SIT (System Integration Testing) or UAT (User Acceptance Testing). Planering kan ytterligare delas in i små steg enligt beskrivningen nedan:

Sätt ihop ditt team

När du kommer igång med LoadRunner Testing är det bäst att dokumentera vem som kommer att delta i aktiviteten från varje inblandat team under processen.

Projektledare:

Nominera den projektledare som ska äga denna aktivitet och fungera som punktperson för eskalering.

Funktionsexpert/affärsanalytiker:

Tillhandahålla användningsanalys av SUL & tillhandahåller expertis om affärsfunktionalitet på webbplatsen/SUL

Expert på prestandatestning:

Skapar de automatiska prestandatesterna och kör belastningsscenarier

Systemkrav Architect:

Tillhandahåller en ritning av SUL

Webbutvecklare och SME:

• Underhåller hemsida och tillhandahåller övervakningsaspekter
• Utvecklar hemsida och fixar buggar

Systemadministratör:

• Underhåller involverade servrar under ett testprojekt

Beskriv ansökningar och affärsprocesser som är involverade:

Framgångsrik Lasttestning kräver att du planerar att genomföra en viss affärsprocess. En affärsprocess består av tydligt definierade steg i överensstämmelse med önskade affärstransaktioner – för att uppnå dina belastningstestemål.

Ett kravmått kan förberedas för att framkalla användarbelastning på systemet. Nedan är ett exempel på ett närvarosystem i ett företag:

I exemplet ovan nämner siffrorna antalet användare som är anslutna till applikationen (SUL) vid en given timme. Vi kan extrahera det maximala antalet användare som är anslutna till en affärsprocess när som helst på dygnet, vilket beräknas i kolumnerna längst till höger.

På samma sätt kan vi konstatera det totala antalet användare som är anslutna till applikationen (SUL) när som helst på dygnet. Detta beräknas i sista raden.

Ovanstående 2 fakta tillsammans ger oss det totala antalet användare som vi behöver testa systemet för prestanda.

Definiera testdatahanteringsprocedurer

Statistik och observationer från prestationstestning påverkas i hög grad av ett flertal faktorer, som tidigare beskrivits. Det är av avgörande betydelse att förbereda testdata för prestationstestning. Ibland förbrukar en viss affärsprocess en datamängd och producerar en annan datamängd. Ta nedanstående exempel:

• En användare 'A' skapar ett finansiellt kontrakt och skickar in det för granskning.
• En annan användare 'B' godkänner 200 kontrakt per dag skapade av användare 'A'
• En annan användare "C" betalar cirka 150 kontrakt per dag som godkänts av användare "B"

I denna situation måste användare B ha 200 kontrakt "skapade" i systemet. Dessutom behöver användare C 150 kontrakt som "godkända" för att simulera en belastning på 150 användare.

Detta innebär implicit att du måste skapa minst 200+150= 350 kontrakt.

Efter det, godkänn 150 kontrakt som ska fungera som testdata för användare C – de återstående 200 kontrakten kommer att fungera som testdata för användare B.

Outline Monitorer

Spekulera varje faktor som kan påverka ett systems prestanda. Till exempel, att ha reducerad hårdvara kommer att ha potentiell inverkan på SUL-prestandan (System Under Load).

Ta med alla faktorer och ställ in monitorer så att du kan mäta dem. Här är några exempel:

• Processor (för webbserver, applikationsserver, databasserver och injektorer)
• RAM (för webbserver, applikationsserver, databasserver och injektorer)
• Webb-/appserver (till exempel IIS, JBoss, Jaguar Server, Tomcat etc)
• DB-server (PGA- och SGA-storlek i händelse av Oracle och MSSQL Server, SPs etc.)
• Användning av nätverksbandbredd
• Internt och externt NIC vid klustring
• Load Balancer (och att den fördelar belastningen jämnt på alla noder av kluster)
• Dataflöde (beräkna hur mycket data som flyttas till och från klient och server – beräkna sedan om en kapacitet på NIC är tillräcklig för att simulera X antal användare)

Steg 2) Skapa VUGen-skript

Nästa steg efter planering är att skapa VUser-skript.

Steg 3) Skapa scenarier

Nästa steg är att skapa ditt laddningsscenario

Steg 4) Scenarioexekvering

Scenarioexekvering är där du emulerar användarbelastning på servern genom att instruera flera VUsers att utföra uppgifter samtidigt.

Du kan ställa in nivån på en belastning genom att öka och minska antalet VUser som utför uppgifter samtidigt.

Denna körning kan leda till att servern blir stressad och beter sig onormalt. Detta är själva syftet med prestandatestningen. Resultaten som ritas används sedan för detaljerad analys och rotorsaksidentifiering.

Steg 5) Resultatanalys (följt av systemjusteringar)

Under scenariekörning registrerar LoadRunner programmets prestanda under olika belastningar. Statistiken från testkörningen sparas och detaljanalys utförs. "HP Analysis"-verktyget genererar olika grafer som hjälper till att identifiera grundorsakerna bakom en fördröjning av systemprestanda, såväl som ett systemfel.

Några av de erhållna graferna inkluderar:

• Dags till den första bufferten
• Transaktionens svarstid
• Genomsnittlig transaktionssvarstid
• Träffar per sekund
• Windows Resurser
• Felstatistik
• Transaktionsöversikt

FAQ