Et optaget script kan simulere en virtuel bruger; dog kan en simpel optagelse muligvis ikke være nok til at replikere den “rigtige brugeradfærd”.
Når et script er optaget, dækker det enkelt og lige flow af emneansøgningen. Mens en reel bruger kan udføre flere gentagelser af enhver proces, før han logger ud. Forsinkelsen mellem at klikke på knapper (tænketid) varierer fra person til person. Chancerne er, at nogle rigtige brugere får adgang til din applikation via DSL, og nogle har adgang til den via en opkaldsforbindelse. Så for at få den virkelige fornemmelse af slutbrugeren er vi nødt til at forbedre vores scripts for at være nøjagtige match eller i det mindste meget tæt på adfærd til rigtige brugere.
Ovenstående er den mest vigtige overvejelse, når man udfører "Performance Testing", men der er mere ved et VU-script. Hvordan vil du måle den nøjagtige tid, det tager af en VUser, når SUL gennemgår en præstationstest? Hvordan ville du vide, om VUser er gået igennem eller mislykkes på et bestemt tidspunkt? Hvad er årsagen til fejlen, hvad enten en backend-proces mislykkedes, eller serverressourcerne var begrænsede?
Vi er nødt til at forbedre vores script for at hjælpe med at besvare alle ovenstående spørgsmål.
- Brug af transaktioner
- Forstå tænketid, Rendezvous-punkter og kommentarer
- Indsættelse af funktioner gennem menuen
- Hvad er parametrering?
- Kørselstidsindstillinger og deres indvirkning på VU-simulering
- Kør logik
- Pacing
- Log
- Think Times
- Hastighedssimulering
- Browseremulering
- Proxy
Brug af transaktioner
Transaktioner er mekanik til måling af serverens responstid for enhver operation. Med enkle ord hjælper brugen af "Transaktion" med at måle den tid, systemet tager for en bestemt anmodning. Det kan være så lille som et klik på en knap eller et AJAX-opkald, når det mister fokus fra tekstfeltet.
Anvendelse af transaktioner er ligetil. Skriv bare en linie kode, før anmodningen sendes til serveren, og luk transaktionen, når anmodningen slutter. LoadRunner kræver kun en streng som transaktionsnavn.
For at åbne en transaktion skal du bruge denne kodelinje:
lr_start_transaction (“Transaktionsnavn”);
For at lukke transaktionen skal du bruge denne kodelinje:
lr_end_transaction ("Transaktionsnavn", );
- LR_AUTO
- LR_PASS
- LR_FAIL
Eksempel:
lr_end_transaction (“My_Login”, LR_AUTO);
lr_end_transaction (“Business_Workflow_Transaction Name”, LR_FAIL);
Punkter at bemærke:
- Glem ikke, du arbejder med “C”, og det er et skift mellem store og små bogstaver.
- Periode (.) Er ikke tilladt i transaktionsnavnet, selvom du kan bruge mellemrum og understregning.
- Hvis du har forgrenet din kode godt og tilføjet kontrolpunkter for at bekræfte svaret fra serveren, kan du bruge brugerdefineret fejlhåndtering, såsom LR_PASS eller LR_FAIL. Ellers kan du bruge LR_AUTO, og LoadRunner håndterer automatisk serverfejl (HTTP 500, 400 osv.)
- Når du anvender transaktioner, skal du sørge for, at der ikke er noget tænk_tid- udsagn, eller at din transaktion ellers altid inkluderer den periode.
- Da LoadRunner kræver en konstant streng som transaktionsnavn, er et almindeligt problem ved anvendelse af transaktion uoverensstemmelse med streng. Hvis du giver et andet navn, når du åbner og lukker en transaktion, får du mindst to fejl. Da den transaktion, du åbnede, aldrig blev afsluttet, vil LoadRunner give en fejl. Desuden blev den transaktion, du forsøger at lukke, aldrig åbnet, hvilket resulterede i en fejl.
- Kan du bruge din intelligens og svare på dig selv, hvilken af ovenstående fejl rapporteres først? Hvorfor ikke lave din egen fejl for at validere dit svar? Hvis du havde svaret rigtigt, er du på rette spor. Hvis du svarede forkert, skal du fokusere.
- Da LoadRunner automatisk tager sig af synkronisering af anmodninger og svar, behøver du ikke bekymre dig om svar, når du anvender transaktioner.
Forstå tænketid, Rendezvous-punkter og kommentarer
Rendezvous-point
Rendezvous Points betyder "mødepunkter". Det er kun en udsagnslinje, der beder LoadRunner om at indføre samtidighed. Du indsætter rendezvous-punkter i VUser-scripts for at efterligne stor brugerbelastning på serveren.
Rendezvous-punkter instruerer VUser om at vente under testudførelse på, at flere VUser ankommer til et bestemt punkt, så de samtidig kan udføre en opgave. For eksempel for at emulere spidsbelastning på bankserveren kan du indsætte et rendezvous-punkt, der instruerer 100 VUser om at indbetale kontanter på deres konti på samme tid. Dette kan let opnås ved hjælp af rendezvous.
Hvis mødepunkterne ikke er placeret korrekt, får VUser adgang til forskellige dele af applikationen - selv for det samme script. Dette skyldes, at hver VUser får forskellig responstid, og derfor er der få brugere, der halter bagefter.
Syntaks: lr_rendesvous (“Logisk navn”);
Bedste praksis:
- Prefix et rendezvous-punkt med “rdv_” for bedre kodelæsbarhed; f.eks. “rdv_Login”
- Fjern eventuelle øjeblikkelige udsagn om tænketid
- Anvendelse af mødepunkter i en scriptvisning (efter optagelse)
Kommentarer
Tilføj kommentarer for at beskrive en aktivitet, et stykke kode eller en kodelinje. Kommentarer hjælper med at gøre koden forståelig for alle der henviser til den i fremtiden. De giver information om specifik drift og adskiller to sektioner til skelnen.
Du kan tilføje kommentarer
- Under optagelse (ved hjælp af værktøj)
- Efter optagelse (direkte skrivning i kode)
Bedste praksis: Marker eventuelle kommentarer øverst i hver scriptfil
Indsættelse af funktioner gennem menuen
Mens du direkte kan skrive enkle kodelinjer, skal du muligvis have en anelse for at huske en funktion. Du kan også bruge trinværktøjskasse (kendt som Indsæt funktion før version 12) til at finde og indsætte en hvilken som helst funktion direkte i dit script.
Du kan finde trinværktøjslinjen under Vis på trinværktøjskasse.
Dette åbner et sidevindue, se på snapshotet:
Hvad er parametrering?
En parameter i VUGen er en container, der indeholder en registreret værdi, der erstattes for forskellige brugere.
Under udførelsen af scriptet (i VUGen eller Controller) erstatter værdien fra en ekstern kilde (som .txt, XML eller database) den tidligere værdi af parameteren.
Parameterisering er nyttig til f.eks. At sende dynamiske (eller unikke) værdier til serveren; en forretningsproces ønskes til at køre 10 iterationer, men vælger unikt brugernavn hver gang.
Det hjælper også med at stimulere ægte adfærd til motivsystemet. Se eksemplet nedenfor:
Eksempel på problemer:
Forretningsprocessen fungerer kun for den aktuelle dato, der kommer fra serveren, og kan derfor ikke sendes som en hardkodet anmodning.
Undertiden videregiver klientapplikationen et unikt ID til serveren (for eksempel session_id) for at processen kan fortsætte (selv for en enkelt bruger) - I et sådant tilfælde hjælper parametrering.
Ofte vedligeholder klientapplikationen en cache med data, der sendes til og fra serveren. Som et resultat modtager serveren ikke en reel brugeradfærd (hvis serveren kører forskellige algoritmer afhængigt af søgekriterier). Mens VUser-scriptet udføres med succes, vil de tegnede præstationsstatistikker ikke være meningsfulde. Brug af forskellige data gennem parametrering hjælper med at emulere serversides aktivitet (procedurer osv.) Og udøve systemet.
En dato, der er hårdkodet i VUser under optagelse, er muligvis ikke længere gyldig, når denne dato er passeret. Parametrering af datoen gør det muligt for VUser-udførelse at lykkes ved at erstatte den hårdkodede dato. Sådanne felter eller anmodninger er de rigtige kandidater til parametrering.
Klik her, hvis videoen ikke er tilgængelig
Kørselstidsindstillinger og deres indvirkning på VU-simulering
Indstillinger for kørselstid har lige så stor betydning som dit VUGen-script. Med forskellige konfigurationer kan du få forskellige testdesign. Dette er grunden til, at du muligvis ender med ikke-gentagelige resultater, hvis indstillingerne for kørselstid ikke er ens. Lad os diskutere hver attribut en efter en.
Kør logik
Kør logik definerer antallet af gange, alle handlinger vil blive udført, undtagen vuser_init og vuser_end.
Sandsynligvis gør dette klarere, hvorfor LoadRunner foreslår at holde al login-koden inden for vuser_init, og Logout-del i vuser_end, begge udelukkende.
Hvis du har oprettet flere handlinger, lad os sige, Log ind, Åbn skærm, Beregn leje, Indsend midler, Tjek saldo og log af, så vil nedenstående scenarie finde sted for hver VUser:
Alle VU-brugere logger ind, udfører åben skærm, beregner udlejning, indsender midler, tjekker saldo - derefter - igen Åbn skærm, beregner huslejer ... og så videre - itererende 10 gange - efterfulgt af aflogning (en gang).
Dette er en stærk indstilling, der gør det muligt at handle mere som en rigtig bruger. Husk, at en rigtig bruger ikke logger ind og logger ud hver gang - han gentager normalt de samme trin.
Hvor mange gange klikker du på "indbakke", når du tjekker din e-mail inden logout?
Pacing
Dette er vigtigt. For det meste er folk ikke i stand til at forstå forskellen mellem tempo og tænketid. Den eneste forskel er, "pacing henviser til forsinkelsen mellem iterationer", hvorimod tænkningstid er forsinkelsen mellem 2 trin.
Anbefalet indstilling afhænger af testdesignet. Men hvis du ønsker at have aggressiv belastning, skal du overveje at vælge "Så snart den tidligere iteration slutter"
Log
En log (som almindeligt forstået) er en bogføring af alle begivenheder, mens du kører LoadRunner. Du kan aktivere log for at vide, hvad der sker mellem din applikation og din server.
LoadRunner giver en kraftig logningsmekanisme, der er robust og skalerbar alene. Det giver dig mulighed for kun at opbevare "Standardlog" eller en detaljeret, konfigurerbar udvidet log eller deaktivere den helt.
En standardlog er informativ og let forståelig. Den indeholder lige den rigtige mængde viden, som du generelt skal bruge til fejlfinding af dine VUser-scripts.
I tilfælde af udvidet log er alle standardlogoplysningerne en delmængde. Derudover kan du have parameterudskiftning. Dette fortæller LoadRunner-komponenten at inkludere komplet information om alle parametrene (fra parametrering) inklusive anmodninger samt svardata.
Hvis du inkluderer "Data returneret af server", vil din log blive lang. Dette inkluderer alle HTML, tags, ressourcer, informationer, der ikke er ressourcer, inkluderet lige i loggen. Indstillingen er kun god, hvis du har brug for seriøs fejlfinding. Normalt gør dette logfilen meget stor i størrelse og ikke let forståelig.
Som du kunne have gættet nu, hvis du vælger "Advance Trace", vil din logfil være massiv. Du skal prøve det. Du vil bemærke, at den tid, det tager af VUGen, også er steget markant, selvom dette ikke har nogen indflydelse på transaktionens svartid rapporteret af VUGen. Dette er imidlertid meget forhåndsinformation og måske nyttigt, hvis du forstår emneansøgningen, klient til serverkommunikation mellem din applikation og hardware samt detaljer om protokolniveau. Normalt er disse oplysninger døde, fordi de kræver ekstrem indsats for at forstå og fejlfinde.
Tips:
- Uanset hvor meget tid VUGen tager, når log er aktiveret, har det ingen indflydelse på transaktionens responstid. HP kalder dette fænomen som ”avanceret teknologi”.
- Deaktiver log, hvis det ikke er nødvendigt.
- Deaktiver log, når du er færdig med dine scripts. Inkludering af scripts med logning aktiveret får controlleren til at køre langsommere og rapportere nagende meddelelser.
- Deaktivering af log vil øge kapaciteten for det maksimale antal brugere, du kan simulere fra LoadRunner.
- Overvej at bruge "Send kun besked, når der opstår en fejl" - dette dæmper unødvendige informationsmeddelelser og rapporterer kun fejlrelaterede meddelelser.
Think Times
Think Time er simpelthen forsinkelsen mellem to trin.
Think Time hjælper med at replikere brugeradfærd, da ingen rigtig bruger kan bruge nogen applikationer som en maskine (VUGen). VUGen genererer tænketid automatisk. Du har stadig fuld kontrol over at fjerne, formere eller svinge varigheden af tænketiden.
For at forstå mere kan en bruger f.eks. Åbne en skærm (det vil sige et svar efterfulgt af en anmodning) og derefter angive, at det er brugernavn og adgangskode, inden han trykker på enter. Den næste interaktion mellem applikationen og serveren sker, når han klikker på "Log ind". Den tid, en bruger tog at skrive sit brugernavn og sin adgangskode, er Think Time i LoadRunner.
Hvis du ønsker at simulere aggressiv belastning på applikationen, skal du overveje at deaktivere tænketid fuldstændigt.
For at simulere en rigtig lignende opførsel kan du dog "Bruger tilfældig tænketid" og indstille procenterne som ønsket.
Overvej at bruge Begræns tænketid til en legitim periode. Normalt er 30 sekunder ret gode nok.
Hastighedssimulering
Hastighedsimulering refererer simpelthen til båndbreddekapacitet for hver klientmaskine.
Da vi simulerer tusinder af VUser'er gennem LoadRunner, er det forbløffende, hvor simpelt LoadRunner har lavet for at kontrollere båndbredde / netværkshastighedsimulering.
Hvis du er kunde, der har adgang til din applikation over 128 Kbps, kan du styre den herfra. Du kommer til at simulere "ægte opførsel", som skal hjælpe med at få de rigtige præstationsstatistikker.
Den bedste anbefaling er at indstille til Brug maksimal båndbredde. Dette hjælper med at se bort fra netværksrelaterede ydeevne flaskehalse og fokusere på eventuelle problemer i applikationen først. Du kan altid køre testen flere gange for at se varierende adfærd under forskellige omstændigheder.
Browseremulering
Brugeroplevelse afhænger ikke af den browser en slutbruger bruger. Det er klart, at dette ligger uden for præstationsmålene. Du kan dog vælge, hvilken browser du vil efterligne.
Kan du svare dig selv, hvornår det virkelig betyder noget for dig at vælge den rigtige browser i denne konfiguration?
Du vil bruge denne konfiguration, hvis du er emne, applikation er en webapplikation, der returnerer forskellige svar for forskellige browsere. For eksempel får du se forskellige billeder og indhold til IE og Firefox osv.
En anden vigtig indstilling er Simuler browser-cache. Hvis du vil måle svartiden, når cache er aktiveret, skal du markere dette felt. Hvis du leder efter en værste tilfælde, er dette naturligvis ikke en overvejelse.
Download ikke-HTML-ressourcer gør det muligt for LoadRunner at downloade CSS, JS og andre rich media. Dette skal forblive kontrolleret. Hvis du derimod skal fjerne dette fra dit ydelsestestdesign, kan du fjerne markeringen fra dette.
Proxy
Det er bedst at fjerne proxy fuldstændigt fra dit testmiljø - dette vil gøre testresultaterne upålidelige. Du kan dog stå over for situationer, hvor det er uundgåeligt. I en sådan situation letter LoadRunner dig med proxyindstillinger.
Du arbejder (eller skal arbejde) uden indstilling for proxy. Du kan få det fra din standardbrowser. Glem dog ikke at kontrollere, hvilken browser der er indstillet til standard, og hvilken proxy-konfiguration til standardbrowser er.
Hvis du bruger en proxy, og det kræver godkendelse (eller et script), kan du klikke på knappen Godkend, der fører til et nyt vindue. Se nedenstående skærmbillede.
Brug denne skærm til at angive brugernavn og adgangskode for at blive godkendt på proxyserveren. Klik på OK for at lukke skærmen.
Tillykke. Du er færdig med at konfigurere dit VUGen-script. Glem ikke at konfigurere det til alle dine VUser-scripts.