LoadRunner testverktyg: ArchiTekturdiagram och komponenter

Vad är LoadRunner?

LoadRunner är en Prestandatester verktyg som var pionjärer av Mercury Interactive 1999. LoadRunner förvärvades senare av HP 2006, och HP:s mjukvaruverksamhet slogs samman med Micro Focus i en affär som tillkännagavs 2016 och slutfördes 2017.

Varumärkesanmärkning: OpenText slutförde förvärvet av Micro Focus i januari 2023Verktyget säljs inte längre som HP eller Micro Focus LoadRunnerLoadRunner Professional är nu tillgänglig OpenText Professionell prestandateknik, LoadRunner Enterprise är OpenText Enterprise Performance Engineering, och LoadRunner Cloud är OpenText Kärnprestandateknik. Komponentnamnen nedan – VuGen, Controller, load generators och Analysis – är oförändrade.

LoadRunner stöder olika utvecklingsverktyg, tekniker och kommunikationsprotokoll. Det har ett av de bredaste protokollbiblioteken på marknaden för att utföra prestandatester. Prestandatestresultat som produceras av LoadRunner-programvaran används som ett riktmärke mot andra verktyg.

LoadRunner-video

Titta på videon nedan för en snabb introduktion till LoadRunner innan du går igenom komponenterna.

Varför LoadRunner?

LoadRunner är inte bara ett banbrytande verktyg inom prestandatestning, det är fortfarande en av marknadsledarna inom prestandatestningsparadigmet och är fortfarande den referenspunkt som många företag jämför sig med.

Protokollomfattningen är den tydligaste anledningen till att team väljer det, vilket komponentkartan nedan visar.

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 Socket. Få konkurrerande verktyg erbjuder ett så brett utbud av protokoll i ett enda verktyg, vilket protokolllistan nedan illustrerar.

Det som är mer övertygande att välja LoadRunner för mjukvarutestning är verktygets trovärdighet. LoadRunner har länge etablerat ett rykte eftersom du ofta hittar kunder som korsverifierar dina prestandamått med hjälp av LoadRunner. Du kommer att finna lättnad om du redan använder LoadRunner för dina prestandatestbehov.

LoadRunner-programvaran är tätt integrerad med de andra verktygen i samma svit — Unified Functional Testing (före detta QTP, säljs nu som OpenText Funktionstestning) och ALM (Application Lifecycle Management, numera OpenText ALM/Kvalitetscenter) — vilket ger dig möjlighet att utföra dina heltäckande testprocesser.

LoadRunner fungerar enligt principen att simulera virtuella användare i den aktuella applikationen. Dessa virtuella användare, även kallade V-användare, replikerar klientens förfrågningar och förväntar sig ett motsvarande svar för att genomföra en transaktion.

Varför behöver du prestationstestning?

Branschuppskattningarna nedan är allmänt citerade och dateras från början av 2010-talet, men mönstret de beskriver har inte förändrats: långsamma sidor kostar pengar.

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

I dagens Web 2.0-ålder klickar användare bort om en webbplats inte svarar inom 8 sekunder. Tänk dig att du väntar i 5 sekunder när du söker efter Google eller göra en vänförfrågan på Facebook. Konsekvenserna av driftstopp är ofta mer förödande än man någonsin kunnat föreställa sig. Det finns välkända exempel som de som drabbade Bank of Americas onlinebanking, Amazon Webbtjänster, Intuit och Blackberry.

Enligt Dun & Bradstreet upplever 59 % av Fortune 500-företagen uppskattningsvis 1.6 timmars driftstopp varje vecka. Med tanke på att ett genomsnittligt Fortune 500-företag med minst 10 000 anställda betalar 56 dollar i timmen, skulle arbetskostnaden för driftstopp för en sådan organisation vara 896 000 dollar i veckan, vilket motsvarar mer än 46 miljoner dollar per år.

Bara 5 minuters driftstopp Google.com i augusti 2013 uppskattas ha kostat sökjätten så mycket som 545 000 dollar.

Det uppskattas att företag förlorade försäljning värd 1 100 dollar per sekund under de senaste åren. Amazon Avbrott i webbtjänster.

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 använder systemet samtidigt jämfört med tidigare

Dock är inte alla ansökningar en kandidat. Lasttestning riktar sig mot klient-server-system med flera användare, så ett skrivbordsverktyg för en användare som det nedan är inte värt att testa för prestanda.

Vad är LoadRunner Architecture?

Generellt sett är arkitekturen i LoadRunner komplex, men ändå lätt att förstå. LoadRunner-arkitekturdiagrammet nedan visar hur de fyra komponenterna samverkar.

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

I en verklig situation kommer alla dessa 5000 användare inte att sitta på hemsidan – de kommer att vara utspridda över olika delar av webbplatsen. Så hur simulerar vi den skillnaden?

VuGen

VuGen eller virtuell användare Generator är en IDE (Integrated Development Environment) eller en redigerare för avancerad kodning. VuGen används för att replikera System Under Load (SUL) beteende. VuGen tillhandahåller en "inspelningsfunktion" som spelar in 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:

• Surfa på produktsidan för Amazon.com
• Till kassan
• Betalning Processing
• Kontrollerar MyAccount-sidan

När skriptet spelas upp rent måste dynamiska servervärden vanligtvis registreras med korrelation innan den kan skalas upp.

Regulator

När ett VUser-skript är färdigställt, Regulator är en av huvudkomponenterna i LoadRunner som styr lastsimuleringen 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.

Med en analogi från vårt exempel kommer Controllern att lägga till följande parametrar i VuGen-skriptet:

1. 3500 användare surfar på produktsidan för Amazon.com
2. 750 användare är i kassan
3. 500 användare utför betalningsbehandling
4. 250 användare kontrollerar Mitt konto-sidan ENDAST efter att 500 användare har slutfört betalningsbearbetningen.

Ännu mer komplexa scenarier är möjliga:

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

Agenter maskin/last Generators/Injektorer

LoadRunner-styrenheten ansvarar för att simulera tusentals VUsers – dessa VUsers förbrukar hårdvaruresurser, till exempel processor och minne – vilket sätter en gräns för den maskin som simulerar dem. Dessutom simulerar styrenheten dessa VUsers från samma maskin (där styrenheten finns) och därför kan resultaten vara oexakta. För att hantera detta problem är alla VUsers utspridda över olika maskiner, kallade LoadRunner-styrenheter. 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.

Med analogin från vår Amazon Till exempel är utdata från den här komponenten 5000 V-användare uppdelade på två injektorer: 2500 V-användare genererade på maskin A och 2500 på maskin B.

Analys

När belastningsscenarier har körts, spelar rollen för Analys komponenten av 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 Access-databasen output.mdb. Analyskomponenten 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 följer ett exempel där bandbredd kan skapa en flaskhals. Låt oss säga att webbservern har en kapacitet på 1 GBps medan datatrafiken överstiger denna kapacitet, vilket orsakar att efterföljande användare lider. För att avgöra om systemet tillgodoser dessa behov måste prestandaingenjören analysera applikationens beteende vid onormal belastning. Nedan visas ett diagram som LoadRunner genererar för att få fram bandbredd.

Hur man gör prestationstestning

En färdplan för prestandatestning kan i stort sett delas in i fem steg, sammanfattade i färdplanen nedan:

1. Planering för belastningstest
2. Skapa VuGen-skript
3. Skapande av scenarier
4. Utförande av scenarie
5. Resultatanalys (följt av systemjusteringar)

Med LoadRunner installerat, låt oss förstå stegen som är involverade i processen ett efter ett.

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 man börjar med LoadRunner-testning är det bäst att dokumentera vilka som kommer att delta i aktiviteten från varje team som är involverat under processen, vilket framgår av teamdiagrammet nedan.

• Projektledare: Nominera den projektledare som ska äga denna aktivitet och fungera som punktperson för eskalering.
• Funktionsexpert / Affärsanalytiker: Tillhandahåller användningsanalys av SUL och expertis om webbplatsens eller SUL:s affärsfunktionalitet.
• Expert på prestandatestning: Skapar automatiserade prestandatester och kör belastningsscenarier.
• Systemkrav Architect: Tillhandahåller en ritning för SUL.
• Webbutvecklare och SME: Underhåller webbplatsen, tillhandahåller övervakningsaspekter, utvecklar webbplatsen och åtgärdar buggar.
• Systemadministratör: Underhåller involverade servrar under hela testprojektet.

Beskriv applikationer 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 anger siffrorna antalet användare som är anslutna till applikationen (SUL) vid en given timme. Vi kan t.ex.tracdet maximala antalet användare som är anslutna till en affärsprocess vid vilken tidpunkt 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 en finansiell blufftracoch skickar in den för granskning.
• En annan användare 'B' godkänner 200 contracen dag skapad av användare 'A'
• En annan användare 'C' betalar cirka 150 contracen dag godkänd av användare 'B'

I den här situationen behöver användare B ha 200 contracts 'skapades' i systemet. Dessutom behöver användare C 150 contracts som "godkända" för att simulera en belastning på 150 användare.

Detta betyder implicit att du måste skapa minst 200 + 150 = 350 contracts.

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

Outline Monitorer

Spekulera i varje faktor som eventuellt kan påverka ett systems prestanda. Till exempel kan minskad hårdvara ha en potentiell inverkan på SUL-prestanda (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)
• Data flux (beräkna hur mycket data som flyttas till och från klient och server – beräkna sedan om ett nätverkskorts kapacitet är tillräcklig för att simulera X antal användare)

Steg 2) Skapa VuGen-skript

Nästa steg efter planeringen är att skapa VUser-skript och lägga till parametrisering, transaktioner och körtidsinställningar allt eftersom manuset mognar.

Steg 3) Skapa scenarier

Nästa steg är att skapa ditt laddningsscenario i kontrollenheten och välja mellan ett manuellt och ett målinriktat scenario.

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 resultera i att servern går under påkänning och beter sig onormalt. Detta är själva syftet med prestandatestning. Resultaten används sedan för detaljerad analys och identifiering av grundorsaker.

Steg 5) Resultatanalys (följt av systemjusteringar)

Under scenariokörning registrerar LoadRunner applikationens prestanda under olika belastningar. Statistiken från testkörningen sparas och detaljerad analys utförs. Analysverktyget (med namnet "HP Analysis" i de versioner som denna genomgång baserades på) genererar olika grafer som hjälper till att identifiera grundorsakerna bakom en försämrad 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

Vanliga frågor