Pruebas de carga de API y la pregunta que no pueden responder

Qué miden realmente las pruebas de carga de API

Capacidad: cuántas peticiones por segundo antes de que la latencia se degrade. Se responde generando tráfico concurrente y observando los tiempos de respuesta y las tasas de error.

Corrección: si la respuesta contiene lo que debe. Se responde con aserciones sobre los cuerpos de respuesta frente a una expectativa.

Una prueba de carga que solo comprueba códigos de estado informará de una ejecución limpia aunque cada respuesta contenga una lista vacía. El servicio fue rápido e incorrecto, y rápido e incorrecto es peor que lento y correcto, porque nadie lo investiga.

Qué te dice una suite funcional sobre la carga y qué no

Los planes de prueba de API generados incluyen casos límite y casos con forma de estrés: payloads demasiado grandes, valores fuera de rango, combinaciones de parámetros poco habituales. Esos detectan una clase real de fallo, pero no son pruebas de carga. Ejercitan los límites de uno en uno en lugar de medir el comportamiento bajo concurrencia sostenida.

Así que la división honesta es esta. Usa una herramienta de carga dedicada para la capacidad. Usa la verificación funcional para la corrección, incluidos los casos límite que solo aparecen con entradas incómodas. Ninguna sustituye a la otra, y ejecutar ambas sale más barato que descubrir el hueco en producción.

Tres cosas que conviene comprobar antes de hacer cualquier prueba de carga

Corrección en condiciones realistas

El hueco que vale la pena cerrar no está entre las pruebas de carga y las funcionales. Está en que la mayoría de las suites funcionales se ejecutan contra un entorno limpio e inactivo, así que nunca ven los fallos que aparecen cuando hay muchos datos o el estado está desordenado. Ejecutar comprobaciones funcionales contra un entorno que ya se ha usado es una forma barata de encontrarlos.

La misma configuración está disponible en el panel de TestSprite si prefieres no instalar nada en local. El resto de la superficie del CLI está en el repositorio del CLI.

Las cuatro cosas que determinan si una suite de API perdura —sesiones, valores capturados, orden y limpieza— se explican en la documentación de pruebas de API.

Leer un resultado de carga con honestidad

Los resultados de carga se sobreinterpretan más que casi cualquier otra salida de prueba, normalmente en dos direcciones.

Un número obtenido en un entorno que no coincide con producción es un punto de comparación para tu siguiente ejecución y nada más. La mitad de la base de datos, una décima parte de los datos, ningún otro tráfico, un tamaño de instancia distinto. Presentar esa cifra como capacidad es la manera en que los equipos acaban sorprendidos el día del lanzamiento por un número que creían haber medido.

La otra dirección es tratar un resultado en verde como prueba de buena salud. Si la ejecución solo hizo aserciones sobre códigos de estado, lo que has medido es que el servicio responde rápido bajo carga, algo que hará con mucha eficiencia cuando una consulta devuelve un conjunto vacío. Activa las aserciones sobre el cuerpo de la respuesta en una muestra de peticiones y esa misma ejecución te dirá algo.

Ejecuta la verificación de corrección en cada cambio

Las pruebas de carga corresponden a un calendario programado o al momento previo a una release. La corrección corresponde a cada pull request, porque es cuando una regresión sale más barata de arreglar.

• La GitHub App es un webhook que configuras en el panel de TestSprite. Escucha el evento de despliegue que tu pipeline ya produce, así que no cambia nada en tu repositorio.

• GitHub Actions coloca el paso dentro de tu propio workflow, configurado desde la terminal.

Dónde encaja TestSprite alrededor de una ejecución de carga

TestSprite cubre la capa de corrección que hace que un número de capacidad signifique algo. Ejercita la API frente al comportamiento que esperas, incluidos los casos límite y de autorización, e informa de lo que realmente se devolvió, no solo de con qué rapidez.

La cobertura se genera a partir de una pasada de descubrimiento sobre el servicio en ejecución más la especificación que tengas, de modo que las entradas incómodas se incluyen sin que nadie las escriba. Auto-Authentication mantiene vivas las sesiones durante toda la ejecución, Dynamic Variables traslada valores entre llamadas, Dependency Chains deriva el orden de ejecución a partir de lo que cada caso necesita y produce, y Auto-Cleanup elimina exactamente lo que la ejecución creó.

El beneficio es un suelo firme bajo tu trabajo de rendimiento: antes de dedicar un día a medir el throughput, sabes que el endpoint devuelve lo que debe. La concurrencia sostenida sigue siendo cosa de tu generador de carga, y ambos se ejecutan con cadencias distintas sin interferir.