Tests de Performance

Aperçu des tests de performance

Un test de performance soumet un nombre défini d’utilisateurs ou de requêtes simultanés à un site Web, une application web ou une API, augmente cette demande selon une courbe planifiée et enregistre ce qui change : les temps de réponse, le débit, le taux d’erreur et la capacité serveur, base de données et réseau utilisée par le système pour suivre. Le résultat est un ensemble de chiffres comparés à une cible, et non une impression de la rapidité ressentie du site.

La cible peut être un site public, un parcours authentifié via un portail ou une application SaaS, une séquence d’appels API, ou une application web interne protégée par un pare-feu.

Le but n’est pas de rendre un site rapide en général. Il est de confirmer que ses pages, flux de travail et appels API les plus importants répondent aux exigences définies aux niveaux de trafic attendus. Un paiement peut fonctionner normalement pour un utilisateur mais ralentir ou expirer lorsque des centaines de clients passent commande simultanément.

Les tests fonctionnels confirment qu’une page ou transaction fonctionne correctement. Les tests de performance mesurent si elle reste rapide, stable et fiable à mesure que le trafic augmente.

Que peut-on tester en performance ?

Les tests de performance couvrent généralement quatre cibles HTTP/S : sites web, applications web, APIs, et applications web internes. Chacune nécessite des scripts et mesures différents.

Pourquoi les tests de performance sont importants

La valeur d’un test de performance est de fournir une réponse spécifique avant que les utilisateurs ne détectent un problème :

• Les goulets d’étranglement apparaissent avant la mise en production. Une requête lente ou une piscine de connexions sous-dimensionnée apparaît dans un rapport de test plutôt que dans la file du support.
• Les plans d’évolution et de montée en charge sont vérifiés. Les règles d’auto-scaling, les paramètres de cache CDN et la taille des instances restent des hypothèses tant que le trafic ne les valide pas.
• Les parcours générant des revenus restent protégés. Connexion, recherche, paiement, téléchargement de fichiers et appels API associés sont les chemins à tester en priorité.
• Les pics d’activité produisent moins de ralentissements, erreurs et pannes. Lancements, campagnes, fenêtres d’inscription et ventes saisonnières suivent souvent des schémas de trafic prévisibles testables en amont.
• Les régressions sont détectées. Les changements de code, API, base de données, infrastructure ou services externes modifient un peu la performance et ces dérives s’accumulent d’une version à l’autre.
• Les décisions de mise en production et les objectifs de service ont des preuves. Un chiffre p95 par rapport à un objectif est plus facile à exploiter qu’une opinion sur la « sensation de lenteur » du site.

Types de tests de performance

Chaque type applique un trafic sous une forme différente pour répondre à une question différente. La plupart des programmes combinent plusieurs types.

Le test d’endurance et le test soak sont deux noms pour un même test, pas deux types différents. Et la frontière entre test de charge et test de stress est celle que les équipes confondent le plus souvent, elle a donc sa propre page : test de charge vs test de stress.

Les tests de performance sont la catégorie globale. Chaque type ci-dessous modifie la quantité de trafic, la vitesse d’arrivée, et la durée.

Tests de performance vs tests de charge

Le test de performance est une pratique plus large d’évaluation de la vitesse, stabilité, scalabilité et utilisation des ressources sous différentes conditions. Le test de charge est un type de test de performance ciblé sur la demande attendue et les pics.

Les termes sont souvent confondus car le test de charge est généralement le premier test de performance effectué par les équipes. D’autres types sont nécessaires pour détecter les points de rupture, la dégradation à long terme ou les problèmes de mise à l’échelle.

Pour une comparaison qui couvre aussi le test de stress, lire tests de performance vs tests de stress vs tests de charge.

Comment réaliser des tests de performance

Les étapes ci-dessous s’appliquent à une page d’atterrissage, un parcours de paiement ou une séquence API authentifiée.

1. Définir l’objectif et les critères d’acceptation

Indiquer ce que le test doit prouver, en chiffres. Exemples : temps de réponse p95 sous 2 secondes pour 1 500 utilisateurs simultanés au paiement ; taux d’erreur inférieur à 0,5 % ; l’API commandes supporte 400 transactions par seconde. Un test sans critère de réussite/échec produit des données mais pas de décision.

2. Modéliser le trafic du site, de l’application ou de l’API

Récupérer les analyses web, journaux d’accès, données APM et prévisions métier. Identifier les pages ou parcours critiques, la répartition du trafic entre eux, le pic de simultanéité, les taux de requêtes, temps de réflexion entre étapes, la répartition géographique et les appels API par session. Les vues de pages ne sont pas des utilisateurs simultanés : 100 000 vues journalières peuvent signifier un pic de quelques centaines de sessions simultanées, le modèle doit préciser lesquelles.

3. Préparer un environnement de test représentatif

Correspondre au mieux possible à la pile web de production, version de l’application, taille de la base, comportement du CDN et du cache, dépendances API, intégrations et règles de montée en charge. Utiliser des comptes test et un bac à sable de paiement sécurisés. Lorsque l’environnement doit différer, documenter la différence pour éviter qu’un résultat soit interprété comme une garantie production.

4. Choisir le type de test et la méthode de test

Sélectionner charge, stress, pic, endurance, volume, scalabilité, ou une combinaison selon l’interrogation de l’étape 1. Puis choisir comment générer le trafic. Les tests HTTP/S envoient directement des requêtes et sont efficaces pour un grand volume contre des pages et APIs. Les tests en vrai navigateur exécutent JavaScript et reproduisent les comportements utilisateurs multisteps, mesurant ainsi ce qu’une personne attend. Beaucoup d’équipes mixent tests protocolaires pour la charge et tests navigateur pour l’expérience utilisateur.

5. Établir une base de référence

Lancer un test contrôlé à charge modérée avant toute modification. Cela confirme que le script s’exécute, que les données sont valides, et que les générateurs de charge ne sont pas le goulet d’étranglement. Enregistrer le résultat et les conditions car des différences de cache, de données ou d’environnement peuvent fausser les comparaisons futures.

6. Lancer le test et surveiller tout le système

Augmenter la demande selon la courbe prévue (rampe régulière, palier, ou pic soudain) plutôt que d’appliquer un nombre d’utilisateurs non expliqué d’un coup. Capturer les données serveur web, application, infrastructure, base de données, réseau et services externes avec les résultats du test. Sans données serveur, vous saurez que c’est devenu lent mais pas pourquoi.

7. Analyser les goulets d’étranglement

Comparer d’abord aux critères d’acceptation. Puis corréler transactions lentes ou erreurs avec CPU, mémoire, base, cache, file d’attente, piscine de connexions, réseau et dépendances sur la même fenêtre temporelle. S’arrêter lorsque le composant et la condition de dégradation peuvent être nommés, pas avec un simple temps moyen de réponse.

8. Corriger, retester et automatiser

Modifier une variable importante à la fois si possible, relancer le même scénario et comparer avec la base. Puis ajouter des petits tests de régression au CI/CD pour que les transactions critiques s’exécutent à chaque build, et programmer les tests plus importants avant les grosses mises en production, campagnes et pics saisonniers.

Principales métriques des tests de performance

Les métriques de test décrivent ce que vivent les utilisateurs. Les métriques système aident à expliquer pourquoi. Les deux sont nécessaires sur les mêmes minutes du test pour identifier la cause.

Les métriques de test identifient des symptômes. Les données serveur, base, et d’observabilité localisent la cause. Les rapports de performance LoadView couvrent le côté test, des graphiques synthétiques jusqu’à un graphe en cascade par session pour tracer une transaction lente jusqu’à une requête spécifique. Mais le côté serveur doit provenir de votre propre monitoring ou APM, synchronisé avec la timeline du test.

Comment lire les résultats d’un test de performance

Quelques schémas se répètent sur la plupart des systèmes web. Aucun ne prouve seul une cause racine, mais chacun indique où enquêter ensuite.

Quand le débit plafonne et le temps de réponse grimpe, le système a probablement atteint sa limite de capacité.

Quand effectuer des tests de performance

Le test de performance n’est pas une tâche unique avant lancement. Déclencheurs utiles :

• En amont de la phase de conception, tant que l’architecture et les parcours clés sont à définir et que les changements sont peu coûteux.
• Après des modifications significatives du code, schéma base, infrastructure ou intégrations, y compris scripts externes et configuration CDN.
• Dans le CI/CD, comme contrôles courts de régression sur les transactions critiques.
• Avant les grosses mises en production, campagnes, pics saisonniers et migrations, au niveau de trafic prévu pour l’événement.
• Après un incident en production, pour confirmer que la correction tient dans les conditions ayant provoqué le problème.
• Selon une cadence régulière, pour détecter toute dérive de performance non expliquée par une version.

Tests de performance vs tests de vitesse de site web

Un test de vitesse charge une page ou une session à un instant donné, généralement sans autre trafic sur le site, et rapporte la durée de chargement. Il est utile pour optimiser le front-end et comparer différentes versions.

Le test de performance applique des niveaux variés de trafic ou utilisateurs simultanés pour observer comment un site, une application ou une API réagit à la croissance de la demande. Les deux mesurent le temps de page ou réponse. Le test de performance ajoute les réponses aux questions que le test de vitesse ne peut pas : combien d’utilisateurs le système supporte, taux d’erreur au pic, où le débit plafonne, et combien de temps le système reste stable. Et une page bien notée au test de vitesse peut toujours échouer à 500 sessions simultanées.

Comment choisir un outil de test de performance

Choisissez un outil de test de charge et de performance cloud selon les tests à réaliser, pas le nombre de fonctionnalités :

• Supporte sites web, applications web multisteps, et protocoles API incluant les flux d’authentification.
• Peut modéliser un trafic réaliste : parcours navigateur, séquences API, temps de réflexion, variation des données, et courbes de charge ajustables.
• Offre une échelle suffisante pour votre pic, depuis des emplacements correspondant à la localisation de vos utilisateurs.
• Supporte les tests protocolaires, en vrai navigateur, ou les deux selon ce qu’il faut mesurer.
• Produit des percentiles exploitables, une répartition des erreurs, résultats par transaction, et rapports partageables avec ceux n’ayant pas effectué les tests.
• S’intègre au CI/CD et à vos outils de monitoring ou d’observabilité pour la partie serveur.
• Supporte les applications internes derrière un pare-feu.
• Est maintenable par les personnes qui créeront et relanceront les tests.

Bonnes pratiques des tests de performance

• Commencez par une question métier ou technique précise, puis concevez le test qui y répond.
• Construisez les charges à partir d’analyses, logs, et prévisions plutôt que d’estimations.
• Testez les transactions clés : connexion, recherche, paiement, pas seulement la page d’accueil.
• Utilisez des volumes de données réalistes et des environnements proches de la production autant que possible, en documentant les différences.
• Distinguez les problèmes du système testé des limites des générateurs de charge. Vérifiez CPU et réseau des générateurs avant d’incriminer l’application.
• Suivez ensemble percentiles, erreurs, débit et ressources serveur sur la même fenêtre test.
• Modifiez une variable principale à la fois lors du diagnostic des améliorations.
• Conservez une base de référence et comparez le même scénario après chaque modification.
• Incluez les dépendances externes et la latence géographique lorsqu’elles impactent le parcours utilisateur, puisque les utilisateurs réels ne les ignorent pas.

Tests de performance avec LoadView

LoadView est une plateforme cloud de tests de charge pour mesurer la performance de sites web, applications web multisteps et APIs sous trafic. La charge vient d’un cloud géré, sans infrastructure de génération de charge à construire ni maintenir.

Quand le volume de requêtes est la question, les tests HTTP/S envoient des milliers de requêtes simultanées et reportent temps de réponse, débit et erreurs par point de terminaison. Quand le parcours utilisateur est la question, le test de charge d’applications web exécute des scripts dans de vrais navigateurs, intégrant ainsi JavaScript et rendu aux mesures. Les scripts sont enregistrés avec EveryStep Web Recorder en cliquant une fois sur le parcours. Le test de charge API couvre les points REST et SOAP, y compris les séquences d’appels authentifiés et multisteps.

Les courbes de charge sont ajustables : une courbe par paliers augmente progressivement les utilisateurs concurrents sur une période définie, une courbe par objectif génère un taux de transaction demandé dans un intervalle fixe, et une courbe dynamique ajustable permet aux équipes de modifier la charge pendant le test. Le trafic peut provenir de plus de 40 zones du réseau géographiquement distribué, intégrant donc latence régionale et comportement CDN aux résultats.

Les rapports montrent le plan d’exécution, transactions par minute, temps de réponse, erreurs par type, avec un graphe en cascade pour chaque session afin de tracer une transaction lente jusqu’à une requête. LoadView s’intègre à Jenkins, Azure DevOps, et CircleCI. Jenkins et CircleCI peuvent utiliser un seuil de sessions échouées pour signaler un build lorsque le pourcentage dépasse la limite autorisée. Les applications internes peuvent être testées via des IP statiques whitelistées ou un injecteur de charge installé localement avec tests derrière le pare-feu.

FAQ sur les tests de performance