Una API puede pasar todas las pruebas funcionales y aun así fallar en producción. Devuelve los datos correctos, con el código de estado correcto, contra el esquema correcto, y luego colapsa en el momento en que mil usuarios la golpean a la vez. Las pruebas funcionales te dicen que la API es correcta. Las pruebas de rendimiento te dicen que es correcta _y_ lo suficientemente rápida para sobrevivir al tráfico real.
Esta guía explica qué son las pruebas de rendimiento de API, los tipos de pruebas que importan, las métricas a observar y cómo ejecutar una prueba de rendimiento paso a paso en Apidog.
Qué son las pruebas de rendimiento de API
Las pruebas de rendimiento de API miden cómo se comporta una API bajo carga: qué tan rápido responde, cuántas solicitudes puede manejar y en qué punto se degrada o falla. No se trata de si la respuesta es correcta; eso es pruebas funcionales. Se trata de si la respuesta llega de forma rápida y fiable cuando el sistema está bajo presión.
El objetivo es encontrar los límites antes de que lo hagan tus usuarios. Toda API tiene un techo, un punto donde los tiempos de respuesta aumentan, aparecen errores o el servicio deja de responder. Las pruebas de rendimiento localizan ese techo en un entorno controlado para que puedas elevarlo, planificar la capacidad en torno a él, o al menos saber que está ahí.
Las API son un buen objetivo para las pruebas de rendimiento porque son deterministas y rápidas de invocar. No hay un navegador que renderizar, ni una UI que esperar. Envías una solicitud, mides la respuesta. Eso hace que las pruebas de rendimiento de API sean más baratas de ejecutar y más estables que las pruebas de carga completas de extremo a extremo.
Los tipos de pruebas de rendimiento
Las "pruebas de rendimiento" son un concepto paraguas. Bajo él se encuentran varios tipos de pruebas distintos, cada uno respondiendo a una pregunta diferente.
Las pruebas de carga aplican el tráfico que realmente esperas, tu volumen de solicitudes normal y pico, y confirman que la API lo maneja dentro de tiempos de respuesta aceptables. Esta es la prueba de referencia que la mayoría de los equipos ejecutan primero.
Las pruebas de estrés superan el tráfico esperado, aumentando la carga hasta que la API se degrada o falla. El objetivo es encontrar el punto de ruptura y ver _cómo_ se rompe. ¿Se ralentiza con elegancia o devuelve errores y pierde datos?
Las pruebas de picos aplican un salto repentino y brusco en el tráfico, del tipo que produce una venta flash o un momento viral, y comprueban si la API lo absorbe o colapsa. Un sistema que maneja una carga constante aún puede fallar ante un pico.
Las pruebas de resistencia, también llamadas pruebas de fatiga, mantienen una carga moderada durante un período prolongado, horas o días, para exponer problemas lentos: fugas de memoria, agotamiento del grupo de conexiones, archivos de registro que llenan un disco. Estos nunca aparecen en una prueba de carga de cinco minutos.
Las pruebas de humo son la verificación previa ligera: una pequeña carga para confirmar que la API y la configuración de la prueba funcionan antes de comprometerse con una ejecución larga y costosa.
La mayoría de los equipos necesitan pruebas de carga, estrés y resistencia como mínimo. Las pruebas de picos son importantes si tu tráfico es irregular.
Las métricas que importan
Una prueba de rendimiento produce números. Estos son los que hay que leer.
El tiempo de respuesta es el tiempo que tarda la API en recibir, procesar y devolver una solicitud. Observa los percentiles, no solo el promedio. El promedio puede parecer saludable mientras que los percentiles 95 y 99, el 5% y el 1% de las solicitudes más lentas, son inaceptables. Los usuarios reales sienten la cola.
El rendimiento (throughput) es el número de solicitudes que la API completa por segundo. Te indica la capacidad real del sistema, independientemente de cuántos usuarios estén conectados.
Los usuarios concurrentes o usuarios virtuales es el número de llamadores simultáneos que simula la prueba. La capacidad se expresa a menudo como la concurrencia máxima que la API soporta antes de que los tiempos de respuesta superen tu presupuesto.
La tasa de errores es el porcentaje de solicitudes que fallan bajo carga. Una API que se mantiene rápida pero comienza a devolver 500s con alta concurrencia aún ha fallado la prueba.
La utilización de recursos, CPU y memoria en el servidor, te dice _por qué_ el rendimiento se degrada. Si los tiempos de respuesta aumentan mientras la CPU está al 100%, estás limitado por la computación; si la CPU está inactiva pero la latencia aumenta, el cuello de botella está en otro lugar, a menudo una base de datos o una llamada a un servicio externo.
Un buen informe de rendimiento une estos elementos: a esta concurrencia, el rendimiento alcanzó su punto máximo, el tiempo de respuesta del percentil 95 fue este, y la tasa de errores fue aquella.
Cómo ejecutar una prueba de rendimiento de API en Apidog
Apidog incluye pruebas de carga integradas en el mismo espacio de trabajo donde diseñas y pruebas funcionalmente tus API, por lo que no necesitas una herramienta separada para empezar.
Paso 1: Elige el endpoint o escenario a probar. Selecciona un único endpoint crítico, o un escenario de prueba de varios pasos que refleje un flujo de usuario real, como el inicio de sesión seguido de una recuperación de datos. Probar un flujo realista proporciona números más honestos que martillar un solo endpoint de forma aislada.
Paso 2: Confirma que pasa las pruebas funcionales primero. Ejecuta la solicitud con sus aserciones una vez. No tiene valor realizar pruebas de carga en un endpoint que devuelve datos incorrectos; corrige la exactitud antes de medir la velocidad.
Paso 3: Configura la carga. Establece el número de usuarios virtuales y la duración de la prueba. Apidog te permite aumentar la carga gradualmente, simulando que los usuarios se unen con el tiempo en lugar de todos a la vez, lo que produce una imagen más realista y ayuda a determinar el nivel de concurrencia en el que cambia el rendimiento.
Paso 4: Ejecuta la prueba. Apidog ejecuta la carga e informa en vivo: tiempos de respuesta, rendimiento (throughput), tasa de errores y cómo cambia cada métrica a medida que aumenta la concurrencia. Observa el punto de inflexión donde el tiempo de respuesta comienza a aumentar más rápido que la carga.
Paso 5: Lee los resultados y encuentra el cuello de botella. Si el tiempo de respuesta del percentil 95 supera tu presupuesto con 300 usuarios concurrentes, ese es tu techo actual. Cruza esta información con la CPU y la memoria del servidor para comprender la causa. Vuelve a ejecutar después de una corrección para confirmar que el techo se movió.
Paso 6: Para necesidades mayores, exporta a JMeter. Cuando necesites generar carga distribuida más allá de una sola máquina, Apidog puede exportar el escenario a JMeter, para que mantengas la misma definición de prueba mientras escalas la fuente de carga.
Descarga Apidog para ejecutar tu primera prueba de carga contra un endpoint que ya tienes.
Interpretando un resultado real de rendimiento
Los números sin interpretación son ruido. Considera una ejecución concreta: realizas una prueba de carga de GET /products con usuarios virtuales aumentando de 0 a 500 en cinco minutos.
Para los primeros 200 usuarios, el tiempo de respuesta del percentil 95 se mantiene estable en torno a los 180 ms y el rendimiento (throughput) aumenta al ritmo de la carga. Esta es la zona saludable; la API está al día. Aproximadamente con 280 usuarios, el tiempo del percentil 95 comienza a aumentar, 240 ms, luego 400 ms, luego 900 ms, mientras que el rendimiento se estanca en lugar de aumentar. Ese estancamiento es la señal: la API ha alcanzado su techo. Añadir más usuarios ahora produce respuestas más lentas, no más trabajo completado. Más allá de los 420 usuarios, la tasa de errores supera el 1% a medida que las solicitudes comienzan a expirar.
El veredicto es concreto. Esta API atiende cómodamente a unos 250 usuarios concurrentes dentro de un presupuesto de 200 ms. Su techo práctico está cerca de los 280, y comienza a fallar alrededor de los 420. Si esperas un tráfico pico de 200 usuarios concurrentes, tienes margen. Si esperas 350, tienes un problema que solucionar antes del lanzamiento, no después.
Eso es lo que ofrece una prueba de rendimiento: no un "aprobado" o "fallido", sino un mapa claro de dónde la API se siente cómoda, dónde se esfuerza y dónde se rompe.
Cuellos de botella comunes en el rendimiento de las API
Cuando una prueba expone un techo, la causa suele ser uno de los pocos culpables conocidos.
Las consultas lentas a la base de datos son las más comunes. Una columna sin indexar, un patrón de consulta N+1 o un límite de consulta faltante convierte un endpoint rápido en lento en el momento en que el volumen de datos o la concurrencia aumentan. Si la latencia aumenta mientras la CPU del servidor se mantiene baja, sospecha primero de la base de datos.
Las llamadas externas bloqueantes arrastran un endpoint a la velocidad de su dependencia más lenta. Una API que llama a un proveedor de pagos o a un servicio de terceros de forma síncrona hereda la latencia y las interrupciones de ese servicio.
El agotamiento del pool de conexiones aparece bajo carga sostenida: la API se queda sin conexiones a la base de datos o clientes HTTP y las solicitudes se acumulan esperando. Este es un hallazgo clásico de las pruebas de resistencia.
La serialización ineficiente de grandes cargas útiles de respuesta consume CPU. Devolver más datos de los que el cliente necesita hace que cada respuesta sea más lenta de construir y más lenta de transferir.
Una prueba de rendimiento señala _dónde_ está el techo; combinarla con métricas del lado del servidor te dice _por qué_.
Integrando las pruebas de rendimiento en tu proceso
Una prueba de rendimiento ejecutada una vez antes de un gran lanzamiento es útil. Una prueba de rendimiento que se ejecuta regularmente es mucho más valiosa, porque el rendimiento se degrada silenciosamente. Una nueva consulta a la base de datos, una llamada adicional a un servicio posterior o una columna sin indexar pueden añadir latencia que ninguna prueba funcional detecta.
Establece un presupuesto de tiempo de respuesta y tasa de errores para tus endpoints críticos, y trata un incumplimiento como un fallo, de la misma manera que tratas una aserción rota. Ejecuta una prueba de carga más ligera como parte de CI/CD para que una regresión salga a la luz en la solicitud de extracción, y reserva las ejecuciones de estrés y resistencia pesadas para las pruebas programadas previas al lanzamiento.
Mantén las pruebas de rendimiento junto a las pruebas funcionales. Cuando ambas conviven, cada cambio en la API se verifica tanto por su corrección como por su velocidad, y "funciona" y "funciona lo suficientemente rápido" dejan de ser preguntas separadas y fácilmente olvidadas.
Preguntas frecuentes
¿Cuál es la diferencia entre pruebas de carga y pruebas de estrés? Las pruebas de carga aplican el tráfico que esperas y confirman que la API lo maneja. Las pruebas de estrés van más allá para encontrar el punto de ruptura. Las pruebas de carga verifican el funcionamiento normal; las pruebas de estrés mapean el modo de fallo.
¿Debería fijarme en los tiempos de respuesta promedio o en los percentiles? En los percentiles. El promedio oculta la cola lenta. Los percentiles 95 y 99 muestran lo que realmente experimentan tus usuarios con menos suerte, y eso es lo que genera quejas.
¿Puedo probar el rendimiento de una API antes de que el backend esté terminado? Puedes probar el contrato y el diseño, pero los números de latencia significativos requieren una infraestructura real. Usa un servidor simulado para el trabajo funcional temprano, y ejecuta pruebas de carga contra la implementación real.
¿Con qué frecuencia deben ejecutarse las pruebas de rendimiento? Ejecuta una prueba de carga ligera en CI con cada cambio en los endpoints críticos, y pruebas completas de estrés y resistencia antes de cada lanzamiento importante. El rendimiento se degrada silenciosamente, por lo que las verificaciones regulares son mejores que una gran ejecución previa al lanzamiento.