Informe
Prueba de concepto con SoapUI
Mauren Martinez
1
Contenido
Informe Prueba de concepto con SoapUI .................................................................................... 1
SoapUI ....................................................................................................................................... 2
REST ........................................................................................................................................... 3
Assertions (Validaciones) .......................................................................................................... 4
Observación............................................................................................................................... 5
Conclusiones ............................................................................................................................. 5
SoapUI
Utilizando la herramienta SoapUI se crear un proyecto de pruebas para el siguiente
servicio SOAP:
http://webservices.oorsprong.org/websamples.countryinfo/CountryInfoService
.wso?WSDL
SoapUI interpreta el contenido del WSDL automáticamente y genera un request (el
mensaje de solicitud al WS) para cada una de las operaciones disponibles.
Al explorar las distintas operaciones se observa que el WS brinda información sobre
distintos países muchas de las request son listas con información que no dependen de
ningún parámetro de entrada mientras que en otros casos estos parámetros son
necesarios.
Podemos ver que se lista los nombres de los continentes, de países, así como dado un
código de un país retorna el nombre del mismo al que pertenece dicho código.
Se realizaron varias pruebas las cuales se dividieron en Test Suites y dentro de ellos los
diferentes casos de prueba.
Los Test Suites son:
TestSuite_SoapUI
TestSuite_SoapInvalidos
Test_SoapUIParametrosEntrada
En el primer caso se encuentras los casos de pruebas correspondientes a aquellos que
no se necesitan parámetros de entradas para que el WS retorne una respuesta válida.
En el segundo caso están los casos donde no se encuentra una respuesta o la misma
no es válida.
2
Por últimos se encuentran los casos de prueba donde para poder ser ejecutados se
deben ingresar parámetros de entrada.
En esta parte no se encontró gran complejidad al momento de realizar ls pruebas las
mismas fueron satisfactorias obteniendo los resultados esperados.
REST
Esta parte se dividio en 2 proyectos:
Proy_CES_REST
REST_Put_Delete
Utilizando la herramienta SoapUI, a partir de un proyecto creado se presiona el botón
derecho sobre el mismo y se hace click en y "New REST Service from URI".
Ingresamos la URL https://jsonplaceholder.typicode.com/posts
Donde observamos que se genera la operación GET de forma automática, al igual que
una petición para dicha operación.
Luego se fueron agregando las distintas operaciones, en el proyecto Proy_CES_REST
encontramos las operaciones: GET con los 2 recursos que estamos solicitando
listar/buscar y POST que inserta se envían todos los valores salvo el ID, de la misma
forma que se despliega cada elemento de la lista.
3
En el proyecto REST_Put_Delete encontramos los métodos PUT - actualizar (se deben
enviar todos los datos, incluyendo ID), también se encuentran las pruebas invalidas y
DELETE - borrar (se puede indicar cual ítem borrar por ID o cualquier otro atributo).
Esta se división se hizo porque en estos casos el valor de la variable id se coloca en el
resource para que las operaciones funcionen de la forma que muestra la imagen a
continuación. Dado que esto
Dado que al hacer esto estamos cambiando el recurso, por lo que en realidad se
debería crear un nuevo "recurso" que incluya la ruta completa (todos los requests van
a tener dicha ruta) por eso es que se crea el nuevo proyecto para estas operaciones.
En cada caso se ingresaron los parámetros correspondientes con sus valores.
Luego de realizadas las pruebas se crearon los TestSuites correspondientes para los
casos REST.
Assertions (Validaciones)
Los assertions que se utilizaron fueron los siguientes:
Contains: Para validar contenido estos se usaron tanto en las pruebas de SOAP como
de REST.
XPath / XQuery Match
Búsqueda y matcheo (emparejado/igualado) estructurado (XML) mediante expresiones
XQuery o XPath. Estas se utilizaron en pruebas de SOAP XPathMatch fue usada por
ejemplo en la prueba de ListaPaisesXCod y XQuery en ListaContinentes.
JsonPath Match: Busca una ocurrencia simple (Existence Match y Match) esta se
utilizó en las pruebas de REST.
4
Observación
El caso de prueba DELETE marca en rojo el assertion contains lo que es correcto ya que
se esta preguntando por el id que debió borrar si la operación fue realizada con éxito
esto debería fallar.
Para saber que esta operación funciono correctamente se va a la pestaña RAW y se
verifica el mensaje HTTP y el número de status, este debe ser 200.
Conclusiones
En términos generales el uso de la herramienta para la parte de los servicios SOAP me
resulto muy fácil de usar e intuitiva.
La parte que se me volvió más compleja fue la de los servicios REST, fuera de las
dificultades en términos generales el tener que rever la tarea me sirvió para entender
un poco más esta parte y utilizar la herramienta para otro tipo de pruebas a las que
estoy acostumbrada a ver.
