LoadRunner testverktøy: ArchiTekturdiagram og komponenter

Hva er LoadRunner?

LoadRunner er en Ytelsestesting verktøy som ble utviklet av Mercury Interactive i 1999. LoadRunner ble senere kjøpt opp av HP i 2006, og HPs programvarevirksomhet fusjonerte med Micro Focus i en avtale som ble annonsert i 2016 og fullført i 2017.

Merkemerknad: OpenText fullførte oppkjøpet av Micro Focus i januar 2023Verktøyet selges ikke lenger som HP eller Micro Focus LoadRunnerLoadRunner Professional er nå OpenText Profesjonell ytelsesteknikk, LoadRunner Enterprise er OpenText Enterprise Performance Engineering, og LoadRunner Cloud er OpenText Kjerneytelsesteknikk. Komponentnavnene nedenfor – VuGen, kontroller, lastgeneratorer og analyse – er uendret.

LoadRunner støtter diverse utviklingsverktøy, teknologier og kommunikasjonsprotokoller. Den har et av de bredeste protokollbibliotekene på markedet for å utføre ytelsestesting. Ytelsestestresultater produsert av LoadRunner-programvaren brukes som en referanse mot andre verktøy.

LoadRunner-video

Se videoen nedenfor for en rask introduksjon til LoadRunner før du går gjennom komponentene.

Hvorfor LoadRunner?

LoadRunner er ikke bare et pionerverktøy innen ytelsestesting, det er fortsatt en av markedslederne innen ytelsestestingsparadigmet og er fortsatt referansepunktet mange bedrifter sammenligner seg med.

Protokolldekningen er den klareste grunnen til at teamene velger den, som komponentkartet nedenfor viser.

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 Socket. Få konkurrerende verktøy tilbyr et så bredt utvalg av protokoller i ett enkelt verktøy, slik protokolllisten nedenfor illustrerer.

Det som er enda mer overbevisende for å velge LoadRunner til programvaretesting er verktøyets troverdighet. LoadRunner har lenge etablert et rykte, siden du ofte vil se kunder kryssverifisere ytelsesstandardene dine ved hjelp av LoadRunner. Du vil finne lettelse hvis du allerede bruker LoadRunner til dine ytelsestestbehov.

LoadRunner-programvaren er tett integrert med de andre verktøyene i samme pakke – Unified Functional Testing (tidligere QTP, selges nå som OpenText Funksjonell testing) og ALM (applikasjonslivssyklushåndtering, nå OpenText ALM/Kvalitetssenter) – som gir deg muligheten til å utføre dine komplette testprosesser.

LoadRunner fungerer etter prinsippet om å simulere virtuelle brukere i den aktuelle applikasjonen. Disse virtuelle brukerne, også kalt V-brukere, replikerer klientens forespørsler og forventer et tilsvarende svar for å gjennomføre en transaksjon.

Hvorfor trenger du ytelsestesting?

Bransjeestimatene nedenfor er mye sitert og stammer fra tidlig på 2010-tallet, men mønsteret de beskriver har ikke endret seg: trege sider koster penger.

Et anslått tap på 4.4 milliarder dollar i inntekter registreres årlig på grunn av dårlig webytelse.

I dagens Web 2.0-tidsalder klikker brukerne seg 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 sende en venneforespørsel på Facebook. Konsekvensene av driftsstans er ofte mer ødeleggende enn noen gang forestilt seg. Det finnes velkjente eksempler, som de som rammet Bank of Americas nettbankvirksomhet, Amazon Nettjenester, Intuit og Blackberry.

Ifølge Dun & Bradstreet opplever 59 % av Fortune 500-selskapene anslagsvis 1.6 timer nedetid hver uke. Tatt i betraktning at et gjennomsnittlig Fortune 500-selskap med minimum 10 000 ansatte betaler 56 dollar i timen, ville arbeidskostnadene for en slik organisasjon være 896 000 dollar i uken, noe som tilsvarer mer enn 46 millioner dollar per år.

Bare 5 minutters nedetid GoogleDet er anslått at .com i august 2013 kostet søkegiganten så mye som 545 000 dollar.

Det anslås at selskaper tapte salg verdt 1,100 dollar per sekund i løpet av det siste Amazon Nettjenester-avbrudd.

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 har tilgang til systemet samtidig sammenlignet med tidligere

Ikke alle søknader er imidlertid en kandidat. Load Testing retter seg mot klient-server-systemer med flere brukere, så et skrivebordsverktøy for én bruker som det nedenfor er ikke verdt å teste for ytelse.

Hva er LoadRunner Archilære?

Generelt sett er arkitekturen til LoadRunner kompleks, men likevel lett å forstå. LoadRunner-arkitekturdiagrammet nedenfor viser hvordan de fire komponentene fungerer sammen.

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

I en virkelig situasjon vil ikke alle disse 5000 brukerne sitte på hjemmesiden – de vil være spredt over forskjellige deler av nettstedet. Så hvordan simulerer vi den forskjellen?

VuGen

VuGen eller virtuell bruker Generator er et IDE (Integrated Development Environment) eller en rik koderedigerer. VuGen brukes til å gjenskape 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 registrere for å simulere følgende forretningsprosesser:

• Surfer på produktsiden til Amazon. Med
• Sjekk ut
• Behandling av betaling
• Sjekker Min konto-siden

Når skriptet spilles av rent, må dynamiske serververdier vanligvis registreres med korrelasjon før den kan skaleres opp.

controller

Når et VUser-skript er ferdigstilt, controller er en av hovedkomponentene i LoadRunner som styrer lastsimuleringen 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.

Ved å ta en analogi fra vårt eksempel, vil kontrolleren legge til følgende parametere i VuGen-skriptet:

1. 3500 brukere surfer på produktsiden til Amazon. Med
2. 750 brukere er i kassen
3. 500 brukere utfører betalingsbehandling
4. 250 brukere sjekker Min konto-siden KUN etter at 500 brukere har fullført betalingsbehandlingen.

Enda mer komplekse scenarier er mulige:

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

Agenter maskin/last Generators/Injektorer

LoadRunner-kontrolleren er ansvarlig for å simulere tusenvis av VUsere – disse VUserne bruker maskinvareressurser, for eksempel prosessor og minne – og setter dermed en grense for maskinen som simulerer dem. Dessuten simulerer kontrolleren disse VUserne fra samme maskin (der kontrolleren befinner seg), og dermed kan resultatene være unøyaktige. For å løse dette problemet er alle VUsere spredt over forskjellige maskiner, kalt LoadRunner. 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 analogien fra vår Amazon For eksempel er utdataene fra denne komponenten 5000 V-brukere fordelt på to injektorer: 2500 V-brukere generert på maskin A og 2500 på maskin B.

Analyse

Når lastscenariene er utført, vil rollen til Analyse komponenten 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 Access-databasen med navnet output.mdb. Analysekomponenten 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å 1 GBps, mens datatrafikken overstiger denne kapasiteten, noe som fører til at påfølgende brukere lider. For å avgjøre om systemet dekker slike behov, må ytelsesingeniøren analysere applikasjonens oppførsel med en unormal belastning. Nedenfor er en graf som LoadRunner genererer for å finne ut båndbredde.

Hvordan utføre ytelsestesting

Veikartet for ytelsestesting kan grovt sett deles inn i fem trinn, oppsummert i veikartet nedenfor:

1. Planlegging for belastningstest
2. Lag VuGen-skript
3. Scenariooppretting
4. Scenarioutførelse
5. Resultatanalyse (etterfulgt av systemjustering)

Når LoadRunner er installert, la oss forstå trinnene som er involvert i prosessen én etter én.

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 starter med LoadRunner-testing, er det best å dokumentere hvem som skal delta i aktiviteten fra hvert team som er involvert i prosessen, slik teamdiagrammet nedenfor viser.

• Prosjektleder: Nominer prosjektlederen som skal eie denne aktiviteten og fungere som punktperson for eskalering.
• Funksjonsekspert / forretningsanalytiker: Tilbyr bruksanalyse av SUL og ekspertise om forretningsfunksjonaliteten til nettstedet eller SUL.
• Ytelsestestekspert: Oppretter automatiserte ytelsestester og utfører belastningsscenarier.
• System Architekt: Gir en skisse av SUL.
• Webutvikler og SMB: Vedlikeholder nettstedet, sørger for overvåking, utvikler nettstedet og retter feil.
• Systemadministrator: Vedlikeholder involverte servere gjennom et testprosjekt.

Oversikt over 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 viser tallene antall brukere som er koblet til applikasjonen (SUL) på et gitt tidspunkt. Vi kan f.eks.tracdet maksimale antallet brukere som er koblet til en forretningsprosess på et hvilket som helst tidspunkt av 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 økonomisk svindeltract og sender den inn til vurdering.
• En annen bruker «B» godkjenner 200 contracen dag opprettet av bruker 'A'
• En annen bruker «C» betaler omtrent 150 kroner.tracts en dag godkjent av bruker 'B'

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

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

Etter det, godkjenn 150 contracts som skal fungere som testdata for bruker C – de resterende 200 contracts vil fungere som testdata for bruker B.

Outline skjermer

Spekuler i hver eneste faktor som muligens kan påvirke ytelsen til et system. For eksempel vil 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)
• Data flux (beregn hvor mye data som flyttes til og fra klient og server – beregn deretter om en kapasitet på et nettverkskort er tilstrekkelig til å simulere X antall brukere)

Trinn 2) Lag VuGen-skript

Neste trinn etter planlegging er å lage VUser-skript, legge til parameterisering, transaksjoner og kjøretidsinnstillinger etter hvert som manuset modnes.

Trinn 3) Scenariooppretting

Neste trinn er å opprette lastescenarioet ditt i kontrolleren, og velge mellom et manuelt og et målorientert scenario.

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 utførelsen kan føre til at serveren går under stresset og oppfører seg unormalt. Dette er selve formålet med ytelsestesting. Resultatene som trekkes ut brukes deretter til detaljert analyse og identifisering av rotårsaker.

Trinn 5) Resultatanalyse (etterfulgt av systemjustering)

Under scenarioutførelse registrerer LoadRunner ytelsen til applikasjonen under forskjellige belastninger. Statistikken fra testutførelsen lagres, og detaljert analyse utføres. Analyseverktøyet (merket «HP Analysis» i utgivelsene denne gjennomgangen ble skrevet mot) genererer forskjellige grafer som hjelper til med å identifisere de underliggende årsakene til en forsinkelse i systemytelsen, samt 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

Spørsmål og svar