Test d'endurance (soak test)

Le test d’endurance (soak testing ou endurance testing) fait tourner un système sous une charge normale et soutenue pendant une longue période, en général plusieurs heures et parfois une journée ou plus. La charge elle-même n’a rien de remarquable ; c’est la durée qui compte. Beaucoup de défauts sont invisibles lors d’un test de charge de 10 minutes parce qu’ils grossissent lentement : quelques mégaoctets perdus tous les mille requêtes, une connexion jamais rendue au pool, un fichier de log qui remplit le disque.

Ce qu’il détecte

• Les fuites mémoire. Une consommation de heap qui monte régulièrement et ne redescend jamais après le garbage collector, jusqu’au crash par manque de mémoire.
• L’épuisement des ressources. Connexions à la base de données, descripteurs de fichiers, threads ou sockets ouverts et jamais libérés.
• La dérive progressive de la latence. Le p95 à la sixième heure est nettement moins bon qu’à la première, souvent à cause de caches qui grossissent, de tables qui gonflent ou de la fragmentation.
• Les interférences des tâches planifiées. Batchs nocturnes, sauvegardes, renouvellements de certificats ou rotation des logs qui entrent en collision avec le trafic réel.
• La croissance du stockage. Des disques qui se remplissent de logs, de fichiers temporaires ou de files d’attente en retard.

Exemple (k6)

export const options = {
  stages: [
    { duration: '10m', target: 80 },
    { duration: '8h', target: 80 },
    { duration: '10m', target: 0 },
  ],
  thresholds: {
    http_req_duration: ['p(95)<600'],
    http_req_failed: ['rate<0.005'],
  },
};

La fonction par défaut est le même parcours utilisateur réaliste que celui d’un test de charge. La différence, c’est la longue phase stable.

Comment lire les résultats

Un test d’endurance se juge sur les tendances, pas seulement sur des seuils réussite/échec. Tracez la mémoire, le nombre de connexions, les percentiles de latence et le taux d’erreur sur toute la durée. Une courbe plate, c’est un succès. Une pente régulièrement ascendante est un défaut, même si l’exécution s’est terminée avant tout crash, car la production tourne bien plus longtemps que huit heures.

Erreurs fréquentes

• Lancer le test d’endurance avec une charge de niveau stress, ce qui mélange deux questions et rend la cause d’un échec floue.
• Ne surveiller que les métriques côté client. Les fuites apparaissent d’abord dans les graphes de mémoire et de pools côté serveur.
• Utiliser un environnement qui redémarre les services ou les remplace par autoscaling pendant l’exécution, ce qui masque précisément l’accumulation que vous cherchez.
• Y renoncer parce que c’est long. Planifiez-le la nuit ou le week-end plutôt que de l’abandonner.