Pruebas funcionales de servicios web con soapUI
Indice
- Pruebas funcionales de servicios web con soapUI 3.0.1
Introducción
Las pruebas unitarias en cualquier paradigma de programación son, más que una buena práctica, una garantía para obtener un software robusto y (más) fácilmente mantenible. Como responsables de diseño o desarrollo de web services hemos de aplicar estas buenas prácticas, y soapUI es una herramienta fenomenal para ello, como veremos a continuación.
A propósito de lo anterior, Leo Antolí (evangelizador de las metodologías ágiles y experto en Autentia) nos recomendó el podcast #64 de javaHispano sobre Test de Aplicaciones. Os invitamos a escucharlo.
Prerrequisitos
Este tutorial se ha desarrollado bajo el siguiente entorno:
- soapUI 3.0.1. Podemos encontrar una introducción a la herramienta en el tutorial: soapUI: jugando con web services
- El web service desarrollado en el tutorial Contract-First web services con Visual Studio 2008, y cuyo código fuente puede descargarse aquí: wsEncriptacion_adictosaltrabajo.zip y ser ejecutado tanto en Microsoft Visual Studio 2008 como en la versión de libre uso Visual Studio 2008 Express del Visual Web Developer 2008 Express Edition
Crear el proyecto en soapUI
Una vez tenemos el web service publicado, accedemos a soapUI y desde el menú File | New soapUI Project, creamos un proyecto para el tutorial con los datos:
- Nombre: Pruebas Funcionales
- WSDL: http://localhost:49193/Service1.asmx?WSDL
- Dejamos activado el checkbox: Create ample requests for…
- Marcamos la opción: Creates a TestSuite for the imported WSDL…
Nuevo proyecto soapUI
OK al diálogo siguiente:
Opciones para generar pruebas de cada operación
Aceptamos el nombre propuesto por defecto:
Aceptamos el nombres propuesto
De igual manera aceptamos el resto de ventanas que aparecen. Al final tendremos la estructura del proyecto:
Proyecto de pruebas recién creado
En adelante vamos a trabajar únicamente con la suite de pruebas de una de las interfaces: Service1Soap TestSuite (hacerlo para la de SOAP 1.2 sería idéntico). Lo primero que vemos en el proyecto es que cada TestSuite tiene una batería de casos de pruebas para cada operación (TestCase) y cada batería se conforma de un conjunto de pasos o pruebas unitarias (Test Steps ()) .
Pruebas de servicios web sobre SOAP
Como vemos en la imagen, soapUI permite definir hasta diez tipos de pruebas unitarias (botón derecho sobre Test Steps () | Add Step):
TestSteps en soapUI
En el tutorial nos vamos a centrar en pruebas de invocaciones sobre SOAP (que figura como Test Request) y los tipos de comprobaciones (assertions) permitidas.
Pruebas sobre el SOAP response
Pulsando dos veces sobre el nodo Encriptar, accedemos al editor de pruebas con un mensaje SOAP request construido según el Schema del servicio:
Editor de pruebas
Creamos un mensaje SOAP request hacia la operación Encriptar con valores de ejemplo sustituyendo los ?:
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"xmlns:tem="http://tempuri.org/"> <soap:Header/> <soap:Body> <tem:Encriptar> <!--Optional:--> <tem:request> <!--Optional:--> <tem:Encriptar> <!--Optional:--> <original>Lorem ipsum dolor sit</original> <!--Optional:--> <clave>autentia2009</clave> <usarHashing>true</usarHashing> </tem:Encriptar> </tem:request> </tem:Encriptar> </soap:Body> </soap:Envelope>
Sobre este mismo moensaje vamos a añadir algunas comprobaciones. Pulsamos sobre el botón 
(a la derecha de la fecha verde), podemos seleccionar una aserción:
Assertions disponibles para pruebas SOAP
En primer lugar, comprobamos que el mensaje SOAP response es válido según un Schema. Seleccionamos la aserción Schema Compliance, pulsamos Aceptar, y nos preguntará en la siguiente ventana por la definición de datos Schema a aplicar. Introducimos la localización del WSDL de nuestro servicio (http://localhost:49193/Service1.asmx?WSDL):
Pulsando sobre la palabra Assertions en la parte inferior del editor, podemos ver la lista de ellos a medida que los añadimos:
Lista de aserciones introducidas
Añadimos una nueva aserción, en este caso de tipo Contains, y en la siguiente ventana de opciones introducimos el valor: (?s).*EncriptarResult.*{2}+ y seleccionamos que sea una expresión regular, para comprobar que el token EncriptarResult aparece dos veces en la respuesta:
Comprobar que el SOAP response contiene determinado token
Añadimos otra aserción de tipo NotSoapFault para comprobar que el mensaje de respuesta no es de tipo fallo.
Podemos añadir otra aserción de tipo Response SLA para comprobar que la invocación al web service cumple con un acuerdo de nivel de servicio (Service Level Agreement) que determine el tiempo máximo de respuesta, que introducimos en la siguiente ventana, en milisegundos:
Acuerdo de Nivel de Servicio
Finalmente añadimos una aserción XPath Match, con la que vamos a comprobar, mediante xpath, la existencia del atributo resultado, y el valor esperado en la respuesta: m2K6Pf20MrNvX3uKR1e54KqpzLxnHmR0
En la pantalla de configuración debemos en primer lugar declarar el espacio de nombres. Ello puede hacerse de manera automática pulsando sobre Declare. A continuación introducir la expresión xpath para acceder al nodo deseado y extraer su valor, y en la ventana inferior, el valor experado que queremos comprobar. En nuestro caso queda de la forma:
Aserción basada en XPath
XPath Expression:
declare namespace ns1=''; declare namespace soap='http://schemas.xmlsoap.org/soap/envelope/'; declare namespace ns2='http://tempuri.org/'; //ns2:EncriptarResponse/ns1:resultado/text()
Expected Result:
m2K6Pf20MrNvX3uKR1e54KqpzLxnHmR0
Si ejecutamos la invocación al web service pulsando en la flecha verde en el editor, obtendremos la respuesta y los test superados:
Todas las condiciones del test superadas con éxito
De hecho la condición del SLA se ha cumplido con mucho margen, puesto que el límite de tiempo permitido de respuesta establecimos 200 ms, y realmente ha tardado 19.
Añadir nuevos casos de prueba
Para ampliar la cobertura de nuestros test funcionales añadiremos un nuevo TestStep bajo Encriptar TestCase, de tipo Test Request, y lo denominamos Encriptar Fault, pues vamos a comprobar condiciones de fallo en la invocación al servicio:
Nuevo caso de prueba
La invocación que nos interesa probar es Service1Soap -> Encriptar:
Interfaz y operación a probar
En este caso aprovechamos el diálogo del asistente para introducir dos aserciones: comprobación de que la respuesta es un mensaje SOAP y que éste cumple con el Schema:
Introducir aserciones a través del asistente
El editor del caso de prueba se abre automáticamente con un SOAP request mínimo:
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"xmlns:tem="http://tempuri.org/"> <soap:Header/> <soap:Body> <tem:Encriptar/> </soap:Body> </soap:Envelope>
Pulsamos en el icono 
para recrear un mensaje de petición que cumpla con el Schema, al que daremos a continuación los valores siguientes:
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"xmlns:tem="http://tempuri.org/"> <soap:Header/> <soap:Body> <tem:Encriptar> <!--Optional:--> <tem:request> <!--Optional:--> <tem:Encriptar> <!--Optional:--> <original></original> <!--Optional:--> <clave></clave> <usarHashing>true</usarHashing> </tem:Encriptar> </tem:request> </tem:Encriptar> </soap:Body> </soap:Envelope>
La respuesta a la invocación será un mensaje de fallo del tipo:
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <soap:Body> <soap:Fault> <faultcode>soap:Server</faultcode> <faultstring>System.Web.Services.Protocols.SoapException: El servidor no puede procesar la solicitud. ---> System.Security.Cryptography.CryptographicException: La clave especificada no tiene el tamaño válido para este algoritmo. en System.Security.Cryptography.TripleDES.set_Key(Byte[] value) en wsEncriptacion.Service1.Encriptar(InputEncriptar request) en C:\Users\igpuebla\Documents \Visual Studio 2008\Projects\wsEncriptacion\wsEncriptacion\Service1.asmx.cs:línea 45 --- Fin del seguimiento de la pila de la excepción interna ---</faultstring> <detail/> </soap:Fault> </soap:Body> </soap:Envelope>
Por tanto vamos a añadir una aserción del tipo Soap Fault. Asimismo la respuesta debe recibirse en un plazo menos a 200 ms, por lo que creamos otra comprobación de tipo Response SLA. Lanzando la invocación, superaremos las aserciones del test:
Todas las condiciones del test superadas con éxito
Ejecución conjunta de los casos de prueba
Los casos de prueba anteriores son ejemplos para este tutorial, y en un entorno real deberán ser complementados. En caso de alcanzar un número elevado, o para probar de manera conjunta todos los TestSteps, abrimos el nodo Encriptar TestCase y accedemos a su editor. Ejecutamos el caso de prueba pulsando sobre la flecha verde y vemos que los test se ejecutan secuencialmente:
Ejecución de un TestCase completo
Ejecución de una suite completa
Asimismo podemos ejecutar todas las operaciones a nivel de interfaz del servicio web, abriendo el editor de pruebas a nivel de nodo Service1Soap TestSuite. Las operaciones sin casos de prueba definidos no interrumpirán la secuencia; podemos observarlo en el log tras una ejecución:
Ejecución de un TestSuite completo
Características avanzadas de la versión soapUI Pro
Antes de finalizar este tutorial, y por si nos estanmos planteando el uso de soapUI a nivel corporativo, quiero comentar un par de características documentadas que me parecen muy interesantes. Quiero dejar claro que no lo hago por publicidad, sino por un critero personal de utilidad de este software.
Generación de informes
Un jefe de proyecto debe estar informado de la evolución del software que desarrolla su equipo. Si no se dispone de un sistema de integración continua donde pueda observar los paneles de métricas, habrá que proporcionárselas de otra manera. Para ello soapUI Pro dispone de la funcionalidad de generación de informes en HTML con los resultados de las pruebas. La imagen que muestro a continuación está obtenida de la propia documentación:
soapUI Pro JUnit-Style Report – http://www.soapui.org/userguide/projects/reporting/junit.html
Panel de cobertura
La calidad de una batería de pruebas se mide principalmente por la cobertura que consigue sobre el objeto de prueba. soapUI Pro ofrece un panel de cobertura realmente interesante:
soapUI Pro Web Service Coverage – http://www.soapui.org/userguide/coverage.html
Conclusión
Este tutorial trata de aportar su granito de arena para concienciar de la importancia que tienen las pruebas unitarias dentro del ciclo de desarrollo de software, sea éste mediante metodologías tradicionales, ágiles u otras.
Si además el entorno tecnológico fomenta las buenas prácticas de implementación (alta encapsulación, bajo acoplamiento, interfaces bien definidas, patrones), como es SOA con respecto a sus servicios web básicos, el uso de pruebas unitarias se convierten en una piedra angular en el desarrollo, versionado y mantenimiento no regresivo de los mismos.
Te tengo que felicitar por tu trabajo.
Buenisimo me has ahorrado muchisimo trabajo.
La verdad es que la herramienta es potente y es fácil usarla 100 % recomendable.
Rafa
Buenas noches solicito su ayuda, al utilizar la herramienta soapUI tengo el siguiente problema
NOMBRE=B1|DESCRIPCION=&Mejoras&respuesta&|
Mi web services hace el consumo de una tabla que tiene en su campo DESCRIPCION: &Mejoras&respuesta& Pero la herramienta soapUI al encontrar el ampersand me devuelve como resultado: &Mejoras&respuesta& como observo al ampersand le adjunta amp; Existe alguna forma de configurar la herramienta para que me devuelva como realmente se encuentra en la tabla &Mejoras&respuesta&. De antemano muchas gracias
Hola:
Estoy realizando una prueba de llamada a un servicio web (desde SoapUI) el cual recibe como parámetro de entrada un fichero XML en base64. Hasta ahora estoy copiando todo el contenido del base64 y pegándolo en soapUI, en el parámetro de entrada correspondiente. ¿Existe la posibilidad de indicar en SoapUI que coja este contenido desde un fichero local en vez de copiarlo y pegarlo cada vez?
Muchas gracias por vuestra ayuda
Mayte
Mi consulta es.
Tengo que probar y hacer unos test de carga o stress, hacia el llenado de unos formularios, se trabaja con json, eso ya pude hacerlo, tanto por hilos como por segundos, ahora individualmente y luego en conjunto me gustaria sumar la prueba de subida o carga de archivo, es un txt pero hace de batch, entonces quiero ver como soporta eso también, como dije individualmente como tarea y luego todas, las de el form mas la de subir archivo.
Como se puede hacer esto con SOAP UI free
Saludos.