Tutorial de pruebas de API REST: Ejemplos de casos de prueba manuales
Equipo editorial
⚡ Resumen inteligente
Las pruebas de API REST validan los servicios web RESTful enviando solicitudes HTTP como GET, POST, PUT y DELETE, y luego verificando el código de estado, los encabezados de respuesta y la carga útil devuelta por el servidor.
¿Qué son las pruebas de API REST?
Pruebas de API REST Es una técnica de automatización de pruebas web de código abierto que se utiliza para probar API RESTful en aplicaciones web. El objetivo de las pruebas de API REST es registrar la respuesta de la API mediante el envío de diversas solicitudes HTTP/S para verificar su correcto funcionamiento. Las pruebas de API REST se realizan mediante los métodos GET, POST, PUT y DELETE.
REST Significa Transferencia de Estado Representacional. Es un estilo arquitectónico y un enfoque de comunicación utilizado en el desarrollo de Servicios WebREST se ha convertido en una opción lógica para la creación de API, ya que permite a los usuarios conectarse e interactuar con los servicios en la nube de manera eficiente.
Una API, o Interfaz de Programación de Aplicaciones, es un conjunto de instrucciones de programación para acceder a una aplicación de software basada en la web. En otras palabras, es un conjunto de comandos que un programa utiliza para comunicarse directamente con otro y aprovechar las funciones del otro para obtener información.
Por ejemplo, una Google Un sitio web puede tener una API para búsquedas, traducciones y calendarios. En general, las API tienen una estructura similar al ejemplo que se muestra a continuación, con un nombre de servidor, rutas y parámetros.
http://<server name>/v1/export/Publisher/Standard_Publisher_Report?format=csv
Pero, ¿por qué invertir esfuerzos de prueba en esta capa?
¿Por qué son importantes las pruebas de API REST?
Una API REST se sitúa entre la interfaz de usuario y la base de datos, lo que la convierte en la capa donde reside la mayor parte de la lógica de negocio. Un fallo en una regla de precios o una comprobación de permisos se manifiesta en la respuesta de la API mucho antes de que alguien detecte un número incorrecto en la pantalla, por lo que las pruebas en esta capa permiten detectar los problemas antes y más cerca de su origen.
La velocidad es la segunda razón. Una solicitud se completa en milisegundos y no requiere navegador, motor de renderizado ni localizadores de elementos complejos. Un evaluador puede probar docenas de puntos finales en el tiempo que tarda una prueba de interfaz en cargar una página, y la misma solicitud se comporta de forma idéntica tanto si la interfaz es un sitio web, una aplicación móvil o una integración con un socio.
La estabilidad es la tercera razón. Los diseños cambian constantemente, pero un REST publicado...tracSe espera que se mantenga estable. Las pruebas escritas contra ese valortracPara que no sobrevivan a los rediseños, protegen las partes del producto sobre las que otros equipos realmente trabajan.
Tipos de métodos API
Hay principalmente 4 tipos de Prueba de API Métodos: GET, POST, DELETE y PUT.
- – El método GET se utiliza paratracinformación del servidor dado usando una URI dada. Al usar una solicitud GET, solo debería extract datos y no debería tener ningún otro efecto sobre los datos.
- PUBLICAR– Se utiliza una solicitud POST para crear una nueva entidad. También se puede utilizar para enviar datos al servidor, por ejemplo, información del cliente, carga de archivos, etc. mediante formularios HTML.
- PUT– Crear una nueva entidad o actualizar una existente.
- BORRAR– Elimina todas las representaciones actuales del recurso de destino proporcionadas por un URI.
Cómo probar la API REST
Las pruebas de API REST requieren que una aplicación interactúe con una API de ejemplo para realizar las pruebas. Para probar una API, se necesitan dos cosas:
- Herramienta/marco de prueba para impulsar la API
- Escribir su propio código para probar la API REST de muestra
Los casos de prueba de la API REST se pueden probar con herramientas como:
- Cliente de descanso avanzado
- Postman-Descanso Cliente
- Rizado en Linux
Aquí utilizaremos Advanced Rest Client. A continuación se detallan los pasos para obtener Advanced Rest Client.
¿Cómo obtener el cliente REST avanzado?
- Vaya al Google ChromeTienda web de
- Busque “Cliente de descanso avanzado” o vaya directamente aquí e instalar la extensión
- Seleccione el icono "Cliente de descanso avanzado" en la sección de aplicaciones de Chrome: chrome://apps/
El listado de la tienda en línea aparece como se muestra a continuación.
Una vez realizada la instalación, siga la prueba a continuación para probar un API RESTful.
Pasos para probar la API REST
Aquí estamos utilizando la extensión de cliente REST en el navegador Chrome. Para entenderlo de forma clara, estamos utilizando una API ficticia para realizar pruebas:
http://ip.jsontest.com/
Paso 1) Abra el cliente REST avanzado
Inicie la aplicación Cliente REST avanzado (ARC), una vez que se haya instalado correctamente.
Paso 2) Introduzca el URL de API para probar
Introduzca la API REST de ejemplo. URL para realizar pruebas en el URL caja de texto.
Paso 3) Seleccione el método HTTP
Seleccione el método para el tipo de métodos HTTP en las pruebas de API para acceder, p. CORREO
Paso 4) Proporcionar encabezados establecidos
Proporcione un conjunto de encabezados en el cuadro de texto Encabezados. Haga clic en Insertar conjunto de encabezados.
Paso 5) Confirme los encabezados establecidos
Siguiente Haga clic en USAR ESTE CONJUNTO.
Paso 6) Proporcionar el contenido del cuerpo requerido
- Ahora cambie a la pestaña Cuerpo.
- Establezca el tipo de contenido del cuerpo requerido y la vista del editor, p. Tipo de contenido del cuerpo: aplicación/json
- Vista del editor: entrada sin procesar.
- En la sección de carga útil, pase el cuerpo de la solicitud de la API de demostración para realizar pruebas en forma de pares clave-valor, por ejemplo, {"clave1": "valor1", "clave2": "valor2"}. Si se trata de una API POST, deberá pasar un cuerpo o parámetros. Los pasará en la sección de carga útil.
{"property" : ["Sites"], "report_type" : ["ALL"]}
⚠️ Advertencia: Un Content-Type de application/json con una carga útil que no es válida JSON Devuelve 400 Solicitud incorrecta.
Paso 7) Envíe los detalles para iniciar la prueba
- Presiona el botón enviar.
- Puede hacer clic en el botón DETALLES para ver los encabezados de respuesta.
Aquí están los detalles de la respuesta:
La respuesta aún debe evaluarse en función del resultado esperado.
Validando los resultados
Principalmente, para las pruebas de API web, necesitamos verificar el código de respuesta, el mensaje de respuesta y el cuerpo de la respuesta.
Los códigos de respuesta se dividen en cinco familias:
| Family | Categoría | Significado |
|---|---|---|
| 1xx | Informativo | Recibido, aún en procesamiento |
| 2xx | Éxito | Completado; 200 OK, 201 Creado |
| 3xx | Redirección | Se requiere una acción adicional |
| 4xx | Error del cliente | Carga útil, token o recurso incorrecto |
| 5xx | Error del Servidor | Solicitud válida, el servidor falló. |
A continuación se muestran los códigos de respuesta que se pueden encontrar.
Una sola solicitud demuestra que el punto final funciona. Un conjunto de pruebas demuestra que sigue funcionando.
Casos de prueba de API REST que debes cubrir
Un conjunto útil de API REST abarca varias categorías en lugar de repetir la misma llamada con datos diferentes:
- Camino feliz: Envía una solicitud válida a cada punto final y confirma el código de estado, el esquema y el valor de cada campo.
- Casos negativos: Si se envía JSON con formato incorrecto, un método no compatible y un ID de recurso faltante, se esperan los códigos 400, 405 y 404 en lugar de 500.
- Valores límite: Si un campo acepta de 1 a 200 caracteres, pruebe con 0, 1, 200 y 201. Las reglas de validación fallan en los límites.
- Caracteres especiales: Haz pasar las letras acentuadas, los emojis, las citas y el texto multibyte a través de todos los campos para detectar fallos de codificación.
- Contraccomprobaciones t: Compare la respuesta con la especificación publicada de OpenAPI o Swagger para detectar a tiempo los cambios no documentados.
- Secuenciación: Llame a los puntos finales en un orden realista, como POST, luego GET y luego DELETE, porque el estado se conserva entre las llamadas.
- Cordura en el desempeño: Registra los tiempos de respuesta en cada ejecución e indica cualquier punto final que supere el umbral acordado con el equipo.
Herramienta de prueba API REST
Las distintas herramientas se adaptan a las distintas etapas de las pruebas.
| Tipo | Mejores para | |
|---|---|---|
| Cliente de descanso avanzado | Cliente de escritorio | Llamadas manuales rápidas |
| Postman | Cliente de escritorio | Colecciones y espacios de trabajo en equipo |
| JMeter | Prueba de carga | Tiempos de respuesta bajo carga |
| SoapUI | Prueba funcional | DESCANSAR y JABÓN juntos |
| Está seguro | Java | Automatización de casos estables |
| cURL | Línea de comando | Cómo pegar llamadas en informes de errores |
Vea el resumen de Herramientas de prueba API.
La mayoría de los sistemas de punto final reales se niegan a responder hasta que la solicitud demuestre quién la envió.
Autenticación y comprobaciones de seguridad de la API REST
Los puntos de acceso de demostración públicos responden a cualquier usuario, pero una API REST de producción está protegida por un esquema de autenticación, y un fallo de autorización es mucho más perjudicial que un valor de campo incorrecto. Primero, identifique el mecanismo: una clave API estática, credenciales HTTP Basic, un token de portador OAuth 2.0 o un token web JSON firmado.
Una vez que una solicitud autenticada se realiza correctamente, analice detenidamente las posibles rutas de error:
- Sin credenciales: Elimine el encabezado de autorización. Espere un error 401 No autorizado y ningún dato de registro en el cuerpo.
- Credenciales con formato incorrecto: Corrompe un carácter del token. Espere otro error 401, con un mensaje que no explique el motivo.
- Credenciales caducadas: Reutilizar un token después de su vencimiento. Confirmar que es rechazado en lugar de aceptado, un defecto común de desfase horario.
- Nivel de privilegio incorrecto: Autentícate como un usuario con pocos privilegios y llama a un punto final exclusivo para administradores. Espera un código 403 Prohibido, no un 200.
- Registro de otro usuario: Modificar el ID para que el usuario A solicite los datos del usuario B. Si esto sucede, se trata de un grave fallo en el control de acceso.
Finalmente, confirme que cada llamada se realiza a través de HTTPS y que las respuestas fallidas no generan fugas de pila. traces o banners de versión, y que las repeticiones rápidas activan el error 429 Demasiadas solicitudes.
Las pruebas de API REST también presentan dificultades que las pruebas de interfaz no tienen.
Desafíos para las pruebas de API
Los problemas interesantes para los evaluadores durante las pruebas de API REST son:
- Para garantizar que el entorno de prueba varíe los parámetros de las llamadas a la API de tal manera que verifique la funcionalidad y, al mismo tiempo, exponga los fallos. Esto incluye explorar las condiciones límite y asignar parámetros comunes.
- Crear combinaciones interesantes de valores de parámetros para llamadas con dos o más parámetros
- Identificar el contenido bajo el cual se deben realizar las llamadas a la API. Esto puede incluir la configuración de condiciones de entorno externas (dispositivos periféricos, archivos, etc.), así como datos almacenados internamente que afectan a la API.
- Secuenciación de llamadas a la API según el orden en que se ejecutará la función
- Hacer que la API produzca resultados útiles a partir de llamadas sucesivas.
