SoapUI est un outil open source permettant de tester les services web et les API. Il a débuté en 2005 comme un moyen de tester les services SOAP, d'où son nom, et il s'est ensuite développé pour prendre également en charge REST, GraphQL, JMS et JDBC. Pendant deux décennies, il a été un pilier des équipes d'assurance qualité en entreprise, en particulier celles qui géraient des intégrations SOAP plus anciennes que les nouveaux outils ont tendance à ignorer.
Si vous n'avez travaillé qu'avec des API REST JSON et un client moderne, SoapUI peut sembler être une relique. Mais c'est toujours l'un des rares outils qui gère correctement les tests SOAP basés sur WSDL, et il reste pertinent partout où les banques, les assureurs, les systèmes gouvernementaux et les plateformes de télécommunications exécutent des services web XML. Ce guide explique ce que fait SoapUI, les fonctionnalités qui comptent, quand c'est le bon choix et les limitations qui poussent de nombreuses équipes vers des alternatives.
Ce que fait réellement SoapUI
SoapUI est une application de bureau qui vous permet de créer, d'envoyer et de valider des requêtes API sans écrire de code d'application. Vous le pointez vers une définition de service, construisez des requêtes de test contre celle-ci, ajoutez des assertions et exécutez ces requêtes sous forme de suites.
Son atout majeur est l'importation WSDL. Un fichier WSDL (Web Services Description Language) est un document XML qui décrit entièrement un service SOAP : ses opérations, les formats de messages et les types de données. Donnez une URL WSDL à SoapUI et il génère des requêtes squelettes pour chaque opération, pré-remplies avec la structure d'enveloppe XML correcte. Vous remplissez les valeurs et envoyez. Cette génération automatique est la raison pour laquelle SoapUI est resté pertinent pour le travail SOAP ; écrire une enveloppe SOAP à la main est fastidieux et sujet aux erreurs.
Côté REST, SoapUI importe les définitions OpenAPI et WADL et vous permet de construire des requêtes avec des méthodes, des paramètres, des en-têtes et des corps, à l'instar de tout autre client API. Il prend en charge les deux styles dans un seul projet, ce qui est utile pour les équipes en pleine migration de SOAP vers REST.
SoapUI est livré en deux éditions. La version open source couvre les tests fonctionnels de base et est gratuite. ReadyAPI est l'édition commerciale de SmartBear ; elle ajoute les tests de charge, l'analyse de sécurité, les tests pilotés par les données à partir de sources externes et une interface plus soignée. Lorsque les gens disent « SoapUI », ils désignent généralement l'outil open source gratuit, et c'est ce sur quoi nous nous concentrerons ici.
Fonctionnalités clés
L'ensemble des fonctionnalités de SoapUI est bâti autour d'une hiérarchie claire : les projets contiennent des suites de tests, les suites de tests contiennent des cas de test, et les cas de test contiennent des étapes de test.
- Projets. Un projet contient toutes les requêtes, suites et configurations pour un service ou un groupe de services liés. C'est le conteneur de plus haut niveau que vous enregistrez et partagez avec l'équipe.
- Suites de tests fonctionnels. Au sein d'un projet, vous construisez des cas de test composés d'étapes ordonnées. Une étape peut être une requête, une assertion, un transfert de propriété, un délai ou un script. Les étapes s'exécutent en séquence, vous pouvez donc vous connecter, capturer un jeton et le réutiliser dans les requêtes ultérieures.
- Assertions. SoapUI offre une large gamme d'assertions intégrées : vérifications du code de statut, correspondances XPath et XQuery sur les réponses XML, vérifications JSONPath sur les JSON, conformité au schéma, limites de temps de réponse SLA et correspondance de contenu. Celles-ci vous permettent de valider une réponse sans écrire de code. Notre guide sur les assertions API explique les modèles qui s'appliquent ici.
- Transfert de propriété. Cette étape copie une valeur d'une réponse vers une requête ultérieure. C'est ainsi que vous chaînez les appels : extrayez un ID de session d'une réponse de connexion et injectez-le dans l'appel suivant. C'est l'équivalent SoapUI de l'extraction de variables dans d'autres outils.
- Scripting Groovy. Lorsque les étapes intégrées ne suffisent pas, SoapUI exécute des scripts Groovy. Vous pouvez générer des données dynamiques, transformer des charges utiles, exécuter des assertions personnalisées ou appeler des systèmes externes. C'est la porte de sortie qui rend SoapUI flexible pour les scénarios d'entreprise complexes.
- Services fictifs (Mock services). SoapUI peut simuler un service SOAP ou REST à partir de sa définition, afin que vous puissiez tester un client avant que le véritable backend n'existe. Si la simulation est centrale à votre flux de travail, comparez les options dans notre article sur les cas d'utilisation de la simulation d'API.
Ensemble, ces fonctionnalités font de SoapUI un environnement de test fonctionnel complet pour les services fortement basés sur XML, ce qui est exactement le créneau pour lequel il a été conçu.
Un flux de travail SoapUI typique
Parcourir une session SoapUI de base concrétise la hiérarchie. Voici comment un testeur aborde généralement un nouveau service.
- Créer un projet à partir d'une définition. Vous démarrez SoapUI, créez un nouveau projet et collez une URL WSDL pour un service SOAP ou un fichier OpenAPI pour un service REST. SoapUI l'analyse et génère une arborescence d'opérations ou de points d'extrémité.
- Envoyer une requête exploratoire. Vous ouvrez l'une des requêtes générées, remplissez des valeurs d'exemple et cliquez sur soumettre. SoapUI affiche la réponse brute, formatée en XML ou JSON, afin que vous puissiez confirmer que le service répond comme prévu.
- Construire une suite de tests. Une fois que vous comprenez le service, vous créez une suite de tests, ajoutez des cas de test et y ajoutez des étapes de test. Une étape de connexion capture un jeton, une étape de transfert de propriété déplace ce jeton, et les étapes de requête suivantes l'utilisent.
- Ajouter des assertions. Sur chaque étape de requête, vous attachez des assertions : une vérification du code de statut, une correspondance XPath sur un élément spécifique, une limite SLA sur le temps de réponse. Celles-ci transforment une requête en un véritable test qui réussit ou échoue.
- Exécuter et examiner. Vous exécutez le cas de test ou la suite entière. SoapUI affiche un résultat de réussite ou d'échec par étape et par assertion, avec les données de réponse disponibles pour toute défaillance que vous devez examiner.
Ce cycle, de la définition à l'exploration, en passant par la suite, les assertions et l'exécution, est le même que vous testiez SOAP ou REST. La structure est ce qui donne à SoapUI sa puissance et aussi ce qui le rend lourd pour les petites tâches.
SoapUI comparé à d'autres outils
Il est utile de situer SoapUI par rapport aux outils que les testeurs utilisent aujourd'hui. Le tableau ci-dessous en esquisse les grandes lignes.
| Aspect | SoapUI | Clients REST modernes |
|---|---|---|
| Support SOAP et WSDL | Fort, de premier ordre | Faible ou absent |
| Assertions XML (XPath, XQuery) | Étendues | Limitées |
| Support REST et OpenAPI | Adéquat | De premier ordre |
| Interface | Denses, datée | Épurée, moderne |
| Courbe d'apprentissage | Raide | Plus douce |
| Tests de charge en édition gratuite | Non inclus | Varie |
Le résumé que le tableau met en évidence est simple. SoapUI l'emporte de manière décisive sur SOAP et XML, et les clients modernes l'emportent sur le flux de travail REST et l'accessibilité. Votre pile technologique détermine quelle colonne est la plus importante.
Quand SoapUI est le bon choix
SoapUI est un excellent choix dans des situations spécifiques. Utilisez-le lorsque vous maintenez des services SOAP et que vous avez besoin d'un véritable support WSDL, car peu d'outils modernes gèrent les enveloppes SOAP et WS-Security aussi proprement. Utilisez-le lorsque vous travaillez dans une entreprise qui a déjà standardisé sur SoapUI ou ReadyAPI, car les coûts de migration et les actifs de test existants favorisent la continuité. Utilisez-le lorsque vous avez besoin d'assertions XPath ou XQuery sur du XML profondément imbriqué, un domaine où SoapUI est vraiment performant.
Il convient également aux équipes qui souhaitent un outil de test fonctionnel gratuit, sans code, et qui peuvent absorber la courbe d'apprentissage. Si vos services sont principalement SOAP, SoapUI sera probablement plus rapide à configurer que de forcer un outil orienté REST à gérer le XML. Pour un aperçu plus large des approches de test, consultez notre vue d'ensemble de ce qu'est le test automatisé.
Où SoapUI échoue
SoapUI porte le poids de son âge, et les limites sont réelles.
La courbe d'apprentissage est raide. La hiérarchie projet-suite-cas-étape est puissante mais peu intuitive, et l'interface expose de nombreuses options simultanément. Les nouveaux utilisateurs se sentent souvent perdus. Construire quoi que ce soit au-delà d'une requête de base signifie souvent de passer à Groovy, ce qui ajoute une exigence de script à un outil commercialisé comme sans code.
L'utilisation des ressources est importante. SoapUI est une application de bureau Java, et les grands projets avec de nombreuses suites peuvent la rendre lente. Sur du matériel modeste, ouvrir un grand projet et exécuter des suites mettra votre patience à l'épreuve.
L'édition open source n'inclut pas les tests de charge. Les tests de performance et de concurrence sont disponibles dans le produit payant ReadyAPI. Si vous avez besoin d'une couverture fonctionnelle et de charge, vous payez ou vous ajoutez un deuxième outil. Notre guide sur les outils de test de performance logicielle couvre les alternatives.
L'intégration CI/CD est fonctionnelle mais datée. SoapUI peut s'exécuter depuis la ligne de commande et il existe un plugin Maven, mais l'expérience semble ajoutée par rapport aux outils conçus dès le départ pour les pipelines. L'interface elle-même reflète une ancienne ère de logiciels de bureau et n'a pas suivi le rythme des clients API modernes.
Enfin, SoapUI est compatible REST mais conçu pour SOAP. Si votre stack entier est basé sur des API REST JSON, vous trouverez probablement un client moderne plus rapide et plus agréable. SoapUI gagne sa place là où SOAP et XML sont encore en jeu.
Une alternative moderne : Apidog
Pour les équipes dont les API sont principalement REST, GraphQL ou construites autour d'OpenAPI, Apidog offre une approche plus actuelle du même flux de travail. Il combine la conception d'API, le débogage, les tests fonctionnels automatisés et les serveurs de maquette dans une seule application. Vous concevez un schéma, envoyez des requêtes, ajoutez des assertions visuelles sans script, et enchaînez les étapes en scénarios de test automatisés, le tout dans une interface conçue pour le travail API moderne plutôt que rétrofittée sur une fondation vieille de vingt ans.
Apidog inclut également des tests de performance dans le même outil, de sorte que vous n'avez pas besoin d'un produit payant séparé pour la couverture de charge. Il prend en charge le CI/CD via un exécuteur en ligne de commande et s'intègre proprement aux pipelines. Vous pouvez télécharger Apidog et utiliser ses fonctionnalités de test principales gratuitement. Si vous avez encore besoin de tests spécifiques à SOAP, notre guide sur les testeurs d'API SOAP en ligne couvre les options pour ce cas.
Le résumé honnête : SoapUI reste le choix pratique pour les tests d'entreprise fortement axés sur SOAP, et il est gratuit et compétent dans ce créneau. Pour les nouveaux projets REST, une plateforme moderne vous sera généralement plus utile.
Foire aux questions
SoapUI est-il gratuit ?
L'édition open source de SoapUI est gratuite et couvre les tests fonctionnels pour les API SOAP et REST. ReadyAPI, l'édition commerciale de SmartBear, est un produit payant qui ajoute des tests de charge, de l'analyse de sécurité, des tests avancés basés sur les données et une interface raffinée. La plupart des références à "SoapUI" désignent l'outil open source gratuit.
SoapUI ne teste-t-il que les API SOAP ?
Non. Malgré son nom, SoapUI teste les API REST, GraphQL, JMS et JDBC en plus de SOAP. Il importe les définitions OpenAPI et WADL pour les services REST. Cela dit, son support WSDL et ses capacités d'assertions XML sont ses points forts, il est donc le plus pertinent pour les équipes ayant des services SOAP à maintenir.
SoapUI peut-il être exécuté dans un pipeline CI/CD ?
Oui. SoapUI peut exécuter des suites de tests depuis la ligne de commande, et il existe un plugin Maven pour l'intégration de build. L'expérience fonctionne mais semble moins soignée que les outils conçus dès le départ pour les pipelines. Pour une utilisation intensive en CI, évaluez le confort de l'exécuteur en ligne de commande pour votre flux de travail.
Quelle est la différence entre SoapUI et Postman ?
SoapUI offre un support SOAP et WSDL plus approfondi et des assertions XML plus solides, et il est construit autour d'une hiérarchie structurée de suites de tests. Postman est orienté REST d'abord, possède une interface plus conviviale et un écosystème plus vaste. Les équipes qui maintiennent des services SOAP préfèrent souvent SoapUI ; les équipes qui construisent des API REST JSON préfèrent généralement Postman ou une alternative moderne.
Dois-je connaître Groovy pour utiliser SoapUI ?
Pas pour les requêtes de base et les assertions intégrées. Mais tout ce qui est dynamique, comme la génération de données de test, la transformation de charges utiles ou l'écriture d'une logique de validation personnalisée, nécessite généralement des scripts Groovy. Prévoyez d'apprendre un peu de Groovy si vos tests vont au-delà des scénarios simples de requête et d'assertion.
SoapUI est-il toujours pertinent en 2026 ?
Oui, dans son créneau. Les services SOAP n'ont pas disparu ; ils restent courants dans les systèmes bancaires, d'assurance, gouvernementaux, de santé et de télécommunications qui ont été construits il y a des années et sont toujours en fonctionnement. Pour tester ces services, le support WSDL de SoapUI est difficile à égaler. Pour les nouveaux projets REST et GraphQL, la plupart des équipes choisissent un outil moderne. SoapUI est pertinent là où SOAP est pertinent.
Quelle est la différence entre SoapUI et ReadyAPI ?
SoapUI est l'outil de test fonctionnel gratuit et open source. ReadyAPI est le produit commercial de SmartBear qui s'appuie sur la même base et ajoute les tests de charge, les tests de sécurité, les tests avancés pilotés par les données et une interface plus raffinée. Si vous avez besoin de tests de performance ou d'analyse de sécurité sans ajouter un deuxième outil, ReadyAPI est la voie payante ; sinon, le SoapUI gratuit couvre les tests fonctionnels.