Il faut ajouter un nouveau test de charge sur le TestCase voulu.
Note: il faut savoir que le test de charge va lancer tous les tests en parallèle, donc il ne faut pas qu’il y a de dépendance entre les services du TestCase, car ceci pourrait fausser vos résultats.

Une fenêtre s’ouvre, il est possible de choisir la stratégie de test et de la configurer.
A savoir : la durée du test, le nombre de threads à utiliser, le délai (aléatoire ou non) entre chaque nouvelle requête, etc.

Sur cette image on peut se rendre compte qu’un service qui renvoie une stacktrace d’exception est couteuse en temps et en données.

Le tableau de résultat affiche : le temps de réponse min max moyen, le nombre de requêtes totales lancées lors du test, le total de données transférées, le nombre d’erreur.

De plus, la console de log en dessous permet d’avoir des détails sur les tests déroulés, comme l’heure de début et de fin du test, les éventuelles erreurs, etc …

Si vous avez une série de requêtes dans votre Test case, il est préférable de créer un script qui se chargera de vous pré-remplir ces champs plutôt que de le faire à la main

Il faut créer un nouveau « step » nommé ‘Groovy Script’.

Voici un exemple de code qui pré-rempli les champs ‘login’ et ‘password’. Ces valeurs doivent être déclarées et initialisées dans l’onglet « Custom Properties » du projet (il s’affiche en cliquant sur le nom du projet).

Entrez ensuite le code du script :

Un petit Copier-(Réfléchir*)-Coller du code suivant simplifiera le travail !             (* © F.D.)

def groovyUtils = new com.eviware.soapui.support.GroovyUtils( context )
//variables definitions
def login = '${#Project#login}'
def password = '${#Project#password}'

//Retrieves all TestSteps of the current testCase
log.info("* " + testRunner.testCase.name )
def testStepList = testRunner.testCase.getTestStepList()

testStepList.each{currentTestStep->
    if (currentTestStep.name != "Inits fields") { //ici liste des steps que le script ne doit pas modifier
        log.info(" \\-- " + currentTestStep.name )
        def holder = groovyUtils.getXmlHolder( currentTestStep.name+"#Request" )
        log.info(" " + 'holder' )
        holder.namespaces["ns"] = "http://schemas.xmlsoap.org/soap/envelope/"

        //Inits values of the current testStep
        log.info(" " + 'login' )
        holder.setNodeValue("//ns:Body/*/login", login)
        log.info(" " + 'password' )
        holder.setNodeValue("//ns:Body/*/password", password)

        //Updates the change
        holder.updateProperty()
    }
}
'Script OK'

Voici la requête une fois le script exécuté :

Note : pour éviter de faire un copier-coller du code à chaque Test case, il est possible de cloner ce « step » et le déplacer dans un autre Test case

Comme nous l’avons vu chacun de nos tests unitaires se trouve dans un arbre. Il est alors possible de lancer l’ensemble des tests de la suite, ou toutes les étapes d’un scénario, simplement en double cliquant sur le nœud correspondant de l’arbre. (Nœuds : TestSuite ou TestCase)

Une fenêtre s’ouvre et permet de voir les résultats

A peine plus compliqué, il est aussi possible de récupérer une valeur dans une réponse et de l’injecter dans le test suivant.

Exemple d’utilisation : Dans nos jeux de tests, on veut réaliser l’enchainement suivant :

• Créer une commande (createOrder)
• Annuler la commande qui vient d’être créée (cancelRequestNumber)

sachant que ce dernier service prend en paramètre un « request number » qui est renvoyé dans la réponse du « createOrder ».

Pour récupérer cette valeur et remplir notre requête « cancelRequestNumber », on utilise la fonctionnalité offerte par soapUI : le « Property Transfer ».

La valeur à récupérer (la « Source ») :

Le champ à remplacer (la « Target ») :

On ajoute un « step » ‘Property Transfer’ à notre Test Case « PropTransfer » :

On donne un nom au remplacement automatique qui sera effectué, à chaque exécution des tests :

On configure les chemins vers les champs qui nous intéressent :

Les chemins représentent les nœuds XML, de la requête et de la réponse SOAP, à parcourir pour atteindre les champs voulus

On place maintenant le « step » ‘Property Transfer’ entre les 2 tests (createOrder et cancelRequestNumber), de façon à obtenir un enchainement logique dans notre TestCase ‘PropTransfer’ :

On peut maintenant dérouler l’ensemble du Test Case

Je vous propose de découvrir dans cet article comment utiliser SoapUI pour réaliser des tests unitaires.

Pour étayer la suite de mon propos, je vais utiliser les 2 web services (basiques ) suivants :

Enregistrer les WSDL dans des fichiers XML pour obtenir les fichiers NewWebService1.xml et NewWebService2.xml.

Créer un nouveau projet dans SoapUI

Nommer le nouveau projet

Ajouter les WSDL à tester

Ajout du premier WSDL

« Create TestSuite » : génère les tests de chaque API du Web Service
« Create MockService » : génère des bouchons pour chaque méthode du Web Service

On obtient l’arborescence suivante :

On crée la TestSuite qui va contenir tous nos tests

On ajoute un TestCase qui va contenir un scénario de tests
(Il suffira d’ajouter un nouveau TestCase pour un autre scénario)

On obtient l’arborescence suivante :

Nous allons maintenant ajouter toutes les étapes de notre scénario de test

Premièrement, on va tester la méthode « Hello » du Web Service n°1

Il est possible de préconfigurer certaines assertions dès la création

On configure la valeur « Toto » dans le SAOP qui sera envoyé pour ce test

On ajoute une assertion de type « Contains » car on sait que la réponse devra contenir la chaîne de caractères : « Hello Toto »

On peut dérouler le test qui vient d’être créé

Tout s’est correctement déroulé, on va maintenant ajouter une autre étape à notre scénario : le test de la méthode « Format » du Web Service n°2

On va tester que la méthode renvoie bien une exception quand on passe la valeur « -1 » en paramètre

La case « Not SOAP Fault » doit être décochée puisque dans notre test on veut s’assurer de recevoir une SOAP Fault

On ajoute l’assertion de « SOAP Fault », après avoir passé la valeur « -1 » dans le SOAP de la requête

On sait aussi que l’exception contient le message : « erreur de valeur ». On peut donc ajouter une assertion « Contains » sur cette chaine de caractères

On déroule le test pour s’assurer que nos assertions fonctionnent

Simple et efficace

Dans des prochains articles je vous expliquerai comment relancer et automatiser ces tests et comment faire des tests de charges.