LoadRunner testverktøy – komponenter og Architecture

Hva er LoadRunner?

Loadrunner er et verktøy for ytelsestesting som ble utviklet 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. Faktisk er dette det eneste verktøyet i markedet som støtter et så stort antall protokoller å gjennomføre Ytelsestesting. Ytelsestestresultater produsert av LoadRunner-programvaren brukes som en målestokk mot andre verktøy

LoadRunner-video

Hvorfor LoadRunner?

Loadrunner er ikke bare et banebrytende verktøy innen ytelsestesting, men det er fortsatt markedsleder innen ytelsestesting-paradigmet. I en fersk vurdering har LoadRunner omtrent 85 % markedsandel i ytelsestestindustrien.

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 over alt, Windows Stikkontakt. Det er ikke noe konkurrentverktøy på markedet som kan tilby et så bredt utvalg av protokoller som ligger i ett 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 som ofte du vil finne klienter kryssverifiserer ytelsesreferansene dine ved hjelp av LoadRunner. Du vil finne lettelse hvis du allerede bruker LoadRunner for dine behov for ytelsestesting.

LoadRunner-programvaren er tett integrert med andre HP-verktøy som Unified Functional Test (QTP) og ALM (Application Lifecycle Management) som gir deg mulighet til å utføre ende-til-ende testprosesser.

LoadRunner fungerer på en prinsipp for simulering av virtuelle brukere på emneapplikasjonen. Disse virtuelle brukerne også kalt VUsers, replikerer klientens forespørsler og forventer et tilsvarende svar på å sende en transaksjon.

Hvorfor trenger du ytelsestesting?

Anslagsvis tap på 4.4 milliarder i omsetning registreres årlig på grunn av dårlig nettytelse.

I dagens Web 2.0-alder klikker brukere unna hvis et nettsted ikke svarer innen 8 sekunder. Se for deg at du venter i 5 sekunder når du søker etter Google eller sender en venneforespørsel på Facebook. Konsekvensene av nedetid i ytelsen er ofte mer ødeleggende enn noen gang har forestilt seg. Vi har eksempler som de som nylig traff Bank of America Online Banking, Amazon Webtjenester, Intuit eller Blackberry.

I følge Dunn & Bradstreet opplever 59 % av Fortune 500-selskapene anslagsvis 1.6 timer nedetid hver uke. Tatt i betraktning at det gjennomsnittlige Fortune 500-selskapet med minimum 10,000 56 ansatte betaler 896,000 dollar per time, vil arbeidsdelen av nedetidskostnadene for en slik organisasjon være 46 XNUMX dollar ukentlig, noe som tilsvarer mer enn XNUMX millioner dollar per år.

Bare en 5-minutters nedetid for Google.com (19-aug-13) anslås å koste søkegiganten så mye som $545,000 XNUMX.

Det er estimat at selskaper tapte salg verdt $1100 per sekund på grunn av en nylig Amazon Netttjenestebrudd.

Når et programvaresystem er distribuert av en organisasjon, kan det støte på mange scenarier som muligens resulterer i ytelsesforsinkelse. En rekke faktorer forårsaker bremsende ytelse, noen eksempler kan inkludere:

• Ø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 tidligere

Hva er LoadRunner Archilære?

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

Anta at du får i oppdrag å kontrollere ytelsen til Amazon.com for 5000 brukere

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

VUGen

VUGen eller virtuell bruker Generator er en IDE (Integrated Development Environment) eller en rik koderedigerer. VUGen brukes til å replikere System Under Load (SUL) oppførsel. VUGen tilbyr en "opptaks"-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 ta opp for å simulere følgende forretningsprosesser:

1. Surfer på produktsiden til Amazon. Med
2. Sjekk ut
3. Behandling av betaling
4. Sjekker Min konto-siden

controller

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

• Hvor mange VUsers som skal simuleres mot hver forretningsprosess eller VUser Group
• Oppførselen til VUsers (rampe opp, rampe ned, samtidig eller samtidig natur osv.)
• Belastningstype-scenario, f.eks. Real Life eller Målorientert eller bekreftende SLA
• Hvilke injektorer skal brukes, hvor mange VUsers mot hver injektor
• Samle resultatene med jevne mellomrom
• IP Spoofing
• Feil rapportering
• Transaksjonsrapportering etc.

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

1) 3500 brukere er Surfer på produktsiden til Amazon. Med

2) 750 brukere er med Sjekk ut

3) 500 brukere er utføre betalingsbehandling

4) 250 brukere er Sjekker Min Konto-side KUN etter at 500 brukere har utført betalingsbehandling

Enda mer komplekse scenarier er mulig

1. Start 5 VUsers hvert 2. sekund til en belastning på 3500 VUsers (surfing Amazon produktside) er oppnådd.
2. Gjenta i 30 minutter
3. Suspend iterasjon for 25 VUsers
4. Start 20 VUSere på nytt
5. Start 2 brukere (i Checkout, Betalingsbehandling, Mine kontoer) hvert sekund.
6. 2500 VUsers vil bli generert ved Machine A
7. 2500 VUsers vil bli generert på Machine B

Agenter maskin/last Generators/Injektorer

HP LoadRunner Controller er ansvarlig for å simulere tusenvis av VUsers – disse VUserne bruker maskinvareressurser for eksempel prosessor og minne – og setter derfor en grense for maskinen som simulerer dem. Dessuten simulerer Controller disse VUsers fra den samme maskinen (der Controller befinner seg) og derfor kan det hende at resultatene ikke er nøyaktige. For å løse denne bekymringen er alle VUsers spredt på forskjellige maskiner, kalt Laste Generators eller belastningsinjektorer.

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

Tar analogi fra vår Amazon Eksempel vil utgangen til denne komponenten være

Analyse

Når lastescenarier er utført, vil rollen som "Analyse” komponenter av LoadRunner kommer inn.

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

Alle feil og unntak logges i en Microsoft tilgangsdatabase, navngitt, output.mdb. "Analyse"-komponenten leser denne databasefilen for å utføre ulike typer analyser og genererer grafer.

Disse grafene viser ulike trender for å forstå årsaken bak feil og feil 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 en kapasitet på 1GBps, mens datatrafikken overskrider denne kapasiteten, noe som får påfølgende brukere til å lide. For å finne ut at systemet dekker slike behov, må Performance Engineer analysere applikasjonsatferd med unormal belastning. Nedenfor er en graf som LoadRunner genererer for å fremkalle båndbredde.

Hvordan utføre ytelsestesting

Veikart for ytelsestesting kan grovt sett deles inn i 5 trinn:

• Planlegging for belastningstest
• 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 én etter én.

Trinn involvert i ytelsestestingsprosessen

Trinn 1) Planlegging for belastningstesten

Planlegging for ytelsestesting er forskjellig fra planlegging av en SIT (systemintegrasjonstesting) or UAT (User Acceptance Testing). Planlegging kan videre deles inn i små stadier 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 involvert under prosessen.

Prosjektleder:

Nominer prosjektlederen som skal eie denne aktiviteten og fungere som punktperson for eskalering.

Funksjonsekspert/ forretningsanalytiker:

Gi bruksanalyse av SUL og gir ekspertise på forretningsfunksjonalitet til nettside/SUL

Ytelsestestekspert:

Oppretter de automatiserte ytelsestestene og utfører belastningsscenarier

System Architekt:

Gir blåkopi av SUL

Webutvikler og SMB:

• Vedlikeholder nettsiden og gir overvåkingsaspekter
• Utvikler nettside og fikser feil

Systemadministrator:

• Vedlikeholder involverte servere gjennom et testprosjekt

Skisser applikasjoner og forretningsprosesser som er involvert:

Vellykket Load Testing krever at du planlegger å utføre bestemte forretningsprosesser. En forretningsprosess består av klart definerte trinn i samsvar med ønskede forretningstransaksjoner – for å oppnå dine belastningstestemål.

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

I eksemplet ovenfor nevner tallene antall brukere koblet til applikasjonen (SUL) på gitt time. Vi kan trekke ut det maksimale antallet brukere som er koblet til en forretningsprosess til enhver tid på døgnet, som beregnes i kolonnene lengst 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.

De to ovennevnte faktaene kombinert gir oss det totale antallet brukere som vi trenger for å teste systemet for ytelse.

Definer testdatabehandlingsprosedyrer

Statistikk og observasjoner hentet fra ytelsestesting er i stor grad påvirket av en rekke faktorer som beskrevet tidligere. Det er av kritisk 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 inn til vurdering.
• En annen bruker 'B' godkjenner 200 kontrakter om dagen opprettet av bruker 'A'
• En annen bruker 'C' betaler omtrent 150 kontrakter per dag 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 som skal fungere som testdata for bruker C – de resterende 200 kontraktene vil fungere som testdata for bruker B.

Outline skjermer

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

Registrer alle faktorer og sett opp monitorer 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-/appserver (for eksempel IIS, JBoss, Jaguar Server, Tomcat osv.)
• DB Server (PGA- og SGA-størrelse i tilfelle Oracle og MSSQL-server, SP-er osv.)
• Utnyttelse av nettverksbåndbredde
• Intern og ekstern NIC i tilfelle klynging
• Load Balancer (og at den fordeler belastningen jevnt på alle noder av klynger)
• Datafluks (beregn hvor mye data som flyttes til og fra klient og server – beregn deretter om en kapasitet på NIC er tilstrekkelig til å simulere X antall brukere)

Trinn 2) Lag VUGen-skript

Neste trinn etter planlegging er å lage VUser-skript.

Trinn 3) Scenariooppretting

Neste trinn er å lage ditt lastescenario

Trinn 4) Scenarioutførelse

Scenariokjøring er der du emulerer brukerbelastning på serveren ved å instruere flere VUsers til å utføre oppgaver samtidig.

Du kan angi nivået på en belastning ved å øke og redusere antall VUsers som utfører oppgaver samtidig.

Denne kjøringen kan føre til at serveren blir stresset og oppfører seg unormalt. Dette er selve formålet med ytelsestestingen. Resultatene som er tegnet brukes deretter til detaljert analyse og identifisering av rotårsak.

Trinn 5) Resultatanalyse (etterfulgt av systemjustering)

Under kjøring av scenarier, registrerer LoadRunner ytelsen til applikasjonen under forskjellige belastninger. Statistikken hentet fra testutførelse lagres og detaljanalyse utføres. "HP Analysis"-verktøyet genererer ulike grafer som hjelper til med å identifisere de grunnleggende årsakene bak en etterslep i systemytelsen, så vel som en systemfeil.

Noen av grafene som er oppnådd inkluderer:

• Tid til den første bufferen
• Transaksjonsresponstid
• Gjennomsnittlig transaksjonsresponstid
• Treff per sekund
• Windows Ressurser
• Feilstatistikk
• Transaksjonssammendrag

Vanlige spørsmål