Pruebas funcionales de servicios web con soapUI

4
62475

Pruebas funcionales de servicios web con soapUI

Indice

  1. Pruebas funcionales de servicios web con soapUI 3.0.1
    1. Introducción
    2. Prerrequisitos
    3. Crear el proyecto en soapUI
    4. Pruebas de servicios web sobre SOAP
    5. Pruebas sobre el SOAP response
    6. Añadir nuevos casos de prueba
    7. Ejecución conjunta de los casos de prueba
    8. Ejecución de una suite completa
    9. Características avanzadas de la versión soapUI Pro
      1. Generación de informes
      2. Panel de cobertura
    10. Conclusión

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:

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
Nuevo proyecto soapUI

OK al diálogo siguiente:

Opciones para generar pruebas de cada operacion
Opciones para generar pruebas de cada operación

Aceptamos el nombre propuesto por defecto:

Aceptamos los nombres propuestos
Aceptamos el nombres propuesto

De igual manera aceptamos el resto de ventanas que aparecen. Al final tendremos la estructura del proyecto:

Proyecto de pruebas creado
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
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
Editor de pruebas

Creamos un mensaje SOAP request hacia la operación Encriptar con valores de ejemplo sustituyendo los ?:

Sobre este mismo moensaje vamos a añadir algunas comprobaciones. Pulsamos sobre el botón soapUI Add Assertion (a la derecha de la fecha verde), podemos seleccionar una aserción:

Assertions disponibles para pruebas SOAP
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):

soapUI SchemaCompliance Assertion

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
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:

Asercion contains
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
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:

Asercion basada en XPath
Aserción basada en XPath

XPath Expression:

Expected Result:

Si ejecutamos la invocación al web service pulsando en la flecha verde en el editor, obtendremos la respuesta y los test superados:

Test superado
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
Nuevo caso de prueba

La invocación que nos interesa probar es Service1Soap -> Encriptar:

Request de la prueba
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 mediante wizard
Introducir aserciones a través del asistente

El editor del caso de prueba se abre automáticamente con un SOAP request mínimo:

Pulsamos en el icono soapUI - recreate a default request from the schema para recrear un mensaje de petición que cumpla con el Schema, al que daremos a continuación los valores siguientes:

La respuesta a la invocación será un mensaje de fallo del tipo:

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:

Ejecucion de un TestCase completo
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:

Ejecucion de un TestSuite completo
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 test report
soapUI Pro JUnit-Style Reporthttp://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:

Cobertura de los test
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.

 

4 Comentarios

  1. 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

  2. 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

  3. 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

  4. 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.

Dejar respuesta

Please enter your comment!
Please enter your name here