LoadRunner-testtool – Componenten en Architectuur

Wat is LoadRunner?

LoadRunner is een prestatietesttool die werd ontwikkeld door Mercury in 1999. LoadRunner werd later, in 2006, overgenomen door HPE. In 2016 werd LoadRunner overgenomen door MicroFocus.

LoadRunner ondersteunt verschillende ontwikkeltools, technologieën en communicatieprotocollen. In feite is dit het enige instrument op de markt dat een dergelijk groot aantal protocollen ondersteunt Performance Testing. Prestatietestresultaten geproduceerd door LoadRunner-software worden gebruikt als benchmark voor andere tools

LoadRunner-video

Waarom LoadRunner?

LoadRunner is niet alleen een pionierstool op het gebied van Performance Testing, maar het is nog steeds marktleider op het gebied van Performance Testing. Uit een recent onderzoek blijkt dat LoadRunner een marktaandeel van ongeveer 85% heeft in de prestatietestindustrie.

In grote lijnen ondersteunt de LoadRunner-tool RIA (Rich Internet Applications), Web 2.0 (HTTP/HTML, Ajax, Flex en Silverlight enz.), Mobiel, SAP, Oracle, MEVR SQL Server, Citrix, RTE, Mail en bovenal, Windows Stopcontact. Er is geen concurrerend hulpmiddel op de markt dat zo'n grote verscheidenheid aan protocollen kan bieden die in één enkel hulpmiddel zijn ondergebracht.

Wat overtuigender is om voor LoadRunner te kiezen bij het testen van software, is de geloofwaardigheid van deze tool. De LoadRunner-tool heeft al lang een reputatie opgebouwd, zoals u vaak zult tegenkomen klanten kruisen uw prestatiebenchmarks met behulp van LoadRunner. U zult verlichting vinden als u LoadRunner al gebruikt voor uw prestatietestbehoeften.

LoadRunner-software is nauw geïntegreerd met andere HP-tools zoals Unified Functional Test (QTP) en ALM (Application Lifecycle Management), waarmee u uw end-to-end testprocessen kunt uitvoeren.

LoadRunner werkt volgens een principe voor het simuleren van virtuele gebruikers op de onderhavige toepassing. Deze virtuele gebruikers, ook wel VUsers genoemd, repliceren de verzoeken van de klant en verwachten een overeenkomstig antwoord op het doorgeven van een transactie.

Waarom heeft u prestatietests nodig?

Naar schatting verlies van 4.4 miljard aan inkomsten wordt jaarlijks geregistreerd vanwege slechte webprestaties.

In het huidige tijdperk van Web 2.0 klikken gebruikers weg als een website niet binnen 8 seconden reageert. Stel je voor dat je 5 seconden moet wachten bij het zoeken op Google of het doen van een vriendschapsverzoek op Facebook. De gevolgen van downtime van de prestaties zijn vaak verwoestender dan ooit gedacht. We hebben voorbeelden zoals die onlangs Bank of America Online Banking troffen, Amazon Webservices, Intuit of Blackberry.

Volgens Dunn & Bradstreet ervaart 59% van de Fortune 500-bedrijven naar schatting 1.6 uur downtime per week. Als we bedenken dat het gemiddelde Fortune 500-bedrijf met minimaal 10,000 werknemers $ 56 per uur betaalt, zou het arbeidsdeel van de downtimekosten voor zo'n organisatie $ 896,000 per week bedragen, wat neerkomt op meer dan $ 46 miljoen per jaar.

Een downtime van slechts vijf minuten op Google.com (5 augustus 19) kost de zoekgigant naar schatting maar liefst $ 13.

Er wordt geschat dat bedrijven een omzet ter waarde van $1100 per seconde hebben verloren als gevolg van een recente Amazon Webservicestoring.

Wanneer een softwaresysteem door een organisatie wordt geïmplementeerd, kan het veel scenario's tegenkomen die mogelijk resulteren in prestatielatentie. Een aantal factoren veroorzaken vertragende prestaties, enkele voorbeelden kunnen zijn:

• Het aantal records in de database is toegenomen
• Toename van het aantal gelijktijdige verzoeken aan het systeem
• een groter aantal gebruikers die tegelijkertijd toegang hebben tot het systeem in vergelijking met het verleden

Wat is LoadRunner Archistructuur?

Globaal gezien is de architectuur van HP LoadRunner complex, maar toch eenvoudig te begrijpen.

Stel dat u de opdracht krijgt om de prestaties van te controleren Amazon.com voor 5000 gebruikers

In een echte situatie zullen al deze 5000 gebruikers niet op de startpagina staan, maar op een ander gedeelte van de websites. Hoe kunnen we anders simuleren.

VUGen

VUGen of Virtuele Gebruiker Generator is een IDE (Integrated Development Environment) of een rijke coderingseditor. VUGen wordt gebruikt om het gedrag van System Under Load (SUL) te repliceren. VUGen biedt een “opname”-functie die de communicatie van en naar de client en server registreert in de vorm van een gecodeerd script – ook wel VUser-script genoemd.

Gezien het bovenstaande voorbeeld kan VUGen de volgende bedrijfsprocessen simuleren:

1. Surfen op de productenpagina van Amazon.com
2. Bestelling
3. Payment Processing
4. Mijn accountpagina controleren

Controller

Zodra een VUser-script is voltooid, is Controller een van de belangrijkste LoadRunner-componenten die de Load-simulatie bestuurt door bijvoorbeeld het volgende te beheren:

• Hoeveel VUsers er moeten worden gesimuleerd voor elk bedrijfsproces of VUser-groep
• Gedrag van VUsers (opstarten, afbouwen, gelijktijdig of gelijktijdig karakter etc.)
• Aard van het belastingscenario, bijvoorbeeld Real Life of Doelgericht of verifiërende SLA
• Welke injectoren te gebruiken, hoeveel VUsers tegen elke injector
• Verzamel periodiek de resultaten
• IP-spoofing
• Foutmelding
• Transactierapportage enz.

Als we een analogie nemen met onze voorbeeldcontroller, voegen we de volgende parameter toe aan het VUGen-script

1) 3500 gebruikers zijn Surfen op de productenpagina van Amazon.com

2) 750 gebruikers zijn binnen Bestelling

3) 500 gebruikers zijn het uitvoeren van betalingsverwerking

4) 250 gebruikers zijn Mijn accountpagina ALLEEN controleren nadat 500 gebruikers de betalingsverwerking hebben voltooid

Er zijn nog complexere scenario's mogelijk

1. Initieer elke 5 seconden 2 VUsers tot een belasting van 3500 VUsers (surfen Amazon productpagina) is bereikt.
2. Herhaal dit gedurende 30 minuten
3. Iteratie onderbreken voor 25 VU's
4. Start 20 VUSers opnieuw
5. Start elke seconde 2 gebruikers (in Afrekenen, Betalingsverwerking, MijnAccounts-pagina).
6. Er worden 2500 VUsers gegenereerd op Machine A
7. Er worden 2500 VUsers gegenereerd op Machine B

Agentenmachine/lading Generators/Injectoren

HP LoadRunner Controller is verantwoordelijk voor het simuleren van duizenden VUsers – deze VUsers verbruiken hardwarebronnen zoals processor en geheugen – waardoor er een limiet wordt gesteld aan de machine die ze simuleert. Bovendien simuleert Controller deze VU's vanaf dezelfde machine (waar Controller zich bevindt) en daarom zijn de resultaten mogelijk niet nauwkeurig. Om dit probleem aan te pakken, worden alle VU's verspreid over verschillende machines, genaamd Laden Generators of Load-injectoren.

Normaal gesproken bevindt de controller zich op een andere machine en wordt de belasting van andere machines gesimuleerd. Afhankelijk van het protocol van VUser-scripts en machinespecificaties kunnen een aantal Load Injectors nodig zijn voor volledige simulatie. VUsers voor een HTTP-script hebben bijvoorbeeld 2-4 MB per VUser nodig voor simulatie, daarom zijn er 4 machines met elk 4 GB RAM nodig om een ​​belasting van 10,000 VUsers te simuleren.

Analogie overgenomen van onze Amazon De uitvoer van dit onderdeel zal bijvoorbeeld zijn

Analyse

Zodra Load-scenario’s zijn uitgevoerd, wordt de rol van “Analyse”componenten van LoadRunner komen binnen.

Tijdens de uitvoering maakt Controller een dump van resultaten in onbewerkte vorm en bevat informatie zoals welke versie van LoadRunner deze resultatendump heeft gemaakt en wat de configuraties waren.

Alle fouten en uitzonderingen worden geregistreerd in een Microsoft toegang tot database, genaamd output.mdb. De component “Analyse” leest dit databasebestand om verschillende soorten analyses uit te voeren en genereert grafieken.

Deze grafieken tonen verschillende trends om de redenering achter fouten en falen onder belasting te begrijpen; helpen dus bepalen of optimalisatie nodig is in SUL, Server (bijv. JBoss, Oracle) of infrastructuur.

Hieronder ziet u een voorbeeld waarbij bandbreedte een knelpunt kan vormen. Laten we zeggen dat de webserver een capaciteit van 1 GBps heeft, terwijl het dataverkeer deze capaciteit overschrijdt, waardoor volgende gebruikers eronder lijden. Om te bepalen of het systeem aan dergelijke behoeften voldoet, moet Performance Engineer het applicatiegedrag met een abnormale belasting analyseren. Hieronder ziet u een grafiek die LoadRunner genereert om bandbreedte te verkrijgen.

Hoe u prestatietests uitvoert

De Performance Testing Roadmap kan grofweg in 5 stappen worden verdeeld:

• Planning voor belastingstest
• VUGen-scripts maken
• Scenariocreatie
• Scenario-uitvoering
• Resultatenanalyse (gevolgd door systeemaanpassingen)

Nu u LoadRunner hebt geïnstalleerd, laten we de stappen die bij het proces betrokken zijn, een voor een begrijpen.

Stappen betrokken bij het prestatietestproces

Stap 1) Planning voor de belastingstest

Het plannen van prestatietests is anders dan het plannen van een SIT (systeemintegratietesten) or UAT (gebruikersacceptatietesten). De planning kan verder worden onderverdeeld in kleine fasen, zoals hieronder beschreven:

Stel uw team samen

Wanneer u aan de slag gaat met LoadRunner Testing, kunt u het beste documenteren wie van elk team dat tijdens het proces aan de activiteit deelneemt, zal deelnemen.

Project Manager:

Nomineer de projectmanager die eigenaar wordt van deze activiteit en die zal fungeren als aanspreekpunt voor escalatie.

Functie Expert/ Business Analist:

Zorg voor gebruiksanalyse van SUL en biedt expertise over de zakelijke functionaliteit van website/SUL

Expert op het gebied van prestatietests:

Creëert de geautomatiseerde prestatietests en voert belastingscenario's uit

Systeem Architect:

Biedt blauwdruk van de SUL

Webontwikkelaar en MKB:

• Onderhoudt de website en zorgt voor monitoringaspecten
• Ontwikkelt website en repareert bugs

Systeem administrator:

• Onderhoudt de betrokken servers tijdens een testproject

Geef een overzicht van de betrokken applicaties en bedrijfsprocessen:

Succesvolle load Testen vereist dat u van plan bent een bepaald bedrijfsproces uit te voeren. Een bedrijfsproces bestaat uit duidelijk gedefinieerde stappen in overeenstemming met de gewenste zakelijke transacties – om zo uw doelstellingen voor het testen van de belasting te bereiken.

Er kan een vereistenmetriek worden opgesteld om de gebruikersbelasting op het systeem te vergroten. Hieronder ziet u een voorbeeld van een aanwezigheidssysteem in een bedrijf:

In het bovenstaande voorbeeld vermelden de cijfers het aantal gebruikers dat op een bepaald uur met de applicatie (SUL) is verbonden. We kunnen op elk uur van de dag het maximale aantal gebruikers dat verbonden is met een bedrijfsproces extraheren. Dit wordt berekend in de meest rechtse kolommen.

Op dezelfde manier kunnen we het totale aantal gebruikers dat op elk uur van de dag met de applicatie (SUL) is verbonden, concluderen. Dit wordt in de laatste rij berekend.

De bovenstaande 2 feiten samen geven ons het totale aantal gebruikers waarmee we het systeem op prestaties moeten testen.

Definieer procedures voor het beheer van testgegevens

Statistieken en observaties uit prestatietests worden sterk beïnvloed door talrijke factoren, zoals eerder vermeld. Het is van cruciaal belang om testgegevens voor te bereiden voor prestatietests. Soms verbruikt een bepaald bedrijfsproces een dataset en produceert het een andere dataset. Neem onderstaand voorbeeld:

• Een gebruiker 'A' maakt een financieel contract aan en dient dit ter beoordeling in.
• Een andere gebruiker 'B' keurt dagelijks 200 contracten goed, aangemaakt door gebruiker 'A'
• Een andere gebruiker 'C' betaalt ongeveer 150 contracten per dag, goedgekeurd door gebruiker 'B'

In deze situatie moet gebruiker B 200 contracten 'aangemaakt' hebben in het systeem. Bovendien heeft gebruiker C 150 contracten als “goedgekeurd” nodig om een ​​belasting van 150 gebruikers te simuleren.

Dit betekent impliciet dat u minimaal 200+150= 350 contracten moet aanmaken.

Keur daarna 150 contracten goed om te dienen als testgegevens voor gebruiker C. De overige 200 contracten zullen dienen als testgegevens voor gebruiker B.

Overzichtsmonitoren

Speculeer elke factor die mogelijk de prestaties van een systeem zou kunnen beïnvloeden. Het hebben van minder hardware zal bijvoorbeeld een potentiële impact hebben op de SUL-prestaties (System Under Load).

Breng alle factoren in kaart en stel monitoren in zodat u ze kunt meten. Hier zijn enkele voorbeelden:

• Processor (voor webserver, applicatieserver, databaseserver en injectoren)
• RAM (voor webserver, applicatieserver, databaseserver en injectoren)
• Web-/app-server (bijvoorbeeld IIS, JBoss, Jaguar Server, Tomcat enz.)
• DB Server (PGA- en SGA-grootte in het geval van Oracle en MSSQL Server, SP's etc.)
• Gebruik van netwerkbandbreedte
• Interne en externe NIC in geval van clustering
• Load Balancer (en dat de belasting gelijkmatig over alle knooppunten van clusters wordt verdeeld)
• Gegevensstroom (bereken hoeveel gegevens van en naar client en server worden verplaatst – bereken vervolgens of de capaciteit van de NIC voldoende is om een ​​X-aantal gebruikers te simuleren)

Stap 2) Maak VUGen-scripts

De volgende stap na het plannen is creëren VUser-scripts.

Stap 3) Scenariocreatie

De volgende stap is het maken van uw Belastingscenario

Stap 4) Scenario-uitvoering

Bij scenario-uitvoering emuleert u de gebruikersbelasting op de server door meerdere VUsers opdracht te geven om taken tegelijkertijd uit te voeren.

U kunt het niveau van een belasting instellen door het aantal VUsers dat tegelijkertijd taken uitvoert te verhogen of te verlagen.

Deze uitvoering kan ertoe leiden dat de server onder druk komt te staan ​​en zich abnormaal gaat gedragen. Dit is precies het doel van de prestatietests. De getrokken resultaten worden vervolgens gebruikt voor gedetailleerde analyse en identificatie van de hoofdoorzaak.

Stap 5) Resultatenanalyse (gevolgd door systeemaanpassingen)

Tijdens de uitvoering van het scenario registreert LoadRunner de prestaties van de applicatie onder verschillende belastingen. De statistieken die uit de uitvoering van de test zijn gehaald, worden opgeslagen en er wordt een gedetailleerde analyse uitgevoerd. De tool 'HP Analysis' genereert verschillende grafieken die helpen bij het identificeren van de grondoorzaken achter een vertraging van de systeemprestaties, evenals een systeemstoring.

Enkele van de verkregen grafieken zijn onder meer:

• Tijd tot de eerste buffer
• Transactieresponstijd
• Gemiddelde transactieresponstijd
• Hits per seconde
• Windows Middelen
• Foutenstatistieken
• Transactieoverzicht

FAQ