Parametrering, functies, transacties in LoadRunner

Inhoudsopgave:

Anonim

Een opgenomen script kan een virtuele gebruiker simuleren; Het is echter mogelijk dat een opname niet voldoende is om het "echte gebruikersgedrag" na te bootsen.

Wanneer een script is opgenomen, omvat het 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) zal van persoon tot persoon verschillen. De kans is groot dat sommige echte gebruikers toegang krijgen tot uw applicatie via DSL en andere via een inbelverbinding. Dus om het echte gevoel van de eindgebruiker te krijgen, moeten we onze scripts verbeteren zodat ze exact overeenkomen, of in ieder geval erg dicht bij echte gebruikers.

Bovenstaande is de belangrijkste overweging bij het uitvoeren van “Performance Testing”, maar er komt meer kijken bij een VU Script. Hoe ga je de precieze hoeveelheid tijd meten die een VUser nodig heeft wanneer SUL een prestatietest ondergaat? Hoe weet u of de VUser op een bepaald moment is doorgegaan of mislukt? Wat is de oorzaak van de storing, of een backend-proces is mislukt of dat de serverbronnen beperkt waren?

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

  • Transacties gebruiken
  • Inzicht in denktijd, ontmoetingspunten en opmerkingen
  • Functies invoegen via menu
  • Wat is parametrering?
  • Runtime-instellingen en hun impact op VU-simulatie
    • Voer Logic uit
    • Tempo
    • Logboek
  • Denk aan tijden
  • Snelheidssimulatie
  • Browser-emulatie
  • Proxy

Transacties gebruiken

Transacties zijn mechanismen om de reactietijd van de server voor elke bewerking te meten. In eenvoudige bewoordingen 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 als de focus uit het tekstvak verloren gaat.

Transacties toepassen is eenvoudig. Schrijf gewoon een regel code voordat het verzoek bij de server wordt ingediend en sluit de transactie wanneer het verzoek is afgelopen. LoadRunner vereist alleen een string als transactienaam.

Gebruik deze regel code om een ​​transactie te openen:

lr_start_transaction ("Transactienaam");

Gebruik deze regel code om de transactie te sluiten:

lr_end_transaction ("Transactienaam", );

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_Dashboard Name", LR_PASS);
lr_end_transaction ("Business_Workflow_Transaction Name", LR_FAIL);

Aandachtspunten:

  • Vergeet niet dat u met “C” werkt en dat is een hoofdlettergevoelige taal.
  • Punt (.) -Teken is niet toegestaan ​​in transactienaam, hoewel u spaties en onderstrepingstekens kunt gebruiken.
  • Als je je code goed hebt vertakt en controlepunten hebt toegevoegd om het antwoord van de server te verifiëren, kun je aangepaste foutafhandeling gebruiken, zoals LR_PASS of LR_FAIL. Anders kunt u LR_AUTO gebruiken en LoadRunner zal automatisch serverfouten afhandelen (HTTP 500, 400 etc.)
  • Zorg er bij het toepassen van transacties voor dat er geen think_time- verklaring wordt ingeklemd, anders omvat uw transactie altijd die periode.
  • Aangezien LoadRunner een constante string als transactienaam vereist, is een veelvoorkomend probleem bij het toepassen van een transactie een verkeerde combinatie van de string. Als u bij het openen en sluiten van een transactie een andere naam opgeeft, krijgt u minimaal 2 fouten. Aangezien de transactie die u heeft geopend 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 worden gerapporteerd? Waarom zou u uw eigen fout niet maken om uw antwoord te valideren? Als je goed had geantwoord, ben je op de goede weg. Als je fout hebt geantwoord, moet je je concentreren.
  • Aangezien LoadRunner automatisch zorgt voor de synchronisatie van verzoeken en respons, hoeft u zich geen zorgen te maken over respons bij het toepassen van transacties.

Inzicht in denktijd, ontmoetingspunten en opmerkingen

Rendez-vous-punten

Rendezvous Points betekent "ontmoetingspunten". Het is slechts één regel die LoadRunner vertelt om concurrency te introduceren. U voegt rendez-vous-punten in VUser-scripts in om een ​​zware gebruikersbelasting op de server te emuleren.

Rendez-vous-punten instrueren VUser om tijdens het uitvoeren van de test te wachten totdat meerdere VUser op een bepaald punt arriveren, zodat ze gelijktijdig een taak kunnen uitvoeren. Om bijvoorbeeld piekbelasting op de bankserver te emuleren, kunt u een rendez-vous-punt invoegen waarin 100 Vgebruiker wordt geïnstrueerd om tegelijkertijd contant geld op hun rekeningen te storten. Dit kan eenvoudig worden bereikt met behulp van rendez-vous.

Als de ontmoetingspunten niet correct zijn, heeft de VUser toegang tot verschillende delen van de applicatie - zelfs voor hetzelfde script. Dit komt doordat elke VUser een andere responstijd krijgt en daardoor weinig gebruikers achterblijven.

Syntaxis: lr_rendesvous ("Logische naam");

Praktische tips:

  • Voeg "rdv_" toe aan een ontmoetingspunt voor een betere leesbaarheid van de code; bijv. "rdv_Login"
  • Verwijder alle onmiddellijke denktijdverklaringen
  • Rendez-vous-punten toepassen in een scriptweergave (na opname)

Opmerkingen

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 bieden informatie over een specifieke operatie en scheiden twee secties om onderscheid te maken.

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 menu

Hoewel u rechtstreeks eenvoudige regels code kunt schrijven, heeft u wellicht een aanwijzing nodig om een ​​functie op te roepen. U kunt ook de Steps Toolbox (bekend als Functie invoegen vóór versie 12) gebruiken om een ​​functie rechtstreeks in uw script te zoeken en in te voegen.

U vindt de Stappenwerkbalk onder Beeld à Stappenwerkset.

Hierdoor wordt een zijvenster geopend, kijk naar de momentopname:

Wat is parametrering?

Een parameter in VUGen is een container die een geregistreerde waarde bevat die voor verschillende gebruikers wordt vervangen.

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

Parametrering is handig bij het verzenden van dynamische (of unieke) waarden naar de server, bijvoorbeeld; een bedrijfsproces is gewenst om 10 iteraties uit te voeren, maar elke keer een unieke gebruikersnaam te kiezen.

Het helpt ook bij het stimuleren van echt gedrag voor het subjectsysteem. Bekijk het onderstaande voorbeeld:

Probleemvoorbeelden:

Bedrijfsproces werkt alleen voor de huidige datum die van de server komt en kan daarom niet worden doorgegeven als een hard gecodeerd verzoek.

Soms geeft de clienttoepassing een unieke ID door aan de server (bijvoorbeeld session_id) zodat het proces kan doorgaan (zelfs voor een enkele gebruiker). In dat geval helpt parametrering.

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 met succes wordt uitgevoerd, zijn de prestatiestatistieken die worden opgesteld niet zinvol. Het gebruik van verschillende gegevens door middel van parametrering helpt bij het emuleren van server-side activiteit (procedures etc.) en oefent het systeem uit.

Een datum die tijdens de opname hard gecodeerd is in de VUser, is mogelijk niet langer geldig als die datum is verstreken. Door de datum te parametreren, kan VUser-uitvoering 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

Runtime-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 een voor een bespreken.

Voer Logic 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 inlogcode binnen vuser_init te houden en het uitloggedeelte in vuser_end, beide exclusief.

Als u meerdere acties heeft gemaakt, laten we zeggen: Inloggen, Scherm openen, Huur berekenen, Gelden indienen, Saldo controleren en uitloggen, dan vindt onderstaand scenario plaats voor elke VUser:

Alle VUsers zullen inloggen, Open Screen uitvoeren, Huur berekenen, Fondsen indienen, Saldo controleren - dan - weer Open scherm, Huur berekenen… enzovoort - 10 keer herhalen - gevolgd door uitloggen (eenmaal).

Dit is een krachtige instelling waarmee u zich meer als een echte gebruiker kunt gedragen. Onthoud dat een echte gebruiker niet elke keer inlogt en uitlogt - hij herhaalt meestal dezelfde stappen.

Hoe vaak klikt u op "inbox" wanneer u uw e-mail controleert voordat u zich afmeldt?

Tempo

Dit is belangrijk. Meestal zijn mensen niet in staat het verschil te begrijpen tussen tempo en denktijd. Het enige verschil is: "pacing verwijst naar de vertraging tussen iteraties", terwijl denktijd de vertraging is tussen twee willekeurige stappen.

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

Logboek

Een logboek (zoals algemeen wordt 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 logboekmechanisme dat op zichzelf robuust en schaalbaar is. Hiermee kunt u alleen "Standaardlogboek" of een gedetailleerd, configureerbaar uitgebreid logboek bijhouden of het helemaal uitschakelen.

Een standaardlogboek is informatief en gemakkelijk te begrijpen. Het bevat precies de juiste hoeveelheid kennis die u over het algemeen nodig zult hebben om uw VUser-scripts op te lossen.

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

Als u "Gegevens geretourneerd door server" opneemt, wordt uw logboek lang. Dit omvat alle HTML, tags, bronnen en niet-bronneninformatie die rechtstreeks in het logboek is opgenomen. De optie is alleen goed als u een serieuze probleemoplossing nodig heeft. Dit maakt het logbestand meestal erg groot en niet gemakkelijk te begrijpen.

Zoals je al zou kunnen raden als je kiest voor "Advance Trace", zal je logbestand enorm zijn. Je moet het proberen. U zult merken dat de hoeveelheid tijd die VUGen nodig heeft ook aanzienlijk is toegenomen, hoewel dit geen invloed heeft op de transactieresponsietijd die door VUGen wordt gerapporteerd. Dit is echter zeer geavanceerde informatie en kan nuttig zijn als u de betreffende toepassing, de client-servercommunicatie tussen uw toepassing en hardware en details op protocolniveau begrijpt. Gewoonlijk is deze informatie in wezen 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 reactietijd van de transactie. HP noemt dit fenomeen 'state of the art technology'.
  • Schakel het logboek uit als het niet vereist is.
  • Schakel het logboek uit als u klaar bent met uw scripts. Door scripts op te nemen waarvoor logboekregistratie is ingeschakeld, zal de controller langzamer werken en vervelende berichten rapporteren.
  • Als u het logboek uitschakelt, wordt de capaciteit van het maximale aantal gebruikers dat u met LoadRunner kunt simuleren, vergroot.
  • Overweeg het gebruik van "Verzend bericht alleen als er een fout optreedt" - dit zal onnodige informatieberichten dempen en alleen foutgerelateerde berichten rapporteren.

Denk aan tijden

Think Time is gewoon de vertraging tussen twee stappen.

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

Om meer te begrijpen, kan een gebruiker bijvoorbeeld een scherm openen (dat is een reactie 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 vindt plaats wanneer hij op "Aanmelden" klikt. De tijd die een gebruiker nodig heeft 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 echter een echt soortgelijk gedrag te simuleren, kunt u "User Random Think Time" gebruiken en de percentages naar wens instellen.

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

Snelheidssimulatie

Snelheidssimulatie verwijst eenvoudigweg naar de bandbreedtecapaciteit voor elke clientcomputer.

Aangezien we duizenden VUser's simuleren met LoadRunner, is het verbazingwekkend hoe eenvoudig LoadRunner het heeft gemaakt om de bandbreedte / netwerksnelheidssimulatie te regelen.

Als u klanten bent die toegang hebben tot uw applicatie via 128 Kbps, kunt u deze vanaf hier beheren. U zult "echt soortgelijk gedrag" kunnen simuleren, wat zou moeten helpen bij het verkrijgen van de juiste prestatiestatistieken.

De beste aanbeveling is om in te stellen op Maximale bandbreedte gebruiken. Dit helpt om eventuele knelpunten in de netwerkprestaties te negeren en eerst te focussen op mogelijke problemen in de applicatie. U 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. Dit valt duidelijk buiten het bereik van prestatiemaatstaven. U kunt echter kiezen welke browser u wilt emuleren.

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

U gebruikt deze configuratie als uw onderwerp een webtoepassing is, die verschillende reacties voor verschillende browsers retourneert. U krijgt bijvoorbeeld verschillende afbeeldingen en inhoud te zien voor IE en Firefox enz.

Een andere belangrijke instelling is Browsercache simuleren. Vink dit vakje aan als u de responstijd wilt meten wanneer de cache is ingeschakeld. Als u op zoek bent naar de slechtste situatie, is dit duidelijk geen overweging.

Als u niet-HTML-bronnen downloadt, kan LoadRunner alle CSS-, JS- en andere rich media downloaden. Dit moet gecontroleerd blijven. Als u dit echter uit het ontwerp van uw prestatietest wilt verwijderen, kunt u dit uitschakelen.

Proxy

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

U werkt (of zou moeten werken) met de instelling Geen proxy. U kunt het verkrijgen via uw standaardbrowser. Vergeet echter niet te controleren welke browser 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 Authenticatie klikken die naar een nieuw venster leidt. Raadpleeg de onderstaande schermafbeelding.

Gebruik dit scherm om een ​​gebruikersnaam en wachtwoord op te geven om u op de proxyserver te laten verifiëren. Klik op OK om het scherm te sluiten.

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