Animado por la entrada que hizo hace unas semanas Chema Alonso en su blog, os voy a contar un poco más sobre la herramienta SoapUI, utilizada para auditar WebServices. Más que en cómo utilizar la herramienta en sí, en este post me gustaría explicar de qué forma se pueden automatizar las pruebas a un WebService utilizando esta herramienta.
SoapUI permite automatizar las pruebas a un WebService utilizando lo que él llama Test Cases. A continuación podemos ver que un TestCase tiene varios pasos (TestSteps), así como varias pruebas de carga y de seguridad, que quedan fuera de nuestro objetivo.
Vamos a centrarnos en los pasos que forman un TestCase. Hay varios tipos de pasos que podemos incluir, siendo los más importantes:
- Peticiones: Realizar una petición a un servicio. Hay peticiones para distintos tipos de servicios como SOAP, REST, JDBC y HTTP, entre otros. Estas peticiones devuelven un resultado, visualizable en el panel de la derecha. A través del desplegable inferior llamado “Assertions” se pueden introducir comprobaciones que verifiquen que el resultado obtenido es válido para nuestros propósitos.
- Propiedades (Properties): Se pueden definir propiedades, que se pueden utilizar en otros scripts como fuente o destino de datos. En la siguiente captura vemos la definición de una propiedad llamada resultado.
Estas propiedades también se pueden transferir (Property Transfer) entre varios pasos de ejecución de un mismo script, como se puede ver en la siguiente captura, donde se pasa la propiedad “result” del TestStep “Groovy Script” (ver “Source”) a un parámetro de una petición SOAP (ver “Target”).
- Scripts (Groovy Script): Permiten introducir fragmentos de código para tratar la información. En la imagen adjunta se ve como se obtiene, de un TestStep llamado “Properties”, el valor de su propiedad “resultado”.
Estos script se pueden crear en JavaScript o en Groovy, un lenguaje implementado sobre Java. A continuación os dejo varios recursos con información interesante sobre Groovy y scripts de ejemplo.
Podemos encontrar más información sobre estos y otros tipos de TestSteps existentes en la web de SoapUI.
Por poner un ejemplo, en una auditoría me topé con un WebService, cuyo flujo de ejecución automaticé del siguiente modo (en la primera captura del post podéis ver los pasos en que se traduce este flujo):
1. Ejecutar un script que lee un fichero origen, y firma dicho fichero digitalmente según un formato personalizado de la aplicación auditada.
2. Pasar el resultado a una petición SOAP.
3. Ejecutar la petición SOAP y recoger el resultado.
4. Guardar el resultado en una propiedad de SoapUI.
5. Mediante un script, descifrar el resultado, obtenido de la propiedad donde se había guardado en el paso anterior, y escribirlo a un fichero resultado.
Una vez creado todo el flujo de ejecución que consideremos necesario, y para agilizar aún más el proceso, podemos además lanzar nuestras pruebas desde consola, ejecutando la siguiente orden (ejemplo bajo Linux):
/<SoapUI_ROOT>/bin/testrunner.sh -s"TestSuite" -c "TestCase" -a /<path>/soapui-project.xml
En nuestro ejemplo, poder lanzar el script desde consola nos permitió generar automáticamente ficheros origen y ejecutarlos para obtener el resultado esperado.
Esperamos que os haya parecido interesante esta breve introducción a la prueba de WebServices mediante SoapUI.
