Parametrering, funktioner, transaktioner i LoadRunner

Ett inspelat skript kan simulera en virtuell användare; dock kanske enbart inspelning inte räcker för att replikera det "riktiga användarbeteendet".

När ett manus spelas in täcker det enstaka och raka flöden av ämnesansökan. 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å knappar (tänk tid) kommer att variera från person till person. Chansen är stor att vissa riktiga användare får åtkomst till din applikation via DSL och vissa får åtkomst till den via en uppringd. Så för att få den verkliga känslan av slutanvändare måste vi förbättra våra skript för att vara exakt matchande, eller åtminstone mycket nära verkliga användares beteende.

Ovanstående är den viktigaste faktorn när man genomför "Prestandatester”, men det finns mer i ett VU-skript. Hur kommer du att mäta den exakta tid det tar för en VUser när SUL genomgår ett prestationstest? Hur skulle du veta om VUser har passerat eller misslyckats vid en viss punkt? Vad är orsaken bakom felet, om någon backend-process misslyckades eller om serverresurserna var begränsade?

Vi måste förbättra vårt manus för att hjälpa oss att svara på alla ovanstående frågor.

Använda transaktioner

Transaktioner är mekaniker för att mäta serverns svarstid för alla operationer. Med enkla ord hjälper användningen av "Transaktion" att mäta den tid som systemet tar för en viss förfrågan. 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 rad kod 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(“Transaction Name”);

För att avsluta transaktionen, använd denna kodrad:

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

De talar om för LoadRunner om den här transaktionen var framgångsrik eller misslyckad. De möjliga parametrarna kan vara:

• LR_AUTO
• LR_PASS
• LR_FAIL

Exempelvis:

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);

Poäng att notera:

• Glöm inte att du arbetar med "C" och det är ett skiftlägeskänsligt språk.
• Period (.)-tecken är inte tillåtet i transaktionsnamn, även om du kan använda mellanslag och understreck.
• 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, som LR_PASS eller LR_FAIL. Annars kan du använda LR_AUTO och LoadRunner kommer automatiskt att hantera serverfel (HTTP 500, 400 etc.)
• När du tillämpar transaktioner, se till att det inte finns något tänka_tid utdraget läggs in eller 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 att strängen inte matchar. Om du anger ett annat namn när du öppnar och avslutar en transaktion kommer du att få minst 2 fel. Eftersom transaktionen du öppnade aldrig stängdes, kommer LoadRunner att ge ett fel. Dessutom öppnades aldrig transaktionen du försöker 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 som kommer att rapporteras först? För att bekräfta 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 kommentarer

Rendezvous Points

Rendezvous Points betyder "träffpunkter". Det är bara en rad påståenden som säger åt LoadRunner att införa samtidighet. Du infogar mötespunkter i VUser-skript för att emulera tung användarbelastning på servern.

Rendezvous points instruerar VUser att vänta under testkörning på att flera VUser kommer fram till en viss punkt, så att de kan utföra en uppgift samtidigt. Till exempel, för att efterlikna toppbelastning på bankservern, kan du infoga en mötesplats som instruerar 100 VUser att sätta in kontanter på sina konton samtidigt. Detta kan enkelt uppnås med hjälp av rendezvous.

Om mötespunkterna inte är korrekta platser kommer VUser åtkomst till olika delar av applikationen – även för samma skript. Detta beror på att varje VUser får olika svarstid och därför ligger få användare efter.

Syntax: lr_rendesvous(“Logiskt namn”);

Bästa metoder:

• Prefix en mötespunkt med "rdv_" för bättre kodläsbarhet; t.ex. "rdv_Login"
• Ta bort alla omedelbara tanketider
• Tillämpa mötespunkter i en skriptvy (efter inspelning)

Kommentarer

Lägg till kommentarer för att beskriva en aktivitet, en kodbit eller en kodrad. Kommentarer hjälper till att göra koden begriplig för alla som hänvisar till den i framtiden. De ger information om specifik operation och separerar två sektioner för åtskillnad.

Du kan lägga till kommentarer

• Under inspelning (med verktyg)
• Efter inspelning (skriver direkt i kod)

Bästa praxis: Markera eventuella kommentarer överst i varje skriptfil

Infoga funktioner via menyn

Även om 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 Infoga funktion före version 12) för att hitta och infoga valfri funktion direkt i ditt skript.

Du hittar Verktygsfältet Steg under Visa à Steg Verktygslåda.

Detta öppnar ett sidofönster, titta på ögonblicksbilden:

Vad är parametrisering?

A 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 på parametern.

Parametrering är användbart för att skicka dynamiska (eller unika) värden till servern, till exempel; en affärsprocess är önskvärd för att köra 10 iterationer men välja ett unikt användarnamn varje gång.

Det hjälper också till att stimulera verkligt beteende för ämnessystemet. Ta en titt på nedanstående exempel:

Exempel på problem:

Affärsprocessen fungerar endast 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 parametrering.

Ofta upprätthåller klientapplikationen en cache med data som skickas till och från servern. Som ett resultat får servern inte ett riktigt användarbeteende (om servern kör olika algoritmer beroende på sökkriterier). Även om VUser-skriptet kommer att köras framgångsrikt, kommer prestationsstatistiken som ritas inte att vara meningsfull. Att använda olika data genom parametrisering hjälper till att emulera serversidans aktivitet (procedurer etc.) och tränar systemet.

Ett datum som är hårdkodat i VUser under inspelning kanske inte längre är giltigt när det datumet har passerat. Genom att parametrera datumet kan körning av VUser lyckas genom att det hårdkodade datumet ersätts. Sådana fält eller förfrågningar är de rätta kandidaterna för parametrering.

Klicka här. om videon inte är tillgänglig

Körtidsinställningar och deras inverkan på simulering av fordonsenhet

Körtidsinställningar har lika stor betydelse som ditt VUGen-skript. Med varierande konfigurationer kan du få olika testdesigner. Det är därför du kan hamna i resultat som inte kan upprepas om körtidsinställningarna inte är konsekventa. Låt oss diskutera varje attribut en efter en.

Kör Logic

Run Logic definierar antalet gånger alla åtgärder kommer att utföras, förutom vuser_init och vuser_end.

Förmodligen gör detta tydligare varför LoadRunner föreslår att man behåller all inloggningskod inom vuser_init, och utloggningsdelen i vuser_end, båda exklusivt.

Om du har skapat flera åtgärder, låt oss säga, Logga in, Öppna skärm, Beräkna hyra, Skicka in pengar, Kontrollera saldo och logga ut, så kommer nedanstående scenario att äga rum för varje VUser:

Alla VUsers kommer att logga in, köra öppen skärm, beräkna hyra, skicka in pengar, kontrollera saldo – sedan – igen Öppna skärm, beräkna hyror... och så vidare – upprepa 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 kollar din e-post innan du loggar ut?

pacing

Det här är viktigt. Oftast kan människor inte förstå skillnaden mellan pacing och tänketid. Den enda skillnaden är, "Pacing hänvisar till fördröjningen mellan iterationer" medan tänk tid ä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 föregående iterationen slutar"

Logga

En logg (som allmänt förstås) ä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 en 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ätt att förstå. Den innehåller precis rätt mängd kunskap som du i allmänhet kommer att kräva för att felsöka dina VUser-skript.

I fallet med utökad logg är all standardlogginformation en delmängd. Dessutom kan du ha parametersubstitution. Detta talar om för LoadRunner-komponenten att inkludera fullständig information om alla parametrar (från parameterisering) inklusive förfrågningar, såväl som svarsdata.

Om du inkluderar "Data returnerad av server" kommer din logg att bli lång. Detta kommer att inkludera all HTML, taggar, resurser, icke-resurser information som ingår direkt i loggen. Alternativet är bara bra om du behöver seriös felsökning. Vanligtvis gör detta loggfilen mycket stor i storlek och inte lätt att förstå.

Som du skulle kunna gissa vid det här laget om du väljer "Advance Trace", kommer din loggfil att vara enorm. Du måste ge det ett försök. Du kommer att märka hur lång tid det tar för VUGen också har ökat avsevärt, även om detta inte kommer att ha någon inverkan på transaktionens svarstid som rapporteras av VUGen. Detta är dock mycket förhandsinformation och kanske användbar om du förstår ämnesapplikationen, klient-till-server-kommunikationen mellan din applikation och hårdvara samt detaljer på protokollnivå. Vanligtvis är denna information i grunden död eftersom den kräver extrema ansträngningar för att förstå och felsöka.

Tips:

• Oavsett hur lång tid VUGen tar när logg är aktiverad, har det ingen inverkan på transaktionssvarstiden. HP kallar detta fenomen som "modern teknik".
• Inaktivera loggen om det inte krävs.
• Inaktivera loggen när du är klar med dina skript. Inkludering av skript med loggning aktiverad gör att kontrollern kör långsammare och rapporterar tjatande meddelanden.
• Om du inaktiverar loggen ökar 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 tystar onödiga informationsmeddelanden och rapporterar endast felrelaterade meddelanden.

Think Times

Think Time är helt enkelt fördröjningen mellan två steg.

Think Time hjälper till att replikera användarbeteende eftersom ingen riktig användare kan använda någon applikation som en maskin (VUGen). VUGen genererar tänketid automatiskt. Du har fortfarande full kontroll över att ta bort, multiplicera eller fluktuera varaktigheten av tanketiden.

För att förstå mer kan en användare till exempel öppna en skärm (det vill säga ett svar följt av en förfrågan) och sedan ange 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 det tog en användare att skriva sitt användarnamn och lösenord är Think Time i LoadRunner.

Om du vill simulera aggressiv belastning på applikationen, överväg att inaktivera tänketiden helt.

Men för att simulera ett verkligt liknande beteende kan du "User Random Think Time" och ställa in procentsatserna efter önskemål.

Överväg att använda Limit Think Time till en legitim period. Vanligtvis är 30 sekunder ganska bra nog.

Hastighetssimulering

Hastighetssimulering hänvisar helt enkelt till bandbreddskapacitet för varje klientdator.

Eftersom vi simulerar tusentals VUser genom LoadRunner, är det otroligt hur enkelt LoadRunner har gjort för att styra simuleringen av bandbredd/nätverkshastighet.

Om ni är kunder som kommer åt er applikation över 128 Kbps kan ni styra den härifrån. Du kommer att få simulera "riktigt likt beteende" vilket borde hjälpa dig att få rätt prestationsstatistik.

Den bästa rekommendationen är att ställa in på Använd maximal bandbredd. Detta kommer att hjälpa till att bortse från nätverksrelaterade prestandaflaskhalsar och fokusera på eventuella problem i applikationen först. Du kan alltid köra testet flera gånger för att se varierande beteende under olika omständigheter.

Webbläsaremulering

Användarupplevelsen beror inte på vilken webbläsare en slutanvändare använder. Uppenbarligen ligger detta utanför ramarna för prestationsmått. Du kan dock välja vilken webbläsare du vill emulera.

Kan du svara för dig själv när exakt det kommer att spela någon roll 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 föremål för ansökan ä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 och så vidare

En annan viktig inställning är Simulera webbläsarcache. Om du vill mäta svarstiden när cache aktiverat, markera den här rutan. Om du letar efter värsta tänkbara situationer är detta uppenbarligen inte ett övervägande.

Nedladdning av icke-HTML-resurser låter LoadRunner ladda ner valfri CSS, JS och annan rich media. Detta bör förbli kontrollerat. Men om du vill ta bort detta från din prestandatestdesign kan du avmarkera detta.

Proxy

Det är bäst att eliminera proxy helt från din Testmiljö – detta kommer att göra 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 proxy-inställning. Du kan hämta den från din standardwebbläsare. Glöm dock inte att kontrollera vilken webbläsare som är inställd på standard och vilken proxykonfiguration för standardwebbläsare som är.

Om du använder en proxy och den kräver autentisering (eller ett skript) kan du klicka på knappen Autentisera vilket leder till ett nytt fönster. Se skärmdumpen nedan.

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.