Informe

Prueba de concepto con SoapUI

Mauren Martinez

1
Contenido
Informe Prueba de concepto con SoapUI .................................................................................... 1
SoapUI ....................................................................................................................................... 2
REST ........................................................................................................................................... 3
Assertions (Validaciones) .......................................................................................................... 4
Observacin............................................................................................................................... 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 automticamente 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 informacin sobre

distintos pases muchas de las request son listas con informacin que no dependen de
ningn parmetro de entrada mientras que en otros casos estos parmetros son
necesarios.

Podemos ver que se lista los nombres de los continentes, de pases, as como dado un
cdigo de un pas retorna el nombre del mismo al que pertenece dicho cdigo.

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 parmetros de entradas para que el WS retorne una respuesta vlida.

En el segundo caso estn los casos donde no se encuentra una respuesta o la misma
no es vlida.

2
Por ltimos se encuentran los casos de prueba donde para poder ser ejecutados se
deben ingresar parmetros 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 botn

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 operacin GET de forma automtica, al igual que
una peticin para dicha operacin.

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 envan 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 mtodos PUT - actualizar (se deben
enviar todos los datos, incluyendo ID), tambin se encuentran las pruebas invalidas y
DELETE - borrar (se puede indicar cual tem borrar por ID o cualquier otro atributo).

Esta se divisin 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
continuacin. Dado que esto

Dado que al hacer esto estamos cambiando el recurso, por lo que en realidad se
debera 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 parmetros 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

Bsqueda 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
Observacin

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 operacin fue realizada con xito
esto debera fallar.

Para saber que esta operacin funciono correctamente se va a la pestaa RAW y se

verifica el mensaje HTTP y el nmero de status, este debe ser 200.

Conclusiones
En trminos generales el uso de la herramienta para la parte de los servicios SOAP me
resulto muy fcil de usar e intuitiva.

La parte que se me volvi ms compleja fue la de los servicios REST, fuera de las
dificultades en trminos generales el tener que rever la tarea me sirvi para entender
un poco ms esta parte y utilizar la herramienta para otro tipo de pruebas a las que
estoy acostumbrada a ver.