Quelle est la différence entre les tests de charge, de stress et d'endurance, et que mesureriez-vous ?

Le test de charge fait tourner le trafic attendu pour confirmer que le système atteint ses objectifs. Le test de stress pousse au-delà de la capacité pour trouver le point de rupture et vérifier que la dégradation est progressive plutôt qu'un effondrement. Le test d'endurance maintient une charge modérée pendant des heures pour révéler les fuites et l'épuisement des ressources. Mesurez les percentiles de latence, le débit, le taux d'erreur, et la saturation du CPU, de la mémoire, des connexions et de la base de données.

Ils diffèrent par l'intention. Le test de charge répond à la question de savoir si le système atteint sa cible au trafic attendu, donc j'ai besoin que cette cible soit convenue avant de commencer, quelque chose comme un p95 sous 300 millisecondes à deux mille utilisateurs simultanés avec un taux d'erreur sous un dixième de pour cent. Le test de stress dépasse délibérément ce point pour trouver où cela casse et, surtout, comment. Une dégradation progressive avec mise en file et erreurs claires est acceptable ; une corruption de données ou une cascade qui emporte les services voisins ne l'est pas. Le test d'endurance maintient une charge modérée pendant huit ou douze heures, ce qui est la seule façon d'attraper les fuites lentes, les pools de connexions qui ne rendent jamais rien, et les volumes de logs qui remplissent un disque. J'ai déjà trouvé une fuite mémoire qui n'apparaissait qu'après environ six heures et qui ne serait jamais sortie dans une exécution de trente minutes. Sur la mesure, je rapporte des percentiles, parce qu'une moyenne cache tout ce qui compte, donc p50, p95 et p99 à côté du débit et du taux d'erreur. Et je surveille la saturation en même temps, donc CPU, mémoire, usage du pool de connexions et verrous de base, parce que le temps de réponse vous dit que quelque chose ne va pas et la saturation vous dit quoi.