Parameterisering, funksjoner, transaksjoner i LoadRunner

Et innspilt skript kan simulere en virtuell bruker; imidlertid kan det hende at et enkelt opptak ikke er nok til å gjenskape den "virkelige brukeratferden".

Når et manus er spilt inn, dekker det enkelt og rett flyt av emneapplikasjonen. Mens en ekte bruker kan utføre flere iterasjoner av enhver prosess før han logger ut. Forsinkelsen mellom å klikke på knappene (tenk tid) vil variere fra person til person. Sjansen er stor for at noen ekte brukere får tilgang til applikasjonen din via DSL og noen får tilgang til den via en oppringt. Så, for å få den virkelige følelsen av sluttbruker, må vi forbedre skriptene våre for å være nøyaktige, eller i det minste veldig nære oppførselen til ekte brukere.

Ovennevnte er det viktigste hensynet når du utfører "Ytelsestesting”, men det er mer ved et VU-skript. Hvordan vil du måle nøyaktig hvor lang tid en VUser tar når SUL gjennomgår en ytelsestest? Hvordan vil du vite om VUser har gått gjennom eller feilet på et bestemt tidspunkt? Hva er årsaken bak feilen, om noen backend-prosess mislyktes eller serverressursene var begrenset?

Vi må forbedre skriptet vårt for å svare på alle spørsmålene ovenfor.

Bruke transaksjoner

Transaksjoner er mekanikk for å måle serverens responstid for enhver operasjon. Med enkle ord hjelper bruken av "Transaksjon" med å måle tiden systemet tar for en bestemt forespørsel. Det kan være så lite som et klikk på en knapp eller et AJAX-anrop når du mister fokus fra tekstboksen.

Det er enkelt å bruke transaksjoner. Bare skriv en linje med kode før forespørselen sendes til serveren og lukk transaksjonen når forespørselen avsluttes. LoadRunner krever bare en streng som transaksjonsnavn.

For å åpne en transaksjon, bruk denne kodelinjen:

lr_start_transaction(“Transaction Name”);

For å avslutte transaksjonen, bruk denne kodelinjen:

lr_end_transaction(“Transaction Name”, <status>);

De forteller LoadRunner om denne bestemte transaksjonen var vellykket eller mislykket. De mulige parameterne kan være:

  • LR_AUTO
  • LR_PASS
  • LR_FAIL

Eksempel:

lr_end_transaction(“Min_pålogging”, LR_AUTO);
lr_end_transaction(“001_Opening_Dashboard Name”, LR_PASS);
lr_end_transaction(“Business_Workflow_Transaction Name”, LR_FAIL);

Poeng å merke seg:

  • Ikke glem at du jobber med "C", og det er et språk som skiller mellom store og små bokstaver.
  • Punktum (.) er ikke tillatt i transaksjonsnavnet, selv om du kan bruke mellomrom og understrek.
  • Hvis du har forgrenet koden din godt og lagt til sjekkpunkter for å bekrefte svaret fra serveren, kan du bruke tilpasset feilhåndtering, for eksempel LR_PASS eller LR_FAIL. Ellers kan du bruke LR_AUTO og LoadRunner vil automatisk håndtere serverfeil (HTTP 500, 400 osv.)
  • Når du bruker transaksjoner, sørg for at det er nei tenke_tid erklæringen blir klemt eller på annen måte vil transaksjonen din alltid inkludere denne perioden.
  • Siden LoadRunner krever en konstant streng som transaksjonsnavn, er et vanlig problem ved bruk av transaksjon at strengen ikke samsvarer. Hvis du gir et annet navn når du åpner og avslutter en transaksjon, vil du ha minst 2 feil. Siden transaksjonen du åpnet aldri ble avsluttet, vil LoadRunner gi en feil. Dessuten ble transaksjonen du prøver å lukke aldri åpnet, og resulterte derfor i en feil.
  • Kan du bruke intelligensen din og svare på deg selv hvilken av de ovennevnte feilene som blir rapportert først? For å bekrefte svaret ditt, hvorfor ikke gjøre din egen feil? Hvis du hadde svart rett, er du i rute. Hvis du svarte feil, må du fokusere.
  • Siden LoadRunner automatisk tar seg av synkronisering av forespørsler og svar, trenger du ikke å bekymre deg for respons når du bruker transaksjoner.

Forstå Think Time, Rendezvous Points og Kommentarer

Rendezvous poeng

Rendezvous Points betyr "møtepunkter". Det er bare en uttalelse som forteller LoadRunner å introdusere samtidighet. Du setter inn rendezvous-punkter i VUser-skript for å etterligne tung brukerbelastning på serveren.

Rendezvous-punkter instruerer VUser om å vente under testkjøring på at flere VUser kommer til et bestemt punkt, slik at de kan utføre en oppgave samtidig. For å etterligne toppbelastning på bankserveren kan du for eksempel sette inn et møtepunkt som instruerer 100 brukere om å sette inn kontanter på kontoene sine samtidig. Dette kan enkelt oppnås ved hjelp av rendezvous.

Hvis møtepunktene ikke er riktige plasseringer, vil VUser få tilgang til forskjellige deler av applikasjonen – selv for det samme skriptet. Dette er fordi hver VUser får forskjellig responstid og derfor henger få brukere etter.

Syntaks: lr_rendesvous(“Logisk navn”);

Beste praksis:

  • Prefiks et møtepunkt med "rdv_" for bedre kodelesbarhet; f.eks. «rdv_Login»
  • Fjern eventuelle umiddelbare utsagn om tenketid
  • Bruk av møtepunkter i en skriptvisning (etter opptak)

Rendezvous poeng

Kommentar

Legg til kommentarer for å beskrive en aktivitet, et kodestykke eller en kodelinje. Kommentarer bidrar til å gjøre koden forståelig for alle som refererer til den i fremtiden. De gir informasjon om spesifikk operasjon og skiller to seksjoner for forskjell.

Du kan legge til kommentarer

  • Under opptak (bruker verktøy)
  • Etter opptak (skriver direkte inn kode)

Beste praksis: Merk eventuelle kommentarer øverst i hver skriptfil

Sette inn funksjoner gjennom menyen

Mens du kan skrive enkle kodelinjer direkte, kan det hende du trenger en anelse for å hente frem en funksjon. Du kan også bruke Steps Toolbox (kjent som Insert Function før versjon 12) for å finne og sette inn en hvilken som helst funksjon direkte i skriptet ditt.

Du finner Steps Toolbar under Vis àSteps Toolbox.

Sette inn funksjoner gjennom menyen

Dette vil åpne et sidevindu, se på øyeblikksbildet:

Sette inn funksjoner gjennom menyen

Hva er parameterisering?

A parameter i VUGen er en container som inneholder en registrert verdi som erstattes for ulike brukere.

Under kjøringen av skriptet (i VUGen eller Controller), erstatter verdien fra en ekstern kilde (som .txt, XML eller database) den forrige verdien til parameteren.

Parametrisering er nyttig for å sende dynamiske (eller unike) verdier til serveren, for eksempel; en forretningsprosess er ønsket for å kjøre 10 iterasjoner, men velge unikt brukernavn hver gang.

Det hjelper også med å stimulere virkelig-lignende oppførsel til fagsystemet. Ta en titt på eksemplet nedenfor:

Eksempler på problemer:

Forretningsprosessen fungerer bare for gjeldende dato som kommer fra serveren, og kan derfor ikke sendes som en hardkodet forespørsel.

Noen ganger sender klientapplikasjonen en unik ID til serveren (for eksempel session_id) for at prosessen skal fortsette (selv for en enkelt bruker) – I et slikt tilfelle hjelper parameterisering.

Ofte opprettholder klientapplikasjonen en hurtigbuffer med data som sendes til og fra serveren. Som et resultat mottar ikke serveren en reell brukeratferd (i tilfelle serveren kjører en annen algoritme avhengig av søkekriterier). Selv om VUser-skriptet vil kjøre vellykket, vil ytelsesstatistikken som trekkes ikke være meningsfull. Bruk av forskjellige data gjennom parameterisering hjelper til med å emulere aktivitet på serversiden (prosedyrer osv.) og trener systemet.

En dato som er hardkodet i VUser under opptak kan ikke lenger være gyldig når denne datoen har passert. Parametrisering av datoen lar VUser-kjøring lykkes ved å erstatte den hardkodede datoen. Slike felt eller forespørsler er de riktige kandidatene for parameterisering.

Klikk her. hvis videoen ikke er tilgjengelig

Kjøretidsinnstillinger og deres innvirkning på VU-simulering

Kjøretidsinnstillinger har like mye betydning som VUGen-skriptet ditt. Med varierende konfigurasjoner kan du få forskjellige testdesign. Dette er grunnen til at du kan ende opp i resultater som ikke kan gjentas hvis kjøretidsinnstillingene ikke er konsistente. La oss diskutere hver egenskap en etter en.

Kjør Logic

Run Logic definerer antall ganger alle handlinger vil bli utført, bortsett fra vuser_init og vuser_end.

Sannsynligvis gjør dette tydeligere hvorfor LoadRunner foreslår å holde all påloggingskoden innenfor vuser_init, og utloggingsdelen i vuser_end, begge utelukkende.

Hvis du har opprettet flere handlinger, la oss si Logg på, Åpne Skjerm, Beregn leie, Send inn midler, Sjekk saldo og utlogging, så vil scenarioet nedenfor finne sted for hver VUser:

Alle VUsers vil logge på, utføre åpen skjerm, beregne leie, sende inn midler, sjekke saldo – deretter – igjen Åpne skjermbilde, kalkulere leie… og så videre – gjenta 10 ganger – etterfulgt av utlogging (en gang).

Kjør Logic

Dette er en kraftig innstilling som gjør det mulig å opptre mer som en ekte bruker. Husk at en ekte bruker ikke logger på og logger ut hver gang – han gjentar vanligvis de samme trinnene.

Hvor mange ganger klikker du på "innboks" når du sjekker e-posten din før du logger ut?

pacing

Dette er viktig. For det meste er folk ikke i stand til å forstå forskjellen mellom pacing og tenketid. Den eneste forskjellen er, "pacing refererer til forsinkelsen mellom iterasjoner" mens tror tid er forsinkelsen mellom to trinn.

Anbefalt innstilling avhenger av testdesignet. Men hvis du ønsker å ha aggressiv belastning, bør du vurdere å velge "Så snart forrige iterasjon slutter"

pacing

Logg

En logg (som generelt forstått) er en bokføring av alle hendelser mens du kjører LoadRunner. Du kan aktivere logg for å vite hva som skjer mellom applikasjonen og serveren.

LoadRunner gir kraftig loggingsmekanisme som er robust og skalerbar alene. Den lar deg bare beholde "Standardlogg" eller en detaljert, konfigurerbar utvidet logg eller deaktivere den helt.

En standardlogg er informativ og lett forståelig. Den inneholder akkurat den rette mengden kunnskap, du vil vanligvis kreve feilsøking av VUser-skriptene dine.

Når det gjelder utvidet logg, er all standard logginformasjon et undersett. I tillegg kan du ha parametererstatning. Dette forteller LoadRunner-komponenten å inkludere fullstendig informasjon om alle parameterne (fra parameterisering) inkludert forespørsler, samt svardata.

Hvis du inkluderer "Data returnert av server" vil loggen din bli lengre. Dette vil inkludere all HTML, tagger, ressurser, ikke-ressurser informasjon inkludert rett i loggen. Alternativet er bare bra hvis du trenger seriøs feilsøking. Vanligvis gjør dette loggfilen veldig stor i størrelse og ikke lett forståelig.

Som du kunne ha gjettet nå hvis du velger "Advance Trace", vil loggfilen din være massiv. Du må prøve det. Du vil legge merke til at tiden det tar VUGen også har økt betydelig, selv om dette ikke vil ha noen innvirkning på transaksjonens responstid rapportert av VUGen. Dette er imidlertid svært forhåndsinformasjon og kan være nyttig hvis du forstår emneapplikasjonen, klient-til-server-kommunikasjonen mellom applikasjonen og maskinvaren, samt detaljer på protokollnivå. Vanligvis er denne informasjonen død av essens siden den krever ekstrem innsats for å forstå og feilsøke.

Logg

Tips:

  • Uansett hvor lang tid VUGen tar når logg er aktivert, har det ingen innvirkning på transaksjonens responstid. HP kaller dette fenomenet som «state of the art-teknologi».
  • Deaktiver logg hvis det ikke er nødvendig.
  • Deaktiver logg når du er ferdig med skriptene dine. Inkludering av skript med logging aktivert vil føre til at kontrolleren kjører saktere og rapporterer irriterende meldinger.
  • Deaktivering av logg vil øke kapasiteten til det maksimale antallet brukere du kan simulere fra LoadRunner.
  • Vurder å bruke "Send melding bare når feil oppstår" - dette vil dempe unødvendige informasjonsmeldinger og rapportere bare feilrelaterte meldinger.

Tenk Times

Think Time er ganske enkelt forsinkelsen mellom to trinn.

Think Time hjelper med å replikere brukeratferd siden ingen ekte brukere kan bruke noen applikasjoner som en maskin (VUGen). VUGen genererer tenketid automatisk. Du har fortsatt full kontroll over å fjerne, multiplisere eller svinge varigheten av tenketiden.

For å forstå mer, for eksempel, kan en bruker åpne en skjerm (det vil si et svar etterfulgt av en forespørsel) og deretter oppgi brukernavn og passord før du trykker på enter. Den neste interaksjonen mellom applikasjonen og serveren vil skje når han klikker "Logg på". Tiden en bruker brukte på å skrive inn brukernavn og passord er Think Time i LoadRunner.

Tenk Times

Hvis du ønsker å simulere aggressiv belastning på applikasjonen, bør du vurdere å deaktivere tenketid fullstendig.

Men for å simulere en ekte lignende oppførsel, kan du "User Random Think Time" og angi prosentene som ønsket.

Vurder å bruke Limit Think Time til en legitim periode. Vanligvis er 30 sekunder ganske bra nok.

Hastighetssimulering

Hastighetssimulering refererer ganske enkelt til båndbreddekapasitet for hver klientmaskin.

Siden vi simulerer tusenvis av VUser gjennom LoadRunner, er det utrolig hvor enkelt LoadRunner har gjort for å kontrollere simuleringen av båndbredde/nettverkshastighet.

Hvis du er kunder som har tilgang til applikasjonen din over 128 Kbps, kan du kontrollere den herfra. Du vil få simulere "ekte som oppførsel" som bør hjelpe deg med å få riktig ytelsesstatistikk.

Hastighetssimulering

Den beste anbefalingen er å sette til Bruk maksimal båndbredde. Dette vil bidra til å se bort fra eventuelle nettverksrelaterte ytelsesflaskehalser og fokusere på eventuelle potensielle problemer i applikasjonen først. Du kan alltid kjøre testen flere ganger for å se varierende oppførsel under forskjellige omstendigheter.

Nettleseremulering

Brukeropplevelsen avhenger ikke av nettleseren en sluttbruker bruker. Dette er klart utenfor rammen av ytelsesmål. Du kan imidlertid velge hvilken nettleser du vil emulere.

Nettleseremulering

Kan du svare for deg selv når akkurat det vil ha betydning for deg å velge riktig nettleser i denne konfigurasjonen?

Du vil bruke denne konfigurasjonen hvis du er underlagt applikasjonen er en nettapplikasjon, som returnerer forskjellige svar for forskjellige nettlesere. For eksempel får du se forskjellige bilder og innhold for IE og Firefox og så videre

En annen viktig innstilling er Simuler nettleserbuffer. Hvis du vil måle responstiden når hurtigbufferen er aktivert, merk av i denne boksen. Hvis du leter etter verste situasjon, er dette åpenbart ikke en vurdering.

Nedlasting av ikke-HTML-ressurser lar LoadRunner laste ned CSS, JS og andre rike medier. Dette bør forbli sjekket. Men hvis du vil fjerne dette fra ytelsestestdesignet ditt, kan du fjerne merket for dette.

Proxy

Det er best å eliminere proxy helt fra din Test miljø – dette vil gjøre testresultatene upålitelige. Du kan imidlertid møte situasjoner der det er uunngåelig. I en slik situasjon letter LoadRunner deg med proxy-innstillinger.

Du vil jobbe (eller bør jobbe) med Ingen proxy-innstilling. Du kan få den fra standardnettleseren din. Men ikke glem å sjekke hvilken nettleser som er satt til standard og hvilken proxy-konfigurasjon for standard nettleser.

Proxy

Hvis du bruker en proxy og den krever autentisering (eller et skript), kan du klikke på Autentiser-knappen som fører til et nytt vindu. Se skjermbildet nedenfor.

Proxy

Bruk denne skjermen til å oppgi brukernavn og passord for å bli autentisert på proxy-serveren. Klikk OK for å lukke skjermen.

Gratulerer. Du er ferdig med å konfigurere VUGen-skriptet ditt. Ikke glem å konfigurere den for alle VUser-skriptene dine.