Cas pratiques Performance Testing

Contexte Un test additionne les temps de réponse pour calculer un total. Le Problème Le script écrase la variable au lieu de l’additionner : totalTime = responseTime; Cela empêche le calcul correct du cumul. Contraintes Corriger l’accumulation afin que chaque nouveau temps soit ajouté au total existant. Livrable attendu Un test de performance calculant correctement le temps total cumulé.

Contexte Un test mesure le temps de réponse de l’endpoint GET /health pour vérifier la disponibilité du service. Le Problème Le script actuel valide un seuil incorrect : const responseTime = result.timings.duration; if (responseTime > 200) { throw new Error('Response too slow'); } Le seuil attendu est en réalité 500 ms. Contraintes Corriger uniquement la valeur seuil sans modifier la logique de mesure. Livrable attendu Un test de performance validant correctement que le temps de réponse reste inférieur à 500 ms.

Contexte Un test mesure le temps de réponse en millisecondes. Le Problème Le script compare la valeur comme si elle était en secondes : if (responseTime > 2) { throw new Error('Too slow'); } La valeur est exprimée en millisecondes. Contraintes Corriger la comparaison en tenant compte de l’unité réelle. Livrable attendu Un test de performance cohérent avec l’unité de mesure utilisée.

Contexte Un endpoint GET /health doit répondre en moins de 300 ms. Le Problème Le script actuel déclenche une erreur lorsque le temps est inférieur au seuil. if (responseTime < 300) { throw new Error('Too slow'); } La condition est inversée. Contraintes Corriger la condition logique sans modifier le reste du test. Livrable attendu Un test de performance validant correctement le seuil maximal.

Contexte Un test exécute 5 requêtes consécutives vers GET /status et calcule une moyenne. Le Problème Le script divise par une mauvaise valeur : const average = totalTime / 10; Seulement 5 requêtes sont exécutées. Contraintes Corriger le calcul de la moyenne sans modifier la logique d’accumulation des temps. Livrable attendu Un test de performance calculant correctement le temps moyen.

Contexte Une API GET /users doit répondre rapidement en conditions normales. Le Problème Il faut mettre en place un test simple mesurant le temps de réponse. Contraintes Envoyer une requête vers l’endpoint et mesurer la durée totale. Ajouter une vérification garantissant que le temps est inférieur à 800 ms. Livrable attendu Un test de performance basique validant la rapidité de l’endpoint.

Contexte Un scénario utilisateur effectue successivement GET /login, GET /profile et GET /dashboard. Le Problème Il faut mesurer le temps total du scénario complet. Contraintes Chronométrer le début avant la première requête et la fin après la dernière. Vérifier que le temps global est inférieur à 1500 ms. Livrable attendu Un test de performance simple validant la rapidité globale d’un scénario utilisateur.

Contexte Un service GET /ping doit être appelé 10 fois consécutivement. Le Problème Il faut vérifier que chaque requête retourne un code 200 et mesurer le temps global. Contraintes Implémenter une boucle exécutant 10 appels séquentiels et vérifier à chaque fois le statut HTTP. Livrable attendu Un test de performance simple validant stabilité et disponibilité.

Contexte Un endpoint GET /health est utilisé pour surveiller la disponibilité du service. Le Problème Il faut vérifier que le service répond correctement sur plusieurs appels consécutifs. Contraintes Envoyer 5 requêtes successives et vérifier que chacune retourne un code 200 avec un temps inférieur à 500 ms. Livrable attendu Un test de performance simple validant la disponibilité continue du service.

Contexte Une API GET /products ne doit jamais dépasser 1000 ms. Le Problème Il faut vérifier que le temps maximal observé reste sous ce seuil. Contraintes Exécuter plusieurs requêtes et identifier le temps le plus élevé. Ajouter une assertion validant qu’il reste inférieur à 1000 ms. Livrable attendu Un test de performance simple contrôlant le temps de réponse maximal.

Contexte Un test envoie 200 requêtes vers GET /status et mesure le nombre d’échecs. Le Problème Le script calcule le taux d’erreur ainsi : const errorRate = errors / 100; Alors que 200 requêtes ont été envoyées. Contraintes Corriger la formule pour utiliser le nombre réel total de requêtes. Livrable attendu Un test de performance calculant correctement le taux d’erreur.

Contexte Un test mesure le temps moyen sur 20 requêtes vers GET /analytics. Le Problème Le script réinitialise la variable totalTime à chaque itération : totalTime = responseTime; Cela empêche le calcul correct de la moyenne. Contraintes Corriger l’accumulation afin de conserver la somme des temps avant division finale. Livrable attendu Un test de performance calculant correctement le temps moyen.

Contexte Un test mesure le temps total d’un lot de requêtes. Le Problème Le chronomètre démarre après la première requête au lieu d’avant : await api.get('/start'); const start = Date.now(); Contraintes Corriger la position du chronomètre afin que la mesure englobe l’ensemble des appels concernés. Livrable attendu Un test de performance mesurant correctement le temps global du scénario.

Contexte Un test de performance simule 50 utilisateurs envoyant des requêtes simultanément vers GET /products. Le Problème Le script actuel exécute les requêtes de manière séquentielle au lieu de parallèle : for (let i = 0; i < 50; i++) { await api.get('/products'); } Cela ne simule pas une vraie charge concurrente. Contraintes Adapter l’implémentation pour exécuter les requêtes en parallèle (ex: Promise.all ou mécanisme équivalent). Mesurer le temps total. Livrable attendu Un test de charge simulant correctement des requêtes concurrentes.

Contexte Un test mesure les temps de réponse et doit calculer le 95e percentile. Le Problème Le script utilise simplement la moyenne au lieu du percentile réel. Contraintes Implémenter un calcul correct du percentile 95 à partir d’un tableau de temps trié. Vérifier qu’il reste inférieur à 1200 ms. Livrable attendu Un test de performance calculant correctement le percentile 95.

Contexte Deux versions d’un endpoint /v1/data et /v2/data doivent être comparées en termes de performance. Le Problème Il faut mesurer le temps moyen de chaque version sous charge identique. Contraintes Exécuter le même nombre de requêtes pour chaque version. Calculer les temps moyens respectifs et comparer les résultats. Identifier laquelle est plus performante. Livrable attendu Un test de performance comparatif validant l’évolution des performances entre versions.

Contexte Un endpoint POST /orders doit supporter une montée progressive de trafic. Le Problème Il faut simuler un ramp-up de 10 à 100 utilisateurs virtuels. Contraintes Implémenter une logique augmentant progressivement le nombre de requêtes concurrentes. Mesurer le taux d’erreur et le temps moyen de réponse. Livrable attendu Un test de performance validant la stabilité du système lors d’une montée en charge progressive.

Contexte Un endpoint POST /events doit gérer un flux important de requêtes. Le Problème Il faut mesurer le nombre de requêtes traitées par seconde sous une charge constante. Contraintes Simuler une charge fixe pendant une durée déterminée (ex: 60 secondes). Calculer le throughput en requêtes par seconde et vérifier qu’il dépasse un seuil minimal. Livrable attendu Un test de performance mesurant correctement le débit du service.

Contexte Un service GET /monitor doit rester stable sous charge constante pendant 10 minutes. Le Problème Il faut vérifier qu’aucune augmentation progressive du temps de réponse n’apparaît. Contraintes Exécuter des requêtes continues pendant une durée définie. Mesurer l’évolution du temps moyen et détecter toute dérive significative. Livrable attendu Un test de performance validant la stabilité prolongée du service.

Contexte Un endpoint GET /reports doit être testé au-delà de la charge normale. Le Problème Il faut augmenter progressivement la charge jusqu’à observer une dégradation significative des performances. Contraintes Implémenter une boucle augmentant progressivement le nombre de requêtes concurrentes. Identifier le seuil où le temps moyen dépasse 2 secondes. Livrable attendu Un test de stress permettant d’identifier le point de rupture du service.

Contexte Un test complexe génère de nombreuses métriques : temps moyen, min, max, percentiles, taux d’erreur et throughput. Le Problème Les résultats sont bruts et difficiles à interpréter. Contraintes Automatiser la génération d’un rapport structuré incluant toutes les métriques clés et une synthèse indiquant si les seuils définis sont respectés ou non. Livrable attendu Un test de performance produisant un rapport analytique clair facilitant la prise de décision.

Contexte Deux architectures backend différentes exposent le même endpoint GET /metrics. Le Problème Il faut comparer objectivement leurs performances sous charge identique. Contraintes Exécuter un benchmark contrôlé avec le même nombre d’utilisateurs virtuels, la même durée et les mêmes scénarios. Calculer temps moyen, percentile 95 et taux d’erreur pour chaque architecture. Livrable attendu Un test de performance comparatif fournissant des métriques exploitables pour prise de décision technique.

Contexte Un service GET /analytics doit être testé jusqu’à atteindre sa limite maximale de traitement. Le Problème Il faut identifier dynamiquement le seuil où le taux d’erreur dépasse 5% ou où le temps moyen dépasse 2 secondes. Contraintes Augmenter progressivement la charge par paliers. Mesurer à chaque étape le taux d’erreur et le temps moyen. Arrêter le test dès que les seuils critiques sont franchis. Livrable attendu Un test de performance capable d’identifier automatiquement le point de saturation du système.

Contexte Un endpoint critique POST /transactions doit supporter 1000 utilisateurs virtuels répartis sur plusieurs nœuds. Le Problème Le test actuel ne s’exécute que sur une seule instance, ce qui ne reflète pas une charge réaliste. Contraintes Mettre en place une simulation distribuée générant de la charge depuis plusieurs workers. Centraliser les métriques (temps moyen, percentile 95, taux d’erreur) et produire un rapport consolidé. Livrable attendu Un test de performance distribué validant la capacité du système sous forte charge réelle.

Contexte Un service API doit rester fonctionnel même avec une latence réseau accrue. Le Problème Il faut simuler une augmentation artificielle de latence et observer l’impact sur les performances. Contraintes Introduire un délai contrôlé entre les requêtes ou simuler une latence réseau. Mesurer l’évolution des temps de réponse et vérifier que le taux d’erreur reste inférieur à 3%. Livrable attendu Un test de performance évaluant la résilience du système face à une dégradation réseau.

Contexte Un endpoint GET /export est appelé en continu pendant 15 minutes. Le Problème Il faut détecter une éventuelle augmentation progressive des temps de réponse pouvant indiquer une fuite mémoire. Contraintes Exécuter un test longue durée, enregistrer les temps moyens par intervalle et détecter toute tendance ascendante significative. Livrable attendu Un test de performance identifiant des symptômes potentiels de fuite mémoire via analyse temporelle.

Contexte Un système expose plusieurs endpoints : GET /products, POST /orders et GET /profile. Le Problème Il faut simuler un trafic réaliste combinant 70% de lecture et 30% d’écriture. Contraintes Créer un scénario mixte répartissant les appels selon le ratio défini. Mesurer séparément les métriques de chaque endpoint et analyser l’impact global. Livrable attendu Un test de performance reflétant un comportement utilisateur réaliste multi-endpoints.

Contexte Un endpoint GET /reports doit maintenir des performances stables même sous charge. Le Problème Il faut analyser non seulement la moyenne mais aussi les percentiles 90, 95 et 99. Contraintes Collecter tous les temps de réponse, les trier et calculer dynamiquement les percentiles requis. Vérifier que le percentile 99 reste sous 2500 ms. Livrable attendu Un test de performance fournissant une analyse complète des percentiles critiques.

Contexte L’infrastructure est censée s’auto-scalER en fonction de la charge sur GET /data. Le Problème Il faut vérifier que l’augmentation du nombre d’utilisateurs virtuels entraîne une amélioration ou stabilisation du temps moyen grâce au scaling. Contraintes Simuler une montée rapide de charge, observer les métriques avant et après scaling, puis comparer les temps moyens. Vérifier que la dégradation reste contrôlée. Livrable attendu Un test de performance validant le comportement d’élasticité de l’infrastructure.

Contexte Le système doit supporter des pics soudains de trafic sur POST /checkout. Le Problème Il faut simuler un spike brutal de 0 à 500 utilisateurs en quelques secondes. Contraintes Implémenter un scénario de spike testing avec montée instantanée. Mesurer le taux d’erreur, le temps moyen et la récupération après le pic. Livrable attendu Un test de performance validant la capacité du système à absorber et récupérer après un pic de charge.