Hva er HP LoadRunner Testing Tool? Arkitektur, komponenter

Hva er LoadRunner?

LoadRunner er et Performance Testing-verktøy som ble banebrytende av Mercury i 1999. LoadRunner ble senere kjøpt opp av HPE i 2006. I 2016 ble LoadRunner kjøpt opp av MicroFocus.

LoadRunner støtter ulike utviklingsverktøy, teknologier og kommunikasjonsprotokoller. Dette er faktisk det eneste verktøyet i markedet som støtter et så stort antall protokoller for å gjennomføre ytelsestesting. Ytelsestestresultater produsert av LoadRunner-programvaren brukes som en målestokk mot andre verktøy

I denne veiledningen vil du lære-

• Hvorfor LoadRunner?
• Hvorfor trenger du ytelsestesting?
• Hva er LoadRunner Architecture?
• Kjøreplan for ytelsestesting: detaljerte trinn
• FAQ

Hvorfor LoadRunner?

LoadRunner er ikke bare banebrytende verktøy i Performance Testing, men det er fortsatt markedsleder i Performance Testing-paradigmet. I en nylig vurdering har LoadRunner omtrent 85% markedsandel i Performance Testing-industrien.

LoadRunner-verktøyet støtter stort sett RIA (Rich Internet Applications), Web 2.0 (HTTP / HTML, Ajax, Flex og Silverlight etc.), Mobile, SAP, Oracle, MS SQL Server, Citrix, RTE, Mail og fremfor alt, Windows Socket. Det er ikke noe konkurrerende verktøy i markedet som kan tilby et så bredt utvalg av protokoller som er samlet i et enkelt verktøy.

Det som er mer overbevisende å velge LoadRunner i programvaretesting er troverdigheten til dette verktøyet. LoadRunner-verktøyet har lenge etablert et rykte, så ofte vil du finne kunder som kryssverifiserer ytelsesverdiene dine ved hjelp av LoadRunner. Du vil finne lettelse hvis du allerede bruker LoadRunner for dine ytelsestestbehov.

LoadRunner-programvaren er tett integrert med andre HP-verktøy som Unified Functional Test (QTP) og ALM (Application Lifecycle Management), slik at du kan utføre test-til-slutt-prosesser.

LoadRunner jobber med en rektor for å simulere virtuelle brukere på emneapplikasjonen. Disse virtuelle brukerne betegnes også som brukerbrukere, replikerer klientens forespørsler og forventer et tilsvarende svar på å sende en transaksjon.

Hvorfor trenger du ytelsestesting?

Anslaglig tap på 4,4 milliarder i inntekter registreres årlig på grunn av dårlig nettytelse.

I dagens tid av Web 2.0, klikker brukerne bort hvis et nettsted ikke svarer innen 8 sekunder. Tenk deg at du venter i 5 sekunder når du søker etter Google eller ber om en venneforespørsel på Facebook. Konsekvensene av nedetid for ytelse er ofte mer ødeleggende enn noen gang forestilt seg. Vi har eksempler som de som nylig traff Bank of America Online Banking, Amazon Web Services, Intuit eller Blackberry.

Ifølge Dunn & Bradstreet opplever 59% av Fortune 500-selskapene anslagsvis 1,6 timers nedetid hver uke. Tatt i betraktning det gjennomsnittlige Fortune 500-selskapet med minst 10 000 ansatte betaler $ 56 per time, vil arbeidsdelen av nedetidskostnadene for en slik organisasjon være $ 896 000 ukentlig, og oversettes til mer enn $ 46 millioner per år.

Bare en 5-minutters nedetid på Google.com (19. august-13) anslås å koste søkegiganten så mye som $ 545.000.

Det er anslått at selskaper mistet salg verdt $ 1100 per sekund på grunn av et nylig Amazon Web Service Outage.

Når et programvaresystem distribueres av en organisasjon, kan det oppstå mange scenarier som muligens kan resultere i ytelsesforsinkelse. En rekke faktorer forårsaker redusert ytelse, noen få eksempler kan omfatte:

• Økt antall poster i databasen
• Økt antall samtidige forespørsler til systemet
• et større antall brukere som får tilgang til systemet om gangen sammenlignet med fortiden

Hva er LoadRunner Architecture?

Generelt sett er arkitekturen til HP LoadRunner kompleks, men likevel lett å forstå.

Anta at du har fått i oppdrag å sjekke ytelsen til Amazon.com for 5000 brukere

I en reell situasjon vil ikke alle disse 5000 brukerne være på hjemmesiden, men i en annen del av nettstedene. Hvordan kan vi simulere annerledes

VUGen:

VUGen eller Virtual User Generator er en IDE (Integrated Development Environment) eller en rik kodingseditor. VUGen brukes til å replikere SUL-oppførsel (System Under Load). VUGen tilbyr en "innspilling" -funksjon som registrerer kommunikasjon til og fra klient og server i form av et kodet skript - også kalt VUser-skript.

Så med tanke på eksemplet ovenfor, kan VUGen registrere for å simulere følgende forretningsprosesser:

1. Surfe på produktsiden på Amazon.com
2. Sjekk ut
3. Betalings prosessering
4. Sjekker Min konto-side

Kontroller

Når et VUser-skript er ferdig, er Controller en av de viktigste LoadRunner-komponentene som styrer Load-simuleringen ved å administrere, for eksempel:

• Hvor mange VU-brukere å simulere mot hver forretningsprosess eller VUser-gruppe
• VUsers atferd (rampe opp, rampe ned, samtidig eller samtidig natur osv.)
• Lastets scenario, f.eks. Real Life eller Goal Oriented eller verifiserende SLA
• Hvilke injektorer du skal bruke, hvor mange enheter mot hver injektor
• Sorter resultatene med jevne mellomrom
• IP Spoofing
• Feilrapportering
• Transaksjonsrapportering etc.

Å ta en analogi fra eksempelkontrolleren vår, vil legge til følgende parameter i VUGen-skriptet

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

2) 750 brukere er i kassen

3) 500 brukere utfører betalingsbehandling

4) 250 brukere sjekker KUN MyAccount-siden etter at 500 brukere har utført betalingsbehandling

Enda mer komplekse scenarier er mulige

1. Start 5 VU-brukere hvert 2. sekund til en belastning på 3500 VU-brukere (surfing på Amazon-produktsiden) er oppnådd.
2. Iterer i 30 minutter
3. Avbryt iterasjon for 25 brukere
4. Start 20 VUSere på nytt
5. Start 2 brukere (i kassa, betalingsbehandling, MyAccounts-side) hvert sekund.
6. 2500 VUsers vil bli generert på Machine A.
7. 2500 VUsers vil bli generert på Machine B.

Agenter Maskin / Lastgeneratorer / Injektorer

HP LoadRunner Controller er ansvarlig for å simulere tusenvis av brukere - disse brukerne bruker maskinvare ressurser for eksempel prosessor og minne - og setter dermed en grense for maskinen som simulerer dem. Dessuten simulerer Controller disse VU-ene fra samme maskin (der Controller befinner seg), og resultatene er derfor kanskje ikke presise. For å imøtekomme denne bekymringen er alle kjøretøyer spredt over forskjellige maskiner, kalt Load Generators eller Load Injectors.

Som en generell praksis bor Controller på en annen maskin, og belastning simuleres fra andre maskiner. Avhengig av protokollen til VUser-skript og maskinspesifikasjoner, kan det være nødvendig med et antall belastningsinjektorer for full simulering. For eksempel vil VU-brukere for et HTTP-skript kreve 2-4 MB per VU-bruker for simulering, og derfor vil 4 maskiner med 4 GB RAM hver være påkrevd for å simulere en belastning på 10 000 VU-brukere.

Tar vi analogi fra vårt Amazon-eksempel, vil utdataene til denne komponenten være

Analyse:

Når belastningsscenarier er utført, kommer rollen som " Analyse " -komponenter i LoadRunner inn.

Under utførelsen oppretter Controller en dump med resultater i rå form og inneholder informasjon som hvilken versjon av LoadRunner som opprettet denne resultatdumpen og hva som var konfigurasjoner.

Alle feilene og unntakene er logget i en Microsoft-tilgangsdatabase, med navnet output.mdb. "Analyse" -komponenten leser denne databasefilen for å utføre forskjellige typer analyser og genererer grafer.

Disse grafene viser forskjellige trender for å forstå resonnementet bak feil og svikt under belastning; dermed bidra til å finne ut om optimalisering er nødvendig i SUL, Server (f.eks. JBoss, Oracle) eller infrastruktur.

Nedenfor er et eksempel der båndbredde kan skape en flaskehals. La oss si at webserveren har 1 GBps kapasitet, mens datatrafikken overstiger denne kapasiteten og forårsaker påfølgende brukere. For å bestemme at systemet tilfredsstiller slike behov, må Performance Engineer analysere applikasjonsatferd med unormal belastning. Nedenfor er en graf LoadRunner genererer for å fremkalle båndbredde.

Kjøreplan for ytelsestesting: detaljerte trinn

Kjøreplan for ytelsestesting kan deles inn i fem trinn:

• Planlegger for lastetest
• Lag VUGen-skript
• Scenariooppretting
• Scenarioutførelse
• Resultatanalyse (etterfulgt av systemjustering)

Nå som du har installert LoadRunner, la oss forstå trinnene som er involvert i prosessen en etter en.

Trinn involvert i ytelsestestingsprosessen

Planlegger for lastetesten

Planlegging for ytelsestesting er forskjellig fra planlegging av en SIT (System Integration Testing) eller UAT (User Acceptance Testing). Planlegging kan videre deles inn i små trinn som beskrevet nedenfor:

Sett sammen teamet ditt

Når du kommer i gang med LoadRunner Testing, er det best å dokumentere hvem som skal delta i aktiviteten fra hvert team som er involvert i løpet av prosessen.

Prosjektleder:

Nominer prosjektlederen som vil eie denne aktiviteten og tjene som punktperson for opptrapping.

Funksjonsekspert / forretningsanalytiker:

Gi bruksanalyse av SUL og gir ekspertise på forretningsfunksjonalitet på nettstedet / SUL

Ytelsestestekspert:

Oppretter automatiserte ytelsestester og utfører belastningsscenarier

Systemarkitekt:

Tilbyr tegning av SUL

Nettutvikler og SMB:

• Vedlikeholder nettstedet og gir overvåkingsaspekter
• Utvikler nettsted og fikser feil

Systemadministrator:

• Opprettholder involverte servere gjennom et testprosjekt

Omfattende applikasjoner og forretningsprosesser involvert:

Vellykket lastetesting krever at du planlegger å utføre en viss forretningsprosess. En forretningsprosess består av klart definerte trinn i samsvar med ønskede forretningstransaksjoner - for å oppnå dine mål for belastningstesting.

En kravmåling kan utarbeides for å fremkalle brukerbelastning på systemet. Nedenfor er et eksempel på et fremmøtesystem i et selskap:

I eksemplet ovenfor nevner figurene antall brukere som er koblet til applikasjonen (SUL) på en gitt time. Vi kan trekke ut maksimalt antall brukere som er koblet til en forretningsprosess til enhver tid på dagen som beregnes i kolonnene til høyre.

På samme måte kan vi konkludere med det totale antallet brukere som er koblet til applikasjonen (SUL) når som helst på dagen. Dette beregnes i siste rad.

Ovennevnte to fakta tilsammen gir oss det totale antallet brukere som vi trenger for å teste systemet for ytelse.

Definer prosedyrer for håndtering av testdata

Statistikk og observasjoner hentet fra Performance Testing er sterkt påvirket av mange faktorer som beskrevet tidligere. Det er av avgjørende betydning å forberede testdata for ytelsestesting. Noen ganger bruker en bestemt forretningsprosess et datasett og produserer et annet datasett. Ta eksemplet nedenfor:

• En bruker 'A' oppretter en finansiell kontrakt og sender den til gjennomgang.
• En annen bruker 'B' godkjenner 200 kontrakter om dagen opprettet av bruker 'A'
• En annen bruker 'C' betaler omtrent 150 kontrakter om dagen godkjent av bruker 'B'

I denne situasjonen må bruker B ha 200 kontrakter 'opprettet' i systemet. Dessuten trenger bruker C 150 kontrakter som "godkjent" for å simulere en belastning på 150 brukere.

Dette betyr implisitt at du må opprette minst 200 + 150 = 350 kontrakter.

Godkjenn deretter 150 kontrakter for å fungere som testdata for bruker C - de resterende 200 kontraktene vil fungere som testdata for bruker B.

Oversiktsmonitorer

Spekulere på hver eneste faktor som muligens kan påvirke ytelsen til et system. For eksempel vil det å ha redusert maskinvare ha potensiell innvirkning på SUL (System Under Load) ytelsen.

Bruk alle faktorene og sett opp skjermer slik at du kan måle dem. Her er noen eksempler:

• Prosessor (for webserver, applikasjonsserver, databaseserver og injektorer)
• RAM (for webserver, applikasjonsserver, databaseserver og injektorer)
• Web / App Server (for eksempel IIS, JBoss, Jaguar Server, Tomcat osv.)
• DB Server (PGA og SGA størrelse i tilfelle Oracle og MSSQL Server, SP osv.)
• Nettverksbåndbreddeutnyttelse
• Internt og eksternt nettverkskort i tilfelle klynging
• Load Balancer (og at den fordeler belastningen jevnt på alle noder i klynger)
• Dataflyt (beregne hvor mye data som beveger seg til og fra klient og server - beregn deretter om kapasiteten på NIC er tilstrekkelig til å simulere X antall brukere)

Lag VUGen-skript

Neste trinn etter planlegging er å lage VUser-skript.

Scenariooppretting

Neste trinn er å lage Load Scenario

Scenarioutførelse

Scenarioutførelse er der du etterligner brukerbelastning på serveren ved å instruere flere VU-brukere om å utføre oppgaver samtidig.

Du kan stille inn nivået på en last ved å øke og redusere antall brukere som utfører oppgaver samtidig.

Denne utførelsen kan føre til at serveren blir stresset og oppfører seg unormalt. Dette er selve formålet med ytelsen Testing. Resultatene som blir trukket blir deretter brukt til detaljert analyse og identifisering av årsaker.

Resultatanalyse (etterfulgt av systemjustering)

Under scenarikjøring registrerer LoadRunner ytelsen til applikasjonen under forskjellige belastninger. Statistikken hentet fra testutførelse lagres og detaljanalyse utføres. HP-analyseverktøyet genererer forskjellige grafer som hjelper til med å identifisere årsakene bak et forsinket systemytelse, samt et systemfeil.

Noen av grafene som er oppnådd inkluderer:

• Tid til den første bufferen
• Transaksjonssvarstid
• Gjennomsnittlig svartid for transaksjon
• Treff per sekund
• Windows-ressurser
• Feilstatistikk
• Transaksjon Sammendrag

FAQ

Hvilke applikasjoner skal vi ytelsestest?

Ytelsestesting utføres alltid kun for klientserverbaserte systemer. Dette betyr at ethvert program som ikke er en klientserverbasert arkitektur, ikke må kreve ytelsestesting.

For eksempel er Microsoft Calculator verken klient-serverbasert, eller den kjører flere brukere; det er derfor ikke en kandidat for ytelsestesting.

Hva er forskjellen mellom Performance Testing & Performance Engineering

Det er viktig å forstå forskjellen mellom Performance Testing og Performance Engineering. En forståelse deles nedenfor:

Performance Testing er en disiplin som er opptatt av å teste og rapportere den nåværende ytelsen til en programvare under forskjellige parametere.

Performance engineering er prosessen der programvare blir testet og innstilt med den hensikt å realisere den nødvendige ytelsen. Denne prosessen har som mål å optimalisere den viktigste applikasjonsytelsesegenskapen, dvs. brukeropplevelse.

Historisk har testing og tuning vært tydelig atskilt og ofte konkurrerende riker. I løpet av de siste årene har imidlertid flere lommer med testere og utviklere samarbeidet uavhengig for å lage tuningteam. Fordi disse teamene har møtt betydelig suksess, har begrepet kobling av ytelsestesting med ytelsesjustering tatt tak, og nå kaller vi det performance engineering.