Hvad er HP LoadRunner testværktøj? Arkitektur, komponenter

Hvad er LoadRunner?

LoadRunner er et Performance Testing-værktøj, der blev banebrydende for Mercury i 1999. LoadRunner blev senere erhvervet af HPE i 2006. I 2016 blev LoadRunner erhvervet 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 til at udføre Performance Testing. Ydelsestestresultater produceret af LoadRunner-software bruges som et benchmark mod andre værktøjer

I denne vejledning lærer du-

• Hvorfor LoadRunner?
• Hvorfor har du brug for præstationstest?
• Hvad er LoadRunner Architecture?
• Køreplanstestkørsel: Detaljerede trin
• FAQ

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.), Mobile, SAP, Oracle, MS SQL Server, Citrix, RTE, Mail og frem for alt Windows Socket. Der er ikke noget konkurrentværktøj på markedet, der kan tilbyde så mange forskellige protokoller, der findes i 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, da ofte finder du kunder, der krydser verificerer dine præstationsbenchmarks ved hjælp af LoadRunner. Du finder lindring, hvis du allerede bruger LoadRunner til dine præstationsbehov.

LoadRunner-softwaren er tæt integreret med andre HP-værktøjer som Unified Functional Test (QTP) og ALM (Application Lifecycle Management), der giver dig mulighed for at udføre test-til-ende-slut-processen.

LoadRunner arbejder på en princip, der simulerer virtuelle brugere på emneansøgningen. Disse virtuelle brugere kaldes også som VU-brugere, replikerer klientens anmodninger og forventer et tilsvarende svar på at gennemføre en transaktion.

Hvorfor har du brug for præstationstest?

Et anslået tab på 4,4 milliarder i omsætning registreres årligt på grund af dårlig webydelse.

I nutidens alder af Web 2.0 klikker brugerne væk, hvis et websted ikke reagerer inden for 8 sekunder. Forestil dig selv at vente i 5 sekunder, når du søger efter Google eller fremsætter en venneanmodning på Facebook. Konsekvenserne af performance downtime er ofte mere ødelæggende end nogensinde forestillet sig. Vi har eksempler som dem, der for nylig ramte Bank of America Online Banking, Amazon Web Services, Intuit eller Blackberry.

Ifølge Dunn & Bradstreet oplever 59% af Fortune 500-virksomhederne anslået 1,6 timers nedetid hver uge. I betragtning af det gennemsnitlige Fortune 500-firma med et minimum på 10.000 ansatte betaler $ 56 i timen, vil arbejdsdelen af ​​nedetidsomkostninger for en sådan organisation være $ 896.000 ugentligt, hvilket betyder mere end $ 46 millioner om året.

Kun 5 minutters nedetid på Google.com (19. august-13) anslås at koste søgegiganten så meget som $ 545.000.

Det anslås, at virksomheder mistede et salg til en værdi af $ 1100 pr. Sekund på grund af en nylig Amazon Web Service Outage.

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

• Øget antal poster, der findes i databasen
• Øget antal samtidige anmodninger til systemet
• et større antal brugere, der har adgang til systemet ad gangen sammenlignet med fortiden

Hvad er LoadRunner Architecture?

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

Antag, at du har til opgave at kontrollere præstationen på Amazon.com for 5000 brugere

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

VUGen:

VUGen eller Virtual User Generator er en IDE (Integrated Development Environment) eller en rig kodningseditor. VUGen bruges til at replikere SUL-adfærd (System Under Load). VUGen leverer en "optagefunktion", der registrerer 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. Surfing af produktsiden på Amazon.com
2. Kasse
3. Betalingsbehandling
4. Kontrol af Min konto-side

Controller

Når et VUser-script er afsluttet, er Controller en af ​​de vigtigste LoadRunner-komponenter, der styrer Load-simuleringen ved at styre for eksempel:

• Hvor mange VU-brugere der skal simulere mod hver forretningsproces eller VUser-gruppe
• VU-brugeres adfærd (rampe op, rampe ned, samtidig eller samtidig natur osv.)
• Load-scenarie, f.eks. Real Life eller målorienteret eller verificerende SLA
• Hvilke injektorer der skal bruges, hvor mange VU'er mod hver injektor
• Saml resultater med jævne mellemrum
• IP-spoofing
• Fejl rapportering
• Transaktionsrapportering mv.

At tage en analogi fra vores eksempelcontroller tilføjer følgende parameter til VUGen-scriptet

1) 3500 brugere surfer på produktsiden på Amazon.com

2) 750 brugere er i kassen

3) 500 brugere udfører betalingsbehandling

4) 250 brugere kontrollerer KUN MyAccount-siden, efter at 500 brugere har foretaget betalingsbehandling

Endnu mere komplekse scenarier er mulige

1. Start 5 VU-brugere hvert 2. sekund, indtil en belastning på 3500 VU-brugere (surfing på Amazon-produktside) er opnået.
2. Iterer i 30 minutter
3. Afbryd iteration for 25 VU-brugere
4. Genstart 20 VUSere
5. Start 2 brugere (i Checkout, Betalingsbehandling, MyAccounts-siden) hvert sekund.
6. 2500 VU-brugere genereres ved maskine A
7. 2500 VU-brugere genereres på maskine B.

Agenter Maskine / Belastningsgeneratorer / Injektorer

HP LoadRunner Controller er ansvarlig for at simulere tusindvis af VU-brugere - disse VU-brugere bruger hardware-ressourcer for eksempel processor og hukommelse - og dermed lægger en grænse for maskinen, der simulerer dem. Desuden simulerer Controller disse VU'er fra den samme maskine (hvor Controller er bosiddende) og derfor er resultaterne muligvis ikke præcise. For at imødegå denne bekymring er alle køretøjsbrugere spredt på forskellige maskiner, kaldet belastningsgeneratorer eller belastningsinjektorer.

Som almindelig praksis er Controller på en anden maskine, og belastning simuleres fra andre maskiner. Afhængig af protokollen med VUser-scripts og maskinspecifikationer, kan der kræves et antal belastningsinjektorer for fuld simulering. For eksempel vil VU-brugere til et HTTP-script kræve 2-4 MB pr. VU-bruger til simulering, og derfor kræves der 4 maskiner med 4 GB RAM hver for at simulere en belastning på 10.000 VU-brugere.

Hvis vi tager analogi fra vores Amazon-eksempel, vil output af denne komponent være

Analyse:

Når belastningsscenarier er udført, kommer rollen som " Analyse " -komponenter i LoadRunner 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 der var konfigurationer.

Alle fejl og undtagelser er logget i en Microsoft-adgangsdatabase med navnet output.mdb. Komponenten "Analyse" læser denne databasefil for at udføre forskellige typer analyser og genererer grafer.

Disse grafer viser forskellige tendenser for at forstå ræsonnementet bag fejl og svigt under belastning; hjælper således med at finde ud af, om der kræves optimering 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 1 GBps kapacitet, mens datatrafikken overstiger denne kapacitet, hvilket får efterfølgende brugere til at lide. For at bestemme, at systemet opfylder 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.

Køreplanstestkørsel: Detaljerede trin

Køreplan for testning af ydeevne kan stort set opdeles i 5 trin:

• Planlægning af belastningstest
• Opret VUGen-scripts
• Scenario oprettelse
• Scenarioudførelse
• Resultatanalyse (efterfulgt af systemtilpasning)

Nu hvor du har installeret LoadRunner, lad os forstå trinene involveret i processen en efter en.

Trin involveret i ydeevne testning proces

Planlægning af belastningstesten

Planlægning for præstationstest er forskellig fra planlægning af en SIT (System Integration Testing) eller 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 deltager i aktiviteten fra hvert involveret hold under processen.

Projektleder:

Nominer projektlederen, der vil eje denne aktivitet og tjene som punktperson til optrapning.

Funktionsekspert / forretningsanalytiker:

Giv brugsanalyse af SUL & giver ekspertise inden for forretningsfunktionalitet på webstedet / SUL

Ekspert til test af ydelse:

Opretter automatiserede præstationstest og udfører belastningsscenarier

Systemarkitekt:

Giver plan for SUL

Webudvikler og SMV:

• Vedligeholder webstedet og leverer overvågningsaspekter
• Udvikler websted og retter fejl

Systemadministrator:

• Vedligeholder involverede servere gennem et testprojekt

Omfattede applikationer og involverede forretningsprocesser:

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

En kravsmåling kan udarbejdes for at fremkalde brugerbelastning på systemet. Nedenfor er et eksempel på et fremmødningssystem i en virksomhed:

I eksemplet ovenfor nævner tallene antallet af brugere, der er forbundet til applikationen (SUL) i en given time. Vi kan udtrække det maksimale antal brugere, der er tilsluttet en forretningsproces på et hvilket som helst tidspunkt af dagen, der beregnes i de yderste kolonner.

På samme måde kan vi konkludere det samlede antal brugere, der er forbundet til applikationen (SUL) på en hvilken som helst time på dagen. Dette beregnes i sidste række.

Ovenstående 2 fakta tilsammen giver os det samlede antal brugere, som vi har brug for til at teste systemet for ydeevne.

Definer procedurer til styring af testdata

Statistik og observationer hentet 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æstationstest. 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 cirka 150 kontrakter om dagen godkendt af bruger 'B'

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

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

Derefter skal du godkende 150 kontrakter, der fungerer som testdata for bruger C - de resterende 200 kontrakter fungerer som testdata for bruger B.

Konturskærme

Spekulere på hver eneste faktor, der muligvis kan påvirke et systems ydeevne. For eksempel vil have reduceret hardware have potentiel indvirkning på SUL (System Under Load) ydeevne.

Anvend alle faktorer, og opret skærme, så du kan måle dem. Her er få eksempler:

• Processor (til webserver, applikationsserver, databaseserver og injektorer)
• RAM (til webserver, applikationsserver, databaseserver og injektorer)
• Web / app-server (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.)
• Brug af netværksbåndbredde
• Intern og ekstern NIC i tilfælde af klyngedannelse
• Load Balancer (og at den fordeler belastningen jævnt på alle noder i klynger)
• Data flux (beregne hvor meget data flytter til og fra klient og server - beregn derefter, om en kapacitet på NIC er tilstrækkelig til at simulere X antal brugere)

Opret VUGen-scripts

Næste trin efter planlægning er at oprette VUser-scripts.

Scenario oprettelse

Næste trin er at oprette dit Load Scenario

Scenarioudførelse

Scenarioudførelse er, hvor du efterligner brugerbelastning på serveren ved at instruere flere VU-brugere om at udføre opgaver samtidigt.

Du kan indstille belastningsniveauet ved at øge og formindske antallet af VU-brugere, 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 performance Testing. Resultaterne, der er trukket, bruges derefter til detaljeret analyse og identifikation af grundårsager.

Resultatanalyse (efterfulgt af systemtilpasning)

Under scenariekørsel registrerer LoadRunner programmets ydeevne under forskellige belastninger. Statistikkerne fra testudførelsen gemmes, og der foretages detaljeret analyse. Værktøjet 'HP-analyse' genererer forskellige grafer, der hjælper med at identificere de grundlæggende årsager til et forsinket systemydelse samt en systemfejl.

Nogle af de opnåede grafer inkluderer:

• Tid til den første buffer
• Transaktionssvarstid
• Gennemsnitlig svartid på transaktion
• Hits pr. Sekund
• Windows-ressourcer
• Fejlstatistik
• Transaktionsoversigt

FAQ

Hvilke applikationer skal vi præstere?

Ydelsestest udføres altid kun for klientserverbaserede systemer. Dette betyder, at ethvert program, der ikke er en klientserverbaseret arkitektur, ikke skal kræve Performance Testing.

For eksempel er Microsoft Calculator hverken klient-serverbaseret, eller den kører flere brugere; det er derfor ikke en kandidat til Performance Testing.

Hvad er forskellen mellem Performance Testing & Performance Engineering

Det er af betydning at forstå forskellen mellem Performance Testing og Performance Engineering. En forståelse deles nedenfor:

Performance Testing er en disciplin, der beskæftiger sig med test og rapportering af den aktuelle ydeevne for en softwareapplikation under forskellige parametre.

Performance engineering er den proces, hvormed software testes og tunes med det formål at realisere den krævede ydeevne. Denne proces har til formål at optimere det vigtigste egenskab ved applikationsydelse, dvs. brugeroplevelse.

Historisk har testning og tuning været tydeligt adskilte og ofte konkurrerende områder. I de sidste par år har imidlertid flere lommer af testere og udviklere samarbejdet uafhængigt for at oprette tuningteams. Fordi disse hold har mødt en betydelig succes, har begrebet kobling af ydelsestest med performance tuning fanget, og nu kalder vi det performance engineering.