Et innspilt skript kan simulere en virtuell bruker; det kan imidlertid hende at bare opptak ikke er nok til å replikere den “virkelige brukeradferden”.
Når et skript er spilt inn, dekker det enkelt og rett flyt av emnesøknaden. Mens en ekte bruker kan utføre flere iterasjoner av en hvilken som helst prosess før han logger ut. Forsinkelsen mellom å klikke på knappene (tenktid) vil variere fra person til person. Sjansen er at noen reelle brukere får tilgang til applikasjonen din via DSL og noen får tilgang til den via en oppringt telefon. Så, for å få den virkelige følelsen av sluttbruker, må vi forbedre skriptene våre for å være nøyaktig samsvarende, eller i det minste veldig nært i oppførsel til virkelige brukere.
Ovennevnte er den viktigste betraktningen når du gjennomfører "Performance Testing", men det er mer med et VU-skript. Hvordan vil du måle nøyaktig hvor lang tid en bruker bruker når SUL gjennomgår en ytelsestest? Hvordan ville du vite om brukeren har gått gjennom eller mislyktes på et bestemt tidspunkt? Hva er årsaken bak feilen, om noen backend-prosesser mislyktes eller serverressursene var begrenset?
Vi må forbedre skriptet vårt for å svare på alle spørsmålene ovenfor.
- Bruke transaksjoner
- Forstå Think Time, Rendezvous Points og Comments
- Sette inn funksjoner gjennom menyen
- Hva er parametrisering?
- Innstillinger for kjøretid og deres innvirkning på VU-simulering
- Kjør Logic
- Pacing
- Logg
- Think Times
- Hastighetssimulering
- Nettleseremulering
- Fullmektig
Bruke transaksjoner
Transaksjoner er mekanikk for å måle responstid for servere for enhver operasjon. Med enkle ord hjelper bruken av “Transaksjon” til å måle tiden det tar for systemet 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.
Å bruke transaksjoner er grei. Bare skriv en kodelinje før forespørsel 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 (“Transaksjonsnavn”);
For å avslutte transaksjonen, bruk denne kodelinjen:
lr_end_transaction (“Transaksjonsnavn”,);
- LR_AUTO
- LR_PASS
- LR_FAIL
Eksempel:
lr_end_transaction (“My_Login”, LR_AUTO);
lr_end_transaction (“Business_Workflow_Transaction Name”, LR_FAIL);
Poeng å merke seg:
- Ikke glem, du jobber med “C” og det er et skift mellom store og små bokstaver.
- Periode (.) Er ikke tillatt i transaksjonsnavnet, selv om du kan bruke mellomrom og understreking.
- Hvis du har forgrenet koden din 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 etc.)
- Når du bruker transaksjoner, må du forsikre deg om at det ikke er noen think_time- uttalelse som ligger i en annen retning, ellers vil transaksjonen alltid inkludere den perioden.
- Siden LoadRunner krever en konstant streng som transaksjonsnavn, er et vanlig problem når du bruker transaksjon, uoverensstemmelse med streng. Hvis du gir et annet navn når du åpner og lukker en transaksjon, vil du ha minst to feil. Siden transaksjonen du åpnet aldri ble avsluttet, vil LoadRunner gi en feil. Dessuten ble transaksjonen du prøver å lukke, aldri åpnet, og dermed en feil.
- Kan du bruke din intelligens og svare på deg selv hvilken av feilene ovenfor blir rapportert først? For å validere svaret ditt, hvorfor ikke gjøre din egen feil? Hvis du hadde svart riktig, er du på rett spor. 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 svar når du bruker transaksjoner.
Forstå Think Time, Rendezvous Points og Comments
Rendezvous-poeng
Rendezvous Points betyr "møtepunkter". Det er bare en uttalelseslinje som forteller LoadRunner å innføre samtidighet. Du setter inn møteplasser i VUser-skript for å etterligne stor brukerbelastning på serveren.
Rendezvous-punkter instruerer VUser om å vente under testutførelse på at flere VUser ankommer et bestemt punkt, slik at de samtidig kan utføre en oppgave. For eksempel, for å etterligne toppbelastning på bankserveren, kan du sette inn et møtepunkt som instruerer 100 VUser om å sette inn kontanter på kontoene sine samtidig. Dette kan enkelt oppnås ved hjelp av rendezvous.
Hvis møtepunktene ikke er plassert riktig, vil brukeren få tilgang til forskjellige deler av applikasjonen - selv for samme skript. Dette er fordi hver VUser får forskjellig responstid og dermed få brukere henger etter.
Syntaks: lr_rendesvous (“Logisk navn”);
Beste praksis:
- Prefiks et møtepunkt med “rdv_” for bedre kodelesbarhet; f.eks. “rdv_Login”
- Fjern eventuelle øyeblikkelige uttalelser om tenktid
- Bruke møtepunkter i en skriptvisning (etter innspilling)
Kommentarer
Legg til kommentarer for å beskrive en aktivitet, et stykke kode eller en kodelinje. Kommentarer hjelper deg med å gjøre koden forståelig for alle som henviser til den i fremtiden. De gir informasjon om spesifikk drift og skiller to seksjoner for å skille.
Du kan legge til kommentarer
- Under opptak (ved hjelp av verktøy)
- Etter innspilling (direkte skriving i 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 å 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.
Du finner Steps Toolbar under View àSteps Toolbox.
Dette åpner et sidevindu, se på øyeblikksbildet:
Hva er parametrisering?
En parameter i VUGen er en container som inneholder en registrert verdi som erstattes for forskjellige brukere.
Under utførelsen av skriptet (i VUGen eller Controller) erstatter verdien fra en ekstern kilde (som .txt, XML eller database) den forrige verdien av parameteren.
Parameterisering er nyttig for å sende dynamiske (eller unike) verdier til serveren, for eksempel; det er ønskelig med en forretningsprosess for å kjøre 10 iterasjoner, men å velge unikt brukernavn hver gang.
Det hjelper også til å stimulere ekte oppførsel til fagsystemet. Ta en titt på eksemplet nedenfor:
Eksempel på problemer:
Forretningsprosessen fungerer bare for den gjeldende datoen 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 cache med data som sendes til og fra serveren. Som et resultat mottar ikke serveren en reell brukeradferd (i tilfelle serveren kjører annen algoritme avhengig av søkekriterier). Mens VUser-skript kjøres vellykket, vil ikke resultatstatistikken som er tegnet ikke være meningsfull. Ved å bruke forskjellige data gjennom parameterisering hjelper det å emulere aktivitet på serveren (prosedyrer osv.) Og utøve systemet.
En dato som er hardkodet i VUser under opptak, er kanskje ikke lenger gyldig når datoen har gått. Parameterisering av datoen gjør at brukerutførelse kan lykkes ved å erstatte den hardkodede datoen. Slike felt eller forespørsler er de rette kandidatene for parameterisering.
Klikk her hvis videoen ikke er tilgjengelig
Innstillinger for kjøretid og deres innvirkning på VU-simulering
Innstillinger for kjøretid har like mye betydning som VUGen-skriptet ditt. Med forskjellige konfigurasjoner kan du få forskjellige testdesigner. Dette er grunnen til at du kan havne i ikke-repeterbare resultater hvis innstillingene for kjøretid ikke er konsistente. La oss diskutere hvert attributt en etter en.
Kjør Logic
Run Logic definerer antall ganger alle handlinger skal utføres, unntatt vuser_init og vuser_end.
Sannsynligvis gjør dette tydeligere hvorfor LoadRunner foreslår å beholde all innloggingskoden i vuser_init, og Logout del i vuser_end, begge eksklusivt.
Hvis du har opprettet flere handlinger, la oss si, Logg på, Åpne skjerm, Beregn leie, Send inn midler, Sjekk saldo og avlogging, så vil scenariet nedenfor finne sted for hver bruker:
Alle brukere vil logge inn, utføre åpen skjerm, beregne utleie, sende inn midler, sjekke saldo - deretter - igjen Åpne skjerm, beregne utleie ... og så videre - itere 10 ganger - etterfulgt av avlogging (en gang).
Dette er en kraftig innstilling som gjør det mulig å oppføre seg 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 klarer ikke folk å forstå forskjellen mellom tempo og tenketid. Den eneste forskjellen er at "pacing refererer til forsinkelsen mellom iterasjoner" mens tenktid er forsinkelsen mellom to trinn.
Anbefalt innstilling avhenger av testdesignet. Men hvis du ønsker å ha aggressiv belastning, bør du vurdere å velge "Så snart den forrige iterasjonen slutter"
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 din og serveren din.
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 kunnskapen du vanligvis trenger å feilsøke VUser-skriptene dine.
Når det gjelder utvidet logg, er all standardlogginformasjonen et delmengde. I tillegg kan du ha parameterutskifting. Dette forteller LoadRunner-komponenten å inkludere fullstendig informasjon om alle parametrene (fra parameterisering) inkludert forespørsler, samt svardata.
Hvis du inkluderer "Data returnert av server", vil loggen din gå i lengde. Dette inkluderer all HTML, koder, ressurser, informasjon som ikke er ressurser inkludert rett i loggen. Alternativet er bare bra hvis du trenger alvorlig 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. Du vil legge merke til hvor lang tid det tar av VUGen også har økt betydelig, selv om dette ikke vil ha noen innvirkning på transaksjonens svartid rapportert av VUGen. Dette er imidlertid veldig forhåndsinformasjon og kanskje nyttig hvis du forstår emneapplikasjonen, klient til serverkommunikasjon mellom applikasjonen og maskinvaren, samt detaljer om protokollnivå. Vanligvis er denne informasjonen død av essens, siden den krever ekstrem innsats for å forstå og feilsøke.
Tips:
- Uansett hvor lang tid VUGen tar når logg er aktivert, har det ingen innvirkning på transaksjonens responstid. HP kaller dette fenomenet som ”toppmoderne teknologi.”
- Deaktiver logg hvis det ikke er nødvendig.
- Deaktiver logg når du er ferdig med skriptene. Inkludering av skript med logging aktivert vil føre til at kontrolleren kjører saktere og rapporterer mase meldinger.
- Deaktivering av logg vil øke kapasiteten til maksimalt antall brukere du kan simulere fra LoadRunner.
- Vurder å bruke "Send melding bare når feil oppstår" - dette vil dempe unødvendige informasjonsmeldinger og kun rapportere feilrelaterte meldinger.
Think Times
Think Time er rett og slett forsinkelsen mellom to trinn.
Think Time hjelper med å replikere brukeratferd siden ingen reell bruker kan bruke noe program som en maskin (VUGen). VUGen genererer tenketid automatisk. Du har fortsatt full kontroll for å fjerne, multiplisere eller svinge varigheten av tenketiden.
For å forstå mer, kan en bruker for eksempel åpne en skjerm (det vil si et svar etterfulgt av en forespørsel) og deretter oppgi at det er brukernavn og passord før du trykker på enter. Den neste interaksjonen mellom applikasjonen og serveren vil skje når han klikker "Logg inn". Tiden en bruker tok å skrive inn brukernavnet og passordet er Think Time i LoadRunner.
Hvis du ønsker å simulere aggressiv belastning på applikasjonen, bør du vurdere å deaktivere tenketiden helt.
For å simulere en virkelig lignende oppførsel, kan du imidlertid "Bruker tilfeldig tenketid" og angi prosentandeler 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åndbreddekapasiteten for hver klientmaskin.
Siden vi simulerer tusenvis av brukere gjennom LoadRunner, er det utrolig hvor enkelt LoadRunner har laget for å kontrollere båndbredde / nettverkshastighetssimulering.
Hvis du er kunder som får tilgang til applikasjonen din over 128 Kbps, kan du kontrollere den herfra. Du får simulere “ekte oppførsel”, noe som kan hjelpe deg med å få riktig ytelsesstatistikk.
Den beste anbefalingen er å sette til Bruk maksimal båndbredde. Dette vil bidra til å se bort fra nettverksrelaterte ytelsesflaskehalser og fokusere på eventuelle problemer i applikasjonen først. Du kan alltid kjøre testen flere ganger for å se varierende atferd under forskjellige omstendigheter.
Nettleseremulering
Brukeropplevelse avhenger ikke av nettleseren en sluttbruker bruker. Det er klart at dette er utenfor omfanget av ytelsesmål. Du kan imidlertid velge hvilken nettleser du vil etterligne.
Kan du svare på deg selv når det virkelig betyr noe for deg å velge riktig nettleser i denne konfigurasjonen?
Du vil bruke denne konfigurasjonen hvis du er temaapplikasjon er et webapplikasjon, og returnerer forskjellige svar for forskjellige nettlesere. For eksempel får du se forskjellige bilder og innhold for IE og Firefox etc.
En annen viktig innstilling er Simuler nettleserbufferen. Hvis du vil måle responstiden når hurtigbufferen er aktivert, merker du av i denne boksen. Hvis du leter etter en verste situasjon, er dette åpenbart ikke en vurdering.
Last ned ressurser som ikke er HTML, slik at LoadRunner kan laste ned CSS, JS og andre rike medier. Dette bør forbli sjekket. Men hvis du vil eliminere dette fra ytelsestestdesignet ditt, kan du fjerne merket for dette.
Fullmektig
Det er best å eliminere proxy fullstendig fra testmiljøet ditt - dette vil gjøre testresultatene upålitelige. Imidlertid kan du møte situasjoner der det er uunngåelig. I en slik situasjon letter LoadRunner deg med proxy-innstillinger.
Du jobber (eller burde jobbe) uten proxy-innstilling. Du kan få det fra standard nettleser. Ikke glem å sjekke hvilken nettleser som er satt til standard og hvilken proxy-konfigurasjon for standard nettleser.
Hvis du bruker en proxy og det krever godkjenning (eller et skript), kan du klikke på Autentiser-knappen som fører til et nytt vindu. Se skjermbildet nedenfor.
Bruk dette skjermbildet til å oppgi brukernavn og passord for å bli autentisert på proxy-serveren. Klikk OK for å lukke skjermen.
Gratulerer. Du er ferdig med å konfigurere VUGen-skriptet. Ikke glem å konfigurere det for alle VUser-skriptene.