Dépannage des tests de charge

Cherchez le message ou le symptôme que vous voyez, puis lisez pourquoi il apparaît et quoi faire. Chaque entrée renvoie à la page qui donne tous les détails. Les messages sont cités tels que l'application les affiche.

Le test ne démarre pas

"Failed to start test"

Ce que vous voyez : une boîte de dialogue intitulée Failed to start test avec le texte "Please try again. If you still encounter an error please contact us."

Pourquoi : LoadFocus n'a pas pu lancer l'exécution, et la raison n'était aucune des limites de forfait décrites plus bas.

Que faire : relancez le test. Une exécution que LoadFocus n'a pas pu démarrer ne compte pas dans les exécutions de votre forfait (voir la dernière section de cette page). Si l'échec se répète, contactez le support en indiquant le nom du test.

"Limite d'exécutions atteinte"

Ce que vous voyez : la boîte de dialogue des limites affiche Limite d'exécutions atteinte, avec une ligne comme "Votre forfait inclut 30 exécutions de test sur 24 heures. Votre équipe en a utilisé 30." et la date à laquelle la prochaine exécution pourra démarrer. Via l'API, le refus indique une raison comme number-of-daily-tests-exceeded, number-of-weekly-tests-exceeded, number-of-monthly-tests-exceeded ou number-of-yearly-tests-exceeded, avec les compteurs current et maximum.

Pourquoi : votre équipe a utilisé toutes les exécutions que son forfait autorise sur cette période. La limite hebdomadaire ne s'applique qu'aux exécutions lancées via l'API et aux exécutions planifiées, sur Load Free, pendant un essai et sur Load Starter.

Que faire : attendez la date indiquée ou passez à un forfait avec plus d'exécutions. Les exécutions planifiées qui atteignent une limite sont ignorées, et le panneau de planification l'indique. Voir Forfaits et limites et Tests de charge planifiés.

"Votre forfait a atteint le nombre de tests pouvant s'exécuter en même temps."

Pourquoi : un autre test de votre équipe est encore en cours et votre forfait n'en autorise pas davantage en même temps.

Que faire : attendez la fin du test en cours ou arrêtez-le. Voir Forfaits et limites.

Refus pendant l'essai : "Vous avez utilisé les exécutions de votre essai", "Ce test demande plus d'utilisateurs virtuels", "Ce site demande un forfait payant"

Pourquoi : pendant l'essai gratuit de 7 jours d'un forfait payant, les tests tournent avec des limites réduites : 50 utilisateurs virtuels, des tests de 5 minutes maximum et 3 exécutions sur 24 heures, tests cloud, JMeter et k6 confondus. Un test cloud lancé pendant un essai ne peut pas non plus cibler un site déjà testé en charge depuis un autre essai ou un compte Free.

Que faire : la boîte de dialogue propose de démarrer votre forfait tout de suite, ce qui lève immédiatement les limites de l'essai, ou d'ajouter une carte pour 3 exécutions de plus aujourd'hui. Voir Limites pendant l'essai gratuit de 7 jours.

"Tests gratuits épuisés pour ce site web"

Pourquoi : tous les comptes Free réunis disposent de 3 tests par jour et 10 par an pour un même site web, et ce quota partagé est épuisé. Il ne s'applique qu'une fois qu'un autre compte a testé ce site sur la même période.

Que faire : la boîte de dialogue indique quand vous pourrez de nouveau tester le site gratuitement. Vos autres sites web ne sont pas concernés, et les forfaits payants n'ont pas de quota partagé. Voir Limites de l'offre Free.

"The test cannot run because the URL fields contain private IP addresses."

Pourquoi : une URL de requête pointe vers localhost, vers une adresse privée comme 192.168.x.x ou 10.x.x.x, ou vers un nom d'hôte qui se résout en une telle adresse. Les générateurs de charge tournent dans le cloud et ne peuvent pas joindre votre réseau interne.

Que faire : testez une URL publique, ou exposez le serveur local avec un tunnel. Voir Qu'est-ce qu'une URL valide pour un test de charge et Comment tester la charge d'un site web ou d'une API hébergé localement.

Le test démarre mais échoue

Un test k6 se termine en FAILED sans résultats

Ce que vous voyez : la liste des tests k6 affiche FAILED et la page de résultats ouvre une boîte de dialogue Test run failed.

Pourquoi : le script a échoué avant d'envoyer la moindre charge : une erreur de syntaxe, un import impossible à charger (comme une extension k6/x/...) ou un setup() qui lève une exception ou dépasse son délai. Un teardown() qui échoue après le test ne fait pas échouer l'exécution.

Que faire : lancez le script en local avec k6 run pour trouver l'erreur, corrigez-la et importez le script de nouveau. Le journal k6 se trouve dans l'onglet Journaux. Voir Analyse des résultats de test de charge k6.

Un test JMeter échoue ou envoie moins de requêtes que prévu

Ce que vous voyez : une boîte de dialogue Test run failed avec "Please try again. There were errors reported during the test run." et un extrait du log JMeter, ou une exécution qui se termine avec bien moins d'échantillons que prévu.

Pourquoi : JMeter a signalé des erreurs en exécutant votre script, par exemple un plugin manquant, un groupe de threads mal configuré ou un fichier CSV que le script lit mais qui n'a pas été importé.

Que faire : ouvrez l'onglet Journaux, lisez le Journal JMeter et cherchez-y ERROR et WARN. Voir Analyse des fichiers de log JMeter et Analyse des logs et fichiers JTL.

Les résultats semblent faux

L'écran de démarrage indique qu'une requête de test a été refusée

Ce que vous voyez : pendant le démarrage d'un test cloud, un avertissement comme "Cloudflare a refusé une requête de test vers example.com envoyée depuis AWS us-east-1. Votre test de charge risque d'être bloqué de la même façon."

Pourquoi : au démarrage d'une exécution cloud, LoadFocus envoie une requête vers la racine du site depuis la région de l'exécution. Un CDN ou l'edge de l'hébergeur placé devant le site l'a refusée. Il s'agit d'une seule requête sans les identifiants de votre test : c'est un indice, pas un verdict, et l'exécution continue.

Que faire : surveillez le taux d'erreur de l'exécution. Si les résultats affichent ensuite l'avis de filtrage décrit plus bas, autorisez le trafic du test dans les réglages de pare-feu ou de protection anti-bots de cette plateforme.

"... filtre probablement le trafic du test."

Ce que vous voyez : dans la vue d'ensemble des résultats d'un test cloud terminé, un avis comme "Vercel filtre probablement le trafic du test." ou "Ce site semble limiter ou bloquer le trafic du test."

Pourquoi : au moins 20 % des requêtes se sont terminées par 403, 429, 430 (503 sur Cloudflare) ou par une connexion coupée ou en échec, ce que produisent la protection anti-bots, la protection DDoS et les limites de débit. Les chiffres décrivent cette protection, pas votre site.

Que faire : autorisez le trafic du test avec les plages d'adresses IP à autoriser, ou testez un environnement de préproduction avec une protection assouplie. Voir Erreurs par type et taux d'erreur.

"Générateur de charge proche de sa capacité - considérez les temps de réponse comme une borne inférieure"

Pourquoi : au moins un générateur de charge a atteint 80 % de CPU ou plus pendant l'exécution, donc les temps de réponse incluent du temps où le générateur attendait son propre CPU.

Que faire : répartissez les utilisateurs sur plus de générateurs de charge ou d'emplacements, retirez du script le travail coûteux par requête et relancez le test. Voir Saturation du générateur de charge.

Erreurs de connexion : ConnectException, HttpHostConnectException, délais dépassés

Ce que vous voyez : des lignes dans l'onglet Erreurs comme HttpHostConnectException ou SocketTimeoutException, ou "Le nom d'hôte n'a pas pu être résolu (DNS)." dans les explications des codes de réponse.

Pourquoi : les générateurs de charge n'ont pas pu ouvrir de connexion ou n'ont reçu aucune réponse : l'hôte est hors service, le nom ne se résout pas depuis internet, ou un pare-feu rejette le trafic des générateurs.

Que faire : vérifiez que l'URL fonctionne depuis l'extérieur de votre réseau et ajoutez les plages d'adresses IP de LoadFocus à votre pare-feu ou WAF. Si les erreurs ne commencent qu'à partir d'un certain nombre d'utilisateurs, c'est une limite de capacité : comparez-les à la courbe des utilisateurs virtuels. Voir Erreurs par type et taux d'erreur.

Erreurs HTTPS : SSLException, SSLHandshakeException

Ce que vous voyez : SSLException ou SSLHandshakeException dans l'onglet Erreurs, ou "La connexion sécurisée (TLS) n'a pas pu être établie."

Pourquoi : la négociation TLS a échoué. Les causes courantes sont un certificat expiré, auto-signé ou émis par une autorité privée, une incompatibilité de protocole ou un serveur qui abandonne des négociations sous charge.

Que faire : vérifiez la chaîne de certificats de l'hôte, par exemple avec le SSL Checker gratuit. Si les erreurs augmentent avec le nombre d'utilisateurs, le serveur peine à suivre les négociations. Voir Différences entre HTTP et HTTPS.

Une ancienne exécution est marquée "Expiré" et ses graphiques sont vides

Pourquoi : les résultats bruts de plus d'un an sont supprimés. L'exécution reste dans votre liste, mais ses graphiques n'ont plus de données. Les exécutions définies comme référence conservent leurs résultats bruts.

Que faire : rien à corriger. Voir Combien de temps LoadFocus conserve vos données.

Les exécutions qui ne comptent pas

• Une exécution que LoadFocus n'a pas pu démarrer ne compte pas dans les limites d'exécutions de votre forfait.
• Une exécution de test cloud terminée sans envoyer une seule requête ne compte pas non plus, jusqu'à deux exécutions de ce type par jour.
• Une exécution que vous arrêtez vous-même compte toujours, même si elle n'a pas encore envoyé de charge.

Voir Tests de charge planifiés pour savoir comment les exécutions planifiées ignorées sont signalées.