rest - probar - soapui libre

Uso de SoapUI para probar la función de inicio de sesión de la aplicación REST (1)

No hago esta pregunta muy general a la ligera, pero he llegado al máximo de lo que puedo entender por mi cuenta.

Estoy iniciando la QA Test Automation en mi nueva compañía (no automatizan nada en la actualidad) y eligieron usar SoapUI para este procedimiento.

La aplicación que están desarrollando es una aplicación REST (realmente no tengo idea de lo que eso significa), así que estoy tratando de crear una solicitud REST y Test Suite para llegar a nuestro servidor de prueba interno (lo que me da XML que soy) no se permite publicar aquí, pero llega al servidor con éxito!) y luego intentar hacer una prueba de inicio de sesión / cierre de sesión.

Estoy pidiendo ayuda con la metodología, porque no tengo idea de dónde empezar. Busqué en Google y revisé sus foros de soporte y busqué en cada rincón de YouTube. Todos están haciendo algo lo suficientemente diferente como para no poder relacionarlo o usarlo.

¿Alguien por ahí usa SoapUI y prueba el inicio de sesión funcional en una aplicación REST? Puedo escribir HTML / CSS y soy bastante experto en Java, así que puedo hacer cosas técnicas si sé qué buscar y qué aprender.

Sintiéndose abrumado Esto no estaba en la descripción de mi trabajo cuando comencé.

Deberías comenzar con REST y luego con SoapUI.

Es difícil captar la esencia de REST .

Es como el híbrido de SOAP y una simple aplicación web impulsada por HTML . Por SOAP , describe su servicio web con un WSDL . Mediante una aplicación web , devuelve hipermedia , por lo que no tiene que escribir un WSDL ni ningún descriptor en su aplicación. Esta es la convención sobre la configuración ...

REST utiliza el mismo enfoque, por lo que también envía hipermedia , pero no envía HTML porque no es procesable por la máquina. El hipermedio enviado por una API REST suele ser un derivado XML o JSON , por ejemplo, ATOM + XML , JSON-LD , etc. Si su servicio web no envía hipervínculos , entonces no se trata de un servicio REST real sino Servicio web SOAP con algunas restricciones REST . Existe una gran diferencia. Por SOAP , debe saber todo sobre el nombre de la operación y los parámetros, si desea enviar una solicitud. Si algo cambia, entonces su cliente SOAP se rompe inmediatamente. Con REST, su cliente automatizado sigue los enlaces , verifica su relación de enlace o los datos vinculados y reconoce qué enlace es el que estaba buscando. Por lo tanto, la modificación de la URL del enlace es irrelevante en el cliente , porque sigue el vocabulario de la aplicación, por ejemplo: hydra es un proyecto que trata de describir esta semántica de nivel de aplicación de una manera general, e intenta vincularla a abrir datos vinculados .

Entonces, al principio, debe verificar que tiene una API REST real , que sigue el principio HATEOAS , o simplemente un REST, como el servicio web SOAP . Esto es muy importante si desea escribir pruebas de extremo a extremo en su contra. Al probar REST , debe seguir los enlaces en sus pruebas devueltos por la API web . Al probar REST como SOAP , usted tiene que construir los enlaces usted mismo en sus pruebas ... ¿Cómo construir dicho enlace ? Estoy seguro de que tiene una descripción de su API REST , pero un enlace generalmente se ve así en formato JSON :

{ rel: "link-relations", method: "METHOD", href: "domain/api-root/version/resource-path?map-reduce", data: {...}, title: "...", ... }

De c. existe una diferencia en cada hipermedia , por lo que debe verificar su tipo de hipermedia XML , cómo representa los enlaces ... Las link-relations y tal vez otros atributos vinculan sus datos a la semántica de su API REST . El METHOD es siempre un verbo , generalmente: OBTENER, PUBLICAR, PONER, PATCH, ELIMINAR , tal vez OPCIONES , y así sucesivamente ... Solo hay unos pocos verbos REST , cada uno de ellos tiene un significado específico . En la url : el domain es el nombre de dominio de su aplicación, por ejemplo, https://example.com . La raíz de la REST API es la raíz de su REST API , generalmente /api . La version es el número de versión de la API actualmente utilizada , generalmente /v1 . Solo los cambios de vocabulario no retroactivos deberían afectar este número de versión. El resource-path es la ruta de su recurso , generalmente /users o /users/inf3rno , etc ... Por REST tiene recursos . Cada uno de ellos tiene una resource-path única , y como puede ver, cada palabra en esa ruta es un nombre . Entonces los recursos son algo que puedes modificar o mostrar con un verbo . Por ejemplo, un GET /users/inf3rno debería devolver una representación de mi página de perfil, y un PATCH /users/inf3rno {nick: "Leslie"} convertirá mi nick: inf3rno en Leslie . Con REST, cada recurso debe tener solo una única ruta de recursos , por lo que este es siempre un identificador único , por lo tanto, el ejemplo anterior con PATCH no era tan perfecto si desea tener múltiples usuarios con el mismo nick ... El map-reduce en queryString de la url , y contiene la configuración de clasificación , paginación y filtrado del recurso que desea modificar o mostrar. Por ejemplo, puede recuperar algunos datos de cada usuario con un primer nombre: "Leslie" con GET /users?filters="firstName: ''Leslie''"&page=3&count=25 . Hay una diferencia entre las siguientes url -s: /users?id="inf3rno" y /users/inf3rno . El primero apunta a un recurso de colección y filtra el resultado por su representación , el segundo apunta a un único recurso de elemento . Por lo tanto, un GET debe devolver una representación de colección con un solo elemento por el primero, y una representación de elementos por segundos. Con los métodos de modificación de recursos no hay diferencia entre las 2 URL ... Por lo tanto, se recomienda agregar solo un identificador único a la resource-path si desea seleccionar un recurso de elemento de una colección. Al reducir la representación de recopilación de cualquier otra manera, debe agregar los filtros a queryString . La parte de data contiene los parámetros de los campos de entrada . El title es el título del enlace , y así sucesivamente ... Puede usar url-templates de las que quiera poner parámetros de entrada en la url también ...
Por REST, el cliente mantiene la sesión y envía las credenciales (nombre de usuario, contraseña) con cada solicitud. Esto se debe a que el servicio REST es como John Snow, no sabe nada sobre la sesión o la identidad del usuario . Tiene que autenticar cada solicitud . Para hacer eso, usa una credentials -> permissions caché de credentials -> permissions . Este es un buen enfoque, porque el servicio escala muy bien si no tiene que mantener la sesión , que es parte del estado de la aplicación (el estado del cliente) ... El servicio REST mantiene solo el estado del recurso , que es no depende de los clientes ...

La respuesta a sus solicitudes de REST suele ser un hipermedia que contiene los enlaces que puede seguir y los datos que ha solicitado. Con REST, como los servicios web SOAP , solo obtiene los datos en formato JSON o XML . Cada respuesta debe contener un encabezado de estado adecuado. Los códigos de estado más frecuentes son:

200 - ok (por PUT exitoso , PATCH y GET )
201 - creado (por POST exitoso)
202 - aceptado (por solicitud asíncrona con consistencia eventual)
204 - sin contenido (por ELIMINACIÓN exitosa)
206 - contenido parcial (por paginación con encabezados de rango)
301 - movido permanentemente (por migración)
304 - no modificado (por caché)
400 - solicitud incorrecta (por entrada no válida)
401 - no autorizado (si no se proporciona una contraseña, o un nombre de usuario o contraseña incorrectos)
403 - acceso denegado (si su cuenta no tiene permiso para realizar la tarea)
404 - no encontrado (por recurso desconocido)
409 - conflicto (por problemas de simultaneidad o problemas de solicitud duplicada o limitación de DB)
410 - ido (si el recurso estaba presente antes, pero ya está eliminado)
415 - tipo de medio no compatible (si el cliente quiere la respuesta en un tipo de medio desconocido)
500 - error interno del servidor (si la solicitud fue correcta, pero algo salió mal al procesarla)

Por cualquier error, debe enviar un mensaje de error detallado con un código de error personalizado, que es comprensible para los usuarios, no solo para los desarrolladores ...

Así es como se ve una API REST .

Para probarlo con las pruebas de e2e , debe configurar los dispositivos para enviar solicitudes de REST y verificar su respuesta . Entonces, es como cualquier otra prueba ... El SoapUI no es necesariamente la mejor herramienta para hacerlo, leí muchas quejas al respecto ... Personalmente, nunca lo utilicé, pero no es tan difícil escribir su sistema de prueba personalizado. Necesita un marco de prueba, que pueda comparar los valores esperados y reales. Necesita algo para enviar solicitudes HTTP o simplemente simular el marco HTTP de la API REST . Necesitas algo para el accesorio . Mediante las pruebas de integración también puede simular la lógica comercial y el marco HTTP , por lo que, para aquellos, simplemente se inyectan las dependencias simuladas y se comprueban las llamadas. Con las pruebas de e2e necesita un conjunto de datos de prueba y compararlo con el XML de resultados en su caso ... Si desea probar e2e a su cliente, puede usar selenio si está basado en HTML , tal vez con nightwatch.js . Al probar una API REST real, necesitará un navegador automatizado , como el selenio para la implementación de la API REST , que puede seleccionar y seguir los enlaces adecuados. Si está desarrollando la API REST , debería escribir un navegador como ese de todos modos si desea un cliente de ejemplo para sus desarrolladores de terceros.