Ett inspelat skript kan simulera en virtuell användare; en inspelning kanske dock inte räcker för att replikera det “riktiga användarbeteendet”.
När ett skript spelas in täcker det enstaka och raka flöden av ämnesapplikationen. Medan en riktig användare kan utföra flera iterationer av vilken process som helst innan han loggar ut. Fördröjningen mellan att klicka på knapparna (tänketid) varierar från person till person. Chansen är att vissa riktiga användare kommer åt din applikation via DSL och vissa får tillgång till den via en fjärranslutning. Så för att få slutanvändarens verkliga känsla måste vi förbättra våra skript för att vara exakt matchande, eller åtminstone mycket nära beteende för riktiga användare.
Ovanstående är den viktigaste överväganden när du utför “Prestandatestning”, men det finns mer i ett VU-skript. Hur kommer du att mäta den exakta tid som en VUser tar när SUL genomgår ett prestandatest? Hur skulle du veta om VUser har passerat eller misslyckats vid en viss tidpunkt? Vad är orsaken bakom felet, oavsett om någon backend-process misslyckades eller om serverresurserna var begränsade?
Vi måste förbättra vårt manus för att svara på alla ovanstående frågor.
- Använda transaktioner
- Förstå Think Time, Rendezvous Points och Comments
- Infoga funktioner via menyn
- Vad är parametrisering?
- Inställningar för körtid och deras inverkan på VU-simulering
- Kör logik
- Pacing
- Logga
- Think Times
- Hastighetssimulering
- Webbläsaremulering
- Ombud
Använda transaktioner
Transaktioner är mekanik för att mäta serverns responstid för alla operationer. Med enkla ord hjälper användningen av "Transaktion" till att mäta den tid som systemet tar för en viss begäran. Det kan vara så litet som ett klick på en knapp eller ett AJAX-samtal när du tappar fokus från textrutan.
Att tillämpa transaktioner är enkelt. Skriv bara en kodrad innan begäran görs till servern och stäng transaktionen när begäran avslutas. LoadRunner kräver endast en sträng som transaktionsnamn.
För att öppna en transaktion, använd denna kodrad:
lr_start_transaction (“Transaktionsnamn”);
För att stänga transaktionen, använd den här kodraden:
lr_end_transaction (“Transaktionsnamn”,);
- LR_AUTO
- LR_PASS
- LR_FAIL
Exempel:
lr_end_transaction (“My_Login”, LR_AUTO);
lr_end_transaction (“Business_Workflow_Transaction Name”, LR_FAIL);
Poäng att notera:
- Glöm inte, du arbetar med “C” och det är ett skiftlägeskänsligt språk.
- Periodtecken (.) Är inte tillåtet i transaktionsnamn, även om du kan använda blanksteg och understrykning.
- Om du har förgrenat din kod väl och lagt till kontrollpunkter för att verifiera svaret från servern kan du använda anpassad felhantering, till exempel LR_PASS eller LR_FAIL. Annars kan du använda LR_AUTO och LoadRunner hanterar automatiskt serverfel (HTTP 500, 400 etc.)
- När du tillämpar transaktioner, se till att det inte finns något think_time- uttalande som kläms fast annars kommer din transaktion alltid att inkludera den perioden.
- Eftersom LoadRunner kräver en konstant sträng som transaktionsnamn, är ett vanligt problem när transaktionen tillämpas felaktig matchning av strängen. Om du anger ett annat namn när du öppnar och stänger en transaktion kommer du att ha minst två fel. Eftersom transaktionen du öppnade aldrig stängdes ger LoadRunner ett fel. Dessutom öppnades aldrig transaktionen du försökte stänga, vilket resulterade i ett fel.
- Kan du använda din intelligens och svara för dig själv vilket av ovanstående fel kommer att rapporteras först? För att validera ditt svar, varför inte göra ditt eget misstag? Om du hade svarat rätt är du på rätt spår. Om du svarade fel måste du fokusera.
- Eftersom LoadRunner automatiskt tar hand om synkronisering av förfrågningar och svar, behöver du inte oroa dig för svar när du tillämpar transaktioner.
Förstå Think Time, Rendezvous Points och Comments
Rendezvous-poäng
Rendezvous Points betyder "mötesplatser". Det är bara ett uttalande som säger till LoadRunner att införa samtidighet. Du infogar mötesplatser i VUser-skript för att emulera stor användarbelastning på servern.
Rendezvous-poäng instruerar VUser att vänta under testkörning för att flera VUser ska komma fram till en viss punkt, så att de samtidigt kan utföra en uppgift. Till exempel, för att emulera toppbelastning på bankservern, kan du infoga en mötesplats som instruerar 100 användare att sätta in kontanter på sina konton samtidigt. Detta kan uppnås enkelt med hjälp av rendezvous.
Om mötespunkterna inte är korrekt placerade kommer användaren att komma åt olika delar av applikationen - även för samma skript. Detta beror på att varje VUser får olika svarstider och därmed få användare släpar efter.
Syntax: lr_rendesvous (“Logiskt namn”);
Bästa praxis:
- Prefix en mötesplats med “rdv_” för bättre kodläsbarhet; t.ex. “rdv_Login”
- Ta bort alla omedelbara tankesedlar
- Tillämpa mötesplatser i en skriptvy (efter inspelning)
Kommentarer
Lägg till kommentarer för att beskriva en aktivitet, en kod eller en kodrad. Kommentarer hjälper till att göra koden förståelig för alla som hänvisar till den i framtiden. De ger information om specifik funktion och separerar två avsnitt för åtskillnad.
Du kan lägga till kommentarer
- Under inspelning (med verktyg)
- Efter inspelning (direkt skrivning i kod)
Bästa praxis: Markera eventuella kommentarer högst upp i varje skriptfil
Infoga funktioner via menyn
Medan du direkt kan skriva enkla kodrader kan du behöva en ledtråd för att återkalla en funktion. Du kan också använda Steps Toolbox (känd som Insert Function före version 12) för att hitta och infoga vilken funktion som helst direkt i ditt skript.
Du hittar Steps Toolbar under Visa àSteps Toolbox.
Detta öppnar ett sidofönster, titta på ögonblicksbilden:
Vad är parametrisering?
En parameter i VUGen är en behållare som innehåller ett registrerat värde som ersätts för olika användare.
Under körningen av skriptet (i VUGen eller Controller) ersätter värdet från en extern källa (som .txt, XML eller databas) det tidigare värdet för parametern.
Parameterisering är användbar för att t.ex. skicka dynamiska (eller unika) värden till servern; en affärsprocess önskas för att köra tio iterationer men välja unikt användarnamn varje gång.
Det hjälper också till att stimulera riktigt beteende för ämnessystemet. Ta en titt på exemplet nedan:
Problemexempel:
Affärsprocessen fungerar bara för det aktuella datumet som kommer från servern, och kan därför inte skickas som en hårdkodad begäran.
Ibland skickar klientapplikationen ett unikt ID till servern (till exempel session_id) för att processen ska fortsätta (även för en enskild användare) - I ett sådant fall hjälper parametreringen.
Klientapplikationen upprätthåller ofta en cache med data som skickas till och från servern. Som ett resultat får inte servern ett riktigt användarbeteende (om servern kör olika algoritmer beroende på sökkriterier). Medan VUser-skript kommer att köras framgångsrikt kommer prestationsstatistiken som ritas inte vara meningsfull. Att använda olika data genom parametrering hjälper till att emulera serverns aktivitet (procedurer etc.) och öva systemet.
Ett datum som är hårdkodat i VUser under inspelning kanske inte längre är giltigt när detta datum har passerat. Genom att parametrera datumet kan VUser-körning lyckas genom att ersätta det hårdkodade datumet. Sådana fält eller förfrågningar är rätt kandidater för parametrering.
Klicka här om videon inte är tillgänglig
Inställningar för körtid och deras inverkan på VU-simulering
Inställningar för körtid har lika mycket betydelse som ditt VUGen-skript. Med olika konfigurationer kan du få olika testdesigner. Det är därför du kan hamna i resultat som inte kan repeteras om inställningarna för körtid inte är konsekventa. Låt oss diskutera varje attribut en efter en.
Kör logik
Körlogik definierar antalet gånger alla åtgärder ska utföras, förutom vuser_init och vuser_end.
Förmodligen blir detta tydligare varför LoadRunner föreslår att du håller all inloggningskod inom vuser_init och Logout del i vuser_end, båda exklusivt.
Om du har skapat flera åtgärder, låt oss säga, Logga in, öppna skärmen, beräkna hyran, skicka in pengar, kontrollera saldot och logga ut, nedanstående scenario kommer att äga rum för varje VUser:
Alla VU-användare loggar in, kör öppen skärm, beräknar hyra, skickar in pengar, kontrollerar saldo - sedan - igen Öppnar skärmen, beräknar hyror ... och så vidare - itererar 10 gånger - följt av utloggning (en gång).
Detta är en kraftfull inställning som gör det möjligt att agera mer som en riktig användare. Kom ihåg att en riktig användare inte loggar in och loggar ut varje gång - han upprepar vanligtvis samma steg.
Hur många gånger klickar du på "inkorgen" när du kontrollerar din e-post innan du loggar ut?
Pacing
Det här är viktigt. För det mesta kan människor inte förstå skillnaden mellan pacing och tänketid. Den enda skillnaden är att "pacing hänvisar till fördröjningen mellan iterationer" medan tänketiden är fördröjningen mellan två steg.
Rekommenderad inställning beror på testdesignen. Men om du vill ha aggressiv belastning, överväg att välja "Så snart den tidigare iterationen slutar"
Logga
En logg (som allmänt känt) är en bokföring av alla händelser medan du kör LoadRunner. Du kan aktivera logg för att veta vad som händer mellan din applikation och din server.
LoadRunner ger kraftfull loggningsmekanism som är robust och skalbar på egen hand. Det låter dig bara behålla "Standardlogg" eller en detaljerad, konfigurerbar utökad logg eller inaktivera den helt.
En standardlogg är informativ och lättförståelig. Den innehåller precis rätt mängd kunskap du vanligtvis behöver felsöka dina VUser-skript.
När det gäller utökad logg är all standardlogginformation en delmängd. Dessutom kan du byta parameter. Detta säger till LoadRunner-komponenten att inkludera fullständig information om alla parametrar (från parametreringen) inklusive förfrågningar samt svarsdata.
Om du inkluderar "Data returnerad av servern" kommer din logg att gå i längd. Detta inkluderar all HTML, taggar, resurser, icke-resursinformation som ingår direkt i loggen. Alternativet är bara bra om du behöver allvarlig felsökning. Vanligtvis gör detta loggfilen mycket stor och inte lätt att förstå.
Som du kan ha gissat nu om du väljer "Advance Trace" kommer din loggfil att vara massiv. Du måste prova. Du kommer att märka att den tid det tar av VUGen också har ökat betydligt, även om detta inte kommer att ha någon inverkan på svarstiden för transaktionen som rapporterats av VUGen. Detta är dock mycket förhandsinformation och kanske användbart om du förstår ämnesapplikationen, klient till serverkommunikation mellan din applikation och hårdvara samt detaljer på protokollnivå. Vanligtvis är denna information död i grunden eftersom den kräver extrema ansträngningar för att förstå och felsöka.
Tips:
- Oavsett hur mycket tid VUGen tar när logg är aktiverat har det ingen inverkan på transaktionssvarstiden. HP kallar detta fenomen som ”toppmodern teknik.”
- Inaktivera logg om det inte krävs.
- Inaktivera logg när du är klar med dina skript. Inkludering av skript med loggning aktiverad kommer att leda till att styrenheten körs långsammare och rapporterar gnagande meddelanden.
- Inaktivera logg kommer att öka kapaciteten för det maximala antalet användare som du kan simulera från LoadRunner.
- Överväg att använda "Skicka meddelande endast när fel uppstår" - detta stänger av onödiga informationsmeddelanden och rapporterar bara felrelaterade meddelanden.
Think Times
Think Time är helt enkelt förseningen mellan två steg.
Think Time hjälper till att replikera användarnas beteende eftersom ingen riktig användare kan använda något program som en maskin (VUGen). VUGen genererar tänktid automatiskt. Du har fortfarande fullständig kontroll för att ta bort, multiplicera eller fluktuera varaktigheten för tänkandetiden.
För att förstå mer kan till exempel en användare öppna en skärm (det vill säga ett svar följt av en begäran) och sedan ange att det är användarnamn och lösenord innan du trycker på enter. Nästa interaktion mellan applikationen och servern kommer att ske när han klickar på "Logga in". Tiden som en användare tog för att skriva sitt användarnamn och lösenord är Think Time i LoadRunner.
Om du vill simulera aggressiv belastning på applikationen, överväga att inaktivera tanketiden helt.
Men för att simulera ett verkligt liknande beteende kan du “Användar slumpmässig tänktid” och ställa in procentsatserna som önskat.
Överväg att använda Limit Think Time till en legitim period. Vanligtvis är 30 sekunder ganska bra nog.
Hastighetssimulering
Hastighetssimulering avser helt enkelt bandbreddskapacitet för varje klientmaskin.
Eftersom vi simulerar tusentals användare genom LoadRunner är det fantastiskt hur enkelt LoadRunner har gjort för att styra bandbredd / nätverkshastighetssimulering.
Om du är kunder som har åtkomst till din applikation över 128 Kbps kan du styra den härifrån. Du kommer att simulera "riktigt liknande beteende" som skulle hjälpa till att få rätt prestationsstatistik.
Den bästa rekommendationen är att ställa in Använd maximal bandbredd. Detta hjälper till att bortse från alla nätverksrelaterade flaskhalsar och fokusera på eventuella problem i applikationen först. Du kan alltid köra testet flera gånger för att se olika beteenden under olika omständigheter.
Webbläsaremulering
Användarupplevelsen beror inte på vilken webbläsare en slutanvändare använder. Det är uppenbart att detta ligger utanför ramen för prestationsåtgärder. Du kan dock välja vilken webbläsare du vill emulera.
Kan du svara för dig själv när det verkligen kommer att betyda för dig att välja rätt webbläsare i den här konfigurationen?
Du kommer att använda den här konfigurationen om du är ämnesapplikation är en webbapplikation som returnerar olika svar för olika webbläsare. Till exempel får du se olika bilder och innehåll för IE och Firefox etc.
En annan viktig inställning är Simulera webbläsarcache. Om du vill mäta svarstiden när cache är aktiverad, markera den här rutan. Om du letar efter värsta fall är detta uppenbarligen inte ett övervägande.
Ladda ner icke-HTML-resurser så att LoadRunner kan ladda ner CSS, JS och andra rich media. Detta bör förbli kontrollerat. Om du däremot vill eliminera detta från din prestandatestdesign kan du avmarkera detta.
Ombud
Det är bäst att eliminera proxy helt från din testmiljö - detta gör testresultaten opålitliga. Du kan dock möta situationer där det är oundvikligt. I en sådan situation underlättar LoadRunner dig med proxyinställningar.
Du kommer att arbeta (eller borde arbeta) med ingen proxyinställning. Du kan hämta det från din standardwebbläsare. Glöm inte att kontrollera vilken webbläsare som är standard och vilken proxykonfiguration för standardwebbläsaren är.
Om du använder en proxy och det kräver autentisering (eller ett skript) kan du klicka på Autentisera-knappen som leder till ett nytt fönster. Se nedan skärmdump.
Använd den här skärmen för att ange användarnamn och lösenord för att bli autentiserad på proxyservern. Klicka på OK för att stänga skärmen.
Grattis. Du är klar med att konfigurera ditt VUGen-skript. Glöm inte att konfigurera det för alla dina VUser-skript.