Pour tester des web services, il n’existe pas énormément de solutions open-source. Je vous en propose 2 en fonction du type de tests que vous souhaitez réaliser. Apache JMeter est l’outil open-source de tests connu et reconnu. Il est généralement utilisé pour tester les performances et la montée en charge de pages web. Il permet également de tester des bases de données, des serveurs FTP, et bien d’autres ressources. Et, depuis peu, il propose un sampler SOAP (encore en version béta) permettant de simuler des clients (threads) interrogeant un WebService. Au niveau facilité d’utilisation, il y a encore des efforts à faire. Aucune aide n’est proposée pour générer le message SOAP. Il faut donc écrire (ou générer avec un autre outil) le message dans la zone de texte. Il est également possible de fournir un fichier texte contenant une liste de message SOAP à utiliser pour le test. Pour ceux qui veulent tester des web services compatibles MTOM, oubliez. La version actuelle du sampler ne supporte pas très bien. Il vous dira que votre réponse est invalide et n’affichera que l’entête. Cela suffit pour des tests de charge mais pas pour des tests fonctionnels. Ajoutez un sniffer TCP si vous voulez voir le message compatible MTOM reçu. Eviware soapUI est moins connu mais spécialisé dans le test des web services. Il propose quelques fonctionnalités dans la version open-source qui dépasse un peu l’objectif du produit, parmi lesquelles on trouve la génération de code pour Axis 1 et 2, xFire et même pour le très récent CXF d’Apache. Très facile d’utilisation, il s’impose comme le couteau-suisse des WS-addicts. Il n’a, à mon avis, qu’un défaut : il n’est pas (encore) capable de répartir les clients de tests sur plusieurs machines, ce que fait très bien JMeter. Ce n’est pas trop grave pour des tests fonctionnels, mais dès qu’on veut exécuter des tests de charge avec un nombre conséquent de clients (threads) simultanés et que la machine sur laquelle s’exécute l’outil de tests n’est pas à la hauteur, on se rend compte de l’importance de cette possibilité offerte par JMeter. En conclusion, par son ergonomie et les fonctionnalités offertes, soapUI reste le leader incontestable du test de web services en open-source. Par contre, pour les gros tests de charge (nombre élevé de threads), quand la machine cliente atteint ses limites et risque de fausser les résultats, il faudra préférer JMeter. . . . → Lire la suite: Test de Web Services : JMeter vs. soapUI
|
||||||
 |
Ceux qui ont déjà exécuté des tests de charge, savent que la machine cliente (celle qui simule les utilisateurs) est aussi importante que le serveur testé. Si la machine cliente est incapable de simuler correctement le nombre d’utilisateurs voulu à cause d’un processeur trop faible, d’un manque de mémoire vive, d’un disque dur trop lent, le serveur ne sera pas suffisament stressé et les résultats seront faussés. Une première solution serait donc d’avoir une machine sur-dimensionnée dédiée uniquement aux tests de charge. Reste que dimensionner correctement une telle machine peut s’avérer difficile et est dépendante de l’outil de tests utilisé et du mode d’utilisation (interface graphique ou ligne de commande). C’est d’autant plus vrai lors des tests de charge aux limites où les demandes en ressources (CPU, RAM, HD, …) seront de plus en plus importante. Si la machine de tests craque avant le serveur, il ne reste plus qu’à investir dans du nouveau matériel. Apache JMeter propose une alternative : le déclenchement de tests à distance. Il s’agit de mutualiser les ressources de plusieurs machines d’un même réseau pour exécuter un test JMeter. Le déclenchement se fait de façon synchronisée depuis une des machines, soit via l’interface graphique de JMeter, soit par ligne de commande. Concrètement, l’opération se fait en 3 étapes : 1. Démarrage de serveurs RMI JMeter sur chaque machine “esclave” 2. Enregistrement des noms réseaux (ou adresses IP) sur la machine “maître” 3. Déclenchement du test depuis la machine “maître” (interface graphique ou ligne de commande) Note 1 : La machine “maître” peut également être “esclave”. Note 2 : Attention aux firewalls entre les machines du réseau. Le port RMI par défaut (1099) peut être modifié. Conclusion : Quand vous n’avez à votre disposition que des machines moyennes pour stresser un super-serveur, pensez à mutualiser leurs ressources avant d’envisager l’achat d’une nouvelle machine. Pour les détails sur ce sujet, jetez un oeil sur le manuel utilisateur de JMeter. . . . → Lire la suite: Remote testing avec JMeter |
|
||||
|
Copyright © 2012 Blog d’Ippon Technologies - All Rights Reserved |
||||||
