Les trois questions que recouvrent les tests de performance des API
| Capacité | Quel volume de trafic simultané avant que la latence ne se dégrade. Exige un générateur de charge. À exécuter avant les mises en production et après les changements d'architecture. |
| Régression | Si cette pull request a rendu un appel plus lent qu'avant. Exige une base de référence et une comparaison, pas une forte concurrence. |
| Exactitude | Si la réponse est correcte, y compris avec des entrées inhabituelles. Exige des assertions sur le corps des réponses. La moins coûteuse des trois, et celle qu'on saute le plus souvent. |
Pourquoi la régression est celle qu'il faut automatiser en premier
Les tests de capacité coûtent cher à exécuter et leurs résultats bougent rarement d'une version à l'autre. La régression de performance, c'est l'inverse : elle s'installe progressivement, une pull request après l'autre, et quand un test de capacité finit par la détecter, vous avez devant vous six mois de changements accumulés sans savoir lequel est en cause.
Une simple comparaison des temps d'appel avec une base de référence, exécutée à chaque modification, repère la requête dix fois plus lente le jour même où elle arrive. Cela vaut mieux qu'un rapport de capacité trimestriel.
Le socle de l'exactitude
Aucun chiffre de latence n'a de sens si les réponses sont fausses. Un endpoint qui renvoie un tableau vide est extrêmement rapide. Cela paraît évident, et c'est exactement ainsi qu'un service part en production avec un filtre cassé et d'excellentes courbes de latence.
L'ordre est donc : exactitude, puis régression, puis capacité. La plupart des équipes procèdent à l'envers, parce que le test de capacité est celui qui ressemble à du travail de performance.
Ce qu'apporte une couverture générée
Les plans de test d'API comprennent des cas aux limites et des cas de type stress, qui font apparaître les combinaisons d'entrées rendant un endpoint lent pour une raison structurelle plutôt que pour une raison de charge. Une requête qui se dégrade avec une taille de page élevée se manifestera ici bien avant qu'un test de capacité ne la trouve.
Ce n'est pas un test de charge, et cela n'en remplace pas un. C'est la couche peu coûteuse qui se trouve en dessous.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
Si vous préférez ne rien installer, le tableau de bord fait la même chose. Tout ce que la ligne de commande sait faire par ailleurs se trouve dans le dépôt CLI.
La session, l'état, l'ordre d'exécution et le nettoyage sont traités dans la documentation des tests d'API.
Où se cache généralement la régression
Quand un endpoint ralentit d'une version à l'autre, la cause est presque toujours l'une de ces trois choses, et les connaître raccourcit considérablement la recherche.
Une requête qui a perdu son index, ou qui a gagné une condition que l'index ne couvre pas. C'est de loin le cas le plus fréquent, et il produit un changement invisible dans le diff, parce que le SQL a l'air correct.
Un appel qui ne faisait qu'un aller-retour et en fait désormais plusieurs, en général parce qu'une fonction utilitaire s'est mise à récupérer les enregistrements liés un par un dans une boucle. Le code se lit mieux qu'avant, et c'est ainsi qu'il passe la revue.
Quelque chose qui a grossi. Une réponse qui contient une collection comptant hier cinq entrées et aujourd'hui cinq cents, parce que le produit a marché. Rien n'est cassé, et l'endpoint est maintenant lent pour tout le monde.
Cadence
Deux options, et le choix tient surtout à qui est responsable du pipeline. Connecter la GitHub App depuis le tableau de bord ne demande aucune modification de votre dépôt, puisqu'elle réagit au déploiement que votre build émet 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 que TestSprite couvre parmi les trois
La troisième, l'exactitude, ainsi que les cas aux limites qui révèlent les lenteurs structurelles. Une requête qui se dégrade avec une taille de page élevée apparaît comme un cas aux limites en échec ou lent bien avant qu'un test de capacité n'y arrive, et pour une fraction du coût.
La couverture provient d'API Discovery et de votre spécification, avec des plans couvrant les catégories fonctionnelle, schéma, autorisation, gestion des erreurs et cas aux limites. Auto-Authentication maintient les sessions actives tout au long d'une exécution, Dynamic Variables transporte les valeurs d'un appel à l'autre, Dependency Chains déduit l'ordre d'exécution de ce que chaque cas exige et produit, et Auto-Cleanup supprime exactement ce que l'exécution a créé.
Vous obtenez la couche qui manque à la plupart des programmes de performance : quelque chose qui s'exécute à chaque pull request et qui remarquerait un endpoint renvoyant des résultats vides, c'est-à-dire la panne qu'un graphique de débit qualifie d'excellente.
TestSprite mesure-t-il la latence ?
Il vérifie l'exactitude, pas la capacité. Les temps de réponse et le débit sous concurrence soutenue exigent un outil de performance dédié.
Qu'est-ce qu'une base de référence raisonnable ?
Vos propres chiffres précédents, sur le même environnement. Des objectifs absolus empruntés à d'autres produits ne vous apprennent pas grand-chose.
Les tests de performance doivent-ils bloquer un merge ?
Une grosse régression sur un chemin critique, oui. Une petite variation, non, sinon vous passerez votre temps à ajuster des seuils au lieu de livrer.
Pourquoi nos chiffres varient-ils autant ?
En général, un environnement partagé, un cache froid ou un volume de données différent. Maîtrisez ces facteurs avant d'accorder du crédit à la moindre comparaison.
Un seul outil peut-il couvrir les trois ?
Certains le prétendent. En pratique, la question de la capacité exige un générateur de charge et celle de l'exactitude des assertions sur le corps des réponses ; faire les deux correctement en une seule exécution est plus rare que le marketing ne le laisse croire.
L'exactitude, puis la régression, puis la capacité.
Les tests de performance des API, ce sont trois questions et trois réponses. La régression est celle qu'il vaut la peine d'automatiser à chaque modification, l'exactitude est le socle sur lequel tout repose, et la capacité est la coûteuse par laquelle la plupart des équipes commencent.