Tutorial de Pruebas de Carga API: Guía para Principiantes

¿Qué es la prueba de carga de API?

La prueba de carga de API es el proceso de evaluar el rendimiento y la escalabilidad de una Interfaz de Programación de Aplicaciones (API) bajo tráfico simulado intenso. Se prueba qué tan bien una API maneja niveles elevados de solicitudes, actividad prolongada, y alcances de prueba más amplios, que van desde puntos finales individuales hasta flujos de trabajo completos de extremo a extremo. El objetivo es confirmar que tu API puede gestionar de manera fiable los niveles esperados de tráfico mientras ofrece una experiencia consistente para los usuarios.

Al realizar pruebas de carga de API, recopilas métricas de rendimiento como tiempos de respuesta, latencia, rendimiento y la salud general de la API bajo estrés. Estas medidas validan si tu sitio web o aplicación puede mantener un rendimiento fluido durante picos de uso.

La prueba de carga de API puede abordarse de muchas maneras según los objetivos de tu proceso de pruebas. Desde pruebas de estrés para determinar puntos de quiebre hasta pruebas de resistencia para uso prolongado, cada tipo de prueba proporciona diferentes perspectivas sobre cómo se desempeña tu API bajo condiciones específicas. Las aplicaciones modernas dependen de múltiples APIs trabajando juntas, lo que hace importante probar cómo funcionan estos servicios bajo uso concurrente.

A medida que las organizaciones adoptan arquitecturas de microservicios y desarrollo centrado en API, las pruebas de carga de API se han vuelto aún más críticas. Las aplicaciones modernas dependen de decenas o incluso cientos de APIs que se comunican simultáneamente, por lo que las pruebas de rendimiento son esenciales para mantener la fiabilidad y escalabilidad.

Pruebas de rendimiento de API

Las pruebas de rendimiento de API miden cómo se comporta una API bajo un nivel definido de tráfico: qué tan rápido responde, cuánto trabajo completa y cuánto de ese trabajo falla. La prueba de carga es una pregunta dentro de esa disciplina, qué sucede al tráfico que esperas. El resto de la categoría cubre qué ocurre más allá de ese nivel, cuando el tráfico llega todo a la vez y cuando nunca se detiene.

Cuatro tipos de pruebas están dentro de esta categoría, y cada una responde a una pregunta diferente con una métrica diferente.

• Prueba de carga mantiene tu API al tráfico que esperas y pregunta si los tiempos de respuesta permanecen dentro de tus objetivos. La métrica es el tiempo de respuesta del percentil 90 en la concurrencia objetivo, escrito p90, no el promedio.
• Prueba de estrés supera el nivel esperado hasta que algo se rompe. La métrica es la concurrencia en la que la tasa de errores comienza a subir, lo que indica cuánto margen tienes sobre el tráfico normal. Load testing vs stress testing cubre la distinción con más profundidad.
• Prueba de picos salta de bajo a alto tráfico en segundos en lugar de rampas. La métrica es el tiempo de recuperación: cuánto tiempo después del pico vuelven los tiempos de respuesta a la línea base. Grupos de autoescalado y pools de conexión tienden a fallar esta prueba aunque pasen una rampa gradual.
• Prueba de resistencia (soak testing) mantiene una carga moderada por horas. La métrica es la deriva, es decir, el tiempo de respuesta o uso de memoria que aumenta constantemente durante una ejecución prolongada. Las fugas de conexión y cachés sin límite solo aparecen aquí.

Los mismos cuatro tipos de prueba, representados como usuarios concurrentes a lo largo del tiempo.

El tiempo de respuesta, el rendimiento y la tasa de error se recopilan en las cuatro pruebas. Lo que cambia es cuál lees primero: tiempo de respuesta en una prueba de carga, tasa de error en una prueba de estrés, la forma de la curva de tiempo de respuesta después de un pico, y la pendiente durante toda la ejecución en una prueba de resistencia.

Realizar solo pruebas de carga es un vacío común. Un servicio puede pasar con éxito una rampa limpia hasta 200 usuarios concurrentes y aun así fallar ante un correo electrónico de marketing que entrega esos mismos 200 usuarios en cuatro segundos, o tener fugas de memoria suficientes en seis horas que requieran un reinicio nocturno.

Por qué la prueba de carga de API es crítica

La prueba de carga de API asegura que tu aplicación funcione sin problemas bajo tráfico intenso. Dado que las APIs son la columna vertebral de las aplicaciones modernas, cualquier lentitud o fallo afecta directamente la experiencia del usuario. La prueba de carga revela los cuellos de botella y límites de rendimiento que necesitas optimizar, lo que previene fallos en picos de uso y mantiene tu app confiable sin importar la demanda.

Beneficios de la prueba de carga de API y por qué deberías hacerlo

Las APIs son la base de la mayoría del software moderno, por lo que probar su carga vale la pena. Te informa sobre cómo rendimiento, escalabilidad y fiabilidad se mantienen bajo uso concurrente, y confirma que la API cumple con tus acuerdos de nivel de servicio.

Minimiza los costos por fallas en la API

Identificar problemas de rendimiento en la API antes del despliegue cuesta mucho menos que solucionar tiempo de inactividad en producción. La prueba de carga encuentra errores de código que causan degradación bajo estrés anticipado o inesperado, y revela fallos de implementación difíciles de reproducir de otra manera.

Minimiza y mitiga el tiempo de inactividad de la API

La prueba de carga de API te muestra la capacidad de la API para manejar solicitudes sin caídas, previniendo tiempos de inactividad. También reduce la probabilidad de interrupciones al identificar y aislar las solicitudes que necesitan mejoras de rendimiento, para que tus recursos se enfoquen donde el tráfico realmente impacta.

Mejora tu infraestructura API

La prueba de carga de API determina la infraestructura adecuada evaluando el volumen de solicitudes en diferentes casos de uso, e identifica el número máximo de solicitudes concurrentes que un punto final puede manejar. Con ese dato, tus equipos pueden planear aumentos esperados de tráfico.

Mejora rendimiento y satisfacción del cliente

Desarrollar APIs es complicado con tantos puntos finales y altas expectativas. Tus APIs podrían enfrentar tiempos de respuesta demorados, problemas de latencia, y límites de rendimiento. La prueba de carga detecta esos cuellos de botella más rápido y te permite corregirlos antes del despliegue en producción.

Cuándo realizar la prueba de carga de API

Vale la pena hacer pruebas de carga de API en varias etapas del ciclo de desarrollo de software. Ayuda durante el desarrollo a identificar cuellos de botella temprano y confirmar que tus APIs soportan cargas esperadas y se comportan predeciblemente bajo estrés. También debería realizarse antes de desplegar APIs a producción para validar escalabilidad y fiabilidad en un entorno simulado. Cuando se hagan cambios significativos en las APIs o la infraestructura subyacente, estas pruebas evalúan el impacto y confirman que las nuevas implementaciones cumplen las expectativas. Además, realizar pruebas de carga periódicas es recomendable para detectar degradación antes de que afecte a los usuarios finales.

Cómo hacer pruebas de carga a APIs

Probar la carga de una API implica ocho pasos: definir el objetivo como un número, elegir el tipo de prueba, configurar la solicitud, añadir validación, establecer la curva de carga, elegir la procedencia de la carga, ejecutar la prueba y leer el informe. El siguiente recorrido cubre los ocho en api.restful-api.dev/objects, una API REST gratuita que no requiere llave. Es un servicio público compartido, así que mantiene pruebas de práctica alrededor de 25 usuarios concurrentes y apunta la misma configuración a tu propio endpoint para los números de 200 usuarios.

Paso 1: Anota lo que intentas averiguar

Escribe tu objetivo como un número que puedas verificar. “Ver si la API es rápida” no puede aprobar o fallar; esto sí:

A 200 usuarios concurrentes sostenidos por 10 minutos, GET /objects devuelve un tiempo de respuesta del percentil 90 por debajo de 400 ms con una tasa de error menor al 1%.

Cuatro cosas hacen esto usable: un número de concurrencia, una duración, el endpoint y un umbral en un percentil en lugar de un promedio. Los promedios ocultan la cola lenta. Si 95 solicitudes responden en 80 ms y 5 tardan 6 segundos, el promedio es un cómodo 376 ms y el 5% de tus usuarios esperó seis segundos.

Toma el umbral de un presupuesto que ya tengas, o ejecuta una vez con baja carga y usa eso como línea base. También necesitas la URL, el método, headers requeridos, un cuerpo si el método lo lleva y credenciales. Aquí: https://api.restful-api.dev/objects, GET, sin autenticación.

Paso 2: Elige el tipo de prueba

LoadView pide primero un tipo de prueba, y eso moldea el resto de la configuración. Las opciones son Navegador Real (Aplicación Web), HTTP/S, SOAP, Rest WEB API, Postman (Colección), JMeter, Selenium, Streaming Media y WebSocket.

A dónde apuntas la prueba decide el tipo.

Para un endpoint JSON, elige Rest WEB API. Verifica disponibilidad, rendimiento, datos devueltos y autenticación bajo carga, con campos para headers, cuerpo y validación. Los otros se ajustan a casos específicos:

• HTTP/S para solicitudes concurrentes contra una URL cuando solo te importa que el servidor responda.
• SOAP para servicios WSDL, donde la solicitud es un sobre XML.
• Postman (Colección) cuando las solicitudes ya existen en una colección: expórtala y súbela, como describe el tutorial de prueba de carga con Postman Collection. JMeter hace lo mismo para un plan JMX.

Paso 3: Configura la solicitud

Ingresa la URL completa incluyendo el esquema, luego establece el método en Tipo de Solicitud: https://api.restful-api.dev/objects con GET.

Cuatro campos, dos con una trampa asociada.

Marcar como Error Respuestas que Excedan define cuántos segundos LoadView espera antes de registrar un error, y es más importante de lo que parece: con un valor grande por defecto, una solicitud de 30 segundos aún cuenta como éxito. Ajústalo donde el usuario habría desistido, aquí 5 segundos.

Los headers se ingresan en la sección Headers como pares de nombre y valor.

Para un POST o PUT, la carga va en la sección Body, llamado Post Data en documentación anterior. Pega el JSON y LoadView lo analiza, te solicita elegir un header de tipo de contenido y lo añade a Headers por ti:

{
  "name": "LoadView Test Object",
  "data": {
    "year": 2026,
    "price": 1849.99,
    "CPU model": "Intel Core i9",
    "Hard disk size": "1 TB"
  }
}

Las credenciales van en la sección Autenticación Básica. La autenticación basada en token implica dos solicitudes en lugar de una configuración, porque debes obtener el token antes de usarlo. LoadView documenta ese patrón para APIs basadas en OAuth 2.0: una solicitud para obtener token y luego la solicitud al recurso con el resultado.

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Agrega la segunda solicitud con Añadir Objetivo; las solicitudes se ejecutan en orden según aparecen en la barra lateral. Para transferir el token, convierte el parámetro que lo requiere en un Parámetro de Contexto, que funciona en la URL, headers, cuerpo y scripts.

Un flujo de token son dos solicitudes, no una configuración.

Paso 4: Añade validación

Una prueba que solo verifica si llegan bytes reporta una ejecución limpia mientras tu API devuelve 500s. Las fallas rápidas son las respuestas más rápidas en cualquier prueba, así que valida dos cosas.

Códigos de respuesta esperados declara qué códigos de estado cuentan como éxito; cualquier otro se registra como error. Para este GET, pon 200. La semántica de códigos de estado viene de RFC 9110, y la trampa es POST: muchas APIs responden una creación exitosa con 201, así que una solicitud que crea un objeto necesita 200, 201 en lugar de solo 200.

Solo el tercer panel demuestra que la solicitud hizo lo que pediste.

Validación de contenido revisa el cuerpo de la respuesta buscando palabras clave que suministres, combinadas con expresiones lógicas donde & es Y, | es O, y ! es NO:

{["Apple MacBook Pro 16"&"CPU model"]}

Elige una palabra clave que aparezca solo en éxito. Un nombre de campo que también aparece en el sobre de error de la API no valida nada.

Paso 5: Establece la curva de carga

LoadView tiene tres opciones de curva de carga. Este recorrido usa Load Step Curve, la que responde “cómo cambian los tiempos de respuesta conforme aumentan los usuarios”. Esta prueba comienza con 5 usuarios concurrentes, sube a 25 en 6 minutos, mantiene 5 minutos, y baja en 2. Contra tu propio endpoint: comienza en 10, sube a 200 en 10 minutos, mantiene 10, baja en 3. El tiempo de mantenimiento es la parte que recortan las personas y la que importa: la rampa indica cuándo comenzaron los problemas y el mantenimiento si se mantienen o no.

La curva que esta prueba usó, con cada segmento etiquetado.

Curva basada en objetivos toma un rendimiento objetivo y ajusta usuarios virtuales para alcanzarlo, adecuada para requisitos expresados en transacciones por minuto. Curva dinámica ajustable permite mover el número de usuarios a mano durante la prueba, útil cuando escalas infraestructura y observas el efecto en la misma ventana.

Paso 6: Elige tus ubicaciones geográficas

Los inyectores de carga comienzan en más de 40 zonas de Norteamérica, Sudamérica, Europa y APAC. La geografía no es decoración aquí: cada 1,000 millas entre cliente y servidor añade latencia de ida y vuelta que ningún ajuste elimina, y un handshake TLS paga este costo varias veces.

Esta prueba usó una sola zona en US East, que separa el comportamiento de la aplicación de la distancia de red. Añade las zonas de tus usuarios una vez tengas esa línea base: si tu API está en us-east-1 y una cuarta parte de tu tráfico es alemán, el número de Frankfurt es lo que esos clientes reciben. La red de inyectores geo-distribuida es gestionada, no tienes que dimensionarla.

El mismo endpoint medido desde tres distancias.

Paso 7: Ejecuta la prueba y lee el informe

LoadView calibra antes de la ejecución para determinar cuántos servidores de inyección necesita. Observa los primeros dos minutos: si los tiempos de respuesta suben a 5 usuarios es un problema de preparación, no de API, así que detén y corrige antes de pagar la curva completa. Después, deja correr la prueba. Reiniciar un servicio durante la prueba produce un gráfico que nadie puede interpretar.

El informe abre en la pestaña Resumen: un resumen mostrando sesiones exitosas contra sesiones con errores, luego los gráficos. Léelos en este orden.

Plan de ejecución es lo primero y muchos lo saltan. Muestra Usuarios Virtuales Actuales contra Esperados y Máximos. Si la línea actual sigue la esperada, la carga aplicada es la que pensabas. Si falla en el intento, el resto describe una prueba que nunca se ejecutó.

Cuatro gráficos, cuatro preguntas, en el orden para hacerlas.

Tiempo de respuesta muestra duración promedio de transacción y percentil 90 juntos. Lee la distancia entre líneas, no solo su altura. Un p90 que se despega del promedio indica que se forma una cola lenta: una cola llenándose, un pool de conexiones en su límite, una caché que empieza a fallar. La brecha se amplía antes que el promedio se mueva, siendo la señal temprana.

Por qué el percentil es la alerta temprana y el promedio la tardía.

Sesiones iniciadas compara sesiones totales contra las exitosas y fallidas. Degradación de tiempos bajo carga puede ser normal y aceptable; fallas en solicitudes, no. Filtra la pestaña Sesiones por estado Fallido para ver respuestas individuales, incluyendo código y respuesta del servidor.

Carga del inyector de carga es la verificación de sentido: alta utilización del inyector con un objetivo lento puede indicar que mides infraestructura de prueba y no la API. Tres lecturas deberían hacerte actuar:

• Tasa de error sube antes que el tiempo de respuesta. Algo rechaza conexiones en lugar de encolarlas. Revisa límites de conexión, conteos de trabajadores y limitación de tasa primero.
• El percentil 90 sube mientras el promedio se mantiene. Algunas solicitudes toman camino lento: fallos en caché, consulta sin índice o dependencia lenta.
• Promedio y p90 suben juntos, proporcionalmente a usuarios. Saturación, el caso más fácil de planear. Note la concurrencia donde cruzaste tu umbral y trátala como techo.

Las mismas tres lecturas, y a dónde te lleva cada una.

Latencia, tráfico, errores y saturación son las cuatro señales que recomienda el libro SRE de Google para un sistema orientado a usuarios. Una prueba de carga mide las tres primeras desde afuera; observa la saturación en servidor y recuerda que la mayoría de sistemas se degradan mucho antes de llegar al 100% de utilización. Para más sobre vistas de informe, ve cómo analizar resultados con LoadView.

Paso 8: Qué salió mal

La prueba POST midió un GET. El tipo de solicitud estaba en POST y el endpoint correcto, pero el cuerpo no se había llenado aún, y LoadView vuelve a GET al guardar si POST, PUT o PATCH están seleccionados sin parámetros. Nada te avisa después. La prueba ejecutó limpia y reportó buenos números para una lectura en un endpoint pensado para escritura. Llena el cuerpo antes de guardar, luego reabre la solicitud y verifica el método.

La segunda trampa es más silenciosa. La API demo responde una creación exitosa con 200, mientras muchas APIs usan 201. Envía una solicitud manual y lee el código antes de llenar Códigos esperados. Una API pública demo también limita tasa, así que si la tasa de error sube en una carga que tu infraestructura toleraría, revisa si el objetivo te está limitando y no saturando.

La documentación de LoadView dice que secuencias multi solicitud en la prueba Rest WEB API pueden ser difíciles de configurar, y apunta a Postman para secuencias complicadas. Si encadenar cuatro solicitudes se vuelve un proyecto, esa es la salida.

Mejores prácticas para prueba de carga de API

Los cinco ajustes que más influyen en tus números son tiempo de pensamiento, datos de prueba, el entorno de prueba, periodo de calentamiento y cuántas veces repites la ejecución. Primero los hábitos generales:

• Prueba en un entorno dedicado, pero usa datos con forma de producción.
• Define tus benchmarks desde el inicio. Los acuerdos de nivel de servicio te dan un objetivo.
• Comienza temprano y prueba seguido, para que los problemas salgan antes de que tus APIs estén en vivo.

Estos cuatro son fáciles de acordar pero difíciles de aplicar sin detalles. Así lucen en configuración.

Ajusta el tiempo de pensamiento según cómo se llama la API

El tiempo de pensamiento es la pausa entre solicitudes, controlada a través del Perfil de Comportamiento del Usuario. Retrasos mínimos hacen que la prueba corra a máxima velocidad, encontrando límites rápido y produciendo una tasa de solicitud que ninguna población humana generaría. Retrasos realistas te dan un número de capacidad para planear.

Lo adecuado depende del llamante. Una API llamada por una app móvil entre toques tiene segundos naturales de espera, así que modela eso. Una llamada por otro servicio en un bucle cerrado no tiene ninguno. Errar por el lado generoso es la forma más común en que una prueba de carga reporta una capacidad que un sistema no tiene.

Dale a cada usuario virtual sus propios datos de prueba

Doscientos usuarios virtuales solicitando /objects/7 se servirán desde caché tras la primera solicitud, y tus números describen la caché. Varía el identificador para que cada usuario acceda a un registro distinto. El campo de script de preparación usa C#. Genera un valor único por sesión y refiérelo en el cuerpo mediante sintaxis Razor:

context.Guid = Guid.NewGuid().ToString();
context.CurrentTime = DateTime.Now.ToUniversalTime().ToString("yyyy-MM-dd\\Thh:mm:ss") + ".0Z";
ProcessPostDataByRazor(currentTask);

El cuerpo referencia esos valores como @Model["Guid"] y @Model["CurrentTime"]. Si tu prueba crea registros, planea cómo se borran. Una prueba de resistencia que escribe por seis horas deja una tabla que la siguiente prueba debe leer.

Decide contra qué pruebas antes de probar

Probar contra producción da la única respuesta verdadera y pone en riesgo a tus clientes. Probar contra staging es seguro y da una respuesta sobre staging. El punto medio viable es un entorno staging que coincida con producción en tres cosas que mueven números de rendimiento: tamaño de instancias, conteo de filas en base de datos y configuración de caché. Una base staging con 10,000 filas no reproducirá el plan de consulta que producción escoge con 40 millones. Si no pueden coincidir, anota las diferencias antes para saber dónde están tus resultados errados.

Calienta antes de medir

El primer minuto de cualquier ejecución mide cachés frías, pools de conexión vacíos y código sin JIT compilado. Esos números son reales, pero responden a otra pregunta. Una rampa maneja esto solo, otra razón para Load Step Curve sobre un inicio plano. Si comienzas plano, descarta los primeros 60 a 120 segundos y sé consistente: comparar ejecución calentada con fría entre versiones produce regresión inexistente.

Ejecuta la misma prueba tres veces

Una única ejecución es anecdótica. Infraestructura compartida, vecinos ruidosos y trabajos en segundo plano mueven resultados más que el cambio que mides.

Ejecuta la misma configuración tres veces y compara el percentil 90 entre las tres. Una variación de aproximadamente 10% te da un número en que puedes confiar y actuar. Más amplio y tu entorno es muy ruidoso para medir, lo que debe corregirse primero. Una vez estable, ese número es la línea base contra la que comparas ejecuciones posteriores.

Automatización de prueba de carga de API en CI/CD

Automatiza la prueba de carga invocando una prueba desde tu pipeline y fallando la construcción cuando no se cumple un umbral. LoadView ofrece integraciones CI/CD para Azure DevOps, Jenkins y CircleCI que hacen justo eso. La mayoría detiene tras la primera corrida exitosa, momento en que una línea base deja de ser rentable.

Divide el trabajo según el costo. Un chequeo corto contra 1 o 2 endpoints debería correr en cada merger a main: baja concurrencia, pocos minutos, suficiente para atrapar una consulta que perdió índice. La curva completa para un candidato a lanzamiento. Ejecutar 200 usuarios concurrentes en cada commit gasta dinero respondiendo una pregunta ya resuelta esa mañana.

Chequeo corto en cada merge, curva completa en candidato a lanzamiento.

El umbral es el Umbral de Sesiones Fallidas: establece el porcentaje de sesiones fallidas tolerables, y la construcción falla si se supera.

Ese umbral cubre errores, no lentitud. Una construcción donde todas las sesiones pasaron con un p90 triple pasa la puerta de sesiones fallidas limpio, así que el tiempo de respuesta necesita su propio chequeo. Extrae p90, compáralo con la línea base guardada y decide antes qué cuenta como regresión. Un 20% sobre línea base es un buen inicio, a ajustar según ruido ambiental.

Mantén la definición de prueba en control de versiones donde la herramienta lo permita: un archivo JMX o colección Postman que viva en el repositorio cambia cuando cambia el código que prueba. Y arregla el entorno ruidoso antes de usarlo como puerta, porque una pipeline que falla construcciones al azar se apaga rápido y pierdes puerta y hábito.

Comparación de herramientas para prueba de carga de API

Apache JMeter, Postman, Grafana k6, SoapUI y LoadView cubren la mayoría del trabajo de prueba de carga de API, y no compiten para el mismo trabajo. Elige según de dónde viene la carga y dónde debe vivir la prueba, no solo por funciones.

1) LoadView gana su lugar por inyectores gestionados, que hacen de una prueba con 40+ zonas una elección de configuración en vez de un proyecto de adquisición, y por pruebas de navegador real junto a pruebas de API. Importa archivos JMX y colecciones Postman, así un plan ya existente sobrevive. Ofrece planes on-demand, suscripción y empresariales, aunque una prueba liviana para cada commit puede ir mejor en herramienta CLI en tu pipeline.

2) Apache JMeter es la opción gratis más capaz y con el ecosistema de plugins más profundo, con cobertura que va más allá de HTTP hacia bases y colas. Su costo no es licencia sino operación: debes proveer y monitorear los generadores de carga, y carga en 5 países implica máquinas en 5 países.

3) Postman tiene la ruta más corta de una solicitud que ya tienes a un número de carga, ejecutando la colección usada en pruebas funcionales desde tu entorno local o la nube de Postman. Para un ingeniero que verifica un endpoint antes de pull request, nada es tan rápido. Es una herramienta de desarrollo, no de planificación de capacidad, y se posiciona así.

4) Grafana k6 es la mejor opción cuando las pruebas de rendimiento deben estar en control de versiones. Las pruebas son JavaScript, así se revisan, comparan y ejecutan con la misma pipeline que el resto, y los umbrales hacen fallar una construcción como un test unitario. Si tu requisito es chequear cada pull request, k6 es mejor por defecto que LoadView, y eso vale decirlo claro.

5) SoapUI cubre pruebas funcionales, seguridad, carga y simulación en una sola herramienta open source para REST, SOAP y GraphQL. Su ventaja es la reutilización: un caso funcional se vuelve prueba de carga sin reconstrucción, importante en ambientes con mucho SOAP. ReadyAPI es la versión comercial con módulo de carga más grande.

Dónde comenzar

Elige el endpoint único que más daño causaría si se volviera lento, usualmente login, búsqueda o pago. Escala una prueba Rest WEB API a tu pico esperado, mantén diez minutos y ejecútala tres veces desde un lugar. Esa es una línea base en una tarde. Los equipos se estancan tratando de modelar todo el sistema de una vez.

Preguntas frecuentes sobre prueba de carga de API

Las preguntas abajo surgen con más frecuencia cuando un equipo empieza a probar carga en una API. Cada respuesta se sostiene sola.

Prueba de carga de APIs con LoadView

Probar la carga de una API con LoadView puede ser tan simple como crear un script que envíe varias llamadas en secuencia y escalar usuarios simultáneos al límite de tráfico esperado. Los scripts son reutilizables y pueden monitorear el sistema durante todo el periodo del servicio.

La prueba de carga de API de LoadView soporta APIs RESTful incluyendo JSON y XML, SOAP y APIs web que requieren autenticación o ejecución multi-paso. Según los requerimientos, la plataforma permite elegir entre varias curvas de carga.

Hay tres curvas: Load Step Curve para número definido de usuarios concurrentes por tiempo especificado, Goal-based Curve para alcanzar tasa de transacciones requerida automáticamente, y Dynamic Adjustable Curve para cambiar carga a mano durante la prueba.

LoadView también distribuye carga en más de 40 regiones geográficas con cualquier división que elijas, y elegir las más cercanas a tus usuarios produce la emulación más precisa.