Les deux familles d'outils de test de performance UI
Laboratoire, synthétique
Charger une page dans des conditions contrôlées et lui attribuer un score.
Reproductible et comparable. Mesure un environnement vierge, avec des données vierges.
Terrain, utilisateurs réels
Collecter les temps mesurés au cours de sessions réelles.
Fidèle à la réalité. Vous prévient une fois que quelqu'un en a déjà fait les frais.
Ce qui passe entre les deux
Les outils de laboratoire s'exécutent sur un environnement de test, donc sur un petit jeu de données. Les outils de terrain voient les volumes de données réels, mais ne signalent rien tant qu'un utilisateur réel n'en a pas fait les frais. Résultat : un écran rapide avec dix lignes et inutilisable avec deux mille passe le laboratoire et ressort sur le terrain, soit l'ordre le plus défavorable possible.
Combler cet écart ne demande pas une nouvelle catégorie d'outils. Il faut un compte pré-rempli à la taille d'un gros client, et les mêmes parcours exécutés dessus avant la mise en production.
Choisir au sein de chaque famille
Outils de laboratoire : privilégiez ceux qui mesurent la latence des interactions, et pas seulement le chargement initial. Le chargement est un coût unique par session, l'interaction est permanente.
Outils de terrain : vérifiez si vous pouvez segmenter par taille de compte. Une moyenne sur l'ensemble des clients masque précisément ceux qui souffrent.
Les deux : comparez à votre propre historique plutôt qu'à un score absolu. Les seuils empruntés ailleurs se transposent rarement d'un produit à l'autre.
Segmenter les données de terrain pour qu'elles veuillent dire quelque chose
La surveillance des utilisateurs réels est la plus honnête des deux familles, et il est facile de la rendre inutile en regardant le mauvais agrégat.
Une moyenne sur tous les utilisateurs mélange un client à cinquante enregistrements et un client à cinquante mille, alors que le second porte tout le signal. Il en va de même lorsque l'on mélange les appareils, les zones géographiques, ou vos utilisateurs internes et vos clients. Le chiffre global peut s'améliorer pendant que vos plus gros comptes se dégradent régulièrement : c'est le mode de défaillance qui coûte des renouvellements.
Segmentez selon la dimension sur laquelle votre produit varie réellement, qui, pour la plupart des logiciels professionnels, est la taille du compte plutôt que l'appareil ou le réseau. Si l'outillage ne sait pas segmenter ainsi, le chiffre qu'il remonte ne mesure pas ce qui vous importe.
Le prérequis que personne ne mentionne
Un écran qui s'affiche instantanément parce que la requête a échoué en silence obtiendra un excellent score dans un outil de laboratoire. L'exactitude du comportement est le socle de toute mesure de performance, et la vérifier coûte moins cher que n'importe lequel des outils ci-dessus.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
La même configuration est disponible dans le tableau de bord TestSprite si vous préférez ne rien installer en local. Le reste des commandes CLI se trouve dans le dépôt CLI.
Où chacun s'exécute
Les outils de laboratoire dans le pipeline, sur chaque pull request, en comparaison avec votre référence. La surveillance de terrain, toujours active. La vérification fonctionnelle sur un compte de taille réaliste, à chaque modification elle aussi, car c'est là l'écart que les deux autres laissent ouvert.
Le déclencheur compte plus que le mécanisme. En le branchant sur votre événement de déploiement, chaque modification est vérifiée sans que personne ait à le décider ; la GitHub App le fait depuis le tableau de bord, et une étape GitHub Actions le fait depuis l'intérieur de votre workflow.
La place de TestSprite entre laboratoire et terrain
Dans l'écart que les deux laissent ouvert : exécuter de vrais parcours sur un environnement aux données réalistes, avant la mise en production. La couverture est générée à partir de votre produit et s'exécute à chaque modification, si bien qu'un écran qui fonctionne avec dix lignes et casse avec deux mille est détecté par son comportement plutôt que par un centile.
TestSprite couvre aussi le prérequis qu'aucune des deux familles ne vérifie. Une page qui s'affiche instantanément parce que la requête a échoué est rapide et fausse, et un score de laboratoire ne vous le dira pas.
L'outillage de laboratoire continue de mesurer les temps de chargement et d'interaction, la surveillance de terrain continue de rapporter ce qu'ont vécu les utilisateurs. L'intérêt, ici, est que la défaillance qui n'apparaît qu'au volume de données de votre plus gros client soit trouvée avant que ce client ne la trouve.
TestSprite fait-il partie de cette catégorie ?
Non. Il vérifie que les parcours se comportent correctement, ce qui est le prérequis pour qu'une mesure de performance ait le moindre sens.
Faut-il à la fois des outils de laboratoire et des outils de terrain ?
Oui. Le laboratoire vous donne un signal reproductible avant la mise en production, le terrain vous dit ce qui s'est réellement passé. Aucun des deux ne suffit à lui seul.
Et la surveillance synthétique ?
Un outil de laboratoire braqué sur la production à intervalles réguliers. Utile pour la disponibilité, et il s'exécute toujours sur les données dont dispose le compte utilisé.
Quelle taille doit avoir un compte de test pré-rempli ?
Celle de votre plus gros client réel. En deçà, vous testez un cas qui n'existe pas en production.
Les scores de performance doivent-ils bloquer les fusions ?
Une forte régression par rapport à votre propre référence, oui. Un seuil de score absolu, généralement non, car il suit le benchmark plutôt que votre produit.
Le laboratoire est trop propre, le terrain arrive trop tard.
Les outils de test de performance UI relèvent du laboratoire ou du terrain, et les deux passent à côté de la dégradation liée aux volumes de données réels. Pré-remplissez un compte à la taille d'un gros client, exécutez-y vos parcours avant la mise en production, et vérifiez d'abord que le comportement est correct.