Load Testing Complete Guide voor beginners

load testing complete guide

Een complete gids voor het testen van belastingen voor beginners:

In deze tutorial zullen we leren waarom we Load Testing uitvoeren, wat ermee wordt bereikt, Architectuur, wat de te volgen aanpak is om een ​​Load Test succesvol uit te voeren, hoe we een Load Test omgeving kunnen opzetten, best practices, samen met de beste Load Testing Tools die op de markt verkrijgbaar zijn.

We hebben gehoord van zowel functionele als niet-functionele tests. Bij niet-functionele tests hebben we verschillende soorten tests, zoals prestatietests, beveiligingstests, gebruikersinterfacetests enz.

Daarom is Load Testing een niet-functioneel type testen dat een subset is van Performance Testing.

Dus als we zeggen dat we een applicatie testen op prestaties, wat testen we dan allemaal hier? We testen de applicatie op belasting, volume, capaciteit, spanning etc.

Wat je leert:

• Wat is belastingtesten?
• Laadtestarchitectuur
• Waarom laden testen?
• Milieu
• Nadering
• Beste praktijken
• Gevolgtrekking
• Aanbevolen literatuur

Wat is belastingtesten?

Load Testing is een subset van Performance Testing, waarbij we de reactie van het systeem onder verschillende belastingsomstandigheden testen door te simuleren dat meerdere gebruikers gelijktijdig toegang hebben tot de applicatie. Deze test meet meestal de snelheid en capaciteit van de applicatie.

Dus wanneer we de belasting wijzigen, volgen we het gedrag van het systeem onder verschillende omstandigheden.

Voorbeeld ​Laten we aannemen dat onze klantvereiste voor een inlogpagina 2-5 seconden is en deze 2-5 seconden moet consistent zijn totdat de belasting 5000 gebruikers is. Dus wat moeten we observeren horen? Is het alleen de laadcapaciteit van het systeem of is het alleen de vereiste reactietijd?

Het antwoord is beide. We willen het systeem dat een belasting van 5000 gebruikers aankan met een responstijd van 2-5 seconden voor alle gelijktijdige gebruikers.

Dus wat wordt bedoeld met een gelijktijdige gebruiker en een virtuele gebruiker?

Gelijktijdige gebruikers zijn gebruikers die inloggen op de applicatie en tegelijkertijd een reeks activiteiten uitvoeren en tegelijkertijd de applicatie afmelden. Aan de andere kant springen virtuele gebruikers gewoon in en uit het systeem, ongeacht de andere gebruikersactiviteiten.

Laadtestarchitectuur

In het onderstaande diagram kunnen we zien hoe verschillende gebruikers toegang hebben tot de applicatie. Hier doet elke gebruiker een verzoek via internet, dat later door een firewall wordt geleid.

Na de firewall hebben we een Load-balancer die de belasting naar een van de webservers verdeelt en vervolgens naar de applicatieserver en later naar de databaseserver gaat, waar het de nodige informatie ophaalt op basis van het gebruikersverzoek.

Het testen van de belasting kan zowel handmatig als met behulp van een tool worden uitgevoerd. Maar handmatige belastingstests worden niet aanbevolen, omdat we de applicatie niet testen voor een lagere belasting.

Voorbeeld: Laten we aannemen dat we een online winkelapplicatie willen testen om de responstijd van de applicatie voor elke klik van een gebruiker te zien, dwz Stap1 - Start-URL, de responstijd, Login op de applicatie en noteer de responstijd, enzovoort, zoals het selecteren van een product, toevoegen aan de winkelwagen, betalen en uitloggen. Dit alles moet worden gedaan voor 10 gebruikers.

Dus als we nu de applicatiebelasting voor 10 gebruikers moeten testen, kunnen we dit bereiken door handmatig 10 fysieke gebruikers van verschillende machines te laden in plaats van een tool te gebruiken. In dit scenario is het raadzaam om voor een handmatige belastingtest te gaan in plaats van te investeren in een tool en het opzetten van een omgeving voor de tool.

Stel je voor dat als we een laadtest voor 1500 gebruikers moeten laden, we de laadtest moeten automatiseren met behulp van een van de beschikbare tools op basis van de technologieën waarin de applicatie is gebouwd en ook op basis van het budget dat we voor het project hebben.

Als we een budget hebben, kunnen we kiezen voor commerciële tools zoals Load Runner, maar als we niet veel budget hebben, kunnen we gaan voor open source-tools zoals JMeter, enz.

hoe je een volledige afspeellijst van youtube kunt downloaden zonder software

Of het nu een commerciële tool is of een open source tool, de details moeten gedeeld worden met de klant voordat we de tool finaliseren. Gewoonlijk wordt een proof of concept voorbereid, waarbij we een voorbeeldscript genereren met behulp van de tool en de voorbeeldrapporten aan de klant laten zien voor goedkeuring van de tool voordat deze wordt afgerond.

Bij geautomatiseerde loadtests vervangen we de gebruikers met behulp van een automatiseringstool, die de real-time gebruikersacties nabootst. Door het laden te automatiseren, kunnen we zowel middelen als tijd besparen.

Hieronder ziet u het diagram dat laat zien hoe de gebruikers worden vervangen met behulp van een tool.

Waarom laden testen?

Laten we aannemen dat er een online winkelwebsite is die het redelijk goed doet tijdens normale werkdagen, dwz gebruikers kunnen inloggen op de applicatie, door de verschillende productcategorieën bladeren, producten selecteren, items toevoegen aan de winkelwagen, uitchecken en uitloggen binnen een acceptabel bereik en er zijn geen paginafouten of enorme reactietijden.

Ondertussen komt er een piekdag, laten we zeggen de Thanks Giving-dag en er zijn duizenden gebruikers die zijn aangemeld bij het systeem, het systeem crasht plotseling en de gebruikers reageren erg traag, sommigen kunnen niet eens log in op de site, een paar konden niet aan de winkelwagen worden toegevoegd en sommige konden niet uitchecken.

Daarom moest het bedrijf op deze grote dag een enorm verlies lijden, omdat het veel klanten en ook veel zaken verloor. Dit alles gebeurde alleen omdat ze de gebruikersbelasting voor piekdagen niet hadden voorspeld, zelfs als ze hadden voorspeld dat er geen belastingtest was uitgevoerd op de bedrijfswebsite, daarom weten ze niet hoeveel belasting de applicatie aankan op de piekdagen.

Om dergelijke situaties het hoofd te bieden en om enorme inkomsten te overwinnen, is het raadzaam om een ​​belastingtest uit te voeren voor dit soort toepassingen.

• Load Testing helpt om sterke en betrouwbare systemen te bouwen.
• De bottleneck in het systeem wordt ruim van tevoren geïdentificeerd voordat de applicatie live gaat.
• Het helpt bij het identificeren van de capaciteit van de applicatie.

Wat wordt er bereikt tijdens een belastingtest?

Met een goede belastingtest kunnen we het volgende precies begrijpen:

1. Het aantal gebruikers dat het systeem aankan of kan opschalen.
2. De reactietijd van elke transactie.
3. Hoe gedraagt ​​elk onderdeel van het hele systeem zich onder Load, d.w.z. toepassingsservercomponenten, webservercomponenten, databasecomponenten enz.
4. Welke serverconfiguratie is het beste om de belasting te verwerken?
5. Of de bestaande hardware voldoende is of is er behoefte aan extra hardware.
6. Knelpunten zoals CPU-gebruik, geheugengebruik, netwerkvertragingen, enz. Worden geïdentificeerd.

Milieu

We hebben een speciale Load Testing-omgeving nodig om onze tests uit te voeren. Omdat de Load-testomgeving meestal hetzelfde is als de productieomgeving en ook de gegevens die beschikbaar zijn in de load-testomgeving zullen hetzelfde zijn als de productie, hoewel het niet dezelfde gegevens zijn.

Er zullen meerdere testomgevingen zijn, zoals een SIT-omgeving, QA-omgeving, enz. Deze omgevingen zijn niet dezelfde productie, omdat ze, in tegenstelling tot load-tests, niet zoveel servers of zo veel testgegevens nodig hebben om functionele tests of integratietests uit te voeren.

Voorbeeld:

In een productieomgeving hebben we 3 applicatieservers, 2 webservers en 2 databaseservers. In QA hebben we slechts 1 toepassingsserver, 1 webserver en 1 databaseserver. Als we dus een belastingtest uitvoeren op de QA-omgeving die niet gelijk is aan de productie, dan zijn onze tests niet geldig en ook onjuist en kunnen we daardoor niet aan deze resultaten voldoen.

Probeer dus altijd een speciale omgeving te hebben voor belastingtests die vergelijkbaar is met die van een productieomgeving.

Soms hebben we ook applicaties van derden die ons systeem zal aanroepen, en daarom kunnen we in dergelijke gevallen stubs gebruiken omdat we niet altijd kunnen samenwerken met de externe leveranciers voor het vernieuwen van gegevens of andere problemen of ondersteuning.

Probeer een momentopname van de omgeving te maken zodra deze gereed is, zodat u deze momentopname kunt gebruiken wanneer u de omgeving opnieuw wilt opbouwen, wat zou helpen bij het tijdbeheer. Er zijn enkele tools die op de markt beschikbaar zijn om de omgeving in te stellen, zoals Puppet, Docker etc.

Nadering

Voordat we met de Load-test beginnen, moeten we weten of er al een Load-test op het systeem is uitgevoerd of niet. Als er eerder een belastingtest is uitgevoerd, moeten we weten wat de responstijd was, de verzamelde client- en serverstatistieken, hoeveel de laadcapaciteit van de gebruiker was, enz.

We hebben ook informatie nodig over hoeveel de huidige afhandelingscapaciteit van applicaties is. Als het een nieuwe applicatie is, moeten we de vereisten begrijpen, wat is de beoogde belasting, wat is de verwachte reactietijd en of het echt haalbaar is of niet.

Als het een bestaande applicatie is, kunt u de laadvereisten en de gebruikerstoegangspatronen uit de serverlogboeken halen. Maar als het een nieuwe applicatie is, moet u contact opnemen met het zakelijke team voor alle informatie.

Zodra we de vereisten hebben, moeten we bepalen hoe we de belastingtest gaan uitvoeren. Gebeurt het handmatig of met behulp van tools? Het handmatig uitvoeren van een belastingtest vereist veel middelen en is ook erg duur. Ook het herhalen van de test, keer op keer, zal ook moeilijk zijn.

Om dit te verhelpen, kunnen we dus ofwel open source-tools of commerciële tools gebruiken. Open source-tools zijn gratis beschikbaar, deze tools hebben misschien niet alle functies zoals de andere commerciële tools, maar als het project een budgetbeperking heeft, kunnen we kiezen voor open source-tools.

Waar commerciële tools veel features hebben, ondersteunen ze veel protocollen en zijn ze erg gebruiksvriendelijk.

Onze Load Test-aanpak zal als volgt zijn:

# 1) Identificeer de acceptatiecriteria voor de belastingstest

Bijvoorbeeld​

1. De reactietijd van de inlogpagina mag niet langer zijn dan 5 seconden, zelfs niet tijdens de maximale belasting.
2. Het CPU-gebruik mag niet meer dan 80% bedragen.
3. De doorvoersnelheid van het systeem moet 100 transacties per seconde zijn.

# 2) Identificeer de bedrijfsscenario's die moeten worden getest.

Test niet alle stromen, maar probeer de belangrijkste bedrijfsstromen te begrijpen die naar verwachting in de productie zullen plaatsvinden. Als het een bestaande applicatie is, kunnen we zijn informatie uit de serverlogboeken van de productieomgeving halen.

Als het een nieuw gebouwde applicatie is, dan moeten we samenwerken met de business teams om inzicht te krijgen in de stroompatronen, applicatiegebruik etc. Soms zal het projectteam workshops houden om een ​​overzicht of details te geven over elk onderdeel van de applicatie.

We moeten de toepassingsworkshop bijwonen en alle vereiste informatie noteren om onze belastingtest uit te voeren.

# 3) Modellering van werkbelasting

Zodra we de details hebben over de bedrijfsstromen, gebruikerstoegangspatronen en het aantal gebruikers, moeten we de werklast zo ontwerpen dat deze de daadwerkelijke gebruikersnavigatie in productie nabootst of zoals verwacht in de toekomst zodra de applicatie zal in productie zijn.

De belangrijkste punten om te onthouden bij het ontwerpen van een werklastmodel is om te zien hoeveel tijd het kost om een ​​bepaalde bedrijfsstroom te voltooien. Hier moeten we de denktijd zo toewijzen dat de gebruiker op een meer realistische manier door de applicatie navigeert.

Het werkbelastingspatroon zal gewoonlijk zijn met een stijging, daling en een stabiele toestand. We moeten het systeem langzaam laden en dus worden ramp-up en ramp-down gebruikt. De stabiele toestand is meestal een laadtest van een uur met een aanlooptijd van 15 minuten en een uitval van 15 minuten.

Laten we een voorbeeld nemen van het werkbelastingmodel:

Overzicht van de applicatie - Laten we aannemen dat gebruikers online winkelen, waarbij de gebruikers inloggen op de applicatie en een grote verscheidenheid aan jurken kunnen kopen, en ze door elk product kunnen navigeren.

Om de details van elk product te bekijken, moeten ze op het product klikken. Als ze de prijs en het merk van het product waarderen, kunnen ze het product aan de winkelwagen toevoegen en het product kopen door af te rekenen en de betaling uit te voeren.

Hieronder vindt u een lijst met scenario's:

1. Bladeren - Hier start de gebruiker de applicatie, logt in op de applicatie, bladert door verschillende categorieën en logt uit bij de applicatie.
2. Bladeren, Productweergave, Toevoegen aan winkelwagen - Hier logt de gebruiker in op de applicatie, bladert door verschillende categorieën, bekijkt productdetails, voegt het product toe aan het winkelwagentje en logt uit.
3. Bladeren, productweergave, toevoegen aan winkelwagen en uitchecken - In dit scenario logt de gebruiker in op de applicatie, bladert door verschillende categorieën, bekijkt productdetails, voegt het product toe aan de winkelwagen, checkt uit en logt uit.
4. Bladeren, Productweergave, Toevoegen aan winkelwagentje Afrekenen en Betalen - Hier logt de gebruiker in op de applicatie, bladert door verschillende categorieën, bekijkt productdetails, voegt het product toe aan de winkelwagen, checkt af, voert betalingen uit en logt uit.

De bovenstaande waarden zijn afgeleid op basis van de volgende berekeningen:

• Transacties per uur = Aantal gebruikers * Transacties uitgevoerd door één gebruiker in één uur.
• Het aantal gebruikers = 1600.
• Het totale aantal transacties in het Browse-scenario = 17.
• Reactietijd voor elke transactie = 3.
• Totale tijd voor een enkele gebruiker om 17 transacties te voltooien = 17 * 3 = 51 afgerond op 60 sec (1 min).
• Transacties per uur = 1600 * 60 = 96000 transacties.

# 4) Ontwerp de belastingtests​ De belastingtest moet worden ontworpen met de gegevens die we tot nu toe hebben verzameld, d.w.z. de bedrijfsstromen, het aantal gebruikers, gebruikerspatronen, te verzamelen en analyseren statistieken. Bovendien moeten de tests op een veel realistische manier worden ontworpen.

# 5) Voer een laadtest uit - Voordat we de Load-test uitvoeren, moet u ervoor zorgen dat de applicatie actief is. De Load-testomgeving is klaar. De applicatie is functioneel getest en is stabiel.

Controleer de configuratie-instellingen van de Load-testomgeving. Het moet hetzelfde zijn als de productieomgeving. Zorg ervoor dat alle testgegevens beschikbaar zijn. Zorg ervoor dat u de nodige tellers toevoegt om de systeemprestaties tijdens de testuitvoering te bewaken.

Begin altijd met een lage belasting en verhoog de belasting geleidelijk. Begin nooit met volle belasting en breek het systeem.

# 6) Analyseer de testresultaten van de belasting - Zorg voor een basislijntest om altijd te vergelijken met de andere testruns. Verzamel de metrische gegevens en serverlogboeken na de testrun om de bottlenecks te vinden.

Sommige projecten gebruiken Application Performance Monitoring Tools om het systeem tijdens het testen te monitoren. Deze APM-tools helpen om de hoofdoorzaak gemakkelijker te identificeren en besparen veel tijd. Met deze tools is het heel gemakkelijk om de hoofdoorzaak van het knelpunt te achterhalen, aangezien ze een breed overzicht hebben om aan te geven waar het probleem zit.

Enkele van de APM-tools op de markt zijn DynaTrace, Wily Introscope, App Dynamics etc.

# 7) Rapportage - Zodra de testrun is voltooid, verzamelt u alle statistieken en stuurt u het testoverzichtrapport naar het betrokken team met uw observaties en aanbevelingen.

Beste praktijken

Hieronder vindt u enkele van de best practices van Load Testing:

# 1) Controleer altijd de stabiliteit van de applicatie voordat u een belastingtest start. De applicatie moet functioneel stabiel worden ondertekend door het functionele testteam en alle belangrijke defecten moeten worden verholpen en getest voordat de build wordt gekopieerd naar de Load Test-omgeving.

#twee) Zorg ervoor dat de Load-testomgeving een replica is of zich dicht bij de productieomgeving bevindt, inclusief het aantal servers, load balancers, serverconfiguraties en firewalls.

# 3) Controleer of de testgegevens uniek zijn en we hebben alle testgegevens gekopieerd naar de laadomgeving voordat we een laadtest uitvoeren.

# 4) Ontwerp de testscenario's zodanig dat ze de real-time gebruikersactie in de productie nabootsen.

# 5) Ontwerp de werklast op basis van de productiegebruikersbelastingen en bedrijfsstromen en kijk in het geval van een oude applicatie of het een nieuw gesprek is met het bedrijfsteam over de bedrijfsstromen en de gebruikersbelasting.

# 6) Verzamel alle belangrijke statistieken, zoals reactietijd, hits per seconde, doorvoer, CPU, geheugen, netwerk en actieve gebruikers.

Aanbevolen lezen => Lijst met prestatietesttools die op de markt beschikbaar zijn voor het uitvoeren van exclusieve belastingtests.

Gevolgtrekking

In deze tutorial hebben we geleerd hoe belastingtesten een belangrijke rol spelen bij het testen van prestaties van een applicatie, hoe het helpt om de efficiëntie en mogelijkheden van de applicatie te begrijpen, enz.

We kwamen ook te weten hoe het helpt om te voorspellen of er aanvullende hardware, software of afstemming nodig is voor een applicatie.

Veel leesplezier !!

Aanbevolen literatuur

• Laadtests met HP LoadRunner-zelfstudies
• Alfatesten en bètatesten (een complete gids)
• Handleiding voor het testen van webapplicaties
• Gids voor stresstests voor beginners
• Beginnershandleiding voor penetratietesten van webapplicaties
• Een complete handleiding voor niet-functionele tests voor beginners
• Build Verification Testing (BVT Testing) Complete Guide
• Prestatietests versus belastingtests versus stresstests (verschil)