Types de tests

Tests de performance : voyez ralentir vos parcours avant vos clients

Une page qui met six secondes à répondre ne déclenche aucune alerte technique. Elle fait juste partir l’utilisateur. Mr Suricate mesure le temps réel de vos parcours, étape par étape, aussi souvent que vous le décidez.

Mesure en conditions réellesWeb, mobile et APIAlerte au dépassement de seuil

Tableau de bord de performance dans Mr Suricate : LCP et FCP mesurés sur six mois avec leurs seuils

Ils nous font confiance

3 M exécutions de scénarios par mois100+ clients15 types de tests couverts

Retail, banque, industrie, transport, services. Hébergement dans l’Union européenne, support francophone, accompagnement humain au démarrage.

En bref

Un test de performance mesure le temps réellement passé par un utilisateur sur chaque étape d'un parcours, pas le score d'une page isolée. Rejoué régulièrement sur les mêmes scénarios que les tests fonctionnels, il permet de comparer une semaine à l'autre et de situer précisément la dégradation.

Une application lente reste une application qui fonctionne

C’est ce qui rend le sujet difficile. Rien n’est en erreur, la supervision est au vert, et pourtant le tunnel de commande met trois fois plus de temps qu’il y a un mois. La dégradation est progressive, personne ne la remarque de l’intérieur, et elle se lit d’abord dans le taux d’abandon. Un test de performance automatisé la rend visible pendant qu’elle s’installe.

Icône souris

Le temps du parcours, pas celui du serveur

Ce qui compte, c’est la durée entre le clic et l’écran réellement utilisable. Elle se mesure sur le parcours complet, étape par étape.

Icône de rectangles violets

Vous fixez le temps acceptable pour chaque étape. Le dépassement déclenche une alerte, pas un rapport de plus.

Icône d'engrenage violet

La dérive dans le temps

Chaque exécution est comparable à la précédente. Une dégradation de 20 % étalée sur trois semaines se voit dans la courbe.

Icône de test API violet

Les mêmes scénarios tournent en pré-production et en production, aux heures de charge réelles de votre activité.

La mesure s'accroche à vos environnements réels

Vos mesures de performance se déclenchent depuis votre CI, s’exécutent sur vos environnements réels et remontent là où vos équipes travaillent déjà. Rien à réoutiller.

1 Déclenchement Vos outils gardent la main
  • GitLab
  • Jenkins
  • Microsoft Azure
  • Appel API
  • Planification
2 ExécutionMr Suricatevos scénarios tournent sur vos environnements réels
  • Parcours web
  • Applications natives iOS et Android
  • Fermes de mobiles réelles
  • API et flux internes
3 Restitution Le résultat arrive où vous travaillez
  • Jira
  • Slack
  • SMS
  • Webhook
  • API
Et une maintenance qui tient dans le temps
  • Blocs réutilisablesune modification met à jour tous les scénarios qui l'utilisent
  • Réparation assistée par IAdes correctifs proposés sur les scénarios en erreur
  • Regroupement des incidentsles anomalies similaires sont traitées une seule fois

Ce que change la mesure continue, ligne par ligne

Sans mesure continue
Avec Mr Suricate
La lenteur remonte par le service client.
Elle remonte au dépassement du seuil.
On mesure au moment où le problème est déjà installé.
La mesure tourne en continu, y compris aux heures de charge.
Un audit de performance donne une photo à un instant.
Vous avez la courbe, semaine après semaine.
Le débat porte sur des ressentis.
Il porte sur des durées, étape par étape.
On optimise la page d'accueil, qui n'est pas le problème.
L'étape la plus lente du parcours est identifiée.
La performance est un chantier ponctuel.
C'est une ligne de votre reporting hebdomadaire.
RésultatLe temps de réponse de chaque étape critique, mesuré en continu et comparable d'une semaine à l'autre.

Ce que la mesure couvre

Temps de réponse mesuré étape par étape sur un parcours réel
Comparaison d'une exécution à l'autre, semaine après semaine
Alerte au dépassement du seuil que vous fixez
Mesure sur les mêmes scénarios que vos tests fonctionnels

Ce que ce n'est pas

Un audit technique de page isolée
Une mesure de l'audience réelle chez vos utilisateurs
Un profilage de code ou une analyse serveur
Un tir de charge

Ces mesures s'appuient sur les mêmes scénarios que vos tests fonctionnels. Le même parcours sert à mesurer un temps de réponse, à encaisser un tir de charge et à assurer le monitoring de production : un seul jeu de parcours à entretenir, pas trois.

temps de réponse, parcours critique, monitoring de production : les définitions sont dans le glossaire QA.

Les indicateurs, en langage métier

Temps avant écran utilisable

Le délai entre le clic et le moment où l’utilisateur peut réellement agir. Ce n’est pas le moment où le serveur a répondu.

Temps de réponse d’une étape

La durée d’une action précise du parcours : ajouter au panier, valider un formulaire, charger un résultat de recherche.

Seuil

Le temps que vous jugez acceptable sur une étape. Au-delà, une alerte part, sans qu’il faille lire un tableau de bord.

Dérive

L’écart entre l’exécution du jour et les précédentes, sur la même étape. C’est elle qui révèle une dégradation lente.

Les autres termes du test automatisé sont définis dans le glossaire QA.

LIVRE BLANC · AUTOMATISATION DES TESTSEt si vos bugs ne coûtaient plus rien à votre business ?Le vrai coût d’une page lente, et comment bâtir une stratégie de test qui tient dans la durée.
Télécharger le livre blanc
“ Mr Suricate est une évidence, car il donne l'assurance qu'il n'y a pas de problème. Un seul bug découvert suffit à rentabiliser la solution pendant une année entière ! ”

Anthony CornevinE-commerce Platform Manager, Vertbaudet

Vous fixez les seuils, nous outillons la mesure

Avec Mr Suricate, votre équipe QA n’est pas remplacée, elle est renforcée. Vous choisissez ce que vous internalisez et ce que vous déléguez : la création des scénarios, leur exécution, ou leur maintenance dans le temps.

  1. 1Identification des parcours critiques, front et back
  2. 2Écriture des tests, sans code
  3. 3Supervision continue et alertes
  4. 4Maintenance et évolution des scénarios
Résultatvous gagnez en couverture sans alourdir la charge de vos équipes. Et si vous préférez tout déléguer, l'externalisation QA prend le relais.

VOS QUESTIONS

Questions fréquentes

Ce que les équipes nous demandent le plus souvent sur la mesure de performance.

Quelle différence entre test de performance et tir de charge ?

Le test de performance mesure le temps de réponse d'un parcours dans les conditions normales d'usage, en continu. Le tir de charge, lui, cherche le point de rupture en simulant un afflux massif d'utilisateurs simultanés. Les deux sont complémentaires et se traitent séparément.

Que mesure exactement Mr Suricate ?

La durée réelle de chaque étape d'un parcours joué comme un utilisateur : temps de chargement, temps de réponse d'une action, temps avant qu'un écran soit utilisable. La mesure porte sur le parcours métier, pas sur une métrique serveur isolée.

Peut-on mesurer la performance en production ?

Oui, et c'est même le cas le plus utile. Les mêmes scénarios tournent en pré-production et en production, aux heures de charge de votre activité. Sur des données de production, la règle est de n'utiliser que des données créées pour les tests.

Comment est-on prévenu quand un seuil est dépassé ?

L'alerte part sur le canal que vous avez défini pour le scénario concerné : e-mail, Slack, SMS ou webhook vers votre propre outil. Les scénarios critiques peuvent avoir un canal et un délai différents des autres.

Les applications mobiles sont-elles couvertes ?

Oui. Les applications natives iOS et Android sont jouées sur des fermes de terminaux réels, ce qui permet de mesurer le temps de réponse sur les modèles et les versions d'OS réellement utilisés par vos clients.

Quelles mesures sont remontées ?

Les indicateurs de chargement suivis dans le temps : réception du premier octet, début d’affichage, fin de chargement du plus gros élément, stabilité visuelle. Chacun est comparé à son seuil, et le tableau de bord montre la répartition des pages qui le respectent ou non.

Peut-on faire échouer un test sur un temps de réponse ?

Oui. Un seuil de performance se déclare dans la configuration du scénario, en millisecondes, et s’applique aux requêtes dont l’URL commence par un motif donné. Au-delà du seuil, l’étape tombe en échec comme n’importe quelle assertion.

Que récupère un développeur pour diagnostiquer ?

L’archive HAR de l’exécution, qui contient le détail des requêtes réseau. Elle se rejoue dans les outils du navigateur, ce qui évite d’avoir à reproduire le problème à la main. Les temps de chargement du rapport d’exécution sont aussi triables.

Est-ce la même chose qu’un audit de performance ?

Non, et la différence compte. Un audit donne une note à un instant donné. Ici la mesure est prise à chaque exécution planifiée, sur le parcours réel de vos utilisateurs, ce qui permet de voir la dérive plutôt qu’un point isolé.

Vous ne croyez que ce que vous voyez ?

Une démo de 30 minutes sur votre propre application. Vous verrez un de vos parcours automatisé en direct, sans écrire de code.