Parameterisering, funksjoner, transaksjoner i LoadRunner

Et innspilt skript kan simulere en virtuell bruker; imidlertid er det ikke sikkert at et enkelt opptak er nok til å gjenskape ekte brukeratferd.

Når et skript spilles inn, dekker det en enkelt, rett flyt gjennom den aktuelle applikasjonen. En ekte bruker kan utføre flere iterasjoner av en prosess før vedkommende logger seg ut. Forsinkelsen mellom å klikke på knapper (tenketiden) varierer fra person til person, og noen brukere når applikasjonen din via en rask tilkobling, mens andre ikke gjør det. Så for å få den virkelige følelsen av en sluttbruker, må vi forbedre skriptene våre slik at de oppfører seg veldig likt ekte brukere.

Det er den viktigste faktoren når man gjennomfører «Ytelsestesting”, men det er mer ved et VUser-skript. Hvordan vil du måle tiden en VUser bruker mens System Under Load (SUL) testes? Hvordan vil du vite om VUser-en bestod eller mislyktes på et bestemt tidspunkt, og om en backend-prosess mislyktes eller om serverressursene ble for korte?

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

Merkemerknad: VuGen ble levert som HP, deretter Micro Focus, og er nå en del av OpenText Profesjonell ytelsesteknikkFunksjonene og innstillingene nedenfor er uendret.

Bruke transaksjoner

Transaksjoner måler serverens responstid for enhver operasjon. Enkelt sagt måler en «transaksjon» tiden systemet bruker på en bestemt forespørsel. Det kan være så lite som et knappeklikk eller et AJAX-kall som utløses når en tekstboks mister fokus.

Det er enkelt å bruke transaksjoner. Skriv én linje med kode før forespørselen sendes, 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(“My_Login”, LR_AUTO);
lr_end_transaction(“001_Opening_Dashboard Name”, LR_PASS);
lr_end_transaction(“Business_Workflow_Transaction Name”, LR_FAIL);

Code merknader: Kodeutdragene er gjengitt nøyaktig slik de er publisert, inkludert typografiske sitater. Et ekte VuGen-skript trenger rette ASCII-dobbelt anførselstegn, så skriv dem inn på nytt hvis du kopierer denne koden.

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 et transaksjonsnavn, men du kan bruke mellomrom og understrek.
• Hvis du har forgrenet koden din godt og lagt til kontrollpunkter for å bekrefte svaret fra serveren, kan du bruke tilpasset feilhåndtering som 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, må du sørge for at det ikke er noen tanketidserklæring innimellom, ellers vil transaksjonen alltid inkludere den perioden.
• Siden LoadRunner krever en konstant streng som transaksjonsnavn, er et vanlig problem når man bruker transaksjoner at strengene ikke samsvarer. Hvis du oppgir et annet navn når du åpner og lukker en transaksjon, vil du få minst to feil. Transaksjonen du åpnet ble aldri lukket, så LoadRunner gir en feil; og transaksjonen du prøver å lukke ble aldri åpnet, noe som gir en andre feil.
• Begge feilene vises i avspillingsloggen, så når en av dem rapporteres, bør du først sjekke transaksjonsnavnet på åpnings- og sluttutskriftene.
• Siden LoadRunner automatisk tar seg av synkronisering av forespørsler og svar, trenger du ikke å bekymre deg for svaret når du bruker transaksjoner.

Møtepunkter, kommentarer og skriptfunksjoner

Tre mindre forbedringer får et skript til å oppføre seg og leses som produksjonskode: møtepunkter, kommentarer og funksjonsleseren som er innebygd i VuGen.

Rendezvous poeng

Et møtepunkt er et «møtepunkt». Det er en enkelt setning som forteller LoadRunner at den skal introdusere samtidighet. Du setter inn møtepunkter i VUser-skript for å emulere høy brukerbelastning på serveren.

Møtepunkter instruerer en V-bruker til å vente under kjøring til flere V-brukere ankommer et bestemt punkt, slik at de kan utføre en oppgave samtidig. For eksempel, for å etterligne toppbelastning på en bankserver, sett inn et møtepunkt som instruerer 100 V-brukere til å sette inn kontanter samtidig.

Hvis møtepunktene ikke er plassert riktig, vil V-brukerne få tilgang til forskjellige deler av applikasjonen selv for det samme skriptet. Dette er fordi hver V-bruker får en annen responstid, og derfor henger noen brukere etter.

Syntaks:

lr_rendezvous(“Logical Name”);

Korreksjonsmerknad: den publiserte siden staves dette lr_rendesvousDet riktige funksjonsnavnet er lr_rendezvous; det feilstavede skjemaet vil ikke kompileres.

Beste praksis:

• Prefiks et møtepunkt med "rdv_" for bedre kodelesbarhet; f.eks. «rdv_Login»
• Fjern eventuelle tenketidsutsagn som ligger rett ved siden av
• Bruk møtepunkter i skriptvisning etter opptak

Skriptvisningen nedenfor viser en rendezvous-setning satt inn i en innspilt handling:

Kommentar

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

Du kan legge til kommentarer

• Under opptak (ved bruk av verktøyet)
• Etter opptak (skriver direkte inn kode)

Beste praksis: merk eventuelle kommentarer øverst i hver skriptfil.

Sette inn funksjoner via menyen

Selv om du kan skrive enkle kodelinjer direkte, kan det hende du trenger en ledetråd for å huske 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 trinnverktøykassen under Vis → Trinnverktøykasse, som vist nedenfor.

Dette vil åpne et sidevindu. Se på øyeblikksbildet:

Hva er parameterisering?

En parameter i VuGen er en beholder som inneholder en registrert verdi som erstattes for forskjellige brukere.

Under kjøringen av skriptet (i VuGen eller controller), erstatter en verdi fra en ekstern kilde (for eksempel en .txt-fil, XML eller en database) den forrige verdien av parameteren.

Parameterisering er nyttig for å sende dynamiske (eller unike) verdier til serveren. For eksempel kan en forretningsprosess være pålagt å kjøre 10 iterasjoner mens den velger et unikt brukernavn hver gang.

Det hjelper også med å simulere virkelighetsnær atferd mot det aktuelle systemet. Ta en titt på eksemplene nedenfor.

Eksempler på problemer:

• En forretningsprosess fungerer bare for gjeldende dato, som kommer fra serveren, så den kan ikke sendes som en hardkodet forespørsel.
• Noen ganger sender klientapplikasjonen en unik ID til serveren (for eksempel session_id) for at prosessen skal kunne fortsette, selv for én enkelt bruker. I slike tilfeller hjelper parameterisering.
• Klientapplikasjonen lagrer ofte en mellomlagring av dataene som sendes til og fra serveren. Som et resultat mottar ikke serveren reell brukeratferd (der serveren kjører en annen algoritme avhengig av søkekriteriene). VUser-skriptet vil kjøres uten problemer, men ytelsesstatistikken som tegnes vil ikke være meningsfull. Bruk av forskjellige data gjennom parameterisering bidrar til å emulere serversideaktivitet, for eksempel lagrede prosedyrer, og trener systemet.
• En dato som er hardkodet i VUser under opptak, er kanskje ikke lenger gyldig når datoen er over. Parameterisering av datoen gjør at VUser-kjøringen kan lykkes ved å erstatte den hardkodede datoen. Slike felt eller forespørsler er de riktige kandidatene for parameterisering.

Du oppretter en ved å høyreklikke på den registrerte verdien i skriptvisning og velge Erstatt med en parameter. VuGen spør deretter hvilken type som leverer verdien:

To ytterligere alternativer bestemmer hvordan data forbrukes på tvers av iterasjoner:

Gjennomgangen nedenfor viser parameterisering brukt på et innspilt skript:

Klikk her. hvis videoen ikke er tilgjengelig.

Kjøretidsinnstillinger og deres innvirkning på VUser-simulering

Kjøretidsinnstillingene er like viktige som VuGen-skriptet ditt. Med varierende konfigurasjoner kan du oppnå helt forskjellige testdesign, og det er derfor inkonsistente kjøretidsinnstillinger er den vanlige årsaken til ikke-repeterbare resultater. La oss diskutere hvert attributt én etter én.

Kjør Logic

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

Dette gjør det sannsynligvis tydeligere hvorfor LoadRunner foreslår keeping all påloggingskoden i vuser_init og utloggingsdelen i vuser_end, begge eksklusivt.

Hvis du har opprettet flere handlinger – for eksempel Logg inn, Åpne skjerm, Beregn leie, Send inn penger, Sjekk saldo og Logg ut – vil scenariet nedenfor finne sted for hver V-bruker:

Alle V-brukere logger inn, utfører Åpne skjerm, Beregn leie, Send inn midler og Sjekk saldo, deretter igjen Åpne skjerm, Beregn leie og så videre, gjentatt 10 ganger, etterfulgt av utlogging (én gang).

Dette er en kraftig innstilling som lar skriptet oppføre seg mer som en ekte bruker. Husk at en ekte bruker ikke logger inn og ut hver gang; de 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. De fleste klarer ikke å forstå forskjellen mellom tempo og tenketid. Den eneste forskjellen er at tempo refererer til forsinkelsen mellom iterasjoner, mens tenketid er forsinkelsen mellom to trinn.

Den anbefalte innstillingen avhenger av testdesignet. Hvis du imidlertid ønsker å bruke aggressiv belastning, bør du vurdere å velge «Så snart forrige iterasjon er avsluttet», som vist nedenfor.

Overnatting

En logg, slik den vanligvis forstås, er en oversikt over alle hendelser mens du kjører LoadRunner. Du kan aktivere loggen slik at den vet hva som skjer mellom applikasjonen din og serveren din.

LoadRunner gir en kraftig loggføringsmekanisme som er robust og skalerbar i seg selv. Den lar deg beholde bare en «standardlogg», en detaljert og konfigurerbar utvidet logg, eller deaktivere logging helt.

En standardlogg er informativ og lettforståelig. Den inneholder akkurat den mengden informasjon du vanligvis trenger for å feilsøke VUser-skriptene dine.

Når det gjelder den utvidede loggen, er all standardlogginformasjon et delsett. I tillegg kan du ha parametersubstitusjon. Dette forteller LoadRunner-komponenten at den skal inkludere fullstendig informasjon om alle parameterne (fra parameterisering), inkludert forespørsler så vel som responsdata.

Hvis du inkluderer «Data returnert av server», vil loggen din bli lengre. Den vil inkludere all HTML, tagger, ressurser og ikke-ressursinformasjon direkte i loggen. Dette alternativet er bare bra hvis du trenger seriøs feilsøking. Vanligvis gjør dette loggfilen veldig stor og ikke lett forståelig.

Som du sikkert har gjettet nå, hvis du velger «Avansert» Trace” vil loggfilen din bli enorm. Du må prøve det. Du vil legge merke til at tiden VuGen bruker også øker betydelig, selv om dette ikke har noen innvirkning på transaksjonsresponstiden som rapporteres av VuGen. Dette er svært avansert informasjon, og den er bare nyttig hvis du forstår den aktuelle applikasjonen, klient-til-server-kommunikasjonen mellom applikasjonen og maskinvaren din, og detaljer på protokollnivå. Vanligvis krever denne informasjonen ekstrem innsats å lese og feilsøke.

Tips:

• Uansett hvor lang tid VuGen bruker når loggen er aktivert, har det ingen innvirkning på transaksjonsresponstiden – loggingsoverhead er ekskludert fra den målte tiden.
• Deaktiver loggen hvis den ikke er nødvendig.
• Deaktiver loggen når du er ferdig med skriptene dine. Hvis du inkluderer skript med logging aktivert, vil kontrolleren kjøre saktere og rapportere irriterende meldinger.
• Deaktivering av loggen vil øke det maksimale antallet brukere du kan simulere fra LoadRunner.
• Vurder å bruke «Send meldinger bare når det oppstår en feil» – dette demper unødvendige informasjonsmeldinger og rapporterer bare feilrelaterte meldinger.

Tenk Times

Think Time er ganske enkelt forsinkelsen mellom to trinn.

Tenketid hjelper med å gjenskape brukeratferd, siden ingen ekte bruker kan bruke et program som en maskin. VuGen genererer tenketid automatisk. Du har fortsatt full kontroll over å fjerne, multiplisere eller variere varigheten av tenketiden.

For å forstå det bedre: en bruker kan åpne en skjerm (et svar etterfulgt av en forespørsel) og deretter skrive inn et brukernavn og passord før de trykker på enter. Den neste interaksjonen mellom applikasjonen og serveren skjer når brukeren klikker på «Logg på». Tiden brukeren brukte på å skrive inn brukernavnet og passordet er «Think Time» i LoadRunner.

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

For å simulere atferd i virkeligheten kan du imidlertid velge «Bruk tilfeldig tenketid» og angi prosentandelene slik du ønsker.

Vurder å bruke «Begrens tenketid» for å begrense det til en legitim periode. Vanligvis er 30 sekunder ganske godt nok.

Hastighetssimulering

Hastighetssimulering refererer ganske enkelt til båndbreddekapasiteten til hver klientmaskin.

Siden vi simulerer tusenvis av V-brukere gjennom LoadRunner, er det bemerkelsesverdig hvor enkelt LoadRunner har gjort simuleringen av båndbredde og nettverkshastighet.

Hvis kundene dine får tilgang til applikasjonen din over 128 kbps, kan du kontrollere det herfra. Du vil kunne simulere virkelighetsoppførsel, noe som skal hjelpe deg med å få riktig ytelsesstatistikk.

Den beste anbefalingen er å sette Bruk maksimal båndbredde. Dette hjelper deg med å ignorere eventuelle nettverksrelaterte ytelsesflaskehalser og fokusere på 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, så dette er i stor grad utenfor omfanget av ytelsesmål. Du kan imidlertid velge hvilken nettleser du ønsker å emulere, som ruten nedenfor viser.

Når spiller det egentlig noen rolle hvilken nettleser du velger i denne konfigurasjonen?

Du bruker denne konfigurasjonen hvis emneapplikasjonen din er en webapplikasjon som returnerer forskjellige svar for forskjellige nettlesere. Du kan for eksempel se forskjellige bilder og innhold for Internet Explorer og Firefox.

En annen viktig innstilling er Simuler nettleserbuffer. Hvis du vil måle responstiden med bufferen aktivert, merk av i denne boksen. Hvis du ser etter verst tenkelige situasjoner, er det åpenbart ikke en vurdering.

Hvis du laster ned ressurser som ikke er i HTML, kan LoadRunner laste ned CSS, JS og andre rike medier. Dette alternativet bør fortsatt være avmerket. Hvis du ønsker å fjerne det fra ytelsestestdesignet ditt, kan du fjerne avmerkingen.

Proxy

Det er best å fjerne proxy-serveren helt fra Test miljø — en proxy som sitter i stien gjør testresultatene upålitelige. Du kan imidlertid støte på situasjoner der det er uunngåelig. I en slik situasjon tilbyr LoadRunner proxy-innstillinger.

Du kommer til å jobbe (eller burde jobbe) med innstillingen Ingen proxy. Du kan hente den fra standardnettleseren din. Men ikke glem å sjekke hvilken nettleser som er satt som standard og hva proxy-konfigurasjonen for den nettleseren er.

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

Bruk dette skjermbildet til å oppgi et brukernavn og passord for å bli autentisert på proxy-serveren. Klikk på OK for å lukke skjermbildet.

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

Neste kommer korrelasjon, kjører scenariet i controller, og lesing resulterer i LoadRunner-analyse. Se LoadRunner-arkitektur og Load Testing guider.

Spørsmål og svar