LoadRunner-testtool – Componenten en Architectuur

Wat is LoadRunner?

LoadRunner is een prestatietesttool die in 1999 door Mercury werd ontwikkeld. LoadRunner was dat wel later overgenomen door HPE in 2006. 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.

LoadRunner

In grote lijnen ondersteunt de LoadRunner-tool RIA (Rich Internet Applications), Web 2.0 (HTTP/HTML, Ajax, Flex en Silverlight etc.), Mobile, 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.

LoadRunner

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 billion in omzet wordt jaarlijks geregistreerd vanwege 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 als je searching voor Google of doe een vriendschapsverzoek op Facebook. De gevolgen van prestatieuitval zijn vaak verwoestender dan ooit tevoren. We hebben voorbeelden zoals die onlangs bij Bank of America Online Banking zijn verschenen, Amazon Webservices, Intuit of Blackberry.

Volgens Dunn & Bradstreet heeft 59% van de Fortune 500-bedrijven te maken met een geschatte 1.6 hours van downtime per week. Als je bedenkt dat het gemiddelde Fortune 500-bedrijf met minimaal 10,000 werknemers $56 per uur betaalt, zou het arbeidsdeel van de downtimekosten voor een dergelijke organisatie $896,000 per week bedragen, wat zich vertaalt in 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 wordt geïmplementeerdyed Een organisatie kan met veel scenario's te maken krijgen die mogelijk tot prestatielatentie leiden. Een aantal factoren veroorzaken vertragende prestaties. Enkele voorbeelden kunnen zijn:

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

Wat is LoadRunner Archistructuur?

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

LoadRunner Architectuur
LoadRunner Archistructuurdiagram

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.

Dus gezien het bovenstaande voorbeeld kan VUGen opnemen om follo te simulerenwing Business processen:

  1. Surfen op de productenpagina van Amazon.com
  2. Afrekenen
  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 VGebruikers (ramp up, ramp naar beneden, gelijktijdigneoons of gelijktijdige natuur enz.)
  • 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, wordt het volgende toegevoegdwing parameter aan het VUGen-script

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

2) 750 gebruikers zijn binnen Afrekenen

3) 500 gebruikers zijn het uitvoeren van betalingsverwerking

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

Nog meer complex scenario's zijn 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.

Analyse

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.

Performance Testing

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

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:

Geef een overzicht van de betrokken applicaties en bedrijfsprocessen

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 het de belasting gelijkmatig verdeelt over alle knooppunten van clusters)
  • 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 het uitvoeren van scenario's emuleert u de gebruikersbelasting op de server door meerdere VU's te instrueren om tegelijkertijd taken uit te voerenneonormaal.

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 uit de testuitvoering worden opgeslagen en details analyse wordt uitgevoerd. De tool ‘HP Analysis’ genereert verschillende grafieken die helpen bij het identificeren van de hoofdoorzaken achter een vertraging in de systeemprestaties, evenals een systeemfout.

Enkele van de verkregen grafieken zijn onder meer:

  • Tijd voor de eerste buffer
  • Transactieresponstijd
  • Gemiddelde transactieresponstijd
  • Hits per seconde
  • Windows Bronnen
  • Foutenstatistieken
  • Transactieoverzicht

FAQ

Prestatietests worden altijd alleen uitgevoerd voor client-server-gebaseerde systemen. Dit betekent elke applicatie die niet op een client-server is gebaseerd architectie, mogen geen prestatietests vereisen.

Bijvoorbeeld Microsoft Calculator is niet client-servergebaseerd en draait ook niet op meerdere gebruikers; daarom is het geen kandidaat voor prestatietests.

Performance Testing

Het is van belang om het verschil tussen prestatietests en prestatie-engineering te begrijpen. Hieronder wordt een inzicht gedeeld:

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

Prestatie-engineering is het proces waarbij software wordt getest en afgestemd met de bedoeling de vereiste prestaties te realiseren. Dit proces is gericht op het optimaliseren van de belangrijkste prestatiekenmerken van applicaties, namelijk de gebruikerservaring.

Historisch gezien waren testen en afstemmen duidelijk gescheiden en vaak concurrerende domeinen. De afgelopen jaren hebben verschillende testers en ontwikkelaars echter onafhankelijk samengewerkt om tuningteams te creëren. Omdat deze teams aanzienlijk succes hebben geboekt, heeft het concept van het koppelen van prestatietests aan prestatietuning aangeslagen, en nu noemen we het prestatie-engineering.