Informe

Prueba de concepto con SoapUI

Mauren Martinez

1

.............................................oorsprong........................................ así como dado un código de un país retorna el nombre del mismo al que pertenece dicho código...................... 3 Assertions (Validaciones) .............................................................................................Contenido Informe Prueba de concepto con SoapUI ............................................ 1 SoapUI ..... En el segundo caso están los casos donde no se encuentra una respuesta o la misma no es válida........ 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................................................. de países............. Podemos ver que se lista los nombres de los continentes..................................................................................................................................................................................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..............org/websamples.......................................... 2 REST .............................................................. 5 SoapUI Utilizando la herramienta SoapUI se crear un proyecto de pruebas para el siguiente servicio SOAP:  http://webservices............................. 2 ..... 5 Conclusiones .................countryinfo/CountryInfoService ....................... 4 Observación..................... Se realizaron varias pruebas las cuales se dividieron en Test Suites y dentro de ellos los diferentes casos de prueba..

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. 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".typicode. 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.Por últimos se encuentran los casos de prueba donde para poder ser ejecutados se deben ingresar parámetros de entrada. Luego se fueron agregando las distintas operaciones.com/posts Donde observamos que se genera la operación GET de forma automática. 3 . al igual que una petición para dicha operación. Ingresamos la URL https://jsonplaceholder.

también se encuentran las pruebas invalidas y DELETE . XPath / XQuery Match Búsqueda y matcheo (emparejado/igualado) estructurado (XML) mediante expresiones XQuery o XPath. 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. JsonPath Match: Busca una ocurrencia simple (Existence Match y Match) esta se utilizó en las pruebas de REST.borrar (se puede indicar cual ítem borrar por ID o cualquier otro atributo).En el proyecto REST_Put_Delete encontramos los métodos PUT . En cada caso se ingresaron los parámetros correspondientes con sus valores. 4 .actualizar (se deben enviar todos los datos. Dado que esto Dado que al hacer esto estamos cambiando el recurso. 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. incluyendo ID). 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. Luego de realizadas las pruebas se crearon los TestSuites correspondientes para los casos REST. Estas se utilizaron en pruebas de SOAP XPathMatch fue usada por ejemplo en la prueba de ListaPaisesXCod y XQuery en ListaContinentes.

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. 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. La parte que se me volvió más compleja fue la de los servicios REST. 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.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. este debe ser 200. 5 .