Parametrering, functies, transacties in LoadRunner

Een opgenomen script kan een virtuele gebruiker simuleren; een loutere opname is echter mogelijk niet voldoende om het “echte gebruikersgedrag” te repliceren.

Wanneer een script wordt opgenomen, bestrijkt dit de enkele en rechte stroom van de onderwerptoepassing. Terwijl een echte gebruiker meerdere iteraties van elk proces kan uitvoeren voordat hij uitlogt. De vertraging tussen het klikken op knoppen (denktijd) varieert van persoon tot persoon. De kans is groot dat sommige echte gebruikers toegang krijgen tot uw applicatie via DSL en sommige via een inbelverbinding. Om dus het echte gevoel van de eindgebruiker te krijgen, moeten we onze scripts verbeteren zodat ze exact overeenkomen, of op zijn minst qua gedrag zeer dicht bij echte gebruikers liggen.

Het bovenstaande is de belangrijkste overweging bij het uitvoeren van “Performance Testing”, maar er zit meer achter een VU-Script. Hoe meet u de precieze hoeveelheid tijd die een VUser nodig heeft wanneer SUL een prestatietest ondergaat? Hoe weet je of de VUser op een bepaald punt is geslaagd of is mislukt? Wat is de oorzaak van de fout: is een back-endproces mislukt of zijn de serverbronnen beperkt?

We moeten ons script verbeteren om alle bovenstaande vragen te kunnen beantwoorden.

Transacties gebruiken

Transacties zijn mechanismen om de serverresponstijd voor elke bewerking te meten. Simpel gezegd helpt het gebruik van "Transactie" om de tijd te meten die het systeem nodig heeft voor een bepaald verzoek. Het kan zo klein zijn als een klik op een knop of een AJAX-oproep bij het verliezen van de focus van het tekstvak.

Het toepassen van transacties is eenvoudig. Schrijf gewoon één regel code voordat er een verzoek aan de server wordt gedaan en sluit de transactie wanneer het verzoek eindigt. LoadRunner vereist alleen een string als transactienaam.

Gebruik deze coderegel om een ​​transactie te openen:

lr_start_transaction(“Transaction Name”);

Gebruik deze coderegel om de transactie te sluiten:

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

De vertelt LoadRunner of deze specifieke transactie succesvol of niet succesvol was. De mogelijke parameters kunnen zijn:

• LR_AUTO
• LR_PASS
• LR_FAIL

Voorbeeld:

lr_end_transaction(“Mijn_Login”, LR_AUTO);
lr_end_transaction(“001_Opening_Dashboardnaam”, LR_PASS);
lr_end_transaction(“Business_Workflow_Transaction Naam”, LR_FAIL);

Aandachtspunten:

• Vergeet niet dat u met “C” werkt en dat is een hoofdlettergevoelige taal.
• Een punt (.) is niet toegestaan ​​in de transactienaam, hoewel u wel spaties en onderstrepingstekens kunt gebruiken.
• Als u uw code goed hebt vertakt en controlepunten hebt toegevoegd om de respons van de server te verifiëren, kunt u aangepaste foutafhandeling gebruiken, zoals LR_PASS of LR_FAIL. Anders kunt u LR_AUTO gebruiken en zal LoadRunner automatisch serverfouten afhandelen (HTTP 500, 400 etc.)
• Zorg er bij het toepassen van transacties voor dat dit niet het geval is denk_tijd als de afschrift tussen de regels staat of als er anderszins een punt in uw transactie staat, zal deze altijd die periode bevatten.
• Omdat LoadRunner een constante tekenreeks als transactienaam vereist, is een veelvoorkomend probleem bij het toepassen van een transactie het niet overeenkomen van de tekenreeks. Als u bij het openen en sluiten van een transactie een andere naam opgeeft, krijgt u minimaal 2 foutmeldingen. Omdat de door u geopende transactie nooit is gesloten, geeft LoadRunner een foutmelding. Bovendien is de transactie die u probeert te sluiten nooit geopend, waardoor er een fout is opgetreden.
• Kunt u uw intelligentie gebruiken en voor uzelf antwoorden welke van de bovenstaande fouten als eerste wordt gerapporteerd? Waarom maakt u niet uw eigen fout om uw antwoord te valideren? Als u het juiste antwoord had gegeven, bent u op de goede weg. Als je verkeerd hebt geantwoord, moet je je concentreren.
• Omdat LoadRunner automatisch zorgt voor de synchronisatie van aanvragen en reacties, hoeft u zich bij het toepassen van transacties geen zorgen te maken over reacties.

Denktijd, ontmoetingspunten en opmerkingen begrijpen

Rendez-vouspunten

Rendezvous Points betekent “ontmoetingspunten”. Het is slechts één regel die LoadRunner vertelt om gelijktijdigheid te introduceren. U voegt ontmoetingspunten in VUser-scripts in om een ​​zware gebruikersbelasting op de server te emuleren.

Rendez-vouspunten instrueren de VUser om tijdens de testuitvoering te wachten tot meerdere VUsers op een bepaald punt arriveren, zodat ze gelijktijdig een taak kunnen uitvoeren. Om bijvoorbeeld de piekbelasting op de bankserver te emuleren, kunt u een ontmoetingspunt invoegen waarin u 100 VUsers de opdracht geeft tegelijkertijd contant geld op hun rekeningen te storten. Dit kan eenvoudig worden bereikt met behulp van rendez-vous.

Als de ontmoetingspunten niet correct zijn geplaatst, heeft de VUser toegang tot verschillende delen van de applicatie – zelfs voor hetzelfde script. Dit komt omdat elke VUser een andere responstijd krijgt en er dus maar weinig gebruikers achterblijven.

Syntaxis: lr_rendesvous(“Logische naam”);

Praktische tips:

• Geef een ontmoetingspunt een voorvoegsel met “rdv_” voor een betere leesbaarheid van de code; bijvoorbeeld “rdv_Login”
• Verwijder alle onmiddellijke denktijdverklaringen
• Rendez-vouspunten toepassen in een scriptweergave (na opname)

Heb je vragen? Stel ze hier.

Voeg opmerkingen toe om een ​​activiteit, een stukje code of een regel code te beschrijven. Opmerkingen helpen de code begrijpelijk te maken voor iedereen die er in de toekomst naar verwijst. Ze geven informatie over specifieke handelingen en scheiden twee secties voor onderscheid.

U kunt opmerkingen toevoegen

• Tijdens het opnemen (met behulp van tool)
• Na opname (direct in code schrijven)

Best Practice: Markeer eventuele opmerkingen bovenaan elk scriptbestand

Functies invoegen via het menu

Hoewel u direct eenvoudige regels code kunt schrijven, hebt u mogelijk een aanwijzing nodig om een ​​functie te herinneren. U kunt ook Steps Toolbox (eerder bekend als Insert Function vóór versie 12) gebruiken om een ​​functie direct in uw script te vinden en in te voegen.

U vindt de Stappenwerkbalk onder Beeld àStappenwerkbalk.

Hierdoor wordt een zijvenster geopend, bekijk de momentopname:

Wat is parameterisatie?

A parameter in VUGen is een container waarin een geregistreerde waarde zit die voor verschillende gebruikers wordt vervangen.

Tijdens de uitvoering van het script (in VUGen of Controller) vervangt de waarde uit een externe bron (zoals .txt, XML of database) de vorige waarde van de parameter.

Parametrering is bijvoorbeeld handig bij het verzenden van dynamische (of unieke) waarden naar de server; Het is wenselijk dat een bedrijfsproces 10 iteraties uitvoert, maar elke keer een unieke gebruikersnaam kiest.

Het helpt ook bij het stimuleren van realistisch gedrag voor het onderwerpsysteem. Kijk eens naar onderstaand voorbeeld:

Probleemvoorbeelden:

Het bedrijfsproces werkt alleen voor de huidige datum die afkomstig is van de server en kan daarom niet worden doorgegeven als een hardgecodeerd verzoek.

Soms geeft de clienttoepassing een uniek ID door aan de server (bijvoorbeeld session_id) zodat het proces kan doorgaan (zelfs voor een enkele gebruiker). In zo'n geval helpt parametrisering.

Vaak houdt de clienttoepassing een cache bij van gegevens die van en naar de server worden verzonden. Als gevolg hiervan ontvangt de server geen echt gebruikersgedrag (in het geval dat de server een ander algoritme uitvoert, afhankelijk van de zoekcriteria). Hoewel het VUser-script succesvol zal worden uitgevoerd, zullen de getrokken prestatiestatistieken niet zinvol zijn. Het gebruik van verschillende gegevens door middel van parametrisering helpt bij het emuleren van activiteit aan de serverzijde (procedures enz.) en oefent het systeem uit.

Een datum die tijdens de opname hardgecodeerd is in de VUser, is mogelijk niet meer geldig als die datum verstreken is. Door de datum te parametreren, kan de uitvoering van VUser slagen door de hardgecodeerde datum te vervangen. Dergelijke velden of verzoeken zijn de juiste kandidaten voor parametrisering.

Klik hier als de video niet toegankelijk is

Run Time-instellingen en hun impact op VU-simulatie

Runtime-instellingen zijn net zo belangrijk als uw VUGen-script. Met verschillende configuraties kunt u verschillende testontwerpen verkrijgen. Dit is de reden waarom u mogelijk niet-herhaalbare resultaten krijgt als de Run Time-instellingen niet consistent zijn. Laten we elk kenmerk één voor één bespreken.

Voer logica uit

Run Logic definieert het aantal keren dat alle acties worden uitgevoerd, behalve vuser_init en vuser_end.

Dit maakt waarschijnlijk duidelijker waarom LoadRunner voorstelt om alle inlogcodes binnen vuser_init en het uitloggedeelte in vuser_end te houden, beide exclusief.

Als u meerdere acties heeft aangemaakt, bijvoorbeeld Inloggen, Scherm openen, Huur berekenen, Geld indienen, Saldo controleren en uitloggen, dan vindt het onderstaande scenario plaats voor elke VUser:

Alle VGebruikers zullen inloggen, Open Scherm uitvoeren, Huur berekenen, Geld indienen, Saldo controleren – dan – opnieuw Scherm openen, Huur berekenen… enzovoort – 10 keer herhalend – gevolgd door uitloggen (eenmaal).

Dit is een krachtige instelling waarmee u zich meer als een echte gebruiker kunt gedragen. Houd er rekening mee dat een echte gebruiker niet elke keer in- en uitlogt; hij herhaalt meestal dezelfde stappen.

Hoe vaak klikt u op “inbox” wanneer u uw e-mail controleert voordat u uitlogt?

pacing

Dit is belangrijk. Meestal kunnen mensen het verschil tussen tempo en denktijd niet begrijpen. Het enige verschil is, "pacing verwijst naar de vertraging tussen iteraties", terwijl denktijd de vertraging is tussen twee stappen.

De aanbevolen instelling is afhankelijk van het testontwerp. Als u echter op zoek bent naar een agressieve belasting, overweeg dan om te kiezen voor “Zodra de vorige iteratie eindigt”

Log

Een logboek (zoals algemeen begrepen) is een boekhouding van alle gebeurtenissen terwijl u LoadRunner uitvoert. U kunt log inschakelen om te weten wat er gebeurt tussen uw applicatie en uw server.

LoadRunner biedt een krachtig logboekregistratiemechanisme dat op zichzelf robuust en schaalbaar is. Hiermee kunt u alleen het “Standaardlogboek” of een gedetailleerd, configureerbaar uitgebreid logbestand bijhouden, of dit helemaal uitschakelen.

Een standaardlogboek is informatief en gemakkelijk te begrijpen. Het bevat precies de juiste hoeveelheid kennis die u doorgaans nodig heeft voor het oplossen van problemen met uw VUser-scripts.

In het geval van Uitgebreid logboek is alle standaardlogboekinformatie een subset. Bovendien kunt u parametervervanging uitvoeren. Dit vertelt de LoadRunner-component om volledige informatie op te nemen van alle parameters (van parametrisering), inclusief verzoeken, evenals responsgegevens.

Als u “Gegevens geretourneerd door server” opneemt, zal uw log lang zijn. Dit omvat alle HTML, tags, bronnen en niet-bronneninformatie die rechtstreeks in het logboek is opgenomen. De optie is alleen goed als u serieuze probleemoplossing nodig heeft. Meestal zorgt dit ervoor dat het logbestand erg groot is en niet gemakkelijk te begrijpen.

Zoals u inmiddels wel kunt raden, zal uw logbestand enorm zijn als u kiest voor "Advance Trace". U moet het proberen. U zult merken dat de hoeveelheid tijd die VUGen nodig heeft ook aanzienlijk is toegenomen, hoewel dit geen invloed zal hebben op de transactieresponstijd die VUGen rapporteert. Dit is echter zeer geavanceerde informatie en kan nuttig zijn als u de onderwerptoepassing, de client-naar-servercommunicatie tussen uw toepassing en hardware en protocolniveaudetails begrijpt. Meestal is deze informatie in essentie dood, omdat het extreme inspanningen vereist om te begrijpen en problemen op te lossen.

Tips:

• Het maakt niet uit hoeveel tijd VUGen nodig heeft als log is ingeschakeld, het heeft geen invloed op de responstijd van de transactie. HP noemt dit fenomeen ‘state of the art technologie’.
• Schakel log uit als dit niet nodig is.
• Schakel log uit als u klaar bent met uw scripts. Het opnemen van scripts waarbij logboekregistratie is ingeschakeld, zorgt ervoor dat de controller langzamer werkt en vervelende berichten rapporteert.
• Als u het logboek uitschakelt, wordt de capaciteit vergroot van het maximale aantal gebruikers dat u vanuit LoadRunner kunt simuleren.
• Overweeg het gebruik van “Verstuur bericht alleen als er een fout optreedt” – dit dempt onnodige informatieberichten en rapporteert alleen foutgerelateerde berichten.

Denk tijden

Denktijd is eenvoudigweg de vertraging tussen twee stappen.

Think Time helpt bij het repliceren van gebruikersgedrag, aangezien geen enkele echte gebruiker een applicatie zoals een machine kan gebruiken (VUGen). VUGen genereert automatisch denktijd. U heeft nog steeds de volledige controle over het verwijderen, vermenigvuldigen of fluctueren van de denktijd.

Om meer te begrijpen, kan een gebruiker bijvoorbeeld een scherm openen (dat is een antwoord gevolgd door een verzoek) en vervolgens zijn gebruikersnaam en wachtwoord opgeven voordat hij op Enter drukt. De volgende interactie van de applicatie met de server zal plaatsvinden wanneer hij op “Aanmelden” klikt. De tijd die een gebruiker nodig had om zijn gebruikersnaam en wachtwoord in te voeren, is Think Time in LoadRunner.

Als u een agressieve belasting van de applicatie wilt simuleren, overweeg dan om de denktijd volledig uit te schakelen.

Om echt gedrag te simuleren, kunt u echter “User Random Think Time” gebruiken en de percentages naar wens instellen.

Overweeg om de denktijd te beperken tot een legitieme periode. Meestal is 30 seconden redelijk goed genoeg.

Snelheidssimulatie

Snelheidssimulatie verwijst eenvoudigweg naar de bandbreedtecapaciteit voor elke clientmachine.

Omdat we duizenden VUsers simuleren via LoadRunner, is het verbazingwekkend hoe eenvoudig LoadRunner het heeft gemaakt om de simulatie van bandbreedte/netwerksnelheid te controleren.

Als u als klant toegang heeft tot uw applicatie via 128 Kbps, kunt u deze vanaf hier beheren. U zult “echt gedrag” kunnen simuleren, wat zou moeten helpen de juiste prestatiestatistieken te verkrijgen.

De beste aanbeveling is om Maximale bandbreedte gebruiken in te stellen. Dit helpt eventuele netwerkgerelateerde prestatieknelpunten te negeren en eerst te focussen op mogelijke problemen in de applicatie. Je kunt de test altijd meerdere keren uitvoeren om wisselend gedrag onder verschillende omstandigheden te zien.

Browser-emulatie

De gebruikerservaring is niet afhankelijk van de browser die een eindgebruiker gebruikt. Het is duidelijk dat dit buiten het bestek van prestatiemetingen valt. U kunt echter kiezen welke browser u wilt emuleren.

Kunt u uzelf antwoorden wanneer het voor u precies van belang is om in deze configuratie de juiste browser te selecteren?

U gebruikt deze configuratie als de toepassing een webtoepassing is, waarbij voor verschillende browsers verschillende antwoorden worden geretourneerd. U krijgt bijvoorbeeld verschillende afbeeldingen en inhoud te zien voor IE en Firefox enz.

Een andere belangrijke instelling is Simulate browser cache. Als u de responstijd wilt meten wanneer cache is ingeschakeld, vinkt u dit vakje aan. Als u op zoek bent naar de worstcasesituatie, is dit uiteraard geen overweging.

Door niet-HTML-bronnen te downloaden, kan LoadRunner alle CSS, JS en andere rich media downloaden. Dit moet gecontroleerd blijven. Als u dit echter uit uw prestatietestontwerp wilt verwijderen, kunt u dit uitschakelen.

volmacht

Het is het beste om proxy volledig uit uw systeem te verwijderen Test omgeving – dit maakt de testresultaten onbetrouwbaar. U kunt echter te maken krijgen met situaties waarin dit onvermijdelijk is. In een dergelijke situatie faciliteert LoadRunner u met proxy-instellingen.

U zult werken (of zou moeten werken) zonder proxy-instelling. U kunt deze verkrijgen via uw standaardbrowser. Vergeet echter niet te controleren welke browser op standaard is ingesteld en welke proxyconfiguratie voor de standaardbrowser is.

Als u een proxy gebruikt en authenticatie (of een script) vereist, kunt u op de knop Authenticeren klikken, waarna een nieuw venster wordt geopend. Zie onderstaande schermafbeelding.

Gebruik dit scherm om gebruikersnaam en wachtwoord op te geven om te worden geverifieerd op de proxyserver. Klik op OK om het scherm te sluiten.

Gefeliciteerd. U bent klaar met het configureren van uw VUGen-script. Vergeet niet om het voor al uw VUser-scripts te configureren.