LoadRunner testværktøj: ArchiTekturdiagram og komponenter

Hvad er LoadRunner?

LoadRunner er en Test af ydeevne værktøj, som blev udviklet af Mercury Interactive i 1999. LoadRunner blev senere opkøbt af HP i 2006, og HP's softwareforretning fusionerede med Micro Focus i en aftale, der blev annonceret i 2016 og afsluttet i 2017.

Mærkebemærkning: OpenText afsluttede opkøbet af Micro Focus i januar 2023Værktøjet sælges ikke længere som HP eller Micro Focus LoadRunnerLoadRunner Professional er nu OpenText Professionel ydeevneteknik, LoadRunner Enterprise er OpenText Enterprise Performance Engineering, og LoadRunner Cloud er OpenText Core Performance Engineering. Komponentnavnene nedenfor — VuGen, Controller, load generators og Analysis — er uændrede.

LoadRunner understøtter forskellige udviklingsværktøjer, teknologier og kommunikationsprotokoller. Det indeholder et af de bredeste protokolbiblioteker på markedet til udførelse af performancetestning. Performancetestresultater produceret af LoadRunner-software bruges som benchmark i forhold til andre værktøjer.

LoadRunner video

Se videoen nedenfor for en hurtig introduktion til LoadRunner, før du går igennem komponenterne.

Hvorfor LoadRunner?

LoadRunner er ikke kun et banebrydende værktøj inden for performancetestning, det er fortsat en af ​​markedslederne inden for performancetestningsparadigmet og er stadig det referencepunkt, som mange virksomheder sammenligner sig med.

Protokoldækningen er den klareste grund til, at teams vælger den, som komponentkortet nedenfor viser.

LoadRunner-værktøjet understøtter stort set RIA (Rich Internet Applications), Web 2.0 (HTTP/HTML, Ajax, Flex og Silverlight osv.), Mobil, SAP, Oracle, FRK SQL Server, Citrix, RTE, Mail og frem for alt, Windows Socket. Få konkurrerende værktøjer tilbyder så bred en vifte af protokoller samlet i et enkelt værktøj, som protokollisten nedenfor illustrerer.

Det, der er mere overbevisende ved at vælge LoadRunner til softwaretest, er værktøjets troværdighed. LoadRunner har længe etableret et ry, da du ofte vil finde klienter, der krydsverificerer dine performance benchmarks ved hjælp af LoadRunner. Du vil finde lindring, hvis du allerede bruger LoadRunner til dine performance testbehov.

LoadRunner-softwaren er tæt integreret med de to værktøjer i samme suite — Unified Functional Testing (tidligere QTP, nu solgt som OpenText Funktionel testning) og ALM (Application Lifecycle Management, nu OpenText ALM/Kvalitetscenter) — som giver dig mulighed for at udføre dine komplette testprocesser.

LoadRunner fungerer ud fra princippet om at simulere virtuelle brugere i den pågældende applikation. Disse virtuelle brugere, også kaldet V-brugere, replikerer klientens anmodninger og forventer et tilsvarende svar for at gennemføre en transaktion.

Hvorfor har du brug for præstationstest?

Brancheestimaterne nedenfor er bredt citeret og stammer fra begyndelsen af ​​2010'erne, men det mønster, de beskriver, har ikke ændret sig: langsomme sider koster penge.

Der registreres et anslået tab på 4.4 milliarder dollars i omsætning årligt på grund af dårlig webpræstation.

I dagens Web 2.0-tidsalder klikker brugerne væk, hvis en hjemmeside ikke svarer inden for 8 sekunder. Forestil dig selv vente i 5 sekunder, når du søger efter Google eller at lave en venneanmodning på Facebook. Konsekvenserne af nedetid er ofte mere ødelæggende end nogensinde forestillet. Der er velkendte eksempler som dem, der ramte Bank of America Online Banking, Amazon Webtjenester, Intuit og Blackberry.

Ifølge Dun & Bradstreet oplever 59 % af Fortune 500-virksomhederne anslået 1.6 timers nedetid hver uge. I betragtning af at den gennemsnitlige Fortune 500-virksomhed med mindst 10,000 ansatte betaler 56 dollars i timen, ville arbejdskraftdelen af ​​nedetidsomkostningerne for en sådan organisation være 896,000 dollars om ugen, hvilket svarer til mere end 46 millioner dollars om året.

Kun 5 minutters nedetid Google.com i august 2013 anslås at have kostet søgegiganten så meget som $545,000.

Det anslås, at virksomheder har mistet et salg på 1,100 dollars pr. sekund i løbet af de seneste år. Amazon Nedbrud på webtjenester.

Når et softwaresystem implementeres af en organisation, kan det støde på mange scenarier, der muligvis resulterer i ydelsesforsinkelse. En række faktorer forårsager decelererende ydeevne, nogle få eksempler kan omfatte:

• Øget antal poster til stede i databasen
• Øget antal samtidige anmodninger til systemet
• Et større antal brugere, der tilgår systemet ad gangen, sammenlignet med tidligere

Det er dog ikke alle ansøgninger, der er en kandidat. Load Testing er rettet mod klient-server, flerbrugersystemer, så et enkeltbruger-skrivebordsværktøj som det nedenfor er ikke værd at teste for ydeevne.

Hvad er LoadRunner Archilære?

Generelt set er arkitekturen i LoadRunner kompleks, men let at forstå. LoadRunner-arkitekturdiagrammet nedenfor viser, hvordan de fire komponenter arbejder sammen.

Antag, at du har fået til opgave at kontrollere ydeevnen af Amazon.com for 5000 brugere.

I en virkelig situation vil alle disse 5000 brugere ikke sidde på hjemmesiden – de vil være spredt ud over forskellige sektioner af hjemmesiden. Så hvordan simulerer vi den forskel?

VuGen

VuGen eller virtuel bruger Generator er et IDE (Integrated Development Environment) eller en rig kodeeditor. VuGen bruges til at replikere System Under Load (SUL) adfærd. VuGen tilbyder en "optagelsesfunktion", der optager kommunikation til og fra klient og server i form af et kodet script – også kaldet VUser-script.

Så i betragtning af ovenstående eksempel kan VuGen optage for at simulere følgende forretningsprocesser:

• Surfer på produktsiden til Amazon.com
• Betaling
• Betaling Processing
• Tjek Min Konto-side

Når scriptet afspilles rent, skal dynamiske serverværdier normalt registreres med korrelation før det kan skaleres op.

controller

Når et VUser-script er færdiggjort, controller er en af ​​de vigtigste LoadRunner-komponenter, som styrer belastningssimuleringen ved f.eks. at administrere:

• Hvor mange VUser der skal simuleres mod hver forretningsproces eller VUser Group
• VUsers adfærd (rampe op, rampe ned, samtidig eller samtidig karakter osv.)
• Belastningstype scenarie, f.eks. Real Life eller Målorienteret eller verificerende SLA
• Hvilke injektorer skal bruges, hvor mange VUser mod hver injektor
• Saml resultater med jævne mellemrum
• IP-spoofing
• Fejl ved rapportering
• Transaktionsrapportering mv.

Med en analogi fra vores eksempel vil controlleren tilføje følgende parametre til VuGen-scriptet:

1. 3500 brugere surfer på produktsiden for Amazon.com
2. 750 brugere er i kassen
3. 500 brugere udfører betalingsbehandling
4. 250 brugere tjekker kun Min Konto-siden efter at 500 brugere har gennemført betalingsbehandlingen.

Endnu mere komplekse scenarier er mulige:

• Start 5 VUsers hvert 2. sekund indtil en belastning på 3500 VUsers (surfing Amazon produktside) er opnået.
• Gentag i 30 minutter
• Suspend iteration for 25 VUsers
• Genstart 20 V-brugere
• Start 2 brugere (i Checkout, Betalingsbehandling, Mine konti-side) hvert sekund.
• 2500 VUsers vil blive genereret ved Machine A
• 2500 VUsers vil blive genereret på Machine B

Agenter Machine/Load Generators/Injektorer

LoadRunner-controlleren er ansvarlig for at simulere tusindvis af VUsere – disse VUsere forbruger hardwareressourcer, f.eks. processor og hukommelse – og sætter dermed en grænse for den maskine, der simulerer dem. Derudover simulerer controlleren disse VUsere fra den samme maskine (hvor controlleren befinder sig), og derfor er resultaterne muligvis ikke præcise. For at imødegå dette problem er alle VUsere spredt på tværs af forskellige maskiner, kaldet LoadRunner. Generators eller Load Injectors.

Som en generel praksis er controlleren placeret på en anden maskine, og belastningen simuleres fra andre maskiner. Afhængigt af protokollen for VUser-scripts og maskinspecifikationer kan der være behov for et antal Load Injectors til fuld simulering. For eksempel vil VUsers til et HTTP-script kræve 2-4MB pr. VUser til simulering, og derfor kræves 4 maskiner med hver 4 GB RAM for at simulere en belastning på 10,000 VUser.

Tager vi analogien fra vores Amazon For eksempel er outputtet fra denne komponent de 5000 VUsere fordelt på to injektorer: 2500 VUsere genereret på Maskine A og 2500 på Maskine B.

Analyse

Når belastningsscenarier er udført, rollen for Analyse komponenten af ​​LoadRunner kommer ind.

Under udførelsen opretter Controller et dump af resultater i rå form og indeholder information som, hvilken version af LoadRunner der oprettede dette resultatdump, og hvad var konfigurationer.

Alle fejl og undtagelser er logget på en Microsoft Access-databasen med navnet output.mdb. Analysekomponenten læser denne databasefil for at udføre forskellige typer analyser og generere grafer.

Disse grafer viser forskellige tendenser for at forstå begrundelsen bag fejl og fejl under belastning; hjælper således med at finde ud af, om optimering er påkrævet i SUL, Server (f.eks. JBoss, Oracle) eller infrastruktur.

Nedenfor er et eksempel, hvor båndbredde kan skabe en flaskehals. Lad os sige, at webserveren har en kapacitet på 1 GBps, mens datatrafikken overstiger denne kapacitet, hvilket forårsager problemer for efterfølgende brugere. For at afgøre, om systemet opfylder disse behov, skal Performance Engineer analysere applikationens adfærd med en unormal belastning. Nedenfor er en graf, som LoadRunner genererer for at finde båndbredde.

Sådan laver du præstationstest

Køreplanen for ydeevnetestning kan groft sagt opdeles i 5 trin, som er opsummeret i køreplanen nedenfor:

1. Planlægning af belastningstest
2. Opret VuGen-scripts
3. Oprettelse af scenarier
4. Udførelse af scenarier
5. Resultatanalyse (efterfulgt af systemjustering)

Når LoadRunner er installeret, lad os forstå de involverede trin i processen et efter et.

Trin 1) Planlægning af belastningstesten

Planlægning af præstationstest er forskellig fra planlægning af en SIT (System Integration Testing) or UAT (User Acceptance Testing). Planlægning kan yderligere opdeles i små faser som beskrevet nedenfor:

Saml dit team

Når man starter med LoadRunner-testning, er det bedst at dokumentere, hvem der skal deltage i aktiviteten fra hvert team, der er involveret i processen, som vist i teamdiagrammet nedenfor.

• Projektleder: Nominer den projektleder, der skal eje denne aktivitet og fungere som point person for eskalering.
• Funktionsekspert / Forretningsanalytiker: Tilbyder brugsanalyse af SUL'en og ekspertise om webstedets eller SUL'ens forretningsfunktionalitet.
• Ekspert i præstationstest: Opretter de automatiserede ydeevnetests og udfører belastningsscenarier.
• Systemkrav Architect: Giver en plan for SUL.
• Webudvikler og SMV: Vedligeholder hjemmesiden, sørger for overvågning, udvikler hjemmesiden og retter fejl.
• Systemadministrator: Vedligeholder involverede servere gennem hele et testprojekt.

Oversigt over applikationer og involverede forretningsprocesser

Vellykket Load Testing kræver, at du planlægger at udføre en bestemt forretningsproces. En forretningsproces består af klart definerede trin i overensstemmelse med ønskede forretningstransaktioner - for at nå dine belastningstestmål.

En krav-metrik kan udarbejdes for at fremkalde brugerbelastning på systemet. Nedenfor er et eksempel på et fremmødesystem i en virksomhed:

I ovenstående eksempel angiver tallene antallet af brugere, der er forbundet til applikationen (SUL) på et givet tidspunkt. Vi kan f.eks.tracdet maksimale antal brugere, der er forbundet til en forretningsproces på et hvilket som helst tidspunkt af dagen, hvilket beregnes i kolonnerne yderst til højre.

På samme måde kan vi konkludere det samlede antal brugere, der er tilsluttet applikationen (SUL) på et hvilket som helst tidspunkt af dagen. Dette beregnes i sidste række.

Ovenstående 2 fakta tilsammen giver os det samlede antal brugere, som vi skal teste systemet for ydeevne med.

Definer testdatastyringsprocedurer

Statistikker og observationer fra Performance Testing er i høj grad påvirket af adskillige faktorer som beskrevet tidligere. Det er af afgørende betydning at forberede testdata til præstationstestning. Nogle gange bruger en bestemt forretningsproces et datasæt og producerer et andet datasæt. Tag nedenstående eksempel:

• Brugeren 'A' opretter en økonomisk svindeltract og indsender den til gennemgang.
• En anden bruger 'B' godkender 200 contracen dag oprettet af bruger 'A'
• En anden bruger 'C' betaler omkring 150 contracts en dag godkendt af bruger 'B'

I denne situation skal bruger B have 200 contracts 'oprettet' i systemet. Desuden har bruger C brug for 150 contracts som "godkendt" for at simulere en belastning på 150 brugere.

Det betyder implicit, at du skal oprette mindst 200 + 150 = 350 contracts.

Derefter godkendes 150 contracts til at fungere som testdata for bruger C – de resterende 200 contracts vil fungere som testdata for bruger B.

Outline skærme

Spekulér i hver eneste faktor, der muligvis kan påvirke et systems ydeevne. For eksempel vil reduceret hardware have en potentiel indvirkning på SUL-ydeevnen (System Under Load).

Indregn alle faktorer, og opsæt skærme, så du kan måle dem. Her er et par eksempler:

• Processor (til webserver, applikationsserver, databaseserver og injektorer)
• RAM (til webserver, applikationsserver, databaseserver og injektorer)
• Web-/appserver (for eksempel IIS, JBoss, Jaguar Server, Tomcat osv.)
• DB Server (PGA- og SGA-størrelse i tilfælde af Oracle og MSSQL-server, SP'er osv.)
• Udnyttelse af netværksbåndbredde
• Intern og ekstern NIC i tilfælde af clustering
• Load Balancer (og at den fordeler belastningen jævnt på alle noder af klynger)
• Data flux (beregn hvor meget data der flyttes til og fra klient og server – beregn derefter om en NIC-kapacitet er tilstrækkelig til at simulere X antal brugere)

Trin 2) Opret VuGen-scripts

Næste trin efter planlægning er at oprette VUser-scripts og tilføje parametrisering, transaktioner og runtime-indstillinger efterhånden som manuskriptet modnes.

Trin 3) Scenarieoprettelse

Næste trin er at oprette dit indlæsningsscenarie i controlleren, hvor du vælger mellem et manuelt og et målorienteret scenarie.

Trin 4) Scenarieudførelse

Scenariekørsel er, hvor du emulerer brugerbelastning på serveren ved at instruere flere VUsers til at udføre opgaver samtidigt.

Du kan indstille niveauet for en belastning ved at øge og mindske antallet af VUser, der udfører opgaver på samme tid.

Denne udførelse kan resultere i, at serveren går under stress og opfører sig unormalt. Dette er selve formålet med præstationstestning. De uddragne resultater bruges derefter til detaljeret analyse og identifikation af de grundlæggende årsager.

Trin 5) Resultatanalyse (efterfulgt af systemjustering)

Under scenarieudførelsen registrerer LoadRunner applikationens ydeevne under forskellige belastninger. Statistikkerne fra testudførelsen gemmes, og der udføres detaljerede analyser. Analyseværktøjet (mærket 'HP Analysis' i de versioner, som denne gennemgang er skrevet i forhold til) genererer forskellige grafer, der hjælper med at identificere de grundlæggende årsager til en forsinkelse i systemydeevnen samt en systemfejl.

Nogle af de opnåede grafer inkluderer:

• Tid til den første buffer
• Transaktionens responstid
• Gennemsnitlig transaktionssvartid
• Hits per sekund
• Windows Ressourcer
• Fejlstatistik
• Transaktionsoversigt

Ofte Stillede Spørgsmål