Alternative à ReadyAPI pour les Tests de Charge d'APIs Modernes

En bref

ReadyAPI inclut LoadUI Pro pour les tests de charge, mais le coût est intégré à une licence par utilisateur déjà chère, et l'outillage a été conçu à une époque où REST était plus récent. Pour les équipes qui testent les API REST et GraphQL modernes, k6 et Gatling sont des alternatives gratuites plus performantes. Apidog gère la couche de tests fonctionnels d'API qui s'associe naturellement à k6 pour les tests de performance.

Introduction

Les tests de charge ne sont pas facultatifs pour les API qui servent de vrais utilisateurs. Vous devez savoir ce qui se passe lorsque 100 utilisateurs sollicitent simultanément votre point de terminaison de recherche, ou lorsqu'une tâche de fond déclenche 500 écritures concurrentes dans la base de données. Découvrir cela de la manière difficile, en production, est coûteux.

ReadyAPI intègre les tests de charge via son composant LoadUI Pro. Pour les équipes utilisant déjà ReadyAPI pour les tests fonctionnels, la capacité de test de charge intégrée est attrayante : utiliser le même outil, réutiliser les mêmes définitions de test, tout gérer en un seul endroit.

En pratique, la situation est plus complexe. LoadUI Pro a une philosophie de conception et un ensemble de compromis spécifiques. Pour certaines équipes, c'est le bon choix. Pour d'autres, les alternatives modernes open source sont plus performantes, plus rentables et mieux alignées sur la façon dont les développeurs travaillent aujourd'hui.

Cet article explique ce que fait LoadUI Pro, comment il se compare à k6 et Gatling, et comment Apidog s'intègre à un flux de travail de test de charge moderne.

Ce que LoadUI Pro fait réellement

LoadUI Pro est le module de test de charge de ReadyAPI. Il étend les capacités de tests fonctionnels de ReadyAPI en permettant d'exécuter des cas de test à grande échelle, avec des comptes d'utilisateurs virtuels configurables, des profils de montée en charge et des réglages de durée.

Principales capacités de LoadUI Pro :

Conversion de tests fonctionnels en tests de charge. Vous pouvez prendre un cas de test ReadyAPI existant et l'exécuter sous charge sans le réécrire comme test de charge. C'est la fonctionnalité la plus attrayante de LoadUI Pro : si vous avez déjà écrit des tests fonctionnels, vous pouvez les utiliser directement.

Profils de charge et scénarios. LoadUI Pro prend en charge différentes stratégies de simulation de charge : mise à l'échelle simple des utilisateurs virtuels, charge en rafale, montée en charge progressive et profils personnalisés. Vous les configurez via l'interface graphique.

Temps de réponse et métriques de débit. Pendant une exécution de test de charge, LoadUI Pro affiche des métriques en temps réel pour les temps de réponse, les taux d'erreur, le débit et le nombre d'utilisateurs virtuels. Après l'exécution, il génère un rapport.

Assertions sous charge. Vous pouvez définir des assertions qui doivent être respectées pendant un test de charge, comme un temps de réponse au 95ème centile inférieur à 2000 ms, et faire échouer le test si elles sont violées.

Limitations de LoadUI Pro :

Il s'exécute par défaut à partir d'une seule machine. Les tests de charge distribués, où vous devez générer de la charge à partir de plusieurs emplacements géographiques ou avec un nombre d'utilisateurs virtuels plus élevé qu'une seule machine ne peut supporter, ne sont pas pris en charge ou nécessitent une infrastructure supplémentaire.

L'approche basée sur l'interface graphique ne se prête pas à des définitions de tests révisées par le code. Les configurations de tests de charge sont stockées au format de fichier projet de ReadyAPI, et non dans des fichiers de code sous contrôle de version.

Le modèle de script utilise Groovy. La personnalisation du comportement des tests de charge nécessite Groovy, que la plupart des développeurs ne connaissent pas.

Les performances par rapport aux outils de test de charge modernes sont limitées par le modèle de thread JVM utilisé par ReadyAPI. Des outils comme k6 peuvent simuler plus d'utilisateurs virtuels sur le même matériel avec moins de surcharge.

k6 : l'alternative open source moderne

k6 est un outil de test de charge open source développé par Grafana Labs et distribué sous licence AGPL-3.0. Il est devenu l'outil de test de charge moderne dominant pour les équipes qui testent les API REST.

Pourquoi k6 est convaincant :

Les tests de charge sont du code. Les tests k6 sont des fichiers JavaScript. Ils résident dans votre dépôt Git aux côtés du code de votre application. Ils passent par une révision de code. Les développeurs peuvent les lire et les modifier sans apprendre un outil spécialisé.

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  vus: 50,
  duration: '30s',
};

export default function () {
  const res = http.get('https://api.example.com/users');
  check(res, {
    'status is 200': (r) => r.status === 200,
    'response time under 500ms': (r) => r.timings.duration < 500,
  });
  sleep(1);
}

Ce test exécute 50 utilisateurs virtuels pendant 30 secondes, chacun effectuant une requête GET et vérifiant le code de statut et le temps de réponse. Le test entier tient en 18 lignes de JavaScript.

Performances de k6. k6 est écrit en Go avec un environnement d'exécution JavaScript. Il est extrêmement efficace. Un seul ordinateur portable exécutant k6 peut générer des milliers d'utilisateurs virtuels avec une surcharge de ressources inférieure à celle des outils basés sur JVM à des niveaux de charge équivalents.

Seuils. Le système de seuils de k6 permet de définir des critères de réussite/échec qui s'intègrent naturellement au CI/CD :

export const options = {
  thresholds: {
    http_req_duration: ['p(95)<500'],
    http_req_failed: ['rate<0.01'],
  },
};

Ce test échoue si le temps de réponse au 95ème centile dépasse 500 ms ou si plus de 1% des requêtes échouent. k6 se termine avec un code non nul si les seuils sont violés, ce qui le rend compatible CI.

Grafana k6 Cloud. Pour les tests de charge distribués depuis plusieurs régions géographiques, Grafana propose k6 Cloud en tant que service payant. L'outil open source gère l'exécution locale. Le service cloud gère la distribution mondiale. Vous utilisez les mêmes scripts de test pour les deux.

Tarification de k6. L'outil open source est gratuit. La tarification de k6 Cloud commence à environ 49 $/mois pour un petit plan de test et évolue avec les heures d'utilisateurs virtuels.

Gatling : tests de performance pour les équipes Java

Gatling est un outil de test de charge open source conçu pour les entreprises Java et Scala. Il dispose d'un DSL de simulation (en Scala) et d'une API Java pour les équipes qui préfèrent Java.

Points forts de Gatling :

Le modèle de simulation de Gatling est puissant pour les scénarios complexes avec des protocoles à état, des variables de session et des parcours utilisateur complexes. Un flux de commande nécessitant de se connecter, de parcourir les produits, d'ajouter au panier et de finaliser un achat est naturellement exprimé dans le DSL de Gatling.

Les rapports HTML sont excellents. La fonction de rapport intégrée de Gatling génère des tableaux de bord HTML détaillés et lisibles sans outils supplémentaires.

L'enregistreur peut capturer le trafic du navigateur et générer une simulation Gatling, de la même manière que ReadyAPI peut enregistrer le trafic REST.

Gatling Enterprise. Gatling propose Gatling Enterprise (anciennement FrontLine) pour l'exécution distribuée, l'intégration CI/CD et les fonctionnalités de collaboration d'équipe. C'est un produit payant. Pour les équipes qui n'ont besoin que de tests de charge locaux, la version open source est suffisante.

Comparaison Gatling à k6. Gatling est mieux adapté aux équipes ayant des antécédents Java/Scala. k6 est mieux adapté aux équipes fortement orientées JavaScript. Les deux sont plus conviviaux pour les développeurs que l'approche Groovy basée sur l'interface graphique de LoadUI Pro.

LoadUI Pro vs k6 : comparaison directe

Le seul avantage clair de LoadUI Pro par rapport à k6 est la capacité à réutiliser les cas de test fonctionnels de ReadyAPI directement comme tests de charge. Si vous avez une grande suite de tests ReadyAPI et que vous souhaitez l'exécuter sous charge sans réécrire les tests, cela est important.

Pour les équipes qui démarrent de zéro ou qui migrent vers une pile moderne, le modèle JavaScript de k6, sa convivialité avec Git et son efficacité sont des avantages convaincants.

Comment Apidog + k6 remplace ReadyAPI + LoadUI Pro

La combinaison ReadyAPI + LoadUI Pro couvre les tests fonctionnels d'API et les tests de charge dans un seul outil. Le remplacer nécessite deux outils travaillant ensemble.

Apidog pour les tests fonctionnels. Apidog gère la conception d'API, les tests REST/GraphQL/gRPC/WebSocket, le Smart Mock et la documentation. Les scripts de test utilisent JavaScript. L'intégration CI/CD se fait via l'interface en ligne de commande (CLI) d'Apidog. Cela remplace les capacités de tests fonctionnels de ReadyAPI pour les équipes qui ne dépendent pas de SOAP/WS-Security.

k6 pour les tests de charge. k6 gère les tests de charge et de performance. Les tests sont des fichiers JavaScript. Ils s'exécutent localement ou sur k6 Cloud. L'intégration CI/CD se fait via la CLI de k6.

Les deux outils fonctionnent à partir d'une source de vérité partagée : votre spécification OpenAPI. Apidog importe la spécification pour les tests fonctionnels. Les scripts k6 appellent les mêmes points de terminaison pour les tests de charge. Lorsque l'API change, les deux suites de tests font référence au même schéma.

Exemple de pipeline CI/CD :

stages:
  - functional-tests
  - load-tests

functional-tests:
  stage: functional-tests
  script:
    - apidog run collection.json --environment staging
  only:
    - merge_requests

load-tests:
  stage: load-tests
  script:
    - k6 run load-tests/api-load.js --env BASE_URL=$STAGING_URL
  only:
    - main

Les tests fonctionnels s'exécutent à chaque demande de fusion. Les tests de charge s'exécutent lorsque le code est fusionné dans la branche principale. Ce modèle fournit un retour rapide pour les régressions fonctionnelles et une validation périodique de la charge pour les déploiements en production.

Comparaison des coûts :

ReadyAPI + LoadUI Pro (10 utilisateurs) : environ 7 490 $ à 20 000 $ par an selon la configuration.

Apidog Basic (10 utilisateurs) + k6 open source : environ 1 080 $ par an.

Apidog Basic (10 utilisateurs) + k6 Cloud (plan de base) : environ 1 080 $ + 588 $ = 1 668 $ par an.

Même en incluant k6 Cloud, la pile moderne coûte beaucoup moins cher que ReadyAPI avec LoadUI Pro.

FAQ

k6 prend-il en charge les tests de charge SOAP ?k6 peut envoyer des requêtes HTTP POST avec des corps XML, ce qui fonctionne techniquement pour les services SOAP. Il n'y a pas d'importation WSDL ni d'outils spécifiques à SOAP. Pour les tests de charge des API REST modernes, k6 est excellent. Pour les tests de charge SOAP, LoadUI Pro reste plus performant.

Puis-je convertir des configurations de tests de charge ReadyAPI existantes en k6 ?Il n'y a pas de convertisseur automatisé. Vous devrez réécrire vos scénarios de tests de charge sous forme de scripts k6. Cela représente généralement quelques heures par scénario pour les développeurs expérimentés. Le modèle de script de k6 est plus simple que Groovy dans la plupart des cas.

Combien d'utilisateurs virtuels k6 peut-il exécuter sur un ordinateur portable standard ?k6 est suffisamment efficace pour exécuter de 1 000 à 10 000 utilisateurs virtuels sur un ordinateur portable moderne, selon le scénario de test et le taux de requêtes. ReadyAPI/LoadUI Pro atteint généralement un maximum de quelques centaines d'utilisateurs virtuels avant que la surcharge mémoire de la JVM ne devienne une contrainte.

Gatling prend-il en charge les tests de charge gRPC ?Gatling prend en charge gRPC de manière expérimentale depuis la version 3.10+. k6 dispose d'un support gRPC dans son API JavaScript de base, ce qui le rend plus mature pour les tests de charge gRPC à partir de 2026.

Existe-t-il un moyen d'exécuter des tests k6 sans aucun service cloud ?Oui, l'outil open source de k6 s'exécute entièrement localement. Vous n'avez pas besoin de Grafana k6 Cloud pour les tests de charge sur une seule machine. Le service cloud ajoute l'exécution distribuée et le stockage des résultats historiques.

LoadUI Pro est-il pris en compte dans le nombre de licences par utilisateur de ReadyAPI ?LoadUI Pro est inclus dans des éditions spécifiques de ReadyAPI. Le nombre par utilisateur s'applique à l'ensemble. Si vous avez 10 utilisateurs ReadyAPI avec LoadUI Pro, cela représente 10 utilisateurs sous licence. L'exécution du test de charge elle-même peut généralement être effectuée sur un agent CI sans être comptabilisée dans les licences d'utilisateur nommées, mais confirmez cela avec votre contrat SmartBear.

LoadUI Pro de ReadyAPI est un outil de test de charge performant pour les équipes déjà investies dans l'écosystème ReadyAPI. Pour les équipes qui évaluent leurs options ou qui démarrent de zéro, k6 offre une approche plus conviviale pour les développeurs, plus rentable et plus évolutive pour les tests de charge d'API. L'association de k6 avec Apidog pour les tests fonctionnels vous offre une pile de test d'API moderne complète pour une fraction du coût de ReadyAPI avec LoadUI Pro.