LoadRunner testværktøj – komponenter og Architecture

Hvad er LoadRunner?

LoadRunner er et præstationstestværktøj, som blev banebrydende af Mercury i 1999. LoadRunner blev senere opkøbt af HPE i 2006. I 2016 blev LoadRunner opkøbt af MicroFocus.

LoadRunner understøtter forskellige udviklingsværktøjer, teknologier og kommunikationsprotokoller. Faktisk er dette det eneste værktøj på markedet, der understøtter et så stort antal protokoller at udføre Test af ydeevne. Præstationstestresultater produceret af LoadRunner-software bruges som et benchmark i forhold til andre værktøjer

LoadRunner video

Hvorfor LoadRunner?

LoadRunner er ikke kun banebrydende værktøj inden for Performance Testing, men det er stadig markedsleder inden for Performance Testing paradigmet. I en nylig vurdering har LoadRunner omkring 85% markedsandel i Performance Testing-industrien.

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 Stikkontakt. Der er ikke noget konkurrentværktøj på markedet, som kunne tilbyde så mange forskellige protokoller, der er tildelt et enkelt værktøj.

Hvad der er mere overbevisende at vælge LoadRunner i softwaretest er troværdigheden af ​​dette værktøj. LoadRunner-værktøjet har længe etableret et ry, som du ofte vil finde klienter krydsverificerer dine præstationsbenchmarks ved hjælp af LoadRunner. Du vil finde lettelse, hvis du allerede bruger LoadRunner til dine behov for præstationstest.

LoadRunner-softwaren er tæt integreret med andre HP-værktøjer som Unified Functional Test (QTP) og ALM (Application Lifecycle Management) med sætter dig i stand til at udføre dine ende-til-ende testprocesser.

LoadRunner arbejder ud fra princippet om at simulere virtuelle brugere på den pågældende applikation. Disse virtuelle brugere også kaldet VUsers, replikerer klientens anmodninger og forventer et tilsvarende svar på at sende en transaktion.

Hvorfor har du brug for præstationstest?

Det anslås, et tab på 4.4 milliarder i omsætning optages årligt på grund af dårlig webydelse.

I dagens Web 2.0-alder klikker brugere væk, hvis en hjemmeside ikke svarer inden for 8 sekunder. Forestil dig, at du venter i 5 sekunder, når du søger efter Google eller laver en venneanmodning på Facebook. Konsekvenserne af nedetid i ydeevnen er ofte mere ødelæggende end nogensinde forestillet. Vi har eksempler som dem, der for nylig ramte Bank of America Online Banking, Amazon Webtjenester, Intuit eller Blackberry.

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

Kun en 5-minutters nedetid på Google.com (19-aug-13) anslås at koste søgegiganten så meget som $545,000.

Det er skøn, at virksomheder mistede salg til en værdi af $1100 pr. sekund på grund af en nylig Amazon Webserviceafbrydelse.

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 får adgang til systemet ad gangen sammenlignet med tidligere

Hvad er LoadRunner Archilære?

Overordnet set er arkitekturen i HP LoadRunner kompleks, men alligevel let at forstå.

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

I en virkelig situation vil disse alle disse 5000 brugere ikke være på hjemmesiden, men i en anden sektion af hjemmesiderne. Hvordan kan vi simulere anderledes.

VUGen

VUGen eller virtuel bruger Generator er en IDE (Integrated Development Environment) eller en rig kodningseditor. VUGen bruges til at replikere System Under Load (SUL) adfærd. VUGen tilbyder en "optagelses"-funktion, som 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:

1. Surfer på produktsiden til Amazon.com
2. Betaling
3. Betaling Processing
4. Tjek Min Konto-side

controller

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

• 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.

Ved at tage en analogi fra vores eksempelcontroller tilføjes følgende parameter til VUGen Scriptet

1) 3500 brugere er Surfer på produktsiden til Amazon.com

2) 750 brugere er med Betaling

3) 500 brugere er udfører betalingsbehandling

4) 250 brugere er Kontrollerer KUN Min Konto-side efter 500 brugere har udført betalingsbehandling

Endnu mere komplekse scenarier er mulige

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

Agenter Machine/Load Generators/Injektorer

HP LoadRunner Controller er ansvarlig for at simulere tusindvis af VUsers – disse VUsers forbruger hardwareressourcer, f.eks. processor og hukommelse – og sætter derfor en grænse for den maskine, der simulerer dem. Desuden simulerer Controller disse VUsers fra den samme maskine (hvor Controller er bosat), og derfor er resultaterne muligvis ikke præcise. For at imødekomme denne bekymring er alle VUsers spredt på forskellige maskiner, kaldet Load 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.

At tage analogi fra vores Amazon Eksempel vil outputtet af denne komponent være

Analyse

Når først indlæsningsscenarier er blevet udført, vil rollen som "Analyse” komponenter 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 adgang til database, navngivet, output.mdb. "Analyse"-komponenten læser denne databasefil for at udføre forskellige typer analyser og genererer 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 kunne skabe en flaskehals. Lad os sige, at webserveren har en kapacitet på 1GBps, hvorimod datatrafikken overstiger denne kapacitet, hvilket får efterfølgende brugere til at lide. For at bestemme, at systemet imødekommer sådanne behov, skal Performance Engineer analysere applikationsadfærd med en unormal belastning. Nedenfor er en graf, som LoadRunner genererer for at fremkalde båndbredde.

Sådan laver du præstationstest

Køreplan for præstationstestning kan groft opdeles i 5 trin:

• Planlægning af belastningstest
• Opret VUGen Scripts
• Oprettelse af scenarier
• Udførelse af scenarier
• Resultatanalyse (efterfulgt af systemjustering)

Nu hvor du har installeret LoadRunner, lad os forstå de trin, der er involveret i processen én efter én.

Trin involveret i præstationstestprocessen

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 du kommer i gang med LoadRunner Testing, er det bedst at dokumentere, hvem der skal deltage i aktiviteten fra hvert involveret team under processen.

Projektleder:

Nominer den projektleder, der skal eje denne aktivitet og fungere som point person for eskalering.

Funktionsekspert/ forretningsanalytiker:

Giv brugsanalyse af SUL og leverer ekspertise om forretningsfunktionalitet af hjemmeside/SUL

Ekspert i præstationstest:

Opretter de automatiserede ydeevnetest og udfører belastningsscenarier

Systemkrav Architect:

Giver blueprint af SUL

Webudvikler og SMV:

• Vedligeholder hjemmeside og sørger for overvågningsaspekter
• Udvikler hjemmeside og retter fejl

Systemadministrator:

• Vedligeholder involverede servere gennem et testprojekt

Skitser applikationer og forretningsprocesser involveret:

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 nævner tallene antallet af brugere forbundet til applikationen (SUL) på en given time. Vi kan udtrække det maksimale antal brugere forbundet til en forretningsproces på et hvilket som helst tidspunkt på dagen, som beregnes i kolonnerne længst 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:

• En bruger 'A' opretter en finansiel kontrakt og sender den til gennemgang.
• En anden bruger 'B' godkender 200 kontrakter om dagen oprettet af bruger 'A'
• En anden bruger 'C' betaler omkring 150 kontrakter om dagen godkendt af bruger 'B'

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

Dette betyder implicit, at du skal oprette mindst 200+150= 350 kontrakter.

Godkend derefter 150 kontrakter til at fungere som testdata for bruger C – de resterende 200 kontrakter vil fungere som testdata for bruger B.

Outline skærme

Spekuler hver eneste faktor, som muligvis kan påvirke et systems ydeevne. For eksempel vil reduceret hardware have en potentiel indflydelse på SUL (System Under Load) ydeevne.

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)
• Dataflux (beregn hvor meget data der flyttes til og fra klient og server – beregn derefter om en kapacitet på NIC er tilstrækkelig til at simulere X antal brugere)

Trin 2) Opret VUGen Scripts

Næste skridt efter planlægning er at skabe VUser scripts.

Trin 3) Scenarieoprettelse

Næste trin er at oprette dit indlæsningsscenario

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 bliver stresset og opfører sig unormalt. Dette er selve formålet med præstationstestningen. De tegnede resultater bruges derefter til detaljeret analyse og identifikation af årsagen.

Trin 5) Resultatanalyse (efterfulgt af systemjustering)

Under udførelse af scenarier registrerer LoadRunner applikationens ydeevne under forskellige belastninger. Statistikken fra testudførelsen gemmes, og detaljeanalysen udføres. 'HP Analysis'-værktøjet genererer forskellige grafer, som hjælper med at identificere de grundlæggende årsager bag en forsinkelse i systemydelsen 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