Qu'est-ce que le soak testing ?

Qu'est-ce que le soak testing ?

Le soak testing, aussi appelé test d'endurance ou endurance testing, maintient une charge réaliste et constante sur un système pendant des heures plutôt que des minutes. La question n'est pas de savoir combien de charge il encaisse, mais s'il reste sain en la portant longtemps. Il révèle des défauts qui mettent des heures à apparaître, comme les fuites mémoire, les pools de connexions épuisés et les disques qui se remplissent.

Les deux noms désignent la même pratique. La durée à prévoir et la lecture de la tendance sont détaillées dans le guide endurance testing (soak testing) du blog LoadFocus.

Comment fonctionne un soak test

• Partez du script de charge moyenne de votre test de charge. Le soak test le réutilise et ne change que la durée du palier.
• Montez jusqu'à une charge normale et attendue, puis tenez-la. La documentation k6 décrit la charge comme moyenne, avec des durées de 3, 4, 8, 12, 24 ou de 48 à 72 heures.
• Enregistrez la tendance, pas seulement la synthèse : temps de réponse, taux d'erreurs, débit, mémoire, utilisation du pool de connexions et disque, idéalement sur le serveur autant que dans l'outil de test.
• Comparez la première heure à la dernière. Toute pente qui ne s'arrête pas est le résultat.

Dans k6, tout le scénario tient en quelques lignes :

export const options = {
  stages: [
    { duration: '5m', target: 100 },
    { duration: '8h', target: 100 },
    { duration: '5m', target: 0 },
  ],
};

Imaginez un service avec un pool de connexions à la base de données. HikariCP, un pool Java courant, propose 10 connexions par défaut, et quand aucune n'est libre, l'appelant attend jusqu'à 30 secondes puis reçoit une SQLException. Si un chemin de code oublie de rendre une connexion toutes les quelques milliers de requêtes, un test de charge de 20 minutes ne le voit pas. Huit heures de charge constante vident le pool, les requêtes s'empilent puis échouent.

Ce qu'un soak test révèle

• Fuites mémoire. La mémoire réservée et jamais libérée grimpe jusqu'à la mort du processus. Sur le graphique, c'est une ligne qui ne se stabilise jamais.
• Fuites de connexions. Des connexions à la base ou HTTP ouvertes et jamais rendues, comme dans l'exemple du pool.
• Croissance du disque et des logs. Logs, fichiers temporaires ou lignes d'audit qui remplissent un volume jamais dimensionné pour une longue exécution.
• Dégradation du cache. Un cache qui grossit sans éviction, ou dont le taux de succès baisse quand le jeu de données actif change.
• Identifiants qui expirent. Un jeton ou un certificat mis en cache et mal renouvelé fait échouer toutes les requêtes après son expiration.
• Tâches planifiées face au trafic. Sauvegardes et nettoyages qui ne tournent qu'une fois par jour et n'ont jamais été observés sous charge.

Erreurs fréquentes

• Tester à la charge de pointe. Une longue exécution à une charge irréaliste est un autre test. Dépasser le trafic normal relève du test de stress ou de capacité, et les mélanger rend le résultat difficile à expliquer.
• S'arrêter trop tôt. L'exécution doit couvrir au moins un cycle naturel du système, comme un traitement horaire ou la sauvegarde de nuit.
• Ne lire que la synthèse. Une moyenne sur huit heures cache une lente dérive. Regardez le graphique dans le temps.
• Ne regarder que le client. L'outil de test voit des réponses plus lentes. La mémoire, les connexions et le disque du serveur en montrent la cause.
• Manquer de données de test. Si les mêmes quelques utilisateurs et enregistrements reviennent, les caches restent chauds et le système paraît plus sain qu'il ne l'est.
• Voir une fuite dans chaque marche. Un saut soudain correspond le plus souvent à un événement. Rapprochez d'abord l'heure des déploiements, des tâches et de la rotation des logs.

Soak testing et tests voisins

• Le test de charge vérifie le comportement à la pointe attendue pendant une durée limitée.
• Le test de capacité cherche la charge la plus élevée que le système soutient.
• Le test de pic (spike testing) frappe le système d'une rafale soudaine et observe la reprise.
• Le soak testing est le seul de ces tests qui porte sur le temps plutôt que sur la taille.

Faire un soak test avec LoadFocus

Écrivez le scénario en JMeter ou k6 et réglez utilisateurs virtuels et durée dans le navigateur sur LoadFocus. La durée maximale dépend de l'offre : jusqu'à 20 minutes en Starter, 1 heure en Basic et 5 heures à partir d'Essential (loadfocus.com/pricing, octobre 2026). Cela couvre un soak court. Pour une exécution de 24 ou 72 heures, lancez le même script sur votre propre infrastructure et surveillez les graphiques côté serveur, car la tendance de la mémoire, des connexions et du disque est le résultat. Le diagnostic des fuites mémoire est traité dans identifier et corriger les fuites mémoire en test de charge.

Questions fréquentes sur le soak testing

Combien de temps un soak test doit-il durer ?

Assez pour couvrir au moins un cycle naturel de votre système, par exemple un traitement horaire ou une sauvegarde de nuit. La documentation k6 cite des durées de 3 à 72 heures. Huit heures constituent une première exécution courante, car elles couvrent une journée de travail.

Le soak testing est-il la même chose que l'endurance testing ?

Oui. Les deux termes décrivent le maintien d'une charge réaliste pendant longtemps pour trouver une dégradation qui n'apparaît qu'avec le temps. Utilisez celui que votre équipe emploie déjà.

Quelle charge un soak test doit-il utiliser ?

La charge normale attendue, pas la pointe. Le but est de voir ce que le temps fait au système, donc la charge doit être supportable. Au-delà, c'est un test de stress.

À quoi ressemble une fuite mémoire dans un soak test ?

La mémoire monte pendant toute l'exécution sans jamais se stabiliser, souvent avec des temps de réponse qui se dégradent peu à peu parce que le ramasse-miettes travaille davantage. Un système sain atteint un palier.

LoadFocus peut-il exécuter un soak test de 24 heures ?

Pas en une seule exécution. La durée maximale est de 5 heures, à partir d'Essential. Un soak plus long se lance sur votre propre infrastructure avec le même script JMeter ou k6.