Diferencia entre revisiones de «SoapUI»
(→Tomando valores dinámicamente entre request) |
|||
| Línea 116: | Línea 116: | ||
En un TestSuite podemos tener un TestCase con Steps, donde cada Step puede ser un request de una operación diferente del web service. Y el valor devuelto en un Step puede ser el valor de entrada en el próximo Step. Más en el [http://www.soapui.org/userguide/functional/propertytransfers.html#The_PropertyTransfer_Editor tutorial de soapUI] | En un TestSuite podemos tener un TestCase con Steps, donde cada Step puede ser un request de una operación diferente del web service. Y el valor devuelto en un Step puede ser el valor de entrada en el próximo Step. Más en el [http://www.soapui.org/userguide/functional/propertytransfers.html#The_PropertyTransfer_Editor tutorial de soapUI] | ||
| + | |||
==Conclusión== | ==Conclusión== | ||
Revisión del 21:15 24 feb 2010
SoapUI es una herramienta de Software Libre gráfica, está basada en Java y sirve para el testeo de Web Service y generación de Clientes De Web Service.
SoapUI permite testear web services de forma facil, ver los resultados. Además, permite facilitar el uso de herramientas comunes para la generación de clientes, como Axis.
Trabajando con web services, y sin interfase gráfica en la aplicación, esta herramienta nos permite automatizar fácilmente las pruebas funcionales y así asegurar la calidad en nuestros proyectos.
Las pruebas funcionales de los web services podrían usarse para más de un propósito:
- Pruebas unitarias: para validar que cada operación de los servicios funciona como se definió.
- Prueba de aceptación: para validar que el servicio retorna resultados aceptables según los requerimientos.
- Pruebas de proceso: para validar que una sucesión de invocaciones del servicio cumple con el proceso de negocio definido.
- Pruebas de manejo de datos: para validar el comportamiento con las entradas de datos externos al sistema (bases de datos, otros sistemas, uso de otros web services).
- Pruebas de regresión: para validar el comportamiento post cambios.
Contenido
Un paso a paso
1. Tener instalada la última versión bajada de la Web oficial de SoapUI.
2. Crear un nuevo proyecto SoapUI para el proyecto a probar. Donde configurar la url que contiene el WSDL del proyecto.
 |
3. Por cada operacion del servicio a probar, crear una peticion. Cada peticion requiere el ingreso de valores para los parámetros definidos. Agregar valores en el XML que nos propone el wizard de la herramienta.
 |
 |
4. El proyecto se persiste en un script XML, que podemos resguardar en el repositorio en el que tengamos el código fuente del proyecto. Y así todo el equipo podrá hacer crecer la prueba funcional automática del proyecto, y de un modo ágil.
5. Con los pasos dados hasta acá, logramos obtener una prueba funcional del proyecto y su documentación.
6. Esta herramienta maneja el concepto de TestSuite, TestCase, TestStep, como lo manejan JUnit, JMeter, etc. Un TestSuite sirve para contener un número arbitrario de casos de prueba (TestCases) que pueden ejecutarse secuencialmente o en paralelo. Los TestSteps sirven para ejecutar TestCases secuencialmente. Una vez creadas las peticiones, es posible generar una TestSuite y así automatizar las pruebas funcionales, con el valor agregado de tener pruebas de regresión.
 |
7. Por cada TestCase es posible hacer validaciones automáticas de los resultados. Entonces, por cada petición, verificar si la respuesta es un fault, o no lo es, o contiene determinado valor, o no lo contiene. Es una buena práctica, en el manejo de web services, que los errores inesperado del sistema (Runtime Exception) viajen en un tag “fault”. Distinto a una respuesta normal del servicio.
 |
 |
 |
8. Con las peticiones agregadas a los casos de prueba, se puede realizar una ejecución masiva utilizando la opción Launch TestRunner.
 |
Mientras se ejecutan los casos de prueba, se pueden visualizar los pasos de ejecución y un resumen global. En el directorio físico configurado, se genera un archivo por cada caso de prueba con la nomenclatura conteniendo el TestSuite que lo ejecutó, el nombre del caso de prueba, y el resultado de la prueba.
Transferencia de datos entre peticiones
En un TestSuite podemos tener un TestCase con Steps, donde cada Step puede ser un request de una operación diferente del web service. Y el valor devuelto en un Step puede ser el valor de entrada en el próximo Step. Más en el tutorial de soapUI
Conclusión
- Es fácil y rápido crear, ejecutar y guardar los casos de prueba funcional que quieras. Se pueden adaptar y expandir en cualquier momento.
- Es fácil hacer aserciones. También con expresiones regulares.
Algo más
- Se puede agregar MockService cuando el web service todavía no está listo.
- Load Tests permite medir performance sobre los tests funcionales creados.
- Esta nota está basada en una guia y en un video de la página oficial de SoapUI.
