Associer les outils de test de performance d'API aux trois questions
Capacité → générateurs de charge
Groupes de threads, montée en charge progressive, workers distribués.
À exécuter avant les releases et après les changements d'architecture. Coûteux en exécution continue.
Régression → comparaison des temps de réponse
Demande une base de référence et un écart, pas une forte concurrence.
La moins coûteuse des trois, et la plus souvent absente.
Exactitude → vérification fonctionnelle
Des assertions sur les corps de réponse, y compris face à des entrées inhabituelles.
Le socle sur lequel reposent les deux autres.
La catégorie qui manque à la plupart des équipes
Presque toutes les équipes qui disent faire du test de performance possèdent un générateur de charge. Très peu disposent de quoi que ce soit qui surveille la régression à chaque changement. C'est l'inverse de ce que dictent le coût et le rendement.
La capacité évolue rarement d'une release à l'autre : la tester en continu n'apprend pas grand-chose. La régression de performance, elle, arrive une pull request à la fois, et quand un test de capacité trimestriel finit par la détecter, vous vous retrouvez devant six mois de commits sans savoir lequel a introduit la requête non indexée.
Ce qu'il faut regarder dans chaque catégorie
Générateurs de charge : pouvez-vous poser des assertions sur les corps de réponse, au moins sur un échantillon. La plupart le permettent et peu d'équipes l'activent, et c'est ainsi qu'un test de charge affiche un résultat impeccable alors que toutes les réponses sont vides.
Outillage de régression : compare-t-il à votre propre historique plutôt qu'à un seuil absolu. Des objectifs empruntés ailleurs ne vous apprennent rien sur votre produit.
Vérification fonctionnelle : couvre-t-elle les cas limites. Une requête qui se dégrade avec une taille de page élevée est un problème structurel que vous trouverez ici bien avant qu'un test de capacité ne le fasse apparaître.
Lire un percentile honnêtement
Les outils de performance rapportent des percentiles, et on les lit couramment de travers, d'une manière qui masque justement le problème recherché.
Un p50 qui paraît bon décrit la requête médiane et ne dit rien de l'expérience des malchanceux. Un p99 qui paraît bon sur un endpoint appelé mille fois par heure représente tout de même dix requêtes lentes par heure, soit dix utilisateurs agacés. Quant à une moyenne calculée sur l'ensemble des endpoints, elle n'a presque aucun sens, puisqu'elle mélange un health check et une génération de rapport.
Deux habitudes règlent l'essentiel. Regardez les percentiles par endpoint plutôt qu'en agrégat, et regardez le p95 et le p99 plutôt que la moyenne. Les endpoints qui comptent tiennent en général sur une courte liste, et suivre ces quatre chiffres dans le temps est plus utile que n'importe quel tableau de bord qui affiche tout d'un coup.
L'ordre qui fait économiser
L'exactitude, puis la régression, puis la capacité. Soumettre à une charge un endpoint qui renvoie le mauvais résultat produit un chiffre assuré qui ne mesure rien, et c'est ainsi qu'un programme de performance gâche le plus souvent son premier trimestre.
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 du CLI se trouve dans le dépôt CLI.
Les sessions, les valeurs capturées, l'ordonnancement et le nettoyage sont traités dans la documentation sur les tests d'API.
Deux voies possibles, et le choix tient surtout à qui possède le pipeline. Connecter la GitHub App depuis le tableau de bord n'exige aucune modification de votre dépôt, puisqu'elle réagit au déploiement que votre build produit déjà. Ajouter une étape GitHub Actions place le contrôle dans le dépôt, où il est relu comme le reste du build.
Ce qu'apporte TestSprite
La colonne exactitude, c'est-à-dire le socle des deux autres. Il pose ses assertions sur les corps de réponse plutôt que sur les codes de statut, couvre les cas limites qui font apparaître les lenteurs structurelles, et s'exécute à chaque pull request.
La couverture est générée à partir d'une passe de découverte et de votre spécification. Auto-Authentication maintient les sessions actives pendant toute l'exécution, Dynamic Variables transporte les valeurs d'un appel à l'autre, Dependency Chains déduit l'ordre d'exécution, et Auto-Cleanup supprime exactement ce que l'exécution a créé.
L'intérêt, c'est que vos chiffres de capacité décrivent enfin un service qui fonctionne. Une requête qui se dégrade avec une taille de page élevée apparaît ici pour une fraction de ce que coûte sa découverte lors d'un test de charge, et un endpoint qui renvoie discrètement des résultats vides cesse d'afficher de bons chiffres de débit.
TestSprite entre-t-il dans cette catégorie ?
Dans la colonne exactitude. Il vérifie le comportement, cas limites compris, et ne génère pas de charge soutenue.
Un seul outil peut-il couvrir les trois ?
Certains le prétendent. En pratique, générer de la charge et poser des assertions poussées sur les corps de réponse tirent dans des directions opposées, car les assertions coûtent du débit au générateur.
Quel seuil de régression est raisonnable ?
Fixez-le à partir de votre propre variance. Si vos chiffres bougent de dix pour cent d'une exécution à l'autre sur un environnement calme, un seuil de cinq pour cent n'est que du bruit.
Avons-nous besoin d'une génération de charge distribuée ?
Seulement lorsqu'un générateur unique devient le goulet d'étranglement. Beaucoup d'équipes achètent une capacité distribuée qu'elles ne saturent jamais.
Où exécuter chacun d'eux ?
L'exactitude et la régression à chaque pull request. La capacité avant les releases et après les changements d'architecture.
Trois questions, trois instruments.
Les outils de test de performance d'API se répartissent entre générateurs de charge, comparaison de régression et vérification fonctionnelle. La plupart des équipes ont le premier et n'ont pas la deuxième, et l'exactitude est le socle des deux.