SOAP UI y JMeter. Colaboraciones

En esta entrega, vamos a hacer un post absolutamente oportunista, combinando dos de las herramientas de prestaciones y calidad quizás más conocidas por los usuarios de este mundillo.
SOAP UI realiza pruebas sobre servicios web. Aunque ya se explicó en otro artículo, daremos unos breves apuntes sobre cómo acceder a un servicio publicado para realizar una grabación del mismo y combinarlo con la herramienta JMeter, para obtener un sistema de pruebas sobre dichos webservices. De esta forma combinaremos las capacidades de manejo de los WDSL de SOAP con las utilidades de análisis y las capacidades de monitorización (a través de los plug-ins) que permite JMeter.

Grabando un webservice. Conceptos y definición

En la pantalla de inicio de SOAP UI, podemos ver la invocación a un WDSL cualquiera  de ejemplo

• Diferentes métodos WDSL - XML descriptivo.
• Validación del WDSL.

La ejecución de un "caso" de prueba sobre una invocación WDSL  muestra la siguiente pantalla:

La pantalla muestra la invocación de un servicio de callejero, que permite conocer datos relativos a domicilios, por diversos criterios de consultas

Invocación servicio desde SOAP UI

La invocación desde JMeter del mismo web service produce la siguiente salida

Invocación servicio desde JMeter

Como se puede observar, la invocación desde el awt de JMeter es notablemente menos intuitivo y usable que desde el equivalente de SOAP UI. Esto nos permite proceder de una manera más sencilla y que podemos adaptar para su uso con JMeter



Las opciones que tenemos para "pasar" el cuerpo de la solicitud a JMeter son dos

1. Utilizar la opción de un proxy externo incluida en el propio SOAP UI, indicando como dirección y puerto, la del servicio proxy del  JMeter. Este capturará la petición en JMeter
2. Seleccionar el BODY de la petición de SOAP y pegarla en un esqueleto de JMeter

 

 

Validando el webservice con JMeter.

En este punto , ya que el trabajo más sucio ha sido realizado por SOAP, utilizaremos el JMeter para parametrizar el script de pruebas y validar ,mediante la capacidad de los manejadores de respuesta de JMeter , la corrección de la misma .

También es interesante añadir receptores (listener) para monitorizar la capacidad.

Hemos de tomar como punto a favor de JMeter , la capacidad de incluir un listener ,tanto uno simple como el escritor de datos, como uno de los gráficos como visualización de peticiones HTTP.

Algunas consideraciones previas a desarrollar

• Ancho de banda necesario
• Memoria inyector
• "Dispersión" a través de varios inyectores

Respecto al ancho de banda, debemos recordar que las peticiones web services se ejecutan muy rápido, por lo que los tiempos de latencia de una red saturada pueden afectar a sus tiempos de respuesta.

Asimismo la memoria dedicada del inyector debe ser suficiente para no saturarse con el manejo de los hilos de ejecución de este tipo de prueba. Un nivel de saturación de este tipo de pruebas puede necesitar del orden de 300 hilos en adelante.

Creando un escenario. Hilos de ejecución y escalado

Aquí controlaremos la inyección masiva de los webservices.Al contrario que en pruebas en los que se simula una navegación completa, la capacidad de inyección es mucho mayor, pudiendo incrementar en un  factor de tres o cuatro, los niveles de concurrencia que se obtiene con sesiones de usuario "real".

Ojo, esto también juega en nuestra contra si el objetivo de la prueba no es tanto saturar o alcanzar altos niveles sino comprobar el correcto funcionamiento. Lógicamente, rendimientos altos generarán altos volúmenes de datos a analizar a posteriori. Hay que especificar bien qué métricas queremos monitorizar ,asi como intervalos de muestreo.

El lanzamiento de una prueba de carga utilizando SOAPUI invoca conceptos similares a los de las pruebas con otras herramientas, como hilos de ejecución, tiempo de duración de la prueba , gráficas incluidas ..etc.

Pantalla de prueba de carga en SOAPUI

En el caso de JMeter , permite una manufactura superior de los datos , gracias a la capacidad de volcarlos a fichero, así como la capacidad de programación de pruebas desatendidas mediante scripts de sistema operativo.

 Análisis de la respuesta

Como criterios principales a la hora de evaluar el comportamiento de los servicios en carga durante la prueba, podemos tomar como criterios los siguientes:

• %Error en invocación
• Througput alcanzado
• Número de invocaciones
• Degradación del tiempo de respuesta 

Dependiendo de cual es el objetivo de la prueba , como saturación, estrés, estabilidad...podemos centrarnos en algunos en especial.

Esperamos que este artículo sea de utilidad para aquellos técnicos que quieran ejecutar pruebas sobre web services. Agradecemos cualquier comentario o corrección sobre este artículo .

Puedes encontrar más información sobre JMETER en nuestra página de Monográficos.