Parametrering, funktioner, transaktioner i LoadRunner

Et optaget script kan simulere en virtuel bruger; dog er en simpel optagelse muligvis ikke nok til at genskabe den reelle brugeradfærd.

Når et script optages, dækker det en enkelt, lige proces gennem den pågældende applikation. En rigtig bruger kan udføre flere iterationer af en proces, før vedkommende logger ud. Forsinkelsen mellem at klikke på knapper (betænkningstiden) varierer fra person til person, og nogle brugere når din applikation via en hurtig forbindelse, mens andre ikke gør. Så for at få den virkelige fornemmelse af en slutbruger, er vi nødt til at forbedre vores scripts, så de opfører sig meget tæt på rigtige brugere.

Det er den vigtigste overvejelse, når man udfører "Test af ydeevne", men der er mere i et VUser-script. Hvordan måler man den tid, det tager for en VUser, mens System Under Load (SUL) testes? Hvordan ved man, om VUser'en bestod eller mislykkedes på et bestemt tidspunkt, og om en backend-proces mislykkedes, eller om serverressourcerne løb tør for strøm?

Vi er nødt til at forbedre vores manuskript for at kunne besvare alle ovenstående spørgsmål.

Mærkebemærkning: VuGen blev lanceret som HP, derefter Micro Focus, og er nu en del af OpenText Professionel præstationsteknikFunktionerne og indstillingerne nedenfor er uændrede.

Brug af transaktioner

Transaktioner måler serverens svartid for enhver handling. Kort sagt måler en "transaktion" den tid, systemet bruger på en bestemt anmodning. Det kan være så lille som et klik på en knap eller et AJAX-kald, der udløses, når en tekstboks mister fokus.

Det er ligetil at anvende transaktioner. Skriv én linje kode, før anmodningen foretages, 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(“Transaction Name”);

For at lukke transaktionen skal du bruge denne kodelinje:

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

Det fortæller LoadRunner, om netop denne transaktion var vellykket eller mislykket. De mulige parametre kunne 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 noter: Uddragene gengives præcis som de er udgivet, inklusive typografiske citater. Et rigtigt VuGen-script kræver direkte ASCII-dobbelte anførselstegn, så skriv dem igen, hvis du kopierer denne kode.

Bemærk:

• Glem ikke, du arbejder med "C", og det er et sprog, der skelner mellem store og små bogstaver.
• Punktumtegnet (.) er ikke tilladt i et transaktionsnavn, selvom du kan bruge mellemrum og understregninger.
• Hvis du har forgrenet din kode godt og tilføjet checkpoints for at verificere svaret fra serveren, kan du bruge brugerdefineret fejlhåndtering såsom LR_PASS eller LR_FAIL. Ellers kan du bruge LR_AUTO, og LoadRunner vil automatisk håndtere serverfejl (HTTP 500, 400 osv.).
• Når du anvender transaktioner, skal du sørge for, at der ikke er nogen tanketidsopgørelse klemt inde i transaktionen, ellers vil den periode altid blive inkluderet i transaktionen.
• Da LoadRunner kræver en konstant streng som transaktionsnavn, er et almindeligt problem ved anvendelse af transaktioner en uoverensstemmelse mellem strengene. Hvis du angiver et forskelligt navn, når du åbner og lukker en transaktion, vil du få mindst 2 fejl. Den transaktion, du åbnede, blev aldrig lukket, så LoadRunner giver en fejl; og den transaktion, du forsøger at lukke, blev aldrig åbnet, hvilket giver en anden fejl.
• Begge fejl vises i afspilningsloggen, så når en af ​​dem rapporteres, skal du først kontrollere transaktionsnavnet på åbnings- og slutopgørelserne.
• Da LoadRunner automatisk tager sig af synkronisering af anmodninger og svar, behøver du ikke bekymre dig om svaret, når du anvender transaktioner.

Mødepunkter, kommentarer og scriptfunktioner

Tre mindre forbedringer får et script til at opføre sig og læse som produktionskode: mødesteder, kommentarer og funktionsbrowseren, der er indbygget i VuGen.

Rendezvous Points

Et mødested er et "mødested". Det er en enkelt sætning, der fortæller LoadRunner at introducere samtidighed. Du indsætter mødesteder i VUser-scripts for at emulere en høj brugerbelastning på serveren.

Mødepunkter instruerer en V-bruger til at vente under udførelsen, indtil flere V-brugere ankommer til et bestemt punkt, så de kan udføre en opgave samtidigt. For eksempel, for at efterligne spidsbelastning på en bankserver, indsæt et mødepunkt, der instruerer 100 V-brugere til at indsætte kontanter på samme tid.

Hvis mødestederne ikke er placeret korrekt, vil V-brugerne tilgå forskellige dele af applikationen, selv for det samme script. Dette skyldes, at hver V-bruger får en forskellig svartid, og derfor halter nogle få brugere bagefter.

Syntaks:

lr_rendezvous(“Logical Name”);

Rettelsesnotat: den udgivne side staver dette lr_rendesvousDet korrekte funktionsnavn er lr_rendezvous; den stavefejlagtigt stavede formular vil ikke kompileres.

Bedste praksis:

• Præfiks et mødepunkt med "rdv_" for bedre kodelæsbarhed; f.eks. "rdv_Login"
• Fjern alle umiddelbart tilstødende tænketidsudsagn
• Anvend mødesteder i scriptvisning efter optagelse

Scriptvisningen nedenfor viser en rendezvous-sætning indsat i en optaget handling:

Kommentarer

Tilføj kommentarer for at beskrive en aktivitet, et stykke kode eller en linje kode. Kommentarer hjælper med at gøre koden forståelig for alle, der henviser til den i fremtiden. De giver information om en specifik handling og adskiller to sektioner for at skelne mellem dem.

Du kan tilføje kommentarer

• Under optagelse (ved brug af værktøjet)
• Efter optagelse (direkte skrivning i kode)

Bedste øvelse: Marker eventuelle kommentarer øverst i hver scriptfil.

Indsættelse af funktioner via menuen

Selvom du kan skrive simple kodelinjer direkte, skal du muligvis bruge et fingerpeg for at huske en funktion. Du kan også bruge Steps Toolbox (kendt som Insert Function før version 12) til at finde og indsætte enhver funktion direkte i dit script.

Du kan finde Trinværktøjskassen under Vis → Trinværktøjskasse, som vist nedenfor.

Dette åbner et sidevindue. Se på snapshottet:

Hvad er parametrisering?

En parameter i VuGen er en beholder, der indeholder en registreret værdi, som erstattes for forskellige brugere.

Under udførelsen af ​​scriptet (i VuGen eller controller), erstatter en værdi fra en ekstern kilde (f.eks. en .txt-fil, XML eller en database) den forrige værdi af parameteren.

Parameterisering er nyttig til at sende dynamiske (eller unikke) værdier til serveren. For eksempel kan en forretningsproces være nødt til at køre 10 iterationer, mens der vælges et unikt brugernavn hver gang.

Det hjælper også med at simulere adfærd i virkeligheden i forhold til det pågældende system. Se på eksemplerne nedenfor.

Eksempler på problemer:

• En forretningsproces fungerer kun for den aktuelle dato, som kommer fra serveren, så den kan ikke sendes som en hardcoded anmodning.
• Nogle gange sender klientapplikationen et unikt ID til serveren (for eksempel session_id), så processen kan fortsætte, selv for en enkelt bruger. I sådanne tilfælde hjælper parametrisering.
• Klientapplikationen vedligeholder ofte en cache af de data, der sendes til og fra serveren. Som følge heraf modtager serveren ikke reel brugeradfærd (hvor serveren kører en anden algoritme afhængigt af søgekriterierne). VUser-scriptet vil udføres korrekt, men den tegnede præstationsstatistik vil ikke være meningsfuld. Brug af forskellige data via parametrisering hjælper med at emulere serversideaktivitet såsom lagrede procedurer og træner systemet.
• En dato, der er hardkodet i VUser under optagelse, er muligvis ikke længere gyldig, når datoen er overskredet. Parameterisering af datoen gør det muligt for VUser-udførelsen at lykkes ved at erstatte den hardkodede dato. Sådanne felter eller anmodninger er de rette kandidater til parametrisering.

Du opretter en ved at højreklikke på den registrerede værdi i scriptvisning og vælge Erstat med en parameter. VuGen spørger derefter, hvilken type der leverer værdien:

To yderligere muligheder bestemmer, hvordan data forbruges på tværs af iterationer:

Gennemgangen nedenfor viser parametrisering anvendt på et optaget script:

Klik link. hvis videoen ikke er tilgængelig.

Køretidsindstillinger og deres indvirkning på VUser-simulering

Køretidsindstillinger er lige så vigtige som dit VuGen-script. Med varierende konfigurationer kan du opnå helt forskellige testdesigns, hvilket er grunden til, at inkonsistente køretidsindstillinger er den sædvanlige årsag til ikke-gentagelige resultater. Lad os diskutere hver attribut én efter én.

Kør Logic

Run Logic definerer antallet af gange, alle handlinger vil blive udført, undtagen vuser_init og vuser_end.

Dette gør det sandsynligvis tydeligere, hvorfor LoadRunner foreslår keeping al login-koden i vuser_init og logout-delen i vuser_end, begge eksklusivt.

Hvis du har oprettet flere handlinger – f.eks. Log ind, Åbn skærm, Beregn leje, Indsend penge, Tjek saldo og Log ud – så vil nedenstående scenarie finde sted for hver V-bruger:

Alle V-brugere logger ind, udfører Åbn skærm, Beregn leje, Indsend midler og Tjek saldo, derefter igen Åbn skærm, Beregn leje osv., gentaget 10 gange, efterfulgt af log ud (én gang).

Dette er en effektiv indstilling, der lader scriptet opføre sig mere som en rigtig bruger. Husk, at en rigtig bruger ikke logger ind og ud hver gang; de gentager normalt de samme trin.

Hvor mange gange klikker du på "indbakke", når du tjekker din e-mail, før du logger ud?

pacing

Dette er vigtigt. De fleste mennesker er ikke i stand til at forstå forskellen mellem pacing og tænketid. Den eneste forskel er, at pacing refererer til forsinkelsen mellem iterationer, hvorimod tænketid er forsinkelsen mellem to trin.

Den anbefalede indstilling afhænger af testdesignet. Hvis du dog ønsker at anvende aggressiv belastning, bør du overveje at vælge "Så snart den forrige iteration slutter", som vist nedenfor.

Log

En log er, som det generelt forstås, en registrering af alle hændelser, mens du kører LoadRunner. Du kan aktivere loggen til at vide, hvad der sker mellem din applikation og din server.

LoadRunner tilbyder en kraftfuld logføringsmekanisme, der er robust og skalerbar i sig selv. Den giver dig mulighed for kun at gemme en "Standardlog", en detaljeret og konfigurerbar udvidet log eller helt at deaktivere logføring.

En standardlog er informativ og letforståelig. Den indeholder præcis den rette mængde information, du generelt har brug for til at fejlfinde dine VUser-scripts.

I tilfælde af den udvidede log er alle standardlogoplysninger en delmængde. Derudover kan du have parametersubstitution. Dette fortæller LoadRunner-komponenten, at den skal inkludere komplette oplysninger om alle parametrene (fra parameterisering), inklusive anmodninger såvel som svardata.

Hvis du inkluderer "Data returneret af server", vil din log blive længere. Den vil inkludere al HTML, tags, ressourcer og ikke-ressourceoplysninger direkte i loggen. Denne mulighed er kun god, hvis du har brug for seriøs fejlfinding. Dette gør normalt logfilen meget stor og ikke letforståelig.

Som du måske har gættet nu, hvis du vælger "Avanceret Trace" din logfil vil være enorm. Du skal prøve det. Du vil bemærke, at den tid, VuGen bruger, også øges betydeligt, selvom dette ikke har nogen indflydelse på den transaktionsresponstid, der rapporteres af VuGen. Dette er meget avanceret information, og den er kun nyttig, hvis du forstår den pågældende applikation, klient-til-server-kommunikationen mellem din applikation og hardware samt detaljer på protokolniveau. Normalt kræver disse oplysninger en ekstrem indsats at læse og fejlfinde.

tips:

• Uanset hvor lang tid VuGen bruger, når loggen er aktiveret, har det ingen indflydelse på transaktionsresponstiden – logføringsoverhead er ikke inkluderet i den målte tid.
• Deaktiver loggen, hvis den ikke er nødvendig.
• Deaktiver loggen, når du er færdig med dine scripts. Hvis du inkluderer scripts med loggen aktiveret, vil controlleren køre langsommere og rapportere irriterende meddelelser.
• Deaktivering af loggen vil øge det maksimale antal brugere, du kan simulere fra LoadRunner.
• Overvej at bruge "Send kun beskeder, når der opstår en fejl" – dette dæmper unødvendige informationsmeddelelser og rapporterer kun fejlrelaterede beskeder.

Tænk Tider

Think Time er simpelthen forsinkelsen mellem to trin.

Tænketid hjælper med at replikere brugeradfærd, da ingen rigtig bruger kan bruge en applikation som en maskine. VuGen genererer tænketid automatisk. Du har stadig fuld kontrol over at fjerne, multiplicere eller variere varigheden af ​​tænketiden.

For at forstå det bedre: en bruger kan åbne en skærm (et svar efterfulgt af en anmodning) og derefter indtaste et brugernavn og en adgangskode, før vedkommende trykker på Enter. Den næste interaktion mellem applikationen og serveren sker, når brugeren klikker på "Log ind". Den tid, det tog brugeren at indtaste brugernavn og 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 adfærd i virkeligheden kan du dog vælge "Brug tilfældig tænketid" og indstille procentdelene som ønsket.

Overvej at bruge "Limit Think Time" til at begrænse det til et legitimt tidsrum. Normalt er 30 sekunder ret godt nok.

Hastighedssimulering

Hastighedssimulering refererer simpelthen til båndbreddekapaciteten for hver klientmaskine.

Da vi simulerer tusindvis af V-brugere via LoadRunner, er det bemærkelsesværdigt, hvor simpel LoadRunner har gjort simuleringen af ​​båndbredde og netværkshastighed.

Hvis dine kunder tilgår din applikation over 128 Kbps, kan du styre det herfra. Du vil kunne simulere adfærd i virkeligheden, hvilket burde hjælpe dig med at få den rigtige præstationsstatistik.

Den bedste anbefaling er at indstille Brug maksimal båndbredde. Dette hjælper dig med at ignorere eventuelle netværksrelaterede flaskehalse i ydeevnen og fokusere på potentielle problemer i applikationen først. Du kan altid køre testen flere gange for at se varierende adfærd under forskellige omstændigheder.

Browseremulering

Brugeroplevelsen afhænger ikke af den browser, en slutbruger bruger, så dette ligger i vid udstrækning uden for rammerne af ydeevnemålinger. Du kan dog vælge, hvilken browser du ønsker at emulere, som ruden nedenfor viser.

Hvornår er det egentlig ligegyldigt, hvilken browser du vælger i denne konfiguration?

Du skal bruge denne konfiguration, hvis din emneapplikation er en webapplikation, der returnerer forskellige svar for forskellige browsere. For eksempel kan du se forskellige billeder og indhold for Internet Explorer og Firefox.

En anden vigtig indstilling er Simuler browsercache. Hvis du vil måle svartid med cachen aktiveret, skal du markere dette felt. Hvis du leder efter den værst tænkelige situation, er det naturligvis ikke en overvejelse.

Hvis du downloader ikke-HTML-ressourcer, kan LoadRunner downloade CSS, JS og andre rich media-ressourcer. Dette skal forblive markeret. Hvis du ønsker at fjerne det fra dit performancetestdesign, kan du fjerne markeringen.

proxy

Det er bedst at fjerne proxyen helt fra din Testmiljø — en proxy, der sidder i stien, gør testresultaterne upålidelige. Du kan dog støde på situationer, hvor det er uundgåeligt. I en sådan situation tilbyder LoadRunner proxyindstillinger.

Du vil arbejde (eller burde arbejde) med indstillingen Ingen proxy. Du kan hente den fra din standardbrowser. Glem dog ikke at kontrollere, hvilken browser der er indstillet som standard, og hvad proxykonfigurationen for den pågældende browser er.

Hvis du bruger en proxy, og det kræver godkendelse (eller et script), kan du klikke på knappen Godkend, hvilket fører til et nyt vindue. Se skærmbilledet nedenfor.

Brug denne skærm til at angive et brugernavn og en adgangskode for at blive godkendt på proxyserveren. Klik på OK for at lukke skærmbilledet.

Tillykke. Du er færdig med at konfigurere dit VuGen-script. Glem ikke at konfigurere det for alle dine VUser-scripts.

Næste kommer korrelation, kører scenariet i controller, og læsning resulterer i LoadRunner-analyse. Se LoadRunner-arkitektur og Load Testing vejledninger.

Ofte Stillede Spørgsmål