Test de stress

Le test de stress (stress testing) pousse délibérément un système au-delà de sa charge attendue, palier par palier, jusqu’à ce qu’il ne tienne plus ses objectifs ou tombe carrément. Là où un test de charge demande « tenons-nous le pic normal ? », un test de stress demande « jusqu’où pouvons-nous aller, qu’est-ce qui casse en premier, et qu’arrive-t-il aux utilisateurs à ce moment-là ? »

Exemple (k6 avec taux d’arrivée progressif)

Augmenter le débit de requêtes par paliers, indépendamment de la vitesse de réponse du serveur :

import http from 'k6/http';

export const options = {
  scenarios: {
    breakpoint: {
      executor: 'ramping-arrival-rate',
      startRate: 50,
      timeUnit: '1s',
      preAllocatedVUs: 200,
      maxVUs: 2000,
      stages: [
        { duration: '5m', target: 200 },
        { duration: '5m', target: 400 },
        { duration: '5m', target: 800 },
        { duration: '3m', target: 0 }, // ramp down to observe recovery
      ],
    },
  },
};

export default function () {
  http.get('https://staging.example.com/api/search?q=shoes');
}

Un executor à taux d’arrivée continue d’envoyer des requêtes au débit cible même quand les réponses ralentissent, ce qui est plus proche du comportement d’utilisateurs réels et met la saturation en évidence plus clairement qu’un nombre fixe d’utilisateurs virtuels.

Ce qu’il faut observer

• Le coude. Le débit à partir duquel les percentiles de latence grimpent brutalement tandis que le débit traité plafonne. C’est votre capacité pratique.
• Le mode de défaillance. Une dégradation maîtrisée se traduit par des réponses 429 ou 503 rapides et un délestage de la charge. Une mauvaise défaillance, ce sont des timeouts, des pannes en cascade dans d’autres services, des données corrompues ou des processus qui plantent.
• Le rétablissement. Après la descente en charge, la latence revient-elle d’elle-même à la normale, ou des connexions bloquées et des files pleines exigent-elles un redémarrage ?
• Le premier goulot d’étranglement. CPU, pool de connexions à la base, pool de threads, mémoire ou dépendance en aval. Le corriger déplace le point de rupture : les tests de stress sont donc souvent répétés.

Différence avec le test de pic

Un test de stress monte progressivement pour trouver une limite. Un test de pic (spike test) passe presque instantanément d’une charge normale à une charge très élevée, par exemple lors d’une vente flash ou d’une notification push, et vérifie que l’autoscaling et les files d’attente réagissent assez vite.

Erreurs fréquentes

Lancer des tests de stress sur des environnements partagés dont dépendent d’autres équipes, les exécuter depuis un seul générateur de charge qui sature avant le serveur, et s’arrêter à « ça a cassé à 800 rps » sans consigner comment ça a cassé ni si le système s’est rétabli.