Wat is Spike-testen bij het testen van software? Leer met voorbeeld
Thomas Hamilton
⚡ Slimme samenvatting
Bij een piekbelastingstest wordt een applicatie blootgesteld aan een plotselinge, extreme piekbelasting, die vervolgens net zo abrupt wordt afgebouwd. Het doel is om te achterhalen of het systeem de schok overleeft en, net zo belangrijk, of het zich daarna herstelt.
Wat is Spike-testen?
Spike-testen is een vorm van softwaretesten waarbij een softwareapplicatie wordt getest met extreme toenames en afnames in de verkeersbelasting. Het belangrijkste doel van piektesten is het evalueren van het gedrag van de softwaretoepassing bij plotselinge toename of afname van de gebruikersbelasting en het bepalen van de hersteltijd na een piek in de gebruikersbelasting.
Spike Testing wordt uitgevoerd om de zwakke punten van softwareapplicaties in te schatten.
Doelstellingen van spike-testen
Het doel van Spike-testen is om te zien hoe het systeem reageert op onverwachte stijgingen en dalingen van de gebruikersbelasting. Bij software-engineering helpt Spike-testen bij het vaststellen dat de systeemprestaties zullen verslechteren bij een plotselinge hoge belasting.
Een ander doel van Spike Testing is het bepalen van de hersteltijd. Tussen twee opeenvolgende pieken in de gebruikersbelasting heeft het systeem enige tijd nodig om te stabiliseren. Deze hersteltijd moet zo kort mogelijk zijn.
Hoe u een Spike-test uitvoert
Hier zijn de eenvoudige stappen om Spike-tests uit te voeren:
Stap 1) Bepaal het laadvermogen
Bepaal de maximale gebruikersbelastingscapaciteit van uw softwareapplicatie.
Stap 2) Bereid de testomgeving voor
Bereid de testomgeving voor en configureer deze om prestatieparameters vast te leggen.
Stap 3) Definieer de verwachte belasting
Pas de verwachte maximale belasting toe op uw softwareapplicatie met behulp van een Prestatietesttool van jouw keuze.
Stap 4) Verhoog de belasting
Verhoog snel de belasting van het systeem gedurende een bepaalde periode.
Stap 5) Zet de belasting terug op normaal
Verlaag de belasting geleidelijk terug naar het oorspronkelijke niveau.
Stap 6) Analyseer de resultaten
Analyseer de prestatiegrafieken en statistieken zoals mislukkingen, verbruikte tijd, virtuele gebruikers, enz.
Voorbeelden van piektestscenario's
- Wanneer een e-commerce winkel speciale aanbiedingen lanceert met geweldige kortingen, zoals op Black Friday.
- Wanneer een webapplicatie een favoriet tv-programma live streamt.
- Wanneer er een flash-uitverkoop plaatsvindt op een dagelijkse dealsite.
- Wanneer de bepaalde inhoud van een site viraal gaat via internet.
- Er wordt een nieuw systeem vrijgegeven voor productie en meerdere gebruikers willen toegang tot het systeem.
- Een stroomstoring kan ervoor zorgen dat alle gebruikers de toegang tot een systeem verliezen. Nadat het probleem is opgelost, loggen alle gebruikers tegelijkertijd weer in op het systeem.
Herstelscenario's bij piekbelastingen
Drie belangrijke herstelscenario’s die kunnen worden geconfigureerd ter bescherming tegen pieken zijn:
- Gebruik cloudplatforms zoals AWS, Azure om de servercapaciteit dynamisch te vergroten in combinatie met de gebruikersbelasting
- Geef sommige gebruikers geen toegang tot de applicatie, zodat het systeem niet zwaar wordt belast. Dit voorkomt dat mensen boven de maximaal ontworpen belasting het systeem binnendringen. Zo wordt het systeem beschermd tegen de dreiging van overmatige belasting.
- Met de sitebeheerder kunnen gebruikers lid worden van het systeem. Maar met de waarschuwing dat ze te maken kunnen krijgen met een trage reactie vanwege de zware belasting. Dit kan een negatief effect hebben op de systeemprestaties. De gebruiker kan echter wel met het systeem werken.
Voordelen en nadelen van spike-testen
Hieronder staan de voor- en nadelen van Spike Testing:
| Voordelen | Nadelen |
|---|---|
| De prestaties van de software moeten koste wat het kost worden gehandhaafd. Wanneer de belasting van een systeem echter extreem toeneemt, is de kans op problemen groot. Spike Testing helpt bij het testen van een dergelijk scenario. | Het enige nadeel van Spike Testing is dat het een duur testproces is. Er moesten dus speciale testomstandigheden worden opgezet. Over de langere duur zal het echter zeker een positieve ROI opleveren. |
| In de standaardtestmethode wordt mogelijk niet ingegaan op de slechte tot worstcasescenario's. Het negeren ervan betekent echter niet dat ze nooit zullen voorkomen. Daarom moet elke software klaar zijn voor dergelijke mogelijkheden. Een voorbeeld van zo'n worstcasescenario is de belasting, die kan worden beoordeeld en geminimaliseerd met behulp van piektests. |
Spike-testhulpmiddelen
1) JMeter
De Apache JMeter is een open source-piektesttool in Java. Het is speciaal ontworpen om functioneel testgedrag te laden en prestaties te meten. Deze prestatietesttool kan worden gebruikt om de prestaties van een webapplicatie of een verscheidenheid aan services te analyseren en te meten. Tegenwoordig wordt het veel gebruikt voor de functionele test, databaseservertest.
2) LoadRunner
LoadRunner is een belastingtesttool voor Windows en Linux, waarmee piektesten van web- en andere apps mogelijk zijn. Het helpt om de prestaties en het resultaat van de toepassing te bepalen, zelfs onder zware belasting.
Hoe deze test past binnen de familie van prestatietests.
Prestatietesten is een overkoepelende term. De onderstaande varianten verschillen alleen in de vorm van de toegepaste belasting en de duur ervan, waardoor ze vaak met elkaar worden verward.
| Testtype | Belastingspatroon | Vraag het beantwoordt |
|---|---|---|
| Load testen | Verwachte piekbelasting, korte duur | Voldoet het systeem aan de doelstellingen bij normale piekbelasting? |
| Stress testen | Verhoogd tot boven de capaciteit tot het faalt | Waar gaat het mis, en verloopt het falen op een elegante manier? |
| Spike-testen | Plotselinge, extreme stijging, gevolgd door terugtrekking. | Kan het een verkeersschok overleven en ervan herstellen? |
| Uithoudingsvermogen testen | Normale belasting gedurende vele uren aangehouden | Neemt de prestatie in de loop der tijd af? |
| Soak testen | Langdurige belasting gedurende een langere periode | Zijn er geheugenlekken of is er sprake van uitputting van de systeembronnen? |
| Stabiliteitstesten | Variërende belasting onder verschillende omstandigheden | Blijft het systeem betrouwbaar bij veranderende omstandigheden? |
| Volume testen | Normale gebruikers, zeer grote hoeveelheden data | Kan het de groei van de database aan? |
Duurzaamheidstesten en weektesten worden vaak als synoniemen beschouwd. In de volksmond worden ze als volgt omschreven: beide tests houden een constante belasting gedurende een lange periode vol. Waar teams wel onderscheid maken tussen beide, richt duurtesten zich op de vraag of de responstijden toenemen, terwijl duurtesten zich richten op het resourceverbruik, zoals geheugen, bestandsdescriptors en verbindingspools. Het uitvoeren van één test levert meestal bewijs voor beide.
Belangrijke meetwaarden om vast te leggen tijdens de test
Een prestatietest is slechts zo goed als wat je vastlegt tijdens de uitvoering. Leg deze zes gegevens vast, zowel aan de server- als aan de clientzijde, en vergelijk ze vervolgens met de basislijn in plaats van af te gaan op je onderbuikgevoel.
| metrisch | Wat het je vertelt | Waarschuwingsbord |
|---|---|---|
| Gemiddelde reactietijd | Typische gebruikerservaring | Elke opwaartse afwijking gedurende de run |
| 95e percentiel reactietijd | De ervaring van de traagste gebruikers | Ver boven het gemiddelde, wat duidt op inconsistentie. |
| Doorvoer | Verzoeken verwerkt per seconde | Dalend terwijl de belasting constant blijft |
| Foutpercentage | Aandeel van mislukte of verlopen aanvragen | Elke stijging boven de overeengekomen drempelwaarde |
| CPU- en geheugengebruik | Servercapaciteit | Een herinnering die opstijgt en nooit meer terugkeert. |
| Databaseverbindingen en threads | zwembaduitputting | Aantallen die gestaag groeien zonder vrijgave |
Lees het gemiddelde en het percentiel samen. Een gemiddelde van 800 ms met een 95e percentiel van 900 ms beschrijft een consistent systeem. Datzelfde gemiddelde met een 95e percentiel van 9 seconden betekent dat één op de twintig gebruikers een slechte ervaring heeft, en dat het gemiddelde dit verbergt.
Let op de vorm, niet alleen op de waarde. Bij elke langdurige test is een vlakke lijn voor de resources een teken van voldoende resultaat en een stijgende lijn een teken van een overschrijding, zelfs als het absolute aantal op het moment dat de test eindigt nog ruim binnen de limiet ligt.
Spike-testen: Belangrijkste conclusies
- software testen is een vorm van softwaretesten waarbij een softwareapplicatie wordt getest met extreme toenames en afnames in de verkeersbelasting.
- De juiste aanpak om piektesten uit te voeren is het onverwacht verhogen van het aantal gebruikers, gevolgd door een onmiddellijke afname van de belasting.
- De onverwachte lading is het belangrijkste kenmerk van de deal.
- Voorbeelden van real-life Spike-testscenario's zijn: wanneer een e-commerce winkel speciale aanbiedingen lanceert met geweldige kortingen, zoals op Black Friday. Als alternatief, wanneer een webapplicatie live een favoriet tv-programma streamt.
- JMeter is zo'n handig hulpmiddel om piektesten uit te voeren.
