SoapUI - Guide rapide

SOAP est l'acronyme de Simple Object Access Protocol. Il est défini par le World Wide Web Consortium (W3C) àhttps://www.w3.org/TR/2000/NOTE-SOAP-20000508 comme suit -

SOAP est un protocole léger pour l'échange d'informations dans un environnement décentralisé et distribué. Il s'agit d'un protocole basé sur XML qui se compose de trois parties: une enveloppe qui définit un cadre pour décrire ce qui est dans un message et comment le traiter; un ensemble de règles de codage pour exprimer des instances de types de données définis par l'application; et une convention pour représenter les appels et les réponses de procédure distante.

SOAP - Caractéristiques importantes

Voici quelques caractéristiques importantes de SOAP.

  • C'est un protocole de communication conçu pour communiquer via Internet.

  • Il peut étendre HTTP pour la messagerie XML.

  • Il assure le transport de données pour les services Web.

  • Il peut échanger des documents complets ou appeler une procédure à distance.

  • Il peut être utilisé pour diffuser un message.

  • Il est à la fois indépendant de la plate-forme et de la langue.

  • C'est la manière XML de définir quelles informations sont envoyées et comment.

  • Il permet aux applications clientes de se connecter facilement à des services distants et d'appeler des méthodes distantes.

Bien que SOAP puisse être utilisé dans une variété de systèmes de messagerie et puisse être fourni via une variété de protocoles de transport, l'objectif initial de SOAP est les appels de procédure à distance transportés via HTTP. D'autres frameworks tels que CORBA, DCOM et Java RMI fournissent des fonctionnalités similaires à SOAP, mais les messages SOAP sont entièrement écrits en XML et sont donc uniquement indépendants de la plate-forme et du langage.

Un message SOAP est un document XML ordinaire contenant les éléments suivants -

  • Envelope- Définit le début et la fin du message. C'est un élément obligatoire.

  • Header- Contient tout attribut facultatif du message utilisé dans le traitement du message, soit à un point intermédiaire, soit à l'extrémité ultime. C'est un élément optionnel.

  • Body- Contient les données XML constituant le message envoyé. C'est un élément obligatoire.

  • Fault - Un élément Fault facultatif qui fournit des informations sur les erreurs qui se produisent lors du traitement du message.

Tous ces éléments sont déclarés dans l'espace de noms par défaut de l'enveloppe SOAP -

https://www.w3.org/2001/12/soap-envelope

L'espace de noms par défaut pour le codage SOAP et les types de données est -

https://www.w3.org/2001/12/soap-encoding

Note- Toutes ces spécifications sont susceptibles d'être modifiées. Ainsi, continuez à vous mettre à jour avec les dernières spécifications disponibles sur le site Web de W3.

SOAP - Structure des messages

Le bloc suivant décrit la structure générale d'un message SOAP -

<?xml version = "1.0"?> 
<SOAP-ENV:Envelope 
xmlns:SOAP-ENV = "http://www.w3.org/2001/12/soap-envelope" 
SOAP-ENV:encodingStyle = "http://www.w3.org/2001/12/soap-encoding">  
   <SOAP-ENV:Header> 
      ... 
      ... 
   </SOAP-ENV:Header>  
   <SOAP-ENV:Body> 
      ... 
      ... 
      <SOAP-ENV:Fault> 
         ... 
         ... 
      </SOAP-ENV:Fault>  
   </SOAP-ENV:Body>  
</SOAP_ENV:Envelope>

REST est l'acronyme de Representational State Transfer. Il peut être défini comme un style architectural de conception de logiciels. REST n'est pas une spécification ou une norme W3C. Par conséquent, il est plus facile de travailler avec les services RESTful. Il ne nécessite aucun cadre de spécification middleware.

REST - Caractéristiques importantes

Voici quelques fonctionnalités importantes de REST.

  • Il repose sur un protocole de communication sans état, client-serveur, pouvant être mis en cache - pratiquement dans tous les cas, HTTP est utilisé.

  • C'est une alternative légère de WebService et RPC (Remote Procedure Call) comme SOAP-WSDL.

  • Il représente tout dans un ID ou des URI uniques.

  • Il utilise des méthodes HTTP standard, telles que GET, POST, PUT, DELETE.

  • Il relie les sources entre elles.

  • Les ressources REST peuvent avoir plusieurs représentations.

  • Toute information nommée est considérée comme une ressource. Par exemple: Une image, une personne, un document, tout peut être considéré comme un exemple de ressource et représenté comme un identifiant unique ou un URI.

  • Le World Wide Web lui-même, basé sur HTTP, peut être considéré comme une architecture basée sur REST.

Les services REST sont indépendants de la plate-forme et de la langue. Puisqu'il est basé sur les standards HTTP, il peut facilement fonctionner en présence de pare-feu. Comme les WebServices, REST n'offre aucune sécurité intégrée, gestion de session, garantie QoS, mais celles-ci peuvent être ajoutées en s'appuyant sur HTTP. Pour le chiffrement, REST peut être utilisé en plus de HTTPS.

SoapUI est un outil qui peut être utilisé pour des tests fonctionnels et non fonctionnels. Il ne se limite pas aux services Web, bien qu'il s'agisse de l'outil de facto utilisé dans les tests de services Web.

SoapUI - Caractéristiques importantes

Voici quelques caractéristiques importantes de SoapUI.

  • Il est capable de jouer le rôle de client et de service.

  • Il permet aux utilisateurs de créer des tests fonctionnels et non fonctionnels rapidement et de manière efficace en utilisant un seul environnement.

  • Il est concédé sous les termes de la licence publique générale GNU Leaser (LGPL).

  • Il est purement implémenté en utilisant la plate-forme JAVA.

  • Il prend en charge Windows, Mac, plusieurs dialectes Linux.

  • Il permet aux testeurs d'exécuter des tests fonctionnels, de régression, de conformité et de charge automatisés sur différentes API Web.

  • Il prend en charge tous les protocoles et technologies standard pour tester toutes sortes d'API.

SoapUI peut être utilisé pour tester des tests complets d'API RESTful et de service Web SOAP. Il prend en charge les tests fonctionnels, les tests de performances, les tests d'interopérabilité, les tests de régression, les tests de charge et bien plus encore.

Il est convivial et il est facile de convertir les tests fonctionnels en tests non fonctionnels tels que les tests de charge et de stress.

SoapUI est riche des cinq aspects suivants -

  • Test fonctionel
  • Test de sécurité
  • Test de charge
  • Protocoles et technologies
  • Intégration avec d'autres outils

Apprenons-en plus sur chacune de ces fonctionnalités.

Test fonctionel

  • SoapUI permet aux testeurs d'écrire des tests API fonctionnels dans SoapUI.

  • SoapUI prend en charge la fonction glisser-déposer qui accélère le développement du script.

  • SoapUI prend en charge le débogage des tests et permet aux testeurs de développer des tests pilotés par les données.

  • SoapUI prend en charge plusieurs environnements, ce qui facilite le basculement entre les environnements QA, Dev et Prod.

  • SoapUI permet des scripts avancés (le testeur peut développer son code personnalisé en fonction des scénarios).

Test de sécurité

  • SoapUI effectue un ensemble complet d'analyse des vulnérabilités.

  • SoapUI empêche l'injection SQL pour sécuriser les bases de données.

  • SoapUI scanne les débordements de pile, causés par des documents de grande taille.

  • SoapUI analyse les scripts intersites, qui se produisent lorsque les paramètres de service sont exposés dans les messages.

  • SoapUI effectue un balayage de fuzzing et un balayage des limites pour éviter un comportement erratique des services.

Test de charge

  • SoapUI distribue les tests de charge sur n nombre d'agents LoadUI.

  • SoapUI simule facilement les tests de charge à volume élevé et dans le monde réel.

  • SoapUI permet des rapports personnalisés avancés pour capturer les paramètres de performance.

  • SoapUI permet la surveillance des performances du système de bout en bout.

Protocoles et technologies

SoapUI prend en charge un large éventail de protocoles -

  • SOAP - Protocole d'accès aux objets simples
  • WSDL - Langage de définition de service Web
  • REST - Transfert d'état de représentation
  • HTTP - Protocole de transmission Hyper Text
  • HTTPS - Protocole de transmission Hyper Text sécurisé
  • AMF - Format du message d'action
  • JDBC - Connectivité de base de données Java
  • JMS - Service de messagerie Java

Intégration avec d'autres outils

  • Projet Apache Maven
  • HUDSON
  • JUnit
  • Apache - Ant et plus….

SoapUI est un outil de version gratuite open source avec des fonctionnalités de base de test, tandis que SoapUI NG Pro est un outil commercialisé ayant des fonctionnalités avancées de reporting, des fonctionnalités basées sur les données et bien plus encore.

Comparaison

Le tableau suivant compare et met en contraste les différentes fonctionnalités de SoapUI et SoapUI NG Pro.

traits SoapUI SoapUI NG Pro
Supported Technologies
SAVON Oui Oui
WSDL / WADL Oui Oui
DU REPOS Oui Oui
JMS Oui Oui
AMF Oui Oui
JDBC Oui Oui
HTTP Oui Oui
General Features
Application autonome Oui Oui
Prise en charge de plusieurs environnements Non Oui
Licence flottante Non Oui
Couverture WSDL Non Oui
Couverture des demandes / réponses Non Oui
Assertion de message Oui Oui
Refactoring de test Non Oui
Exécution de plusieurs tests Oui Oui
Test piloté par la source de données Non Oui
Bibliothèques de scripts Non Oui
Rapports d'unité Non Oui
Étapes de test manuel Oui Oui
Reporting
Rapports Junit Non Oui
Exporter les données du rapport Non Oui
Rapport HTML WSDL Oui Oui
Couverture de la suite de tests Non Oui
Couverture de cas de test Non Oui
Couverture des assertions Non Oui
Couverture de l'enregistrement des messages Non Oui

SoapUI est un outil multiplateforme. Il prend en charge les systèmes d'exploitation Windows, Linux et Mac.

Conditions préalables

  • Processor - Processeur 32 bits ou 64 bits de 1 GHz ou plus.

  • RAM - 512 Mo de RAM.

  • Hard Disk Space - Minimum 200 Mo d'espace disque dur pour l'installation.

  • Operating System Version - Windows XP ou version ultérieure, MAC OS 10.4 ou version ultérieure.

  • JAVA - JAVA 6 ou version ultérieure.

Processus de téléchargement

Step 1- Allez sur www.soapui.org et cliquez sur Télécharger SoapUI.

Step 2- Cliquez sur «Get It» pour télécharger SoapUI Open Source. Il commencera à télécharger le fichier .exe de 112 Mo dans le système. Attendez que le processus de téléchargement soit terminé.

Processus d'installation

Step 1 - Après le téléchargement, exécutez le fichier .exe en tant que «Exécuter en tant qu'administrateur».

Windows démarrera le processus de configuration comme indiqué dans la capture d'écran suivante.

Step 2 - Une fois configuré, la fenêtre de processus affiche l'écran suivant, cliquez sur Suivant.

Step 3 - Acceptez le contrat de licence et cliquez sur Suivant.

Step 4- Choisissez le répertoire d'installation ou conservez-le comme chemin par défaut sélectionné par le système. Cliquez sur Suivant.

Step 5- Choisissez les composants que vous souhaitez installer. Cliquez sur Suivant.

Step 6 - Acceptez le contrat de licence pour HermesJMS et cliquez sur Suivant.

Step 7 - Sélectionnez le répertoire cible pour enregistrer les didacticiels et cliquez sur Suivant.

Step 8 - Choisissez l'emplacement du dossier du menu Démarrer ou laissez l'emplacement par défaut tel quel et cliquez sur «Suivant».

Step 9 - Cochez la case «créer une icône de bureau» et cliquez sur «Suivant».

Maintenant, l'installation démarre. Cela prendra quelques minutes.

Step 10 - Une fois l'installation terminée, cliquez sur Terminer dans l'assistant suivant.

En cliquant sur Terminer, SoapUI est lancé.

  • Barre de menu
  • Barre d'outils
  • Barre de navigation du projet
  • Propriétés de l'espace de travail
  • Panneau de journal

Processus de configuration

La première étape consiste à créer un espace de travail pouvant contenir plusieurs projets.

Step 1 - Allez dans Fichier → Nouvel espace de travail.

Step 2 - Ajoutez le nom de l'espace de travail et cliquez sur OK.

Step 3 - Sélectionnez maintenant le chemin dans lequel l'espace de travail xml sera enregistré.

Step 4 - Sélectionnez le chemin et cliquez sur Enregistrer.

L'espace de travail est créé comme illustré dans la capture d'écran suivante. Les propriétés de l'espace de travail sont également exposées.

WSDL signifie Web Services Description Language. C'est un format standard pour décrire un service Web. WSDL a été développé conjointement par Microsoft et IBM. WSDL est prononcé comme «wiz-terne» et épelé comme «WSD-L».

WSDL ─ Une brève histoire

WSDL 1.1 a été soumis en tant que note du W3C par Ariba, IBM et Microsoft pour la description des services pour l'activité XML du W3C sur les protocoles XML en mars 2001.

WSDL 1.1 n'a pas été approuvé par le World Wide Web Consortium (W3C), mais il vient de publier une ébauche pour la version 2.0 qui sera une recommandation (une norme officielle), et donc approuvée par le W3C.

WSDL ─ Points à noter

WSDL est un protocole basé sur XML pour l'échange d'informations dans un environnement décentralisé et distribué. Certaines des autres fonctionnalités de WSDL sont les suivantes:

  • Les définitions WSDL décrivent comment accéder à un service Web et quelles opérations il effectuera.

  • C'est un langage pour décrire comment s'interfacer avec des services basés sur XML.

  • Il fait partie intégrante de Universal Description, Discovery, and Integration (UDDI), un registre mondial des entreprises basé sur XML.

  • WSDL est le langage utilisé par UDDI.

Utilisation WSDL

WSDL est souvent utilisé en combinaison avec SOAP et XML Schema pour fournir des services Web sur Internet. Un programme client se connectant à un service Web peut lire le WSDL pour déterminer les fonctions disponibles sur le serveur. Tous les types de données spéciaux utilisés sont incorporés dans le fichier WSDL sous la forme de schéma XML. Le client peut alors utiliser SOAP pour appeler en fait l'une des fonctions répertoriées dans le WSDL.

Comprendre WSDL

WSDL décompose les services Web en trois éléments spécifiques et identifiables qui peuvent être combinés ou réutilisés une fois définis.

Les trois principaux éléments de WSDL qui peuvent être définis séparément sont:

  • Types
  • Operations
  • Binding

Un document WSDL comporte divers éléments, mais ils sont contenus dans ces trois éléments principaux, qui peuvent être développés en tant que documents séparés, puis ils peuvent être combinés ou réutilisés pour former des fichiers WSDL complets.

Dans ce tutoriel, nous suivons CurrencyConverter WSDL: http://www.webservicex.net

Format et éléments

CurrencyConverter WSDL ressemblera à ce qui suit -

WSDL ─ Type de port

L'élément <portType> combine plusieurs éléments de message pour former une opération complète unidirectionnelle ou aller-retour. Par exemple, un <portType> peut combiner une demande et un message de réponse en une seule opération de demande / réponse. Ceci est le plus couramment utilisé dans les services SOAP. Un portType peut définir plusieurs opérations.

Exemple

  • L'élément portType définit une seule opération, appelée ConversionRate.
  • L'opération consiste en un seul message d'entrée ConversionRateHttpPostIn.
  • L'opération pour le message de sortie est ConversionRateHttpPostOut.

Modèles de fonctionnement

WSDL prend en charge quatre modèles de fonctionnement de base -

Sens Unique

Le service reçoit un message. L'opération a donc un seul élément d'entrée. La grammaire pour une opération unidirectionnelle est -

<wsdl:definitions .... >  
   <wsdl:portType .... > * 
      <wsdl:operation name = "nmtoken"> 
         <wsdl:input name = "nmtoken"? message = "qname"/> 
      </wsdl:operation> 
   </wsdl:portType > 
</wsdl:definitions>

Demande ─ Réponse

Le service reçoit un message et envoie une réponse. L'opération a donc un élément d'entrée, suivi d'un élément de sortie. Pour encapsuler les erreurs, un élément fault facultatif peut également être spécifié. La grammaire pour une opération de demande-réponse est -

<wsdl:definitions .... > 
   <wsdl:portType .... > * 
      <wsdl:operation name = "nmtoken" parameterOrder = "nmtokens"> 
         <wsdl:input name = "nmtoken"? message = "qname"/> 
         <wsdl:output name = "nmtoken"? message = "qname"/> 
         <wsdl:fault name = "nmtoken" message = "qname"/>* 
      </wsdl:operation> 
   </wsdl:portType > 
</wsdl:definitions>

Solliciter ─ Réponse

Le service envoie un message et reçoit une réponse. L'opération a donc un élément de sortie, suivi d'un élément d'entrée. Pour encapsuler les erreurs, un élément fault facultatif peut également être spécifié. La grammaire pour une opération de sollicitation-réponse est -

<wsdl:definitions .... > 
   <wsdl:portType .... > * 
      <wsdl:operation name = "nmtoken" parameterOrder = "nmtokens"> 
         <wsdl:output name = "nmtoken"? message = "qname"/> 
         <wsdl:input name = "nmtoken"? message = "qname"/> 
         <wsdl:fault name = "nmtoken" message = "qname"/>* 
      </wsdl:operation> 
   </wsdl:portType > 
</wsdl:definitions>

Notifications

Le service envoie un message. L'opération a donc un seul élément de sortie. Voici la grammaire pour une opération de notification -

<wsdl:definitions .... > 
   <wsdl:portType .... > * 
      <wsdl:operation name = "nmtoken"> 
         <wsdl:output name = "nmtoken"? message = "qname"/> 
      </wsdl:operation> 
   </wsdl:portType > 
</wsdl:definitions>

WSDL ─ Liaison et service

le <binding>L'élément fournit des détails spécifiques sur la manière dont une opération portType sera réellement transmise sur le câble.

  • Les liaisons peuvent être rendues disponibles via plusieurs transports, notamment HTTP GET, HTTP POST ou SOAP.

  • Les liaisons fournissent des informations concrètes sur le protocole utilisé pour transférer les opérations portType.

  • Les liaisons fournissent des informations sur l'emplacement du service.

  • Pour le protocole SOAP, la liaison est <soap: binding> et le transport est constitué de messages SOAP au-dessus du protocole HTTP.

  • Vous pouvez spécifier plusieurs liaisons pour un seul portType.

Un service

le <service>L'élément définit les ports pris en charge par le service Web. Pour chacun des protocoles pris en charge, il existe un élément de port. L'élément de service est une collection de ports.

Les clients de service Web peuvent apprendre ce qui suit à partir de l'élément de service:

  • Où accéder au service,
  • Par quel port accéder au service Web, et
  • Comment les messages de communication sont définis.

L'élément de service comprend un élément de documentation pour fournir une documentation lisible par l'homme.

<wsdl:service name = "CurrencyConvertor">
   <wsdl:port name = "CurrencyConvertorSoap" binding = "tns:CurrencyConvertorSoap">
      <soap:address location = "http://www.webservicex.net/CurrencyConvertor.asmx" />
   </wsdl:port>
   <wsdl:port name = "CurrencyConvertorSoap12"binding = "tns:CurrencyConvertorSoap12>
      <soap12:address location = "http://www.webservicex.net/CurrencyConvertor.asmx" />
   </wsdl:port>
   <wsdl:port name = "CurrencyConvertorHttpGet" binding = "tns:CurrencyConvertorHttpGet">
      <http:address location = "http://www.webservicex.net/CurrencyConvertor.asmx" />
   </wsdl:port>
   <wsdl:portname = "CurrencyConvertorHttpPost"binding = "tns:CurrencyConvertorHttpPost">
      <http:address location = "http://www.webservicex.net/CurrencyConvertor.asmx" />
   </wsdl:port> 
</wsdl:service>

Le projet SoapUI est le point central de tous les tests SoapUI. Une fois le projet créé, l'utilisateur peut créer et exécuter des tests fonctionnels, charger des tests, créer des services simulés et bien plus encore.

Dans ce chapitre, nous discuterons de deux choses - Comment -

  • Créer un projet SOAP
  • Ajouter un WSDL

Créer un projet SOAP

Step 1 - Dans le navigateur à gauche de l'écran, cliquez avec le bouton droit de la souris sur «Projet» et sélectionnez «Nouveau projet SOAP».

Ou allez dans Fichier et sélectionnez Nouveau projet Soap.

Lors de la sélection, une nouvelle fenêtre pop-up s'ouvre - Nouveau projet Soap.

Step 2 - Project Name: Entrez un nom de projet - il s'agit du champ de saisie utilisateur. Initial WSDL: Ce n'est pas obligatoire. Cela dépend de l'utilisateur. L'utilisateur peut fournir WSDL ou ajouter après la création du projet.

Dans ce cas, nous créons un projet et ajoutons le WSDL ultérieurement.

Step 3- Cliquez sur OK. Il créera un nouveau projet et sera visible sur le panneau de navigation de gauche.

Ajouter un WSDL

Les projets SOAP sont basés sur WSDL. Il n'est pas nécessaire de commencer par importer un WSDL, mais cela facilite les tests car le WSDL contient toutes les informations nécessaires pour tester un service Web, telles que les informations sur les demandes et les réponses, ce qu'elles contiennent et bien plus encore, ce qui simplifie les tests SoapUI.

Step 1 - Pour ajouter un WSDL, cliquez avec le bouton droit sur le nom du projet (SOAP - Exemple) et sélectionnez Ajouter WSDL.

Lors de la sélection, l'assistant WSDL s'affiche.

Step 2 - WSDL Location: Entrez un WSDL comme http://www.webservicex.com ou parcourez-le depuis l'ordinateur.

Step 3- Dès que WSDL est entré, 3 cases à cocher - Créer des demandes, Créer une suite de test, Créer des MockServices seront activées. En fonction des besoins, l'utilisateur peut cocher une ou plusieurs cases.

Par défaut, la case à cocher Créer des demandes est cochée.

Step 4- Cliquez sur OK. WSDL est ajouté avec succès dans le projet. Il peut être vérifié en observant le panneau de navigation de gauche. À l'intérieur du projet, il y a plusieurs opérations et les demandes sont ajoutées selon WSDL.

Vue détaillée

Pour obtenir plus de détails sur le projet, double-cliquez sur le nom du projet, cela ouvrira une nouvelle fenêtre avec divers détails.

Dans l'onglet Vue d'ensemble, diverses informations sont fournies telles que -

  • File Path - Il affiche l'emplacement du projet xml enregistré.

  • Interface Summary - Nom de l'interface et WSDL qui lui sont associés.

  • Test Summary - Il affiche les suites de tests, les cas de test, les étapes de test, les assertions ajoutées au projet.

L'utilisateur peut double-cliquer sur le nom de l'interface pour obtenir les détails de l'interface. Il ouvrira une nouvelle fenêtre et affichera les informations relatives au WSDL. Ceux-ci sont très utiles pour parcourir et examiner un WSDL.

Dans l'onglet Présentation, il répertorie les définitions WSDL, les parties de définition et les détails de l'opération.

De même, Service Endpoints répertorie les détails des endpoints.

Dans l'onglet Contenu WSDL, tous les détails de WSDL au format XML / schéma sont fournis comme illustré dans la capture d'écran suivante.

TestSuiteest une collection de cas de test qui peuvent être utilisés pour regrouper les tests fonctionnels en unités logiques. N'importe quel nombre de TestSuites peut être créé dans un projet SoapUI pour prendre en charge des scénarios de test massifs.

Création de TestSuite

Step 1 - Dans un projet, faites un clic droit sur l'interface (à côté du nom du projet) puis cliquez sur «Générer TestSuite».

Ici, SOAP - Example est un nom de projet tandis que CurrencyConvertorSoap et CurrencyConvertorSoap12 sont des interfaces.

Step 2- Un nouvel assistant s'ouvre. Sélectionnez les choix en fonction de l'exigence.

Step 3 - Une fois la sélection effectuée, cliquez sur OK.

Step 4- Cochez la case Generate LoadTest. Cela générera un LoadTest pour chaque TestCase créé dans cette TestSuite.

Step 5 - Entrez le nom de TestSuite dans le nouvel assistant, puis cliquez sur OK.

La TestSuite créée s'affiche dans le panneau de navigation comme illustré dans la capture d'écran suivante.

Step 6- Double-cliquez sur le nom de TestSuite et la fenêtre TestSuite s'ouvre dans le panneau de droite. Puisqu'aucun testCase n'est ajouté, il est vide.

Les propriétés de TestSuite sont visibles au bas du panneau de navigation. De nouvelles propriétés personnalisées peuvent être ajoutées au niveau TestSuite.

Un TestCase est une collection de TestSteps assemblés pour tester certains aspects spécifiques du ou des services Web. L'utilisateur peut ajouter n nombre de TestCases à un TestSuite et même les modulariser pour qu'ils s'appellent les uns les autres pour des scénarios de test complexes.

Création de TestCase

Step 1- Dans une TestSuite, l'utilisateur peut ajouter plusieurs cas de test. Cliquez avec le bouton droit sur la suite de tests et sélectionnez «Nouveau scénario de test».

Step 2 - Entrez le nom du TestCase et cliquez sur OK.

Le TestCase créé n'a actuellement aucune étape de test. TestCase est ajouté avec zéro TestSteps pour tous les types de tests disponibles. Une fois les TestSteps ajoutés, les nombres entre parenthèses changeraient automatiquement. Le TestStep fonctionnel doit entrer dans «Test Steps» tandis qu'un TestStep de performance doit aller dans «Load Test», et un TestStep de sécurité doit aller dans «Security Tests».

Step 3- Double-cliquez sur le nom TestCase, et une fenêtre TestCase s'ouvre sur le panneau de droite. Puisqu'il n'y a pas de TestSteps ajouté, il est vide comme le montre la capture d'écran suivante.

Les TestSteps sont les "blocs de construction" des tests fonctionnels dans SoapUI. Ceux-ci sont ajoutés à un TestCase et utilisés pour contrôler le flux d'exécution et valider la fonctionnalité du (des) service (s) Web à tester.

Insertion de TestStep

Step 1- Cliquez avec le bouton droit sur TestSteps. Ajoutez une étape et sélectionnez une étape de test appropriée dans la liste. Par exemple, si l'utilisateur doit tester un WebService REST, il sélectionne la demande de test REST.

Step 2 - Ajoutez un TestStep pour valider la requête SOAP importée en sélectionnant TestSteps → Add Step → SOAP Request.

Step 3 - Entrez le nom du TestStep et cliquez sur OK dans l'assistant.

En cliquant sur «OK», une boîte de dialogue apparaît pour sélectionner l'opération à appeler. Toutes les opérations sont répertoriées et les utilisateurs peuvent sélectionner l'opération qu'ils souhaitent appeler.

Deux opérations seront répertoriées. Les deux opérations sont identiques à l'exception de la version SOAP utilisée.CurrencyConvertorSoap utilise SOAP version 1.1 alors que, CurrencyConvertorSoap12 utilise SOAP version 1.2.

Step 4 - Sélectionnez le premier - CurrencyConvertorSoap et cliquez sur OK.

Lors de l'ajout d'un TestCase, différentes assertions standard peuvent être ajoutées. Les assertions sont également appelées points de contrôle / points de validation de la demande / réponse SOAP.

Step 5 - Créons un TestCase avec une option par défaut qui signifie créer un TestStep SANS aucun des points de validation suivants -

  • Vérifie si le message de réponse est SOAP, lors de l'exécution du test.
  • Vérifie si le schéma de réponse est valide.
  • Vérifie si la réponse SOAP contient FAULT.

Step 6 - En cliquant sur OK, la capture d'écran XML de demande suivante apparaît.

Le nombre d'étapes de test est maintenant incrémenté à un en tant que TestStep fonctionnel ajouté. De même, lors de l'ajout de TestSteps de charge et de sécurité, le nombre correspondant augmente automatiquement en fonction du nombre d'étapes ajoutées.

Demander la configuration

Ici, nous effectuerons la conversion de la devise de INR en USD.

  • FromCurrency - INR
  • ToCurrency - USD

Ensuite, entrez ces entrées à la place du point d'interrogation qui sera envoyé sous forme de requête XML. Après avoir placé ces valeurs dans les balises XML correspondantes, cliquez sur le bouton «Soumettre la demande» pour vérifier la réponse.

Réponse

Lors de la soumission d'une demande, la demande de service Web est traitée par le serveur Web et renvoie une réponse comme indiqué dans la capture d'écran suivante.

En lisant la réponse, on peut conclure qu'une unité d'INR = 0,0147 unité d'USD.

Requête HTTP

Les messages SOAP sont transportés par le protocole HTTP. Pour afficher la requête HTTP, cliquez sur RAW dans la fenêtre de requête SoapUI (côté gauche).

La demande est publiée sur le serveur Web. Par conséquent, la méthode POST de Http est utilisée.

La requête SOAP est transportée dans le corps du message http, qui est présenté comme suit.

POST http://www.webservicex.com/currencyconvertor.asmx HTTP/1.1 
Accept-Encoding: gzip,deflate 
Content-Type: text/xml;charset = UTF-8 
SOAPAction: "http://www.webserviceX.NET/ConversionRate" 
Content-Length: 353 
Host: www.webservicex.com 
Connection: Keep-Alive 
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)

Réponse HTTP

Cliquez sur l'onglet «RAW» dans la fenêtre de réponse SOAP-UI pour comprendre comment la réponse est envoyée via HTTP.

Après le traitement de la demande, le code de réponse http (200) est affiché, ce qui signifie qu'il s'agit d'un succès. Le serveur Web l'a traité avec succès.

La réponse SOAP est renvoyée au client dans le cadre du corps du message HTTP.

HTTP/1.1 200 OK 
Cache-Control: private, max-age = 0 
Content-Type: text/xml; charset = utf-8 
Content-Encoding: gzip 
Vary: Accept-Encoding 
Server: Microsoft-IIS/7.0 
X-AspNet-Version: 4.0.30319 
X-Powered-By: ASP.NET 
Date: Sun, 22 Jan 2017 19:39:31 GMT 
Content-Length: 316

Les codes HTTP suivants sont utilisés pour envoyer des réponses par le serveur Web et sont très utiles pour le débogage.

Code HTTP La description

1xx:

Informational - Cela signifie qu'une demande a été reçue et qu'un processus se poursuit.

2xx:

Success - L'action a été reçue, comprise et acceptée avec succès.

3xx:

Redirection - Cela signifie que des mesures supplémentaires doivent être prises afin de compléter la demande.

4xx:

Client Error - Cela signifie que la requête contient une mauvaise syntaxe ou ne peut pas être satisfaite.

5xx:

Server Error - Le serveur n'a pas répondu à une demande apparemment valide.

Les propriétés sont un aspect central des tests plus avancés avec SoapUI. Les propriétés des tests fonctionnels sont utilisées pour paramétrer l'exécution et la fonctionnalité des tests.

  • Les propriétés peuvent être utilisées pour contenir les points de terminaison des services, ce qui facilite la modification des points de terminaison réels utilisés pendant l'exécution du test.

  • Les propriétés peuvent être utilisées pour conserver les informations d'authentification, ce qui facilite leur gestion dans un emplacement central ou dans un fichier externe.

  • Les propriétés peuvent être utilisées pour transférer et partager les identifiants de session pendant l'exécution du test, de sorte que plusieurs étapes de test ou scénarios de test peuvent partager les mêmes sessions.

Définition des propriétés

Les propriétés peuvent être définies à plusieurs niveaux dans un projet.

  • Les propriétés communes au niveau du projet peuvent être définies au niveau du projet.

  • De même, les propriétés spécifiques à TestSuite et TestCase peuvent être définies à leurs niveaux respectifs.

  • Les propriétés spécifiques au projet sont définies dans l'onglet Propriétés personnalisées.

Par exemple, une propriété «ToCurrency» peut être définie au niveau du projet en cliquant sur le symbole «+» et en entrant le nom et la valeur de la propriété.

Accès à la propriété

Une propriété est accessible n'importe où dans le projet à l'aide de l'extension de propriété.

La structure serait comme -

  • $ {# Project # PropertyName} - Pour le niveau du projet

  • $ {# TestSuite # PropertyName} - Pour le niveau de la suite de tests

  • $ {# TestCase # PropertyName} - Pour le niveau de scénario de test

  • $ {TestStepName # PropertyName} - Pour le niveau Étape de test

  • $ {# MockService # PropertyName} - Pour la propriété MockService

  • $ {# Global # PropertyName} - Pour les propriétés globales, trouvé dans Fichier → Préférences → onglet Propriétés globales. Cette propriété peut être utilisée dans tous les projets

  • $ {# System # PropertyName} - Pour la propriété système, trouvée dans Aide → Propriétés système

  • $ {# Env # PropertyName} - Pour la variable d'environnement

La même structure peut être placée dans Request XML pour obtenir la valeur d'un attribut spécifique pendant l'exécution.

Une propriété peut également être considérée comme une variable dans un programme informatique. Si l'utilisateur veut définir quelque chose qui peut être utilisé ailleurs aussi, les propriétés sont très utiles. Les propriétés peuvent également être définies de manière dynamique, mais elles dépendent du script Groovy.

Parfois, il est nécessaire d'extraire une valeur d'un message de réponse et de l'inclure dans la ou les demandes suivantes. Dans un tel cas, nous avons besoin d'un mécanisme pour récupérer une valeur spécifiée et la transférer aux autres éléments du projet. SoapUI prend en charge ces fonctionnalités via le Property Transfer TestStep.

Ajouter un transfert de propriété

Step 1 - Sélectionnez TestCase ou TestStep, cliquez avec le bouton droit de la souris → Ajouter des étapes → Transfert de propriété.

Step 2 - Entrez le nom du TestStep et cliquez sur OK.

Step 3 - L'étape RateTransfer est ajoutée et un nouvel assistant s'ouvre.

Step 4- Cliquez sur l'icône Ajoute un nouveau transfert de propriété + dans le coin supérieur gauche de la fenêtre de transfert de propriété. Il sera invité à entrer un nom pour le transfert. Entrez Taux et cliquez sur OK.

Transférer une propriété

Une fois le transfert créé, Source et Target panesdevez spécifier les expressions XPath appropriées pour extraire et remplacer les valeurs de propriété. Dans la liste déroulante à côté de Source, différents niveaux de projets SoapUI sont répertoriés et peuvent être utilisés comme source de transferts de propriété. Par défaut, le TestStep le plus proche sera affiché.

Dans ce cas, c'est le Request – INR to USDTestStep. La liste déroulante en regard de Propriété affiche la propriété source utilisée dans le transfert, qui peut être une demande, une réponse ou un point de terminaison de service.

Step 1- Sélectionnez Réponse et accédez à Langue du chemin. L'utilisateur peut sélectionner XPath, Xquery ou Jason pour définir la propriété. Dans ce cas, sélectionnez XPath.

Step 2 - Pour obtenir la déclaration du xml source, cliquez sur ns et spécifiez XPath.

Step 3- Spécifiez la cible où la valeur extraite de l'expression XPath ci-dessus doit être transférée. Le volet cible est utilisé en bas de la fenêtre de transfert de propriété pour cela.

Step 4 - Transférer la valeur extraite de ConversionRateResult à partir de la réponse de l'étape RequestINRtoUSD.

Target - Propriétés

Property - ConversionRate (une nouvelle propriété ajoutée, elle n'a aucune valeur au départ).

Step 5 - Une fois le scénario de test exécuté avec succès, la propriété «ConversionRate» est mise à jour en fonction de la réponse.

Voici la capture d'écran au départ.

Voici la capture d'écran après une exécution réussie.

De même, Target peut être un XML de requête suivant. Si la cible est une requête SOAP, nous devons fournir XPath pour identifier l'attribut cible.

Le volet Journaux stocke les informations complètes concernant la transaction entre le client et le serveur. Les utilisateurs pourront voir les différents onglets du volet du journal. Nous discuterons des volets de journal les plus couramment utilisés lors de l'utilisation de SoapUI dans ce chapitre.

Journal SoapUI

Le journal SoapUI affiche les informations de réponse du serveur Web. Les mêmes informations sont stockées dans le fichier soapui.log du dossier installé SOAP-UI sous le répertoire 'bin'.

Journal HTTP

Le journal HTTP affiche tous les transferts de paquets HTTP. Toutes les informations en «RAW» sont affichées dans le journal HTTP.

Journal des erreurs

Le journal des erreurs affiche toutes les erreurs rencontrées pendant toute la session du projet. Les mêmes informations sont disponibles dans 'soapui-errors.log' présent dans le répertoire 'bin' de l'emplacement d'installation de SoapUI.

Journal de la mémoire

Cet onglet surveille la consommation de mémoire et l'affiche sous la forme du graphique, comme illustré dans la capture d'écran suivante. C'est vraiment utile lorsqu'une opération gourmande en mémoire est effectuée.

L'assertion peut être interprétée comme un point de contrôle ou un point de validation. Une fois qu'une demande est envoyée à un serveur Web, une réponse est reçue. Il est nécessaire de valider la réponse qui contient les données comme prévu ou non. Afin de valider la réponse, SoapUI dispose d'une fonction d'assertions.

Points à noter

  • Les assertions sont utilisées pour valider le message reçu par un TestStep pendant l'exécution.

  • Il compare la partie du message ou le message entier à une valeur attendue.

  • N'importe quel nombre d'assertions peut être ajouté à un TestStep, chacun validant un aspect et un contenu différents du message de réponse.

  • Après l'exécution d'un TestStep, toutes ses assertions sont appliquées à la réponse reçue et si l'une d'elles échoue, TestStep est marqué comme ayant échoué dans la vue TestCase.

  • L'entrée ayant échoué s'affiche dans le journal d'exécution du test.

Type d'assertions

SoapUI prend en charge un large éventail d'assertions en réponse.

Voici la liste des affirmations prises en charge par SoapUI.

Affirmation La description
Property Content
Contient Vérifie l'existence de la chaîne spécifiée. Il prend également en charge les expressions régulières.
Ne contient pas Vérifie la non-existence de la chaîne spécifiée. Il prend également en charge les expressions régulières.
Match XPath Utilise l'expression XPath pour sélectionner le nœud cible et ses valeurs. Compare le résultat d'une expression XPath à une valeur attendue.
Correspondance XQuery Utilise une expression Xquery pour sélectionner le contenu de la propriété cible. Compare le résultat d'une expression XQuery à une valeur attendue.
Compliance, Status, Standards
HTTP DOwnload All Resource Télécharge toutes les ressources référencées comme un document HTML (images, scripts, etc.) et valide qu'elles sont toutes disponibles. Applicable à toute propriété contenant du HTML.
Codes d'état HTTP non valides Vérifie que le TestStep cible a reçu un résultat HTTP avec un code d'état ne figurant pas dans la liste des codes définis. Applicable à tout TestStep qui reçoit des messages HTTP.
Pas de faute SOAP Valide que le dernier message reçu n'est pas une erreur SOAP. Applicable aux étapes de test SOAP.
Conformité du schéma Valide que le dernier message reçu est conforme à la définition de schéma WSDL ou WADL associée. Applicable aux étapes de test SOAP et REST. L'URL de définition de schéma prend en charge les extensions de propriétés (par exemple $ {# System # my.wsdl.endpoint} / services / PortType? Wsdl).
Défaut SOAP Valide que le dernier message reçu est une erreur SOAP. Applicable à SOAP TestSteps SOAP Request - valide que la dernière demande reçue est une demande SOAP valide. Applicable uniquement aux étapes du test MockResponse.
Réponse SOAP Valide que la dernière réponse reçue est une réponse SOAP valide. Applicable uniquement aux étapes SOAP TestRequest.
Codes d'état HTTP valides Vérifie que le TestStep cible a reçu un résultat HTTP avec un code d'état dans la liste des codes définis. Applicable à tout TestStep qui reçoit des messages HTTP.
Demande d'adressage WS Valide que la dernière demande reçue contient des en-têtes d'adressage WS valides. Applicable uniquement aux étapes de test MockResponse.
Réponse WS-Addressing Valide que la dernière réponse reçue contient des en-têtes d'adressage WS valides. Applicable uniquement aux étapes SOAP TestRequest.
État de la sécurité WS Valide que le dernier message reçu contenait des en-têtes WS-Security valides. Applicable aux étapes de test SOAP.
Script
Assertion de script Permet aux utilisateurs d'exécuter un script personnalisé pour effectuer des validations définies par l'utilisateur. Applicable uniquement aux TestSteps (c'est-à-dire pas aux propriétés)
SLA
SLA de réponse Valide si le temps de réponse de la dernière réponse reçue était dans la limite définie. Applicable aux Script TestSteps et TestSteps qui envoient des demandes et reçoivent des réponses.
JMS
Statut JMS Valide que la demande JMS du TestStep cible est exécutée avec succès. Applicable à Request TestSteps avec un point de terminaison JMS.
Délai JMS Valide que l'instruction JMS du TestStep cible n'a pas pris plus de temps que la durée spécifiée. Applicable à Request TestSteps avec un point de terminaison JMS.
Security
Exposition aux informations sensibles Vérifie si le message de réponse n'expose pas d'informations sensibles sur le système cible. Nous pouvons utiliser cette assertion pour les tests REST, SOAP et HTTP.
JDBC
État JDBC Valide que la requête JDBC du TestStep cible a été exécutée avec succès. Applicable uniquement aux TestSteps JDBC.
Délai JDBC Valide que l'instruction JDBC du TestStep cible n'a pas pris plus de temps que la durée spécifiée. Applicable uniquement aux TestSteps JDBC.

Dans SoapUI, les utilisateurs sont confrontés à de nombreux problèmes communs génériques qui pourraient être résolus avec un peu de vigilance. Certains de ces problèmes les plus courants sont les suivants:

Issue- L'espace de noms est mal défini. Utilisez l'espace de noms correct. L'espace de noms doit être l'URL où se trouve le service Web.

Solution - Si une erreur est générée lors du développement d'une assertion de script, utilisez 'log.info' pour imprimer le contenu des variables.

Issue - Si un code d'erreur est reçu comme réponse XML, cela peut être dû à une entrée invalide.

Solution - Vérifiez l'entrée de la requête XML.

Example - Dans le convertisseur de devises, si l'entrée de la 'FromCurrency' est '123' qui n'existe pas, la sortie renvoie un code d'erreur comme 'SOAP-Client', ce qui signifie que le problème est lié au paramètre qui est passé depuis le côté client.

Demande

Réponse

Issue - Aucune correspondance dans la réponse actuelle lors de l'utilisation de XPath ou XQuery.

Solution -

  • Utilisez la syntaxe correcte lors de la définition de XPath ou XQuery.
  • Vérifiez que deux points sont utilisés et non point lors de la déclaration de l'espace de noms.
  • Assurez-vous que XPath et XQuery sont corrects.

Les tests de performances sont l'un des points de contrôle importants les plus courants dans les tests de services Web. Les tests de performances sont définis comme la création ou la simulation artificiellement de la charge et la mesure de la manière dont l'environnement la gère.

Cela signifie qu'il n'est pas nécessaire que le système fonctionne sous une charge élevée, mais aussi comment il fonctionne sous une charge de base ou une charge attendue. Il n'a même pas besoin d'être structuré, automatisé ou créé dans TestWare tel que SoapUI; Le simple fait de rafraîchir le navigateur Web encore et encore très rapidement est également un test de charge.

Types de tests de performance

Voici les types de tests de performance -

  • Baseline Testing - Examine comment un système fonctionne sous une charge attendue ou normale et crée une base de référence par rapport à laquelle les autres types de tests peuvent être comparés.

  • Load Testing- Comprend l'augmentation de la charge et voir comment le système se comporte sous une charge plus élevée. Pendant les tests de charge, l'utilisateur peut surveiller les temps de réponse, le débit, l'état du serveur et bien plus encore. Le but du test de charge n'est pas de briser l'environnement cible.

  • Soak Testing - Le but des tests est de s'assurer qu'aucun comportement indésirable n'apparaît sur une période plus longue.

  • Scalability Testing- Le test d'évolutivité ressemble beaucoup au test de charge, mais au lieu d'augmenter le nombre de requêtes, il augmente la taille ou la complexité des requêtes envoyées. Par exemple, l'envoi de requêtes volumineuses, de pièces jointes volumineuses ou de requêtes profondément imbriquées.

Aspects clés du service Web

Deux aspects ressortent des caractéristiques uniques des performances des services Web.

Premier aspect

Du côté du serveur, le traitement XML / JSON est en cours, à la fois l'analyse XML / JSON et la sérialisation . La chose qui échoue souvent en premier est le traitement des charges utiles. Les raisons de l'échec peuvent être multiples; il peut s'agir de la plate-forme, des faiblesses du serveur d'applications ou d'un problème d'implémentation sous la forme de WSDL inutilement complexes. Cela pourrait également signifier que le code envoie une demande à une base de données qui répond lentement.

Testing Aspect- La complexité de l'analyse de la charge utile XML / JSON signifie qu'il est nécessaire de se concentrer davantage sur les tests d'évolutivité. Cela signifie également que les WSDL doivent être examinés de près. Si les demandes et les réponses sont complexes ou plus volumineuses, ou si elles incluent des pièces jointes volumineuses, l'accent doit être mis sur l'accentuation de la complexité et de voir comment il se comporte sous charge.

Deuxième aspect

Un autre facteur fréquemment rencontré est la sécurité. Les sites sécurisés derrière HTTPS ont des performances considérablement inférieures et dans les tests de services Web, nous pouvons ajouter une couche de sécurité WSSecurity à la couche de sécurité HTTP, ce qui diminue encore plus les performances.

Testing Aspect- La question des moyens de sécurité, il faut se concentrer sur la réalisation de tests de requêtes sécurisées. Si l'ensemble du service Web est sécurisé, cela signifie que le test de charge est plus important, en particulier si WS-Security et la gestion des jetons sont utilisés.

Load testingest une forme spécifique de test de performance qui est effectuée pour évaluer le comportement du système sous une charge spécifique. Dans SoapUI, nous utilisons généralement le terme «test de charge» pour tous les types de tests non fonctionnels, cependant SoapUI prend en charge tous les types d'évaluation des performances des services Web tels que la charge, le stress et l'endurance.

Points à noter

  • Le test de charge est assez unique dans SoapUI; un cas de test fonctionnel qui permet de créer et de modifier rapidement des tests de performance.

  • Le principal différenciateur est que les tests de performance dans SoapUI sont généralement créés à partir des tests fonctionnels existants. Cela permet de créer rapidement des tests de performances avancés.

  • Les performances du service Web peuvent être validées dans différents scénarios de charge. Maintenez les validations fonctionnelles pour voir qu'elles ne se cassent pas sous la charge, exécutez plusieurs tests de charge simultanément pour voir comment elles se touchent et bien plus encore.

Création du test de charge

Step 1 - Cliquez avec le bouton droit sur Cas de test fonctionnel et sélectionnez Nouveau test de charge.

Step 2 - Entrez le nom de Load Test et cliquez sur OK dans l'assistant de dialogue.

Le test de charge s'ouvre et le test de charge est créé comme indiqué dans la capture d'écran suivante.

Exécution du test de charge

Lorsqu'un nouveau test de charge est créé, il est préconfiguré pour s'exécuter pendant 60 secondes (en haut à droite) avec 5 threads en utilisant la stratégie de chargement simple.

Modifiez ces valeurs selon les exigences et exécutez. Note - L'utilisateur doit connaître la configuration et les concepts du test de charge.

L'utilisateur verra le tableau des statistiques au milieu, en commençant par la collecte des données et après 60 secondes devrait avoir un LoadTest terminé.

Ajouter une assertion

Step 1 - Dans l'éditeur LoadTest, sélectionnez l'onglet LoadTest Assertion en bas de l'éditeur.

Step 2 - Cliquez sur le bouton Ajouter une assertion dans la barre de menus LoadTest Assertion pour ajouter une assertion.

Step 3- La boîte de dialogue Ajouter une assertion s'ouvre. Sélectionnez Pas maximum. Sélectionnez Maximum définit un temps maximum en millisecondes que les réponses sont autorisées à prendre, si le temps dépasse ce que nous avons défini, le test échouera. Cliquez sur OK.

Step 4- La fenêtre TestStep Max Assertion s'ouvre. Comme le montre la capture d'écran suivante, nous autorisons une réponse maximale d'une seconde, 1000 millisecondes. Ne modifions rien. Cliquez sur OK.

L'assertion Step Maximum sera maintenant ajoutée avec succès.

Step 5- Exécutez à nouveau le test. Si les réponses prennent trop de temps, vous devriez voir les nombres dans la colonne err s'additionner rapidement.

Un service Web est un ensemble de protocoles et de normes ouverts utilisés pour l'échange de données entre des applications ou des systèmes. Les applications logicielles écrites dans divers langages de programmation et fonctionnant sur diverses plates-formes peuvent utiliser des services Web pour échanger des données sur des réseaux informatiques tels qu'Internet d'une manière similaire à la communication inter-processus sur un seul ordinateur. Cette interopérabilité (par exemple, entre Java et Python, ou entre les applications Windows et Linux) est due à l'utilisation de standards ouverts.

Les services Web basés sur l'architecture REST sont appelés services Web RESTful. Ces services Web utilisent des méthodes HTTP pour implémenter le concept d'architecture REST. Un service Web RESTful définit généralement un URI (Uniform Resource Identifier), qui est un service qui fournit une représentation des ressources telle que JSON et un ensemble de méthodes HTTP.

Toutes les capacités de test REST de SoapUI sont basées sur une représentation logique appelée service REST. Nous ne devons pas confondre cela avec le terme «service» ici, car ce n'est pas une implémentation de service mais un mappage du service RESTful qui est appelé. Nous pouvons ajouter autant de services REST que possible dans un projet SoapUI. Chacun représente un service RESTful particulier. Ils sont les suivants -

SoapUI permet de gérer le fonctionnement de la base de données à l'aide d'un TestStep appelé JDBC Request.

Step 1 - Cliquez avec le bouton droit sur TestStep et sélectionnez Ajouter une étape → Demande JDBC.

Step 2 - Entrez le nom de l'étape et cliquez sur OK.

L'étape JDBC est ajoutée. Double-cliquez sur l'étape et l'assistant JDBC s'ouvre.

Pour créer une connexion JDBC, l'utilisateur doit fournir un pilote et une chaîne de connexion valides. Ces paramètres sont utilisés pour identifier le type de base de données et créer une connexion pour utiliser la base de données.

Pour MySQL, le pilote de base de données peut être com.mysql.jdbc.Driver. De même, pour les autres bases de données, il existe un pilote prédéfini qui peut être trouvé dans la section document de la base de données.

Step 3 - La chaîne de connexion doit être au format suivant -

Jdbc:mysql://[host]:[port]/[database]?[property][=value]

Ici, la propriété est le nom d'utilisateur et le mot de passe ainsi que d'autres paramètres requis pour se connecter à une base de données.

Par exemple,

jdbc:mysql://localhost:8089/xxx_DB?user=root&password=root

Step 4- Cliquez sur Tester la connexion. En cas de connexion réussie, il affichera SUCCESS, sinon fournira les détails de l'échec.

JDBC a sa propre section Add property qui peut être utilisée comme variable dans SQL Query.

Voyons comment il se comporte -

Supposons que la requête SQL qui doit être exécutée dans l'étape JDBC est Select * from Currency où CurrencyCode = 'xxx'.

Dans ce scénario, CurrencyCode peut être modifié en fonction de l'entrée de la demande. Si l'utilisateur fournit une valeur codée en dur, l'étape JDBC ne s'exécutera pas pour la devise indiquée dans la demande.

Pour surmonter de tels scénarios, JDBC prend en charge la propriété add, où un code de propriété peut être défini et il continuera à changer à l'aide de l'étape de transfert de propriété.

SQL Query s'exécutera en fonction de la valeur actuelle du code de propriété et SQL Query paramétrera le CurrencyCode =: Code.

Cliquez sur Ajouter une propriété + et le nom en tant que code et donnez une valeur ou laissez vide pour utiliser l'étape de transfert de propriété pour la fournir.

La requête JDBC peut également utiliser la plupart des assertions avec la requête SOAP TestSteps. Dans SoapUI, la plupart de ces assertions sont indépendantes de TestSteps. Par conséquent, les assertions telles que Contains et XPath Match peuvent être utilisées avec JDBC Request TestStep.

En cliquant sur le Add an assertion dans le menu supérieur de JDBC Request TestStep, l'utilisateur peut découvrir quelles assertions sont prises en charge par TestStep.

En plus des assertions génériques, il existe deux assertions spécifiques JDBC Request TestStep -

JDBC Timeout - Cette assertion peut être utilisée pour vérifier si la requête SQL actuelle est exécutée dans la valeur de la propriété Query Timeout spécifiée.

JDBC Status - Afin de vérifier si l'instruction SQL est exécutée avec succès, nous pouvons utiliser l'assertion JDBC Status.

Pour définir le délai d'expiration de la requête, indiquez la valeur respective du délai d'expiration de la requête de propriété sur le côté gauche de l'écran. Gardez à l'esprit qu'il accepte une valeur en millisecondes (ms).