Wat is de HP LoadRunner-testtool? Architectuur, componenten

Wat is LoadRunner?

LoadRunner is een prestatietesttool die in 1999 door Mercury werd ontwikkeld. 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 de enige tool op de markt die zo'n groot aantal protocollen ondersteunt om prestatietests uit te voeren. Prestatietestresultaten geproduceerd door LoadRunner-software worden gebruikt als maatstaf voor andere tools

In deze tutorial leer je-

• Waarom LoadRunner?
• Waarom heb je prestatietests nodig?
• Wat is LoadRunner-architectuur?
• Routekaart voor prestatietests: gedetailleerde stappen
• FAQ

Waarom LoadRunner?

LoadRunner is niet alleen een pionierstool in Performance Testing, maar het is nog steeds een marktleider in het Performance Testing-paradigma. In een recente beoordeling heeft LoadRunner een marktaandeel van ongeveer 85% in de Performance Testing-industrie.

In grote lijnen ondersteunt de LoadRunner-tool RIA (Rich Internet Applications), Web 2.0 (HTTP / HTML, Ajax, Flex en Silverlight etc.), Mobile, SAP, Oracle, MS SQL Server, Citrix, RTE, Mail en vooral Windows Socket. Er is geen tool van een concurrent op de markt die zo'n grote verscheidenheid aan protocollen kan bieden die in één enkele tool 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, omdat u vaak zult merken dat klanten uw prestatiebenchmarks kruisen met LoadRunner. U zult verlichting vinden als u LoadRunner al gebruikt voor uw prestatietests.

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

LoadRunner werkt op basis van het simuleren van virtuele gebruikers op de betreffende 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 heb je prestatietests nodig?

Een geschat verlies van 4,4 miljard aan inkomsten wordt jaarlijks geregistreerd als gevolg van slechte webprestaties.

In het huidige Web 2.0-tijdperk klikken gebruikers weg als een website niet binnen 8 seconden reageert. Stel je voor dat je 5 seconden wacht wanneer je naar Google zoekt of een vriendschapsverzoek doet op Facebook. De gevolgen van uitval van prestaties zijn vaak verwoestender dan ooit gedacht. We hebben voorbeelden zoals die onlangs Bank of America Online Banking, Amazon Web Services, Intuit of Blackberry troffen.

Volgens Dunn & Bradstreet ervaart 59% van de Fortune 500-bedrijven wekelijks naar schatting 1,6 uur downtime. Als je bedenkt dat het gemiddelde Fortune 500-bedrijf met minimaal 10.000 werknemers $ 56 per uur betaalt, zou het arbeidsdeel van de downtime-kosten voor zo'n organisatie $ 896.000 per week bedragen, wat zich vertaalt in meer dan $ 46 miljoen per jaar.

Slechts 5 minuten downtime van Google.com (19 aug. 13) kost de zoekgigant naar schatting maar liefst $ 545.000.

Er wordt geschat dat bedrijven een omzet van $ 1100 per seconde hebben verloren als gevolg van een recente Amazon Web Service-storing.

Wanneer een softwaresysteem door een organisatie wordt geïmplementeerd, kan het veel scenario's tegenkomen die mogelijk resulteren in latentie van de prestaties. Een aantal factoren leidt tot afnemende prestaties, enkele voorbeelden kunnen zijn:

• Verhoogd aantal records aanwezig in de database
• Verhoogd aantal gelijktijdige verzoeken aan het systeem
• een groter aantal gebruikers dat tegelijkertijd toegang heeft tot het systeem in vergelijking met het verleden

Wat is LoadRunner-architectuur?

In grote lijnen is de architectuur van HP LoadRunner complex, maar toch gemakkelijk te begrijpen.

Stel dat u wordt toegewezen om de prestaties van Amazon.com voor 5000 gebruikers te controleren

In de praktijk bevinden al deze 5000 gebruikers zich niet op de homepage, maar in een ander gedeelte van de websites. Hoe kunnen we anders simuleren

VUGen:

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

Gezien het bovenstaande voorbeeld kan VUGen dus opnemen om de volgende bedrijfsprocessen te simuleren:

1. Surfen op de productenpagina van Amazon.com
2. Uitchecken
3. Verwerking van betalingen
4. Controleer de MyAccount-pagina

Controller

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

• Hoeveel VUsers simuleren tegen elk bedrijfsproces of VUser Group
• Gedrag van VUsers (ramp up, ramp down, gelijktijdige of gelijktijdige aard etc.)
• Aard van het belastingsscenario, bijv. Real-life of doelgericht of verifiërende SLA
• Welke injectoren te gebruiken, hoeveel VUsers tegen elke injector
• Verzamel de resultaten regelmatig
• IP-spoofing
• Foutmelding
• Transactierapportage etc.

Als we een analogie nemen van onze voorbeeldcontroller, wordt de volgende parameter aan het VUGen-script toegevoegd

1) 3500 gebruikers surfen op de productenpagina van Amazon.com

2) 750 gebruikers zijn aan het afrekenen

3) 500 gebruikers voeren betalingsverwerking uit

4) 250 gebruikers controleren de MyAccount-pagina ALLEEN nadat 500 gebruikers de betalingsverwerking hebben voltooid

Nog complexere scenario's zijn mogelijk

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

Agents Machine / Load Generatoren / Injectoren

HP LoadRunner Controller is verantwoordelijk voor het simuleren van duizenden VUsers - deze VUsers verbruiken hardwarebronnen, bijvoorbeeld processor en geheugen - en legt dus een limiet op de machine die ze simuleert. Bovendien simuleert Controller deze VUsers vanaf dezelfde machine (waar Controller zich bevindt) en daarom zijn de resultaten mogelijk niet precies. Om deze zorg weg te nemen, zijn alle VUsers verspreid over verschillende machines, genaamd Load Generators of Load Injectors.

Als algemene praktijk 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, kan een aantal Load Injectors vereist zijn voor volledige simulatie. VUsers voor een HTTP-script hebben bijvoorbeeld 2-4 MB per VUser nodig voor simulatie, dus zijn er 4 machines met elk 4 GB RAM nodig om een ​​belasting van 10.000 VUsers te simuleren.

Door analoog uit ons Amazon-voorbeeld te nemen, zal de output van deze component zijn

Analyse:

Zodra Load-scenario's zijn uitgevoerd, komt de rol van " Analyse " -componenten van LoadRunner om de hoek kijken.

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 waren configuraties.

Alle fouten en uitzonderingen worden vastgelegd in een Microsoft Access-database met de naam output.mdb. De component "Analyse" leest dit databasebestand om verschillende soorten analyses uit te voeren en genereert grafieken.

Deze grafieken laten verschillende trends zien om de redenering achter fouten en uitval onder belasting te begrijpen; help zo om erachter te komen of optimalisatie nodig is in SUL, Server (bijv. JBoss, Oracle) of infrastructuur.

Hieronder ziet u een voorbeeld waarbij bandbreedte een knelpunt zou kunnen zijn. Laten we zeggen dat de webserver een capaciteit van 1GBps 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 gedrag van applicaties met een abnormale belasting analyseren. Hieronder ziet u een grafiek die LoadRunner genereert om bandbreedte op te wekken.

Routekaart voor prestatietests: gedetailleerde stappen

Performance Testing Roadmap kan grofweg worden onderverdeeld in 5 stappen:

• Planning voor belastingtest
• Maak VUGen-scripts
• Scenario-creatie
• 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 die betrokken zijn bij het prestatietestproces

Planning voor de belastingtest

Planning voor prestatietests is iets anders dan het plannen van een SIT (System Integration Testing) of UAT (User Acceptance Testing). De planning kan verder worden onderverdeeld in kleine fasen, zoals hieronder wordt beschreven:

Stel uw team samen

Wanneer u aan de slag gaat met LoadRunner Testing, is het het beste om te documenteren van elk team dat tijdens het proces aan de activiteit zal deelnemen.

Projectleider:

Benoem de projectmanager die eigenaar zal zijn van deze activiteit en die dient als aanspreekpunt voor escalatie.

Functie Expert / Business Analist:

Zorg voor gebruiksanalyse van SUL en biedt expertise op het gebied van zakelijke functionaliteit van website / SUL

Expert op het gebied van prestatietests:

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

Systeemarchitect:

Biedt blauwdruk van de SUL

Webontwikkelaar en MKB:

• Onderhoudt website en zorgt voor monitoringaspecten
• Ontwikkelt website en lost bugs op

Systeem administrator:

• Onderhoudt betrokken servers tijdens een testproject

Geef een overzicht van de betrokken applicaties en bedrijfsprocessen:

Succesvolle belastingtests vereisen dat u van plan bent om een ​​bepaald bedrijfsproces uit te voeren. Een bedrijfsproces bestaat uit duidelijk gedefinieerde stappen in overeenstemming met de gewenste zakelijke transacties - om uw doelstellingen voor het testen van de belasting te bereiken.

Er kan een metriek voor vereisten worden opgesteld om gebruikersbelasting op het systeem uit te lokken. 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 op de applicatie (SUL) is aangesloten. We kunnen het maximale aantal gebruikers dat is verbonden met een bedrijfsproces op elk uur van de dag extraheren, dat wordt berekend in de meest rechtse kolommen.

Evenzo kunnen we op elk uur van de dag het totale aantal gebruikers concluderen dat op de applicatie (SUL) is aangesloten. Dit wordt berekend in de laatste rij.

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 afkomstig van prestatietests worden sterk beïnvloed door tal van 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 het onderstaande voorbeeld:

• Een gebruiker 'A' maakt een financieel contract en dient dit ter beoordeling in.
• Een andere gebruiker 'B' keurt 200 contracten per dag goed die zijn gemaakt 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 hebben 'aangemaakt' in het systeem. Bovendien heeft gebruiker C 150 contracten nodig als "goedgekeurd" 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 als testgegevens voor gebruiker C te dienen - de resterende 200 contracten zullen dienen als testgegevens voor gebruiker B.

Overzicht monitoren

Speculeer elke factor die de prestaties van een systeem zou kunnen beïnvloeden. Als u bijvoorbeeld minder hardware heeft, kan dit een mogelijke invloed hebben op de SUL-prestaties (System Under Load).

Maak gebruik van alle factoren en stel monitoren in zodat u ze kunt meten. Hier zijn enkele voorbeelden:

• Processor (voor webserver, toepassingsserver, databaseserver en injectoren)
• RAM (voor webserver, toepassingsserver, databaseserver en injectoren)
• Web / App Server (bijvoorbeeld IIS, JBoss, Jaguar Server, Tomcat etc)
• 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 het de belasting gelijkmatig verdeelt over alle knooppunten van clusters)
• Dataflux (bereken hoeveel data van en naar client en server wordt verplaatst - bereken vervolgens of een capaciteit van NIC voldoende is om een ​​X-aantal gebruikers te simuleren)

Maak VUGen-scripts

De volgende stap na het plannen is het maken van VUser-scripts.

Scenario-creatie

De volgende stap is het maken van uw laadscenario

Scenario-uitvoering

Scenario-uitvoering is waar u de gebruikersbelasting op de server emuleert door meerdere VU's te instrueren om taken tegelijkertijd uit te voeren.

U kunt het niveau van een belasting instellen door het aantal VU's dat tegelijkertijd taken uitvoert, te verhogen en te verlagen.

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

Resultatenanalyse (gevolgd door systeemaanpassingen)

Tijdens het uitvoeren van een scenario registreert LoadRunner de prestaties van de applicatie onder verschillende belastingen. De statistieken van de testuitvoering worden opgeslagen en er wordt een detailanalyse uitgevoerd. De 'HP-analyse'-tool genereert verschillende grafieken die helpen bij het identificeren van de hoofdoorzaken achter een vertraging van de systeemprestaties, evenals een systeemstoring.

Enkele van de verkregen grafieken zijn onder meer:

• Tijd tot de eerste buffer
• Reactietijd transactie
• Gemiddelde transactiereactietijd
• Hits per seconde
• Windows-bronnen
• Fouten Statistieken
• Transactieoverzicht

FAQ

Welke applicaties moeten we prestatietesten?

Prestatietests worden altijd alleen uitgevoerd voor client-server-gebaseerde systemen. Dit betekent dat elke toepassing die geen client-servergebaseerde architectuur is, geen prestatietests nodig heeft.

Microsoft Calculator is bijvoorbeeld niet client-server-gebaseerd en heeft ook geen toegang tot meerdere gebruikers; daarom is het geen kandidaat voor prestatietests.

Wat is het verschil tussen Performance Testing & Performance Engineering

Het is belangrijk om het verschil te begrijpen tussen Performance Testing en Performance Engineering. Een begrip wordt hieronder gedeeld:

Performance Testing is een discipline die zich bezighoudt met het testen en rapporteren van de huidige prestaties van een softwareapplicatie onder verschillende parameters.

Performance engineering is het proces waarmee software wordt getest en afgestemd met de bedoeling de vereiste prestaties te realiseren. Dit proces is bedoeld om de belangrijkste eigenschap van de applicatieprestaties, namelijk de gebruikerservaring, te optimaliseren.

Historisch gezien waren testen en afstemmen duidelijk gescheiden en vaak concurrerende domeinen. In de afgelopen jaren hebben verschillende groepen testers en ontwikkelaars echter onafhankelijk samengewerkt om afstemmingsteams te creëren. Omdat deze teams aanzienlijk succes hebben geboekt, is het concept van het koppelen van prestatietests met prestatieafstemming aangeslagen, en nu noemen we het prestatie-engineering.