Parametrering, funktioner, transaktioner i LoadRunner

Ett inspelat skript kan simulera en virtuell användare; dock kanske en enkel inspelning inte räcker för att replikera verkligt användarbeteende.

När ett skript spelas in täcker det ett enda, rakt flöde genom den aktuella applikationen. En riktig användare kan utföra flera iterationer av en process innan hen loggar ut. Fördröjningen mellan att klicka på knappar (betänketid) varierar från person till person, och vissa användare når din applikation via en snabb anslutning medan andra inte gör det. Så för att få den verkliga känslan av en slutanvändare måste vi förbättra våra skript så att de beter sig mycket likt riktiga användare.

Det är den viktigaste faktorn att beakta när man genomför ”Prestandatester”, men det finns mer i ett VUser-skript. Hur mäter man den tid det tar för en VUser medan System Under Load (SUL) testas? Hur vet man om VUsern klarade eller misslyckades vid en viss tidpunkt, och om en backend-process misslyckades eller om serverresurserna fick brist på tid?

Vi behöver förbättra vårt manus för att kunna besvara alla ovanstående frågor.

Varumärkesanmärkning: VuGen lanserades som HP, sedan Micro Focus, och är nu en del av OpenText Professionell prestandateknikFunktionerna och inställningarna nedan är oförändrade.

Använda transaktioner

Transaktioner mäter serverns svarstid för alla operationer. Enkelt uttryckt mäter en "transaktion" den tid det tar för systemet att svara på en viss begäran. Det kan vara så litet som ett knappklick eller ett AJAX-anrop som utlöses när en textruta tappar fokus.

Att tillämpa transaktioner är enkelt. Skriv en rad kod innan begäran görs och stäng transaktionen när begäran avslutas. LoadRunner kräver bara 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

Exempel:

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 anteckningar: Utdragen återges exakt som de publicerades, inklusive typografiska citat. Ett riktigt VuGen-skript behöver raka ASCII-citattecken, så skriv om dem om du kopierar den här koden.

Poäng att notera:

• Glöm inte att du arbetar med "C" och det är ett skiftlägeskänsligt språk.
• Punkttecknet (.) är inte tillåtet i ett transaktionsnamn, men du kan använda mellanslag och understreck.
• Om du har brancherat 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 så hanterar LoadRunner automatiskt serverfel (HTTP 500, 400 etc.).
• När du tillämpar transaktioner, se till att det inte finns någon betänketid inklämd, annars kommer din transaktion alltid att inkludera den perioden.
• Eftersom LoadRunner kräver en konstant sträng som transaktionsnamn är ett vanligt problem vid tillämpning av transaktioner att strängarna inte stämmer överens. Om du anger ett annat namn när du öppnar och stänger en transaktion får du minst två felmeddelanden. Transaktionen du öppnade stängdes aldrig, så LoadRunner ger ett felmeddelande; och transaktionen du försöker stänga öppnades aldrig, vilket ger ett andra felmeddelande.
• Båda felen visas i replay-loggen, så när något av dem rapporteras, kontrollera först transaktionsnamnet på öppnings- och stängningsrapporterna.
• Eftersom LoadRunner automatiskt hanterar synkronisering av förfrågningar och svar behöver du inte oroa dig för svaret när du tillämpar transaktioner.

Mötesplatser, kommentarer och skriptfunktioner

Tre mindre förbättringar gör att ett skript beter sig och läses som produktionskod: mötesplatser, kommentarer och funktionsläsaren som är inbyggd i VuGen.

Rendezvous Points

En mötesplats är en "mötesplats". Det är en enda sats som anger att LoadRunner ska introducera samtidighet. Du infogar mötesplatser i VUser-skript för att emulera hög användarbelastning på servern.

Mötesplatser instruerar en VU-användare att vänta under körningen tills flera VU-användare anländer till en viss punkt, så att de kan utföra en uppgift samtidigt. För att till exempel emulera toppbelastning på en bankserver, infoga en mötesplats som instruerar 100 VU-användare att sätta in kontanter samtidigt.

Om mötesplatserna inte placeras korrekt kommer V-användarna att komma åt olika delar av applikationen även för samma skript. Detta beror på att varje V-användare får olika svarstid och därför halkar några användare efter.

Syntax:

lr_rendezvous(“Logical Name”);

Korrigeringsanmärkning: den publicerade sidan stavas detta lr_rendesvousDet korrekta funktionsnamnet är lr_rendezvous; det felstavade formuläret kompileras inte.

Bästa metoder:

• Prefix en mötespunkt med "rdv_" för bättre kodläsbarhet; t.ex. "rdv_Login"
• Ta bort alla omedelbart intilliggande tanketidsuttryck
• Använd mötesplatser i skriptvyn efter inspelning

Skriptvyn nedan visar en rendezvous-sats infogad i en inspelad åtgärd:

Kommentarer

Lägg till kommentarer för att beskriva en aktivitet, en kodstycke 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 en specifik operation och separerar två avsnitt för att skilja dem åt.

Du kan lägga till kommentarer

• Under inspelning (med hjälp av verktyget)
• Efter inspelning (skriver direkt i kod)

Bästa praxis: markera eventuella kommentarer högst upp i varje skriptfil.

Infoga funktioner via menyn

Även om du kan skriva enkla rader kod direkt kan du behöva en ledtråd för att komma ihåg en funktion. Du kan också använda Steps Toolbox (känd som Insert Function före version 12) för att hitta och infoga valfri funktion direkt i ditt skript.

Du hittar verktygslådan Steg under Visa → Stegverktygslåda, som visas nedan.

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 Regulator), ersätter ett värde från en extern källa (t.ex. en .txt-fil, XML eller en databas) parameterns föregående värde.

Parameterisering är användbart för att skicka dynamiska (eller unika) värden till servern. Till exempel kan en affärsprocess behöva köra 10 iterationer samtidigt som ett unikt användarnamn väljs varje gång.

Det hjälper också till att simulera verkligt beteende mot det aktuella systemet. Ta en titt på exemplen nedan.

Exempel på problem:

• En affärsprocess fungerar bara för det aktuella datumet, vilket kommer från servern, så den kan 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 kunna fortsätta, även för en enskild användare. I sådana fall hjälper parametrisering.
• Ofta lagrar klientapplikationen en cache för data som skickas till och från servern. Som ett resultat tar servern inte emot verkligt användarbeteende (där servern kör en annan algoritm beroende på sökkriterierna). VUser-skriptet kommer att köras utan problem, men prestandastatistiken som ritas kommer inte att vara meningsfull. Att använda olika data genom parametrisering hjälper till att emulera serversidesaktivitet, såsom lagrade procedurer, 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. Att parametrisera datumet gör att VUser-körningen lyckas genom att ersätta det hårdkodade datumet. Sådana fält eller förfrågningar är rätt kandidater för parametrisering.

Du skapar en genom att högerklicka på det inspelade värdet i skriptvyn och välja Ersätt med en parameter. VuGen frågar sedan vilken typ som anger värdet:

Två ytterligare alternativ avgör hur data konsumeras över iterationer:

Genomgången nedan visar parametrisering som tillämpas på ett inspelat skript:

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

Körtidsinställningar och deras inverkan på VUser-simulering

Körtidsinställningarna är lika viktiga som ditt VuGen-skript. Med varierande konfigurationer kan du få helt olika testdesigner, vilket är anledningen till att inkonsekventa körtidsinställningar är den vanliga orsaken till icke-repeterbara resultat. Låt oss diskutera varje attribut ett efter ett.

Kör Logic

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

Detta gör det förmodligen tydligare varför LoadRunner föreslår keeping all inloggningskod i vuser_init och utloggningsdelen i vuser_end, båda exklusivt.

Om du har skapat flera åtgärder – till exempel Logga in, Öppna skärmen, Beräkna hyra, Skicka in pengar, Kontrollera saldo och Logga ut – så kommer scenariot nedan att inträffa för varje V-användare:

Alla V-användare loggar in, kör Öppna skärm, Beräkna hyra, Skicka in medel och Kontrollera saldo, sedan igen Öppna skärm, Beräkna hyra och så vidare, upprepade gånger 10 gånger, följt av utloggning (en gång).

Det här är en kraftfull inställning som låter skriptet agera mer som en riktig användare. Kom ihåg att en riktig användare inte loggar in och ut varje gång; de upprepar vanligtvis samma steg.

Hur många gånger klickar du på "inkorg" när du kollar din e-post innan du loggar ut?

pacing

Detta är viktigt. De flesta människor kan inte förstå skillnaden mellan tempo och tanketid. Den enda skillnaden är att tempo syftar på fördröjningen mellan iterationer, medan tanketid är fördröjningen mellan två steg.

Den rekommenderade inställningen beror på testdesignen. Om du däremot vill tillämpa aggressiv belastning kan du överväga att välja "Så snart föregående iteration avslutas", som visas nedan.

Logga

En logg, som den allmänt förstås, är en registrering av alla händelser medan du kör LoadRunner. Du kan aktivera loggen för att veta vad som händer mellan din applikation och din server.

LoadRunner erbjuder en kraftfull loggningsmekanism som är robust och skalbar i sig själv. Den låter dig behålla endast en "standardlogg", en detaljerad och konfigurerbar utökad logg, eller inaktivera loggning helt och hållet.

En standardlogg är informativ och lättförståelig. Den innehåller precis rätt mängd information som du vanligtvis behöver för att felsöka dina VUser-skript.

När det gäller den utökade loggen är all standardlogginformation en delmängd. Dessutom kan du använda parametersubstitution. Detta anger att LoadRunner-komponenten ska inkludera fullständig information om alla parametrar (från parameterisering), inklusive förfrågningar och svarsdata.

Om du inkluderar "Data returnerad av servern" kommer din logg att bli längre. Den kommer att inkludera all HTML, taggar, resurser och icke-resursinformation direkt i loggen. Alternativet är bara bra om du behöver seriös felsökning. Vanligtvis gör detta att loggfilen blir väldigt stor och svårbegriplig.

Som du kanske gissat vid det här laget, om du väljer "Avancerad Trace” kommer din loggfil att bli enorm. Du måste prova det. Du kommer att märka att den tid det tar för VuGen också ökar avsevärt, även om detta inte påverkar transaktionssvarstiden som rapporteras av VuGen. Detta är mycket avancerad information, och den är bara användbar om du förstår den aktuella applikationen, klient-till-server-kommunikationen mellan din applikation och hårdvara, samt detaljer på protokollnivå. Vanligtvis kräver denna information extrem ansträngning att läsa och felsöka.

Tips:

• Oavsett hur lång tid VuGen tar när loggen är aktiverad, har det ingen inverkan på transaktionssvarstiden – loggningsoverhead exkluderas från den uppmätta tiden.
• Inaktivera loggen om den inte behövs.
• Inaktivera loggen när du är klar med dina skript. Om du inkluderar skript med loggning aktiverad kommer kontrollenheten att köras långsammare och rapportera irriterande meddelanden.
• Om du inaktiverar loggen ökar det maximala antalet användare som du kan simulera från LoadRunner.
• Överväg att använda ”Skicka endast meddelanden när ett 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.

Tanketid hjälper till att replikera användarbeteende, eftersom ingen riktig användare kan använda en applikation som en maskin. VuGen genererar tanketid automatiskt. Du har fortfarande fullständig kontroll över att ta bort, multiplicera eller variera tanketidens varaktighet.

För att förstå det bättre: en användare kan öppna en skärm (ett svar följt av en förfrågan) och sedan skriva in ett användarnamn och lösenord innan hen trycker på Enter. Nästa interaktion mellan applikationen och servern sker när användaren klickar på "Logga in". Tiden det tog för användaren att skriva in användarnamnet och lösenordet är Think Time i LoadRunner.

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

För att simulera verkligt beteende kan du dock välja "Använd slumpmässig tanketid" och ställa in procentsatserna efter önskemål.

Överväg att använda Begränsa tanketid för att begränsa den till en legitim period. Vanligtvis är 30 sekunder ganska bra.

Hastighetssimulering

Hastighetssimulering hänvisar helt enkelt till bandbreddskapaciteten för varje klientmaskin.

Eftersom vi simulerar tusentals V-användare via LoadRunner är det anmärkningsvärt hur enkel LoadRunner har gjort simuleringen av bandbredd och nätverkshastighet.

Om dina kunder använder din applikation över 128 Kbps kan du styra det härifrån. Du kommer att kunna simulera verkligt beteende, vilket bör hjälpa dig att få rätt prestandastatistik.

Den bästa rekommendationen är att ställa in Använd maximal bandbredd. Detta hjälper dig att ignorera eventuella nätverksrelaterade prestandaflaskhalsar och fokusera på potentiella 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, så detta ligger till stor del utanför prestandamåttens ram. Du kan dock välja vilken webbläsare du vill emulera, som rutan nedan visar.

När spelar det egentligen någon roll vilken webbläsare man väljer i den här konfigurationen?

Du kommer att använda den här konfigurationen om ditt ämnesprogram är ett webbprogram som returnerar olika svar för olika webbläsare. Du kan till exempel se olika bilder och innehåll för Internet Explorer och Firefox.

En annan viktig inställning är Simulera webbläsarcache. Om du vill mäta svarstiden med cachen aktiverad markerar du den här rutan. Om du letar efter värsta tänkbara situationen är det uppenbarligen inte en faktor att beakta.

Om du laddar ner icke-HTML-resurser kan LoadRunner ladda ner CSS, JS och andra rikt media. Detta bör förbli markerat. Om du vill ta bort det från din prestandatestdesign kan du avmarkera det.

Proxy

Det är bäst att helt ta bort proxyn från din Testmiljö — en proxy som sitter i sökvägen gör testresultaten opålitliga. Du kan dock stöta på situationer där det är oundvikligt. I en sådan situation tillhandahåller LoadRunner proxyinställningar.

Du kommer att arbeta (eller borde arbeta) med inställningen Ingen proxy. Du kan hämta den från din standardwebbläsare. Glöm dock inte att kontrollera vilken webbläsare som är inställd som standard och vad proxykonfigurationen för den webbläsaren är.

Om du använder en proxy och det 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 ett användarnamn och lösenord för att autentisera dig 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.

Nästa kommer korrelation, kör scenariot i Regulator, och läsning resulterar i LoadRunner-analys. Se LoadRunner-arkitektur och Lasttestning guider.

Vanliga frågor