Stress Test in mobiele ontwikkeling: wat is het, doelen en hoe het wordt uitgevoerd

Wat is Stress Test?

Stress Test (stresstesten) is het proces van het evalueren van het vermogen van een systeem om te werken onder omstandigheden die de berekende parameters overschrijden. Voor een mobiele applicatie kan dit 10000 gelijktijdige pushmeldingen betekenen bij een norm van 1000, voor de backend — 50000 RPS bij een verwachte 5000. Het belangrijkste verschil tussen Stress Test en Load Test is dat het doel niet het bevestigen van prestaties is, maar het bestuderen van systeemgedrag buiten de ontworpen capaciteit. Netflix Engineering (2024) definieert Stress Test als “het testen van de hypothese dat het systeem op een voorspelbare manier faalt”.

Stresstesten omvat twee verplichte fasen: belasten tot falen en observatie van herstel. Herstel (recovery) is het vermogen van het systeem om terug te keren naar normaal functioneren nadat de overbelasting is weggenomen. Een systeem dat niet herstelt zonder herstart wordt als kwetsbaar beschouwd, zelfs als het kortstondige overbelasting weerstaat. Volgens AWS Well-Architected Framework (2024) mag de hersteltijd na een Stress Test niet meer dan 5 minuten bedragen.

Voor mobiele clients omvat Stress Test het controleren van de werking bij gedwongen beëindiging van processen, netwerkuitval en uitputting van RAM-geheugen. Android Low Memory Killer kan een achtergrondproces beëindigen bij RAM-tekort — de stresstest moet controleren of de applicatie de status correct herstelt na een dergelijke beëindiging. Apple UIKit (2024) raadt aan om memory warning-scenario's op elk scherm van de applicatie te testen.

Doelen van stresstesten

Bepalen van het faalpunt

Het eerste doel van Stress Test — bepalen van het faalpunt (breaking point). Dit is het moment waarop een van de belangrijkste prestatie-indicatoren een kritieke drempel overschrijdt: p95-responsetijd overschrijdt 10 seconden, percentage HTTP 5XX-fouten overschrijdt 5% of doorvoer daalt onder 50% van de baseline. Het vastleggen van het faalpunt stelt het team in staat om van tevoren de schaalbaarheidsgrens van het systeem te kennen. Capacity planning vertrouwt juist op gegevens van Stress Test, niet van Load Test, omdat Load Test geen grenstoestanden controleert.

Controleren van herstelmechanismen

Het tweede doel — controleren van herstelmechanismen. Nadat de belasting is gedaald tot het normale niveau, moet het systeem terugkeren naar de standaardindicatoren. Als de databaseverbindingspool niet wordt vrijgemaakt of de cache niet wordt ongeldig gemaakt, zal Stress Test dit probleem aan het licht brengen. Circuit breaker (Hystrix, Resilience4j) moet worden geactiveerd bij overbelasting en de verbinding automatisch herstellen na stabilisatie. Health check-endpoints helpen om de status van elke service tijdens de test te monitoren.

Validatie van auto-scaling

Het derde doel — validatie van auto-scaling. Als de infrastructuur Kubernetes of AWS Auto Scaling gebruikt, controleert Stress Test of nieuwe pods of instanties snel genoeg worden aangemaakt. Volgens Google Kubernetes Engine (2024) mag de implementatietijd van een nieuwe pod niet meer dan 30 seconden bedragen vanaf het moment dat de HPA-metric (Horizontal Pod Autoscaler) wordt geactiveerd. HPA moet schalen op basis van CPU, geheugen en aangepaste metrics. Cluster Autoscaler voegt nieuwe knooppunten toe als de bestaande geen pods kunnen huisvesten.

Methodologie van Stress Test

Geleidelijke verhoging van belasting (Ramp-up Stress Test) — het meest voorkomende scenario. De initiële belasting wordt ingesteld op 50% van de verwachte waarde, vervolgens wordt deze elke 2 minuten met 10% verhoogd totdat het systeem faalt. Dit scenario maakt het mogelijk om de exacte grens van veerkracht te vinden. Grafana Cloud k6 (2025) raadt een verhogingsstap van niet meer dan 10% aan voor een vloeiende grafiek van de responstijd.

Plotselinge piek van belasting (Spike Stress Test) — de belasting stijgt van 10% naar 500% binnen 10–30 seconden. Dit scenario modelleert situaties zoals virale verspreiding van inhoud of een DDoS-aanval. Spike Stress Test controleert niet zozeer prestaties als wel de levensvatbaarheid van het systeem: het vermogen om niet volledig uit te vallen en terug te keren naar werking na stabilisatie. API Gateway moet rate limiting configureren om de backend te beschermen tegen plotselinge pieken.

Langdurig vasthouden van overbelasting (Sustained Stress Test) — het systeem wordt gedurende 30–60 minuten in een staat van overbelasting gehouden. Dit scenario brengt resourcelekken aan het licht die niet optreden bij kortdurende tests. Geheugenlek in Java/Kotlin-applicaties accumuleert gedurende 20–40 minuten intensief werk en alleen Sustained Stress Test detecteert het.

Analyse van faalpunt en herstel

Faalpunt wordt bepaald op basis van drie criteria: responstijd, foutpercentage en doorvoer. Meestal wordt eerst de responstijdlimiet overschreden — verzoeken worden langer uitgevoerd dan de ingestelde limiet. Vervolgens stijgt het foutpercentage: de server kan de verzoeken niet verwerken en retourneert 503. Als laatste daalt de Throughput — het systeem kan zelfs minimale belasting niet aan. Metric van het faalpunt wordt vastgelegd in het belastingsprofiel voor capaciteitsplanning.

Herstelanalyse omvat drie fasen: onmiddellijke reactie (eerste 30 seconden na het wegnemen van belasting), stabilisatie (1–5 minuten) en volledig herstel (5–30 minuten). In de onmiddellijke reactiefase moet de responstijd onder de baseline dalen — het systeem wordt bevrijd van wachtrijen. Als dit niet gebeurt, ligt het probleem niet in de belasting maar in de geaccumuleerde toestand. Graceful degradation — het vermogen van het systeem om gedeeltelijke functionaliteit te behouden bij overbelasting — is een belangrijke indicator van architectuurvolwassenheid.

Chaos Engineering vult Stress Test aan door opzettelijk storingen te introduceren: uitschakelen van de databaseserver, netwerkvertraging, stoppen van een microservice. Chaos Monkey van Netflix (2024) beëindigt willekeurig processen in productie en test de veerkracht van het systeem. Voor mobiele applicaties betekent Chaos Engineering het testen van scenario's: geen netwerk, API niet beschikbaar, lege serverrespons.

Hulpmiddelen voor Stress Test

k6 met ramping-arrival-rate

k6 ondersteunt Stress Test via de `execution`-module met ramping-arrival-rate-configuratie. Deze modus verhoogt het aantal verzoeken per seconde onafhankelijk van de uitvoeringstijd van elk verzoek. In vergelijking met Load Test vereist Stress Test in k6 het instellen van agressievere thresholds en het uitschakelen van gracefull-stop voor simulatie van plotseling falen. Grafana Cloud detecteert automatisch het faalpunt op basis van de knik in de responstijdgrafiek. k6-operator voor Kubernetes maakt het mogelijk om gedistribueerde Stress Tests vanuit het cluster uit te voeren.

JMeter met Ultimate Thread Group

JMeter maakt configuratie van Stress Test mogelijk via Ultimate Thread Group — een plug-in die het belastingsprofiel definieert in tabelvorm: aantal threads, opwarmtijd, houdtijd, afkoeltijd. Ultimate Thread Group is handig voor complexe meerfasige scenario's. JMeter Backend Listener stuurt metrics naar InfluxDB voor het bouwen van grafieken van het faalpunt. Voor Stress Test in JMeter wordt aanbevolen om verbindingstime-outs uit te schakelen om het gedrag bij overbelasting nauwkeuriger te meten.

Gremlin voor Chaos Engineering

Gremlin — een Chaos Engineering-platform voor Stress Test van infrastructuur. Gremlin maakt het mogelijk om het netwerk uit te schakelen, CPU te belasten, de schijf te vullen en processen te beëindigen op het niveau van individuele Kubernetes-pods. SRE-teams gebruiken Gremlin samen met k6 voor uitgebreide Stress Test: k6 creëert belasting, Gremlin introduceert storingen. Game Day — regelmatige Stress Test-sessies met Gremlin die worden gedocumenteerd in “caos rapport” voor analyse van systeemveerkracht.

Voorbeeld van Stress Test op k6

Het gepresenteerde script op k6 demonstreert een Stress Test met geleidelijke belastingsverhoging tot falen. Ramping-arrival-rate verhoogt het aantal verzoeken per seconde onafhankelijk van de uitvoeringstijd. Thresholds zijn ingesteld voor agressieve detectie van degradatie: p95 niet meer dan 2000 ms, error rate niet meer dan 5%. Bij overschrijding van de drempels beëindigt k6 de test met een foutcode, wat het mogelijk maakt om Stress Test in de CI/CD-pipeline te integreren.

import http from 'k6/http'
import check from 'k6'

export const options = {
    scenarios: {
        stress: {
            executor: 'ramping-arrival-rate',
            startRate: 50,
            timeUnit: '1s',
            stages: [
                { duration: '2m', target: 200 },
                { duration: '5m', target: 500 },
                { duration: '2m', target: 1000 },
            ],
            preAllocatedVUs: 50,
            maxVUs: 200,
        },
    },
    thresholds: {
        http_req_duration: ['p(95)<2000'],
        http_req_failed: ['rate<0.05'],
    },
}

export default function() {
    const res = http.get('https://api.example.com/health')
    check(res, {
        'status is 200': (r) => r.status === 200,
    })
}

Beste praktijken voor stresstesten

Begin Stress Test op staging — stresstesten in productie vereist geavanceerde monitoring en een terugdraaiplan. Google SRE (2024) beveelt aan om Stress Test uit te voeren in een 100% geïsoleerde omgeving die productie qua architectuur en capaciteit nabootst. Na een succesvolle test op staging kan worden overgegaan naar productie onder toezicht van SRE. Feature flag voor het uitschakelen van functionaliteit bij overbelasting is een verplicht element.

Automatiseer Stress Test in CI/CD voor regressieanalyse van het faalpunt. Als een nieuwe versie van de applicatie een faalpunt heeft dat 20% lager ligt dan de vorige, is dit een regressie die voor de release moet worden opgelost. Baseline breaking point wordt opgeslagen in metrics en automatisch vergeleken met het resultaat van elke Stress Test. Een alarm wordt geactiveerd bij een daling van het faalpunt van 10%.

Documenteer elke Stress Test: belastingsprofiel, faalpunt, herstelgedrag en lijst van ontdekte problemen. Netflix Engineering (2024) organiseert “Game Day” — regelmatige Stress Test-sessies waarvan de resultaten worden gedocumenteerd in “caos rapport”. Rapport over stresstesten moet een grafiek “RPS — responstijd” bevatten met het gemarkeerde faalpunt.