Parametrering, funktioner, transaktioner i LoadRunner

Et optaget script kan simulere en virtuel bruger; dog er blot en optagelse måske ikke nok til at replikere den "rigtige brugeradfærd".

Når et manuskript er optaget, dækker det enkelt og lige flow af emneapplikationen. Mens en rigtig bruger kan udføre flere iterationer af enhver proces, før han logger ud. Forsinkelsen mellem at trykke på knapperne (tænk tid) vil variere fra person til person. Chancerne er, at nogle rigtige brugere får adgang til din applikation via DSL, og nogle får adgang til den via en dial-up. Så for at få den rigtige fornemmelse af slutbrugeren, er vi nødt til at forbedre vores scripts, så de matcher nøjagtigt, eller i det mindste meget tæt på virkelige brugeres adfærd.

Ovenstående er den vigtigste overvejelse, når man udfører "Test af ydeevne”, men der er mere i et VU Script. Hvordan vil du måle den nøjagtige tid, det tager en VUser, når SUL gennemgår en præstationstest? Hvordan ville du vide, om VUser er gået igennem eller fejlede på et bestemt tidspunkt? Hvad er årsagen til fejlen, om en eller anden backend-proces mislykkedes, eller om 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

Transaktioner er mekanik til at måle serverens responstid for enhver operation. Med enkle ord hjælper brugen af ​​"Transaktion" med at måle den tid, det tager systemet for en bestemt anmodning. Det kan være så lille som et klik på en knap eller et AJAX-opkald, når du mister fokus fra tekstboksen.

Det er ligetil at anvende transaktioner. Bare skriv en linje 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(“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(“Mit_Login”, LR_AUTO);
lr_end_transaction(“001_Opening_Dashboard Name”, LR_PASS);
lr_end_transaction("Business_Workflow_Transaction Name", LR_FAIL);

Bemærk:

• Glem ikke, du arbejder med "C", og det er et sprog, der skelner mellem store og små bogstaver.
• Punktum (.) 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 tilpasset 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 sikre dig, at der ikke er nogen tænke_tid erklæring bliver klemt eller på anden måde vil din transaktion altid inkludere denne periode.
• Da LoadRunner kræver en konstant streng som transaktionsnavn, er et almindeligt problem ved anvendelse af transaktion uoverensstemmelse mellem streng. Hvis du giver et andet navn, når du åbner og lukker en transaktion, vil du have mindst 2 fejl. Da transaktionen du åbnede aldrig blev lukket, vil LoadRunner give en fejl. Desuden blev transaktionen, du forsøger at lukke, aldrig åbnet, hvilket resulterede i en fejl.
• Kan du bruge din intelligens og svare dig selv på, hvilken af ​​ovenstående fejl der vil blive rapporteret først? For at validere dit svar, hvorfor så ikke lave din egen fejl? Hvis du har svaret rigtigt, er du på vej track. Hvis du svarede forkert, skal du fokusere.
• Da LoadRunner automatisk sørger for synkronisering af anmodninger og svar, behøver du ikke bekymre dig om svar, når du anvender transaktioner.

Forstå Think Time, Rendezvous Points og Kommentarer

Rendezvous Points

Rendezvous Points betyder "mødepunkter". Det er kun én udsagn, der fortæller LoadRunner at introducere samtidighed. Du indsætter rendezvous-punkter i VUser-scripts for at efterligne tung brugerbelastning på serveren.

Rendezvous-punkter instruerer VUser om at vente under testudførelsen på, at flere VUser ankommer til et bestemt punkt, så de kan udføre en opgave samtidigt. For at efterligne spidsbelastning på bankserveren kan du f.eks. indsætte et mødepunkt, der instruerer 100 VUser om at indbetale kontanter på deres konti på samme tid. Dette kan nemt opnås ved hjælp af rendezvous.

Hvis mødepunkterne ikke er placeret korrekt, vil VUser få adgang til forskellige dele af applikationen – selv for det samme script. Dette skyldes, at hver VUser får forskellig responstid, og derfor er få brugere bagud.

Syntaks: lr_rendesvous(“Logisk navn”);

Bedste praksis:

• Præfiks et mødepunkt med "rdv_" for bedre kodelæsbarhed; f.eks. "rdv_Login"
• Fjern eventuelle øjeblikkelige tænketidsudsagn
• Anvendelse af mødepunkter i en scriptvisning (efter optagelse)

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 specifik drift og adskiller to sektioner for at skelne.

Du kan tilføje kommentarer

• Under optagelse (ved hjælp af værktøj)
• Efter optagelse (direkte skrivning i kode)

Bedste Practice: Marker eventuelle kommentarer øverst på hver scriptfil

Indsættelse af funktioner gennem menuen

Selvom du direkte kan skrive enkle kodelinjer, har du muligvis brug for et fingerpeg for at genkalde 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 Steps Toolbar under Vis àSteps Toolbox.

Dette åbner et sidevindue, se på øjebliksbilledet:

Hvad er parametrisering?

A parameter i VUGen er en container, der indeholder en registreret værdi, der udskiftes 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 forrige værdi af parameteren.

Parametrisering er nyttig til at sende dynamiske (eller unikke) værdier til serveren, for eksempel; en forretningsproces ønskes til at køre 10 iterationer, men vælge unikt brugernavn hver gang.

Det hjælper også med at stimulere virkelig-lignende adfærd til emnesystemet. Tag et kig på nedenstående eksempel:

Eksempler på problemer:

Forretningsprocessen fungerer kun for den aktuelle dato, som kommer fra serveren, og kan derfor ikke videregives som en hårdkodet anmodning.

Nogle gange sender 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 parameterisering.

Ofte vedligeholder klientapplikationen en cache af data, der sendes til og fra serveren. Som et resultat modtager serveren ikke en reel brugeradfærd (i tilfælde af at serveren kører forskellige algoritmer afhængigt af søgekriterier). Selvom VUser-scriptet vil køre med succes, vil de tegnede præstationsstatistikker ikke være meningsfulde. Brug af forskellige data gennem parameterisering hjælper med at emulere aktivitet på serversiden (procedurer osv.) og træner systemet.

En dato, der er hårdkodet i VUser under optagelse, er muligvis ikke længere gyldig, når denne dato er passeret. Parametrisering af datoen gør det muligt for VUser-udførelsen at lykkes ved at erstatte den hårdkodede dato. Sådanne felter eller anmodninger er de rigtige kandidater til parameterisering.

Klik link. hvis videoen ikke er tilgængelig

Kørselstidsindstillinger og deres indvirkning på VU-simulering

Køretidsindstillinger har lige så meget betydning som dit VUGen-script. Med varierende konfigurationer kan du opnå forskellige testdesigns. Det er derfor, du kan ende i ikke-gentagelige resultater, hvis kørselstidsindstillingerne ikke er konsistente. Lad os diskutere hver egenskab en efter en.

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, lad os sige, Log ind, Åbn skærm, Beregn leje, Indsend midler, Tjek saldo og log ud, så vil nedenstående scenarie finde sted for hver VUser:

Alle VUsers vil logge ind, udføre åben skærm, beregne leje, indsende midler, kontrollere saldo – derefter – igen Åbne skærm, beregne leje... og så videre – gentage 10 gange – efterfulgt af log ud (én gang).

Dette er en kraftfuld indstilling, der gør det muligt at agere 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, før du logger ud?

pacing

Dette er vigtigt. For det meste er folk ude af stand til at forstå forskellen mellem pacing og tænketid. Den eneste forskel er, "pacing refererer til forsinkelsen mellem iterationer", hvorimod tror tid er forsinkelsen mellem 2 trin.

Den anbefalede indstilling afhænger af testdesignet. Men hvis du ønsker at have aggressiv belastning, kan du overveje at vælge "Så snart den forrige iteration slutter"

Log

En log (som den generelt forstås) er en bogholderping af alle hændelser, mens du kører LoadRunner. Du kan aktivere log for at vide, hvad der sker mellem din applikation og din server.

LoadRunner giver en kraftfuld logningsmekanisme, som er robust og skalerbar i sig selv. Det giver dig mulighed for kun at beholde "Standard Log" eller en detaljeret, konfigurerbar udvidet log eller deaktivere den helt.

En standardlog er informativ og let forståelig. Den indeholder den helt rigtige mængde viden, du vil generelt kræve fejlfinding af dine VUser-scripts.

I tilfælde af udvidet log er alle standard logoplysninger en delmængde. Derudover kan du have parametersubstitution. Dette fortæller LoadRunner-komponenten at inkludere fuldstændig information om alle parametrene (fra parametrering), inklusive anmodninger, samt svardata.

Hvis du inkluderer "Data returneret af server", vil din log blive længere. Dette vil inkludere al HTML, tags, ressourcer, ikke-ressourceoplysninger inkluderet direkte i loggen. Muligheden 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 måske har gættet nu, hvis du vælger "Forhåndsvisning" Trace”, vil din logfil være enorm. Du skal prøve det. Du vil bemærke, at den tid, som VUGen bruger, også er steget betydeligt, selvom dette ikke vil have nogen indflydelse på den transaktionsresponstid, der rapporteres af VUGen. Dette er dog meget avanceret information og kan være nyttig, hvis du forstår den pågældende applikation, klient-til-server-kommunikationen mellem din applikation og hardware samt detaljer på protokolniveau. Normalt er disse oplysninger døde i bund og grund, da det kræver en ekstrem indsats at forstå og fejlfinde.

tips:

• Uanset hvor lang tid VUGen tager, når log er aktiveret, har det ingen indflydelse på transaktionens responstid. HP kalder dette fænomen som "state of the art teknologi."
• Deaktiver log, hvis det ikke er påkrævet.
• Deaktiver log, når du er færdig med dine scripts. Inkludering af scripts med logning aktiveret vil få controlleren til at køre langsommere og rapportere nagende beskeder.
• 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 fejl" - dette vil slå unødvendige informationsmeddelelser fra og kun rapportere fejlrelaterede meddelelser.

Tænk Tider

Think Time er simpelthen forsinkelsen mellem to trin.

Think Time hjælper med at replikere brugeradfærd, da ingen rigtig bruger kan bruge nogen applikation som en maskine (VUGen). VUGen genererer tænketid automatisk. Du har stadig fuld kontrol over at fjerne, multiplicere 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 brugernavnet og adgangskoden, før han trykker på Enter. Den næste interaktion mellem applikationen og serveren vil ske, når han klikker på "Log ind". Den tid, det tog en bruger at indtaste sit brugernavn og password, er Think Time i LoadRunner.

Hvis du ønsker at simulere aggressiv belastning på applikationen, skal du overveje at deaktivere tænketid fuldstændigt.

Men for at simulere en rigtig lignende adfærd kan du "User Random Think Time" og indstille procenterne som ønsket.

Overvej at bruge Limit Think Time til en legitim periode. Normalt er 30 sekunder ret godt nok.

Hastighedssimulering

Hastighedssimulering refererer simpelthen til båndbreddekapacitet for hver klientmaskine.

Da vi simulerer tusindvis af VUser'er gennem LoadRunner, er det forbløffende, hvor enkelt LoadRunner har gjort at styre båndbredde/netværkshastighedssimuleringen.

Hvis du er kunder, får adgang til din applikation over 128 Kbps, kan du styre den herfra. Du vil komme til at simulere "rigtig lignende adfærd", hvilket burde hjælpe med at få den rigtige præstationsstatistik.

Den bedste anbefaling er at indstille til Brug maksimal båndbredde. Dette vil hjælpe med at se bort fra eventuelle netværksrelaterede ydeevneflaskehalse og fokusere på eventuelle 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. Det er klart, at dette ligger uden for rækkevidden af ​​præstationsmål. Du kan dog vælge, hvilken browser du ønsker at emulere.

Kan du svare dig selv på, hvornår det præcist vil betyde noget for dig at vælge den rigtige browser i denne konfiguration?

Du vil bruge denne konfiguration, hvis din applikation er en webapplikation, der returnerer forskellige svar for forskellige browsere. For eksempel kan du se forskellige billeder og indhold til IE og Firefox etc.

En anden vigtig indstilling er Simuler browsercache. Hvis du vil måle responstiden, når cache er aktiveret, skal du markere dette felt. Hvis du leder efter worst case situation, er dette naturligvis ikke en overvejelse.

Download ikke-HTML-ressourcer vil lade LoadRunner downloade enhver CSS, JS og andre rich media. Dette bør forblive kontrolleret. Men hvis du vil fjerne dette fra dit præstationstestdesign, kan du fjerne markeringen af ​​dette.

proxy

Det er bedst at fjerne proxy helt fra din Testmiljø – dette vil gøre testresultaterne upålidelige. Du kan dog komme i situationer, hvor det er uundgåeligt. I en sådan situation letter LoadRunner dig med proxyindstillinger.

Du vil arbejde (eller burde arbejde) med Ingen proxy-indstilling. Du kan hente det fra din standardbrowser. Glem dog ikke at tjekke, hvilken browser der er sat til standard, og hvilken proxy-konfiguration for standardbrowseren er.

Hvis du bruger en proxy, og den kræver godkendelse (eller et script), kan du klikke på knappen Godkend, som 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.