LoadRunner-testtool: ArchiStructuurdiagram en componenten

Wat is LoadRunner?

LoadRunner is een Performance Testing een instrument dat als eerste werd ontwikkeld door Mercury LoadRunner werd in 1999 gelanceerd en later overgenomen door HP in 2006. De softwaretak van HP fuseerde vervolgens met Micro Focus in een deal die in 2016 werd aangekondigd en in 2017 werd afgerond.

Merknotitie: OpenText De overname van Micro Focus werd in januari 2023 afgerond.Het gereedschap wordt niet langer verkocht onder de naam HP of Micro Focus LoadRunnerLoadRunner Professional is nu beschikbaar. OpenText Professionele prestatie-engineering, LoadRunner Enterprise is OpenText Enterprise Performance Engineering, en LoadRunner Cloud is OpenText Kernprestatie-engineering. De onderstaande componentnamen — VuGen, Controller, loadgeneratoren en Analyse — blijven ongewijzigd.

LoadRunner ondersteunt diverse ontwikkeltools, technologieën en communicatieprotocollen. Het beschikt over een van de meest uitgebreide protocolbibliotheken op de markt voor het uitvoeren van prestatietests. De resultaten van de prestatietests die LoadRunner produceert, worden gebruikt als benchmark ten opzichte van andere tools.

LoadRunner-video

Bekijk de onderstaande video voor een korte introductie tot LoadRunner voordat u de verschillende onderdelen doorneemt.

Waarom LoadRunner?

LoadRunner is niet alleen een baanbrekend hulpmiddel voor prestatietesten, het blijft ook een van de marktleiders in dit vakgebied en is nog steeds het referentiepunt waaraan veel bedrijven hun prestaties afmeten.

De protocoldekking is de duidelijkste reden waarom teams ervoor kiezen, zoals de onderstaande componentenkaart laat zien.

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 Socket. Weinig concurrerende tools bieden zo'n breed scala aan protocollen in één tool, zoals de onderstaande protocollijst illustreert.

Wat LoadRunner nog overtuigender maakt voor softwaretesten, is de geloofwaardigheid van deze tool. LoadRunner heeft een goede reputatie opgebouwd, en klanten controleren uw prestatiebenchmarks vaak met behulp van LoadRunner. Als u LoadRunner al gebruikt voor uw prestatietesten, zult u zich hier zeker prettig bij voelen.

De LoadRunner-software is nauw geïntegreerd met de verwante tools in dezelfde suite, waaronder Unified Functional Testing (de voormalige). QTP, nu verkocht als OpenText Functionele testen) en ALM (Application Lifecycle Management, nu OpenText ALM/Quality Center) — waarmee u uw volledige testprocessen kunt uitvoeren.

LoadRunner werkt volgens het principe van het simuleren van virtuele gebruikers op de betreffende applicatie. Deze virtuele gebruikers, ook wel VUsers genoemd, repliceren de verzoeken van de client en verwachten een overeenkomstige reactie om een ​​transactie te voltooien.

Waarom heeft u prestatietests nodig?

De onderstaande schattingen uit de branche worden veelvuldig aangehaald en dateren uit het begin van de jaren 2010, maar het patroon dat ze beschrijven is niet veranderd: trage pagina's kosten geld.

Door slechte webprestaties wordt jaarlijks een geschat omzetverlies van 4.4 miljard dollar geregistreerd.

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 moet wachten tijdens het zoeken naar iets. Google of het versturen van een vriendschapsverzoek op Facebook. De gevolgen van prestatieverlies zijn vaak veel ernstiger dan gedacht. Er zijn bekende voorbeelden, zoals de storingen die Bank of America Online Banking troffen. Amazon Webdiensten, Intuit en Blackberry.

Volgens Dun & Bradstreet heeft 59% van de Fortune 500-bedrijven naar schatting 1.6 uur downtime per week. Aangezien een gemiddeld Fortune 500-bedrijf met minimaal 10,000 werknemers $56 per uur betaalt, zouden de arbeidskosten van deze downtime voor een dergelijke organisatie $896,000 per week bedragen, wat neerkomt op meer dan $46 miljoen per jaar.

Slechts 5 minuten downtime. GoogleDe overname van .com in augustus 2013 zou de zoekgigant naar schatting maar liefst $545,000 hebben gekost.

Naar schatting hebben bedrijven in het verleden $1,100 aan omzet per seconde verloren. Amazon Storing in de webdiensten.

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 heeft tegelijkertijd toegang tot het systeem in vergelijking met het verleden.

Niet elke sollicitatie is echter een geschikte kandidaat. load Testen Het is gericht op client-server-systemen met meerdere gebruikers, dus een desktopapplicatie voor één gebruiker zoals de onderstaande is niet de moeite waard om op prestaties te testen.

Wat is LoadRunner Archistructuur?

In grote lijnen is de architectuur van LoadRunner complex, maar toch gemakkelijk te begrijpen. Het onderstaande architectuurdiagram van LoadRunner laat zien hoe de vier componenten met elkaar samenwerken.

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

In de praktijk zullen al die 5000 gebruikers niet allemaal op de homepage blijven, maar verspreid zijn over verschillende delen van de website. Hoe simuleren we dat verschil?

VuGen

VuGen of virtuele gebruiker Generator VuGen is een IDE (Integrated Development Environment) of een uitgebreide code-editor. VuGen wordt gebruikt om het gedrag van een systeem onder belasting (System Under Load, SUL) te simuleren. VuGen biedt een "opnamefunctie" waarmee de communicatie tussen client en server wordt vastgelegd in de vorm van een gecodeerd script – ook wel een script genoemd. VUser-script.

Gezien het bovenstaande voorbeeld kan VuGen opnames maken om de volgende bedrijfsprocessen te simuleren:

• Surfen op de productenpagina van Amazon.com
• Afrekenen
• Payment Processing
• Mijn accountpagina controleren

Zodra het script probleemloos wordt afgespeeld, moeten dynamische serverwaarden meestal worden vastgelegd met correlatie voordat het opgeschaald kan worden.

Controller

Zodra een VUser-script is afgerond, Controller is een van de belangrijkste LoadRunner-componenten die de belastingssimulatie aanstuurt 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.

Om een ​​analogie met ons voorbeeld te gebruiken: de controller voegt de volgende parameters toe aan het VuGen-script:

1. 3500 gebruikers bezoeken de productpagina van Amazon.com
2. Er zijn 750 gebruikers in de betaalmodus.
3. 500 gebruikers verwerken betalingen.
4. 250 gebruikers kunnen hun accountpagina bekijken, maar pas nadat 500 gebruikers de betaling hebben verwerkt.

Nog complexere scenario's zijn mogelijk:

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

Agentenmachine/lading Generators/Injectoren

De LoadRunner Controller is verantwoordelijk voor het simuleren van duizenden VUsers. Deze VUsers verbruiken hardwarebronnen zoals processor en geheugen, waardoor de machine die ze simuleert een limiet krijgt. Bovendien simuleert de Controller deze VUsers vanaf dezelfde machine (waar de Controller zich bevindt), waardoor de resultaten mogelijk niet nauwkeurig zijn. Om dit probleem op te lossen, worden alle VUsers verdeeld over verschillende machines, die Loads worden genoemd. 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.

Om de analogie van onze te gebruiken Amazon Bijvoorbeeld, de output van dit onderdeel is 5000 VUsers verdeeld over twee injectoren: 2500 VUsers gegenereerd op machine A en 2500 op machine B.

Analyse

Nadat de laadscenario's zijn uitgevoerd, is de rol van de Analyse Het LoadRunner-onderdeel komt in beeld.

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 de database met de naam output.mdb. De analysecomponent leest dit databasebestand om verschillende soorten analyses uit te voeren en grafieken te genereren.

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 een voorbeeld waarbij bandbreedte een knelpunt kan vormen. Stel dat de webserver een capaciteit van 1 Gbps heeft, maar het dataverkeer deze capaciteit overschrijdt, waardoor andere gebruikers hinder ondervinden. Om te bepalen of het systeem aan dergelijke behoeften voldoet, moet de performance engineer het gedrag van de applicatie bij een abnormale belasting analyseren. Hieronder ziet u een grafiek die LoadRunner genereert om de bandbreedte in kaart te brengen.

Hoe u prestatietests uitvoert

De roadmap voor prestatietesten kan grofweg worden onderverdeeld in 5 stappen, die hieronder worden samengevat:

1. Planning voor belastingstest
2. VuGen-scripts maken
3. Scenariocreatie
4. Scenario-uitvoering
5. Resultatenanalyse (gevolgd door systeemaanpassingen)

Nu LoadRunner is geïnstalleerd, zullen we de stappen in dit proces één voor één bekijken.

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

Bij de start van LoadRunner-testen is het raadzaam om vast te leggen wie van elk team dat bij het proces betrokken is, aan de activiteit deelneemt, zoals in het onderstaande teamschema wordt weergegeven.

• Project Manager: Nomineer de projectmanager die eigenaar wordt van deze activiteit en die zal fungeren als aanspreekpunt voor escalatie.
• Functie-expert / Bedrijfsanalist: Biedt gebruiksanalyses van de SUL en expertise over de zakelijke functionaliteit van de website of SUL.
• Expert op het gebied van prestatietests: Creëert geautomatiseerde prestatietests en voert belastingsscenario's uit.
• Systeem Architect: Biedt de blauwdruk voor de SUL.
• Webontwikkelaar en MKB: Onderhoudt de website, voert monitoringtaken uit, ontwikkelt de website en verhelpt bugs.
• Systeem administrator: Onderhoudt de betrokken servers gedurende een testproject.

Beschrijf de toepassingen en bedrijfsprocessen die hierbij betrokken zijn.

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 geven de cijfers het aantal gebruikers weer dat op een bepaald uur met de applicatie is verbonden (SUL). We kunnen bijvoorbeeldtract is het maximale aantal gebruikers dat op een willekeurig uur van de dag is verbonden met een bedrijfsproces, 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:

• Gebruiker 'A' maakt een financieel contract aantracen dient het ter beoordeling in.
• Een andere gebruiker 'B' keurt 200 con goed.tracts a day gemaakt door gebruiker 'A'
• Een andere gebruiker 'C' betaalt ongeveer 150 euro.tracts per dag goedgekeurd door gebruiker 'B'

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

Dit betekent impliciet dat je minimaal 200 + 150 = 350 contacten moet aanmaken.tracts.

Daarna keur je 150 con goed.tracts om te dienen als testgegevens voor gebruiker C – de resterende 200 contracts zal dienen als testdata voor gebruiker B.

Overzichtsmonitoren

Bedenk welke factoren mogelijk van invloed kunnen zijn op de prestaties van een systeem. Zo kan bijvoorbeeld minder hardware een negatieve invloed 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)
• Data flux (bereken hoeveel data er van en naar de client en server wordt verzonden – bereken vervolgens of de capaciteit van de netwerkkaart voldoende is om X aantal gebruikers te simuleren)

Stap 2) VuGen-scripts maken

De volgende stap na de planning is het maken van VUser-scripts, inclusief het toevoegen van... parameterisering, transacties en runtime-instellingen naarmate het script zich verder ontwikkelt.

Stap 3) Scenariocreatie

De volgende stap is het creëren van uw laadscenario in de controller, waarbij u kunt kiezen tussen een handmatig en een doelgericht scenario.

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 uitvalt. spanning en zich abnormaal gedragen. Dat is precies het doel van prestatietesten. De verkregen resultaten worden vervolgens gebruikt voor een gedetailleerde analyse en het vaststellen van de onderliggende oorzaak.

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 tijdens de testuitvoering worden verzameld, worden opgeslagen en gedetailleerd geanalyseerd. De analysetool (in de versies waarop deze handleiding is gebaseerd, bekend als 'HP Analysis') genereert diverse grafieken die helpen bij het identificeren van de oorzaken van prestatievertragingen en systeemstoringen.

Enkele van de verkregen grafieken zijn onder meer:

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

Veelgestelde vragen