Wat is belastingtesten? (Voorbeelden)
⚡ Slimme samenvatting
Belastingstesten meten hoe een softwareapplicatie zich gedraagt wanneer veel gebruikers er tegelijkertijd toegang toe hebben, tot de verwachte piekbelasting. Het identificeert de maximale operationele capaciteit, de knelpunten die deze beperken en of de huidige infrastructuur toereikend is.

Wat is loadtesten?
load Testen is een niet-functioneel softwaretestproces waarbij de prestaties van softwaretoepassingen worden getest onder een specifieke verwachte belasting. Het bepaalt hoe de softwaretoepassing zich gedraagt terwijl deze door meerdere gebruikers tegelijkertijd wordt gebruikt. Het doel van Load Testing is om prestatieknelpunten te verbeteren en de stabiliteit en soepele werking van softwaretoepassingen te garanderen vóór implementatie.
Deze tests identificeren meestal:
- De maximale operationele capaciteit van een applicatie
- Bepaal of de huidige infrastructuur voldoende is om de applicatie te laten draaien
- Duurzaamheid van de toepassing met betrekking tot piekgebruiksbelasting
- Aantal gelijktijdige gebruikers dat een applicatie kan ondersteunen, en schaalbaarheid zodat meer gebruikers er toegang toe hebben.
Het is een vorm van niet-functioneel testen. Bij software-engineering wordt belastingtesten vaak gebruikt voor client/server- en webgebaseerde applicaties – zowel intranet als internet.
Waarom is belastingstests nodig?
Sommige extreem populaire sites hebben te maken gehad met ernstige downtime als ze enorme verkeersvolumes ontvangen. E-commercewebsites investeren zwaar in advertentiecampagnes, maar niet in Load Testing om optimale systeemprestaties te garanderen, wanneer die marketing verkeer genereert.
Voorbeelden van belastingstests
- Toysrus.com kon de verkeersdrukte die de eigen advertentiecampagne genereerde niet aan, waardoor zowel het marketingbudget als de beoogde omzet verloren gingen.
- Een website van een luchtvaartmaatschappij kon tijdens een festivalaanbieding niet meer dan 10000 gebruikers verwerken.
- Encyclopedia Britannica verklaarde gratis toegang tot hun online database als een promotionele aanbieding. Ze konden de aanval van verkeer wekenlang niet bijhouden.
Veel sites hebben last van vertraagde laadtijden als ze veel verkeer tegenkomen. Enkele feiten –
- Het aantal afgebroken pagina's neemt sterk toe na ongeveer 3 seconden laadtijd, en dit effect wordt versterkt op mobiele verbindingen.
- Trage pagina's kosten e-commercewebsites meetbare inkomsten bij elk bezoek, daarom wordt prestatie als een bedrijfsindicator beschouwd in plaats van een technische.
Waarom belastingtesten?
- Belastingtesten geven vertrouwen in het systeem en de betrouwbaarheid en prestaties ervan.
- Load Testing helpt bij het identificeren van de knelpunten in het systeem onder zware gebruikersstressscenario's voordat deze zich voordoen in een productieomgeving.
- Belastingtesten bieden uitstekende bescherming tegen slechte prestaties en bieden aanvullende strategieën voor prestatiebeheer en monitoring van een productieomgeving.
Doelen van belastingtesten
Bij het uitvoeren van laadtesten worden de volgende problemen geïdentificeerd voordat de applicatie op de markt wordt gebracht of in productie wordt genomen:
- Reactietijd voor elke transactie
- Prestaties van systeemcomponenten onder verschillende belastingen
- Prestaties van databasecomponenten onder verschillende belastingen
- Netwerkvertraging tussen de client en de server
- Problemen met softwareontwerp
- Serverconfiguratieproblemen zoals een webserver, applicatieserver, databaseserver enz.
- Problemen met hardwarebeperkingen, zoals CPU-maximalisatie, geheugenbeperkingen, netwerkknelpunten, enz.
Belastingtesten zullen bepalen of het systeem moet worden verfijnd of dat er aanpassing van hardware en software nodig is om de prestaties te verbeteren. Om belastingtests effectief uit te voeren, kunt u verschillende gebruiken prestatietestinstrumenten die beschikbaar zijn om u te helpen bij het identificeren van verbeterpunten.
Voorwaarden voor belastingstesten
De belangrijkste maatstaf voor belastingtests is de responstijd. Voordat u begint met het testen van de belasting, moet u bepalen:
- Of de responstijd al is gemeten en vergeleken – Kwantitatief
- Of de responstijd van toepassing is op het bedrijfsproces – Relevant
- Of de responstijd gerechtvaardigd is – Realistisch
- Of de responstijd haalbaar is – haalbaar
- Of de responstijd meetbaar is met behulp van een hulpmiddel of stopwatch – Meetbaar
Omgevingsinstellingen vóór de belastingstest
| Hardware Platform | software Configuration |
|---|---|
|
|
Strategieën voor belastingstesten
Er zijn veel manieren om load testing uit te voeren. Hieronder staan een paar load testing strategieën:
- Handmatige belastingtesten: Dit is een van de strategieën om belastingtests uit te voeren, maar het levert geen herhaalbare resultaten op, kan geen meetbare belastingniveaus voor een applicatie opleveren en is een onmogelijk proces om te coördineren.
- In eigen huis ontwikkelde belastingtesttools: Een organisatie die het belang van belastingtests beseft, kan hun eigen tools bouwen om belastingtests uit te voeren.
- Open source belastingtesttools: Er zijn verschillende belastingtesttools beschikbaar als open source die gratis zijn. Ze zijn misschien niet zo geavanceerd als hun betaalde tegenhangers, maar als je een beperkt budget hebt, zijn ze de beste keuze.
- Belastingtesttools van ondernemingsklasse: Ze worden meestal geleverd met een opname-/afspeelfunctie. Ze ondersteunen een groot aantal protocollen. Ze kunnen een uitzonderlijk groot aantal gebruikers simuleren.
Hoe u een belastingtest uitvoert
Het belastingtestproces kan kort worden beschreven, zoals hieronder:
- Maak een speciale Test omgeving voor belastingtesten
- Definieer de scenario's voor de belastingstest.
- Bepalen van belastingtesttransacties voor een applicatie
- Bereid gegevens voor elke transactie voor
- Het aantal gebruikers dat toegang heeft tot het systeem moet worden voorspeld
- Bepaal de verbindingssnelheden. Sommige gebruikers kunnen verbonden zijn via huurlijnen, terwijl anderen gebruik kunnen maken van een inbelverbinding
- Bepaal de verschillende browsers en besturingssystemen die door de gebruikers worden gebruikt
- Een configuratie van alle servers zoals web-, applicatie- en DB-servers
- Uitvoering en monitoring van testscenario's. Verzamelen van verschillende statistieken
- Analyseer de resultaten. Maak aanbevelingen
- Verfijn het systeem
- Opnieuw testen
Richtlijnen voor belastingstests
- Belastingtesten moeten worden gepland zodra de applicatie functioneel stabiel wordt.
- Er moet een groot aantal unieke gegevens in de datapool aanwezig zijn
- Voor elk scenario of elk script moet het aantal gebruikers worden bepaald
- Vermijd het maken van gedetailleerde logboeken om de IO-ruimte op de schijf te besparen
- Probeer het downloaden van afbeeldingen op de site te vermijden
- Tijdens het uitvoeren van testgevallen met belastingtests moet de consistentie van de responstijd over de verstreken periode worden geregistreerd en moet deze worden vergeleken met verschillende testruns.
Verschil tussen belasting- en stresstests
| load Testen | Stress testen |
|---|---|
| Belastingtesten identificeren de knelpunten in het systeem onder verschillende werkbelastingen en controleren hoe het systeem reageert wanneer de belasting geleidelijk wordt verhoogd | Stress testen bepaalt het breekpunt van het systeem om het maximale punt te onthullen waarna het breekt. |
| Om de bovengrens van het systeem te herkennen, stelt u de SLA van de app in en controleert u hoe het systeem een zware belasting aankan. | Om na te gaan hoe het systeem zich gedraagt onder extreme belasting en hoe het herstelt na een storing. |
| Het genereren van een verhoogde belasting van een webapplicatie is het hoofddoel van het testen van de belasting. | Stresstests zijn bedoeld om ervoor te zorgen dat de servers bij plotselinge hoge belasting gedurende een aanzienlijke tijd niet crashen. |
| De kenmerken die bij een belastingstest worden gecontroleerd, zijn topprestaties, serverhoeveelheid en responstijd. | Dit soort testen controleert de stabiliteit, responstijd, enz. |
| Bij belastingtests is de belastingslimiet een drempel voor een breuk. | Bij stresstests ligt de belastingslimiet boven de drempel van een breuk. |
Verschil tussen functionele testen en belastingtesten
| Functioneel testen | load Testen |
|---|---|
| Resultaten van functionele tests zijn gemakkelijk voorspelbaar omdat we de juiste stappen en randvoorwaarden hebben gedefinieerd | De resultaten van belastingtests zijn onvoorspelbaar |
| Resultaten van functionele tests variëren enigszins | De resultaten van de belastingstest variëren drastisch |
| Frequentie van uitvoering Functioneel testen hoog zal zijn | De frequentie van het uitvoeren van belastingtests zal laag zijn |
| Resultaten van functionele tests zijn afhankelijk van de testgegevens | Belastingtesten zijn afhankelijk van het aantal gebruikers. |
Laad testtools
LoadRunner
LoadRunner, oorspronkelijk van HP en nu onderdeel van OpenText Na de overname van Micro Focus test het systeem applicaties onder normale en piekbelasting. Het genereert belasting via virtuele gebruikers die het werkelijke netwerkverkeer simuleren en rapporteert de resultaten grafisch.
Lees meer in de LoadRunner-handleiding.
Apache JMeter
Een open-source Java Het is een handige tool en de meest gebruikte gratis optie. Het ondersteunt HTTP, JDBC, JMS, FTP en meer, slaat testplannen op als XML en integreert in CI-pipelines. Zie de JMeter zelfstudie voor een rondleiding.
Gatling
Een open-source tool waarvan de tests als code in Scala zijn geschreven of JavaHet kan hoge gelijktijdigheid aan op bescheiden hardware en produceert gedetailleerde HTML-rapporten, wat geschikt is voor teams die de voorkeur geven aan versiebeheerde testscripts.
k6
Een open-source tool met tests geschreven in JavaScript, ontworpen voor prestatietests die door ontwikkelaars zelf worden uitgevoerd binnen een CI-pipeline, in plaats van als een aparte QA-activiteit.
Een hulpmiddel kiezen
Pick JMeter Voor de breedst mogelijke protocoldekking zonder kosten, Gatling of k6 wanneer het team de tests samen met de applicatie in versiebeheer wil bewaren, en een commerciële tool zoals LoadRunner wanneer ondersteuning voor bedrijfsprotocollen en hulp van de leverancier de licentie rechtvaardigen.
Voordelen en nadelen van belastingstesten
Dit zijn de voordelen van load testing:
- Prestatieknelpunten identificeren vóór productie
- Verbetert de schaalbaarheid van het systeem
- Minimaliseer het risico met betrekking tot systeemuitval
- Lagere faalkosten
- Verhoog de klanttevredenheid
Nadelen van belastingtesten:
- De meeste tools vereisen programmeerkennis om realistische scenario's te kunnen programmeren.
- Tools kunnen duur zijn, omdat de prijs afhankelijk is van het aantal ondersteunde virtuele gebruikers.
Belangrijke meetwaarden om vast te leggen tijdens een belastingstest
In het gedeelte met de randvoorwaarden wordt de responstijd als belangrijkste meetwaarde vastgesteld. In de praktijk heeft een rapport van een belastingstest zes cijfers nodig, omdat de responstijd alleen niet kan verklaren waarom een systeem vertraagd is.
| metrisch | Wat het je vertelt | Waarschuwingsbord |
|---|---|---|
| Gemiddelde reactietijd | De typische gebruikerservaring | Stijgend naarmate de belasting toeneemt |
| 95e percentiel reactietijd | De ervaring van de traagste gebruikers | Ver boven het gemiddelde |
| Doorvoer | Aantal succesvol verwerkte verzoeken per seconde | Afvlakken of inzakken terwijl de belasting toeneemt |
| Foutpercentage | Aandeel van mislukte of verlopen aanvragen | Elke stijging boven de overeengekomen drempelwaarde |
| Gelijktijdige gebruikers | Daadwerkelijk gelijktijdige sessies bereikt | Lager dan het beoogde scenario |
| Serverresourcegebruik | Capaciteit voor CPU, geheugen, schijf en netwerk | Elke bron boven de circa 80 procent |
Leesdoorvoer in combinatie met responstijd. Een stijgende responstijd bij een stijgende doorvoer betekent simpelweg dat het systeem drukker is. Een stijgende responstijd met vallend Doorvoer betekent dat de capaciteit is overschreden en dat er nu werk verloren gaat, en dat is precies het punt dat de test probeert vast te stellen.
Rapporteer nooit alleen het gemiddelde. Een gemiddelde van 900 ms met een 95e percentiel van 1.1 seconden beschrijft een consistent systeem. Datzelfde gemiddelde met een 95e percentiel van 11 seconden betekent dat één op de twintig gebruikers een onacceptabele ervaring heeft die door het gemiddelde wordt verhuld.
Hoe deze test zich verhoudt tot andere prestatietests
Prestatietesten vormen een verzameling testen die verschillen in de aard van de toegepaste belasting, waardoor ze zo gemakkelijk met elkaar verward kunnen worden.
| Testtype | Wat wordt verhoogd? | Vraag het beantwoordt |
|---|---|---|
| Load testen | Gelijktijdige gebruikers, tot het verwachte piekniveau | Voldoet het aan de doelstellingen bij normale piekbelasting? |
| Volume testen | Gegevens opgeslagen in de database | Kan het systeem de groei van de dataset aan? |
| Stress testen | Overbelasting tot het maximale vermogen, tot het bezwijkt. | Waar gaat het kapot, en hoe? |
| Spike-testen | Laad direct en extreem snel | Overleeft het een schok en herstelt het ervan? |
| Uithoudingsvermogen testen | Duur, bij normale belasting | Neemt de prestatie in de loop der tijd af? |
| Soak testen | Duur, kijkbronnen | Zijn er geheugen- of handle-lekken? |
| Stabiliteitstesten | Wisselende omstandigheden | Blijft het betrouwbaar als de omstandigheden veranderen? |
Het belangrijkste onderscheid hier is: Volumetesten schalen de data, belastingstesten schalen het aantal gebruikers. Een rapport dat in twee seconden wordt verwerkt met tienduizend rijen en in twee minuten met tien miljoen rijen, heeft een probleem met het volume, niet met de belasting, en geen enkele hoeveelheid extra servercapaciteit zal dit oplossen.



