Vad är HP LoadRunner Testing Tool? Arkitektur, komponenter

Vad är LoadRunner?

LoadRunner är ett prestandatestverktyg som grundades av Mercury 1999. LoadRunner förvärvades senare av HPE 2006. 2016 förvärvades LoadRunner av MicroFocus.

LoadRunner stöder olika utvecklingsverktyg, tekniker och kommunikationsprotokoll. I själva verket är detta det enda verktyget på marknaden som stöder ett så stort antal protokoll för att genomföra prestandatestning. Prestandatestresultat som produceras av LoadRunner-programvaran används som ett riktmärke mot andra verktyg

I den här handledningen lär du dig-

• Varför LoadRunner?
• Varför behöver du prestandatestning?
• Vad är LoadRunner Architecture?
• Färdplan för prestandatestning: detaljerade steg
• FAQ

Varför LoadRunner?

LoadRunner är inte bara pionjärverktyg inom Performance Testing, utan är fortfarande marknadsledande inom Performance Testing-paradigmet. I en nyligen genomförd bedömning har LoadRunner cirka 85% marknadsandel inom Performance Testing-industrin.

LoadRunner-verktyget stöder i stort sett RIA (Rich Internet Applications), Web 2.0 (HTTP / HTML, Ajax, Flex och Silverlight etc.), Mobile, SAP, Oracle, MS SQL Server, Citrix, RTE, Mail och framför allt Windows Socket. Det finns inget konkurrerande verktyg på marknaden som kan erbjuda så många olika protokoll som finns i ett enda verktyg.

Det som är mer övertygande att välja LoadRunner i programvarutestning är trovärdigheten hos detta verktyg. LoadRunner-verktyget har länge skapat ett rykte, så ofta kommer du att hitta kunder som korsverifierar dina prestandamätvärden med LoadRunner. Du kommer att hitta lättnad om du redan använder LoadRunner för dina prestandatestbehov.

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

LoadRunner arbetar med en princip för att simulera virtuella användare i ämnesapplikationen. Dessa virtuella användare kallas också som VUsers, replikerar klientens förfrågningar och förväntar sig ett motsvarande svar på att skicka en transaktion.

Varför behöver du prestandatestning?

En beräknad 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 bort om en webbplats inte svarar inom 8 sekunder. Föreställ dig att du väntar i 5 sekunder när du söker efter Google eller gör en vänförfrågan på Facebook. Följderna av driftstopp är ofta mer förödande än någonsin föreställt sig. Vi har exempel som de som nyligen slog Bank of America Online Banking, Amazon Web Services, Intuit eller Blackberry.

Enligt Dunn & Bradstreet upplever 59% av Fortune 500-företag cirka 1,6 timmars stillestånd varje vecka. Med tanke på det genomsnittliga Fortune 500-företaget med minst 10 000 anställda betalar 56 dollar per timme, skulle arbetskraftsdelen av stilleståndskostnaderna för en sådan organisation vara 896 000 dollar per vecka, vilket innebär mer än 46 miljoner dollar per år.

Bara en 5-minuters stilleståndstid från Google.com (19-augusti-13) beräknas kosta sökjätten så mycket som 545 000 dollar.

Det uppskattas att företag tappade försäljningen till ett värde av 1100 dollar per sekund på grund av ett nyligen avbrott i Amazon Web Service.

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

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

Vad är LoadRunner Architecture?

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

Antag att du har tilldelats att kontrollera prestanda för Amazon.com för 5000 användare

I en verklig situation kommer 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 Virtual User 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 "inspelningsfunktion" som registrerar kommunikation till och från klient och server i form av ett kodat skript - även kallat VUser-skript.

Så med tanke på ovanstående exempel kan VUGen spela in för att simulera följande affärsprocesser:

1. Surfa på produktsidan på Amazon.com
2. Kolla upp
3. Betalningen behandlas
4. Kontrollerar sidan MyAccount

Kontroller

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 användare som ska simulera mot varje affärsprocess eller VUser-grupp
• VUsers beteende (ramp upp, ramp ned, samtidig eller samtidig natur etc.)
• Typ av belastningsscenario, t.ex. verkligt liv eller målinriktad eller verifierande SLA
• Vilka injektorer ska användas, hur många enheter mot varje injektor
• Samla resultat regelbundet
• IP-förfalskning
• Felrapportering
• Transaktionsrapportering etc.

Att ta en analogi från vårt exempel på kontroller kommer att lägga till följande parameter i VUGen-skriptet

1) 3500 användare surfar på produktsidan på Amazon.com

2) 750 användare är i kassan

3) 500 användare utför betalningshantering

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

Ännu mer komplexa scenarier är möjliga

1. Starta 5 VUsers varannan sekund tills en belastning på 3500 VUsers (surfa Amazon-produktsida) uppnås.
2. Iterera i 30 minuter
3. Avbryt iteration för 25 VU-användare
4. Starta om 20 VUSers
5. Starta 2 användare (i kassan, betalningshantering, mina kontosida) varje sekund.
6. 2500 VUsers kommer att genereras vid maskin A
7. 2500 VUsers kommer att genereras vid maskin B.

Agenter Maskin / Lastgeneratorer / Injektorer

HP LoadRunner Controller är ansvarig för att simulera tusentals VUsers - dessa VUsers förbrukar hårdvaruresurser till exempel processor och minne - därmed sätter en gräns för maskinen som simulerar dem. Dessutom simulerar Controller dessa VUsers från samma maskin (där Controller finns) och följaktligen är resultaten kanske inte exakta. För att lösa detta problem är alla VU-användare spridda över olika maskiner, så kallade Load Generators eller Load Injectors.

Som allmän praxis finns Controller på en annan maskin och belastningen simuleras från andra maskiner. Beroende på protokollet för VUser-skript och maskinspecifikationer kan ett antal belastningsinjektorer krävas för fullständig simulering. Till exempel kommer VU-användare för ett HTTP-skript att kräva 2-4 MB per V-användare för simulering, varför fyra maskiner med vardera 4 GB RAM krävs för att simulera en belastning på 10 000 VU-användare.

Med analogi från vårt Amazon-exempel kommer produktionen av denna komponent att vara

Analys:

När Load-scenarier har utförts kommer rollen som " Analys " -komponenter i LoadRunner in.

Under körningen skapar Controller en dumpning 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 med namnet output.mdb. Komponenten "Analys" läser denna databasfil för att utföra olika typer av analyser och genererar grafer.

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

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

Färdplan för prestandatestning: detaljerade steg

Färdplanstestning kan i stort sett delas in i fem steg:

• Planering för lasttest
• Skapa VUGen-skript
• Scenarioskapande
• Scenarioutförande
• Resultatanalys (följt av systemjustering)

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

Steg involverade i prestandatestprocessen

Planering för lasttestet

Planering för prestandatestning skiljer sig från att planera en SIT (System Integration Testing) eller UAT (User Acceptance Testing). Planering kan ytterligare delas in i små steg som beskrivs 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 team som är involverat under processen.

Projektledare:

Nominera projektledaren som kommer att äga denna aktivitet och tjäna som punktperson för eskalering.

Funktionsexpert / affärsanalytiker:

Tillhandahåll användningsanalys av SUL och tillhandahåller expertis om webbplatsens / SULs affärsfunktionalitet

Prestandatestingsexpert:

Skapar de automatiska prestandatesterna och kör belastningsscenarier

Systemarkitekt:

Ger ritning av SUL

Webutvecklare och små och medelstora företag:

• Underhåller webbplatsen och tillhandahåller övervakningsaspekter
• Utvecklar webbplats och fixar buggar

Systemadministratör:

• Underhåller involverade servrar under ett testprojekt

Beskriva applikationer och affärsprocesser:

Framgångsrik belastningstestning kräver att du planerar att genomföra en viss affärsprocess. En affärsprocess består av tydligt definierade steg i enlighet med önskade affärstransaktioner - för att uppnå dina lasttestmål.

Ett kravvärde kan förberedas för att framkalla användarbelastning på systemet. Nedan följer 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 avsluta 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 procedurer för hantering av testdata

Statistik och observationer hämtade från Performance Testing påverkas i hög grad av många faktorer som tidigare beskrivits. Det är av avgörande betydelse att förbereda testdata för prestandatestning. Ibland förbrukar en viss affärsprocess en datamängd och producerar en annan datamängd. Ta exemplet nedan:

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

I den här situationen 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.

Godkänn därefter 150 kontrakt för att fungera som testdata för användare C - de återstående 200 kontrakten kommer att fungera som testdata för användare B.

Konturskärmar

Spekulera på varje faktor som eventuellt kan påverka systemets prestanda. Till exempel, att ha minskad hårdvara kommer att ha potentiell inverkan på SUL (System Under Load) -prestanda.

Anskaffa alla faktorer och ställa in bildskärmar 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)
• Web / App Server (till exempel IIS, JBoss, Jaguar Server, Tomcat etc)
• DB Server (PGA- och SGA-storlek vid Oracle- och MSSQL-server, SP etc.)
• Nätverkets bandbredd
• Internt och externt nätverkskort i händelse av kluster
• Load Balancer (och att den fördelar belastningen jämnt på alla noder i kluster)
• Dataflöde (beräkna hur mycket data flyttar 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)

Skapa VUGen-skript

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

Scenarioskapande

Nästa steg är att skapa ditt Load Scenario

Scenarioutförande

Scenariokörning är där du emulerar användarbelastning på servern genom att instruera flera VU-användare att utföra uppgifter samtidigt.

Du kan ställa in en lastnivå genom att öka och minska antalet VU-användare som utför uppgifter samtidigt.

Detta utförande kan leda till att servern blir stressad och beter sig onormalt. Detta är själva syftet med prestandatestningen. De ritade resultaten används sedan för detaljerad analys och identifiering av orsaker.

Resultatanalys (följt av systemjustering)

Under scenariekörning registrerar LoadRunner programmets prestanda under olika belastningar. Statistiken från testkörningen sparas och analysen utförs. Verktyget '' HP-analys '' genererar olika grafer som hjälper till att identifiera de grundläggande orsakerna bakom en fördröjning av systemets prestanda, liksom ett systemfel.

Några av de erhållna graferna inkluderar:

• Dags till den första bufferten
• Transaktionssvarstid
• Genomsnittlig svarstid för transaktion
• Träffar per sekund
• Windows-resurser
• Felstatistik
• Transaktionsöversikt

FAQ

Vilka applikationer ska vi prestanda testa?

Prestandatestning görs alltid endast för klientserverbaserade system. Detta innebär att alla applikationer som inte är en klientserverbaserad arkitektur inte behöver kräva prestandatestning.

Till exempel är Microsoft Calculator varken klientserverbaserad eller den kör flera användare; det är därför inte en kandidat för prestandatestning.

Vad är skillnaden mellan Performance Testing & Performance Engineering

Det är av betydelse att förstå skillnaden mellan Performance Testing och Performance Engineering. En förståelse delas nedan:

Prestandatestning är en disciplin som handlar om att testa och rapportera den aktuella prestandan för en programvara under olika parametrar.

Prestandateknik är den process genom vilken programvara testas och ställs in i syfte att förverkliga den prestanda som krävs. Denna process syftar till att optimera de viktigaste egenskaperna för applikationsprestanda, dvs. användarupplevelse.

Historiskt har testning och tuning varit tydligt separata och ofta konkurrerande områden. Under de senaste åren har dock flera fickor av testare och utvecklare samarbetat oberoende för att skapa tuningteam. Eftersom dessa lag har uppnått betydande framgångar har konceptet att koppla prestandatestning med prestandastämning fångat upp, och nu kallar vi det prestandateknik.