Reproducción de sesiones y prueba de carga

Una solicitud capturada se puede volver a ejecutar exactamente tal cual, en dos modos que cada uno hace su propio trabajo: la reproducción de sesiones reproduce una serie de solicitudes de forma masiva, en su orden original (reproducir un flujo, verificar por regresión, reproducir contra un entorno diferente); la prueba de carga aplica presión de alta frecuencia a una sola solicitud para comprobar si aguanta. A ambas se llega con clic derecho desde los registros de captura, e incluso las APIs privadas que llevan una firma / marca de tiempo funcionan sin problema.

---

1. Tres formas de “volver a enviarla”, cada una con su propio trabajo

La misma idea de volver a enviar una solicitud capturada, dividida según el propósito:

Capacidad	Función
Componer y reproducir	Editar y reenviar una solicitud individual
Reproducción de sesiones (primera mitad de esta página)	Reproducción masiva de varias solicitudes en orden, observando el estado y la latencia de cada una
Prueba de carga (segunda mitad de esta página)	Presión de alta frecuencia sobre una sola solicitud, midiendo el rendimiento y los percentiles de latencia

---

2. Reproducción de sesiones: reproduce una serie de solicitudes de forma masiva

Toma una serie de solicitudes capturadas y vuelve a ejecutarlas de forma masiva en su orden original, reproduciendo fielmente la secuencia de solicitudes, con la opción de repetir la serie entera N veces en bucle.

Cómo llegar ahí

• Partir de una captura: haz clic derecho en “Reproducir esta solicitud” en la lista de capturas, o selecciona varias y “Reproducir las solicitudes seleccionadas”.
• Añadir a mano: “+ Añadir solicitud” en el panel, donde cada una se puede editar en el sitio, método / URL / parámetros / cabeceras / Body.

Configurable

• Número de repeticiones: ejecuta la secuencia entera N veces.
• Intervalo entre solicitudes: pausa un rato entre una y otra.
• Cambio de entorno: elige un entorno y reproduce la serie entera contra uno diferente con un solo clic.

Resultados: enumera el método, la URL, el código de estado y la latencia de cada solicitud, además del progreso general, el recuento de éxitos / fallos y el tiempo total transcurrido.

Cuándo usarlo

• Reproducir un flujo de varios pasos o un problema dependiente del tiempo.
• Regresión por lotes para verificar un grupo de endpoints.
• Reproducir un tramo de solicitudes capturadas en producción tal cual contra un entorno de prueba.

---

3. Prueba de carga: lleva una sola solicitud al límite

¿Capturaste un endpoint y quieres saber si aguanta? Haz clic derecho en “Probar la carga de esta solicitud” sobre cualquier solicitud capturada para empezar de inmediato, con el rendimiento y los percentiles de latencia reportados en tiempo real.

Dos puntos de entrada

• Prueba de carga directamente desde un registro de captura: haz clic derecho en “Probar la carga de esta solicitud”, y el método / la dirección / las cabeceras / el cuerpo se trasladan automáticamente y empieza de inmediato, rellenando cualquier protocolo que falte.
• Configuración manual: abre “Prueba de carga” desde la caja de herramientas y rellena tú mismo el objetivo y los parámetros. Es una ventana flotante, y puedes ejecutar varias pruebas de carga independientes en varias ventanas a la vez sin que interfieran entre sí.

A diferencia de las herramientas de prueba de carga ordinarias: aquí haces clic derecho en una solicitud capturada para probar su carga, sin volver a introducir parámetros, ahorrándote el ir y venir de “capturar primero en otro lugar y luego pasarlo a mano a la herramienta de prueba de carga”.

Dos modos

• Tasa constante (QPS): aplica presión de forma uniforme al ritmo de solicitudes por segundo configurado, usando un método de medición de latencia más riguroso, de modo que las latencias de cola como p99 se mantienen honestas bajo carga alta en lugar de leerse artificialmente bajas, adecuado para evaluar “la latencia real de este endpoint a X QPS”. Este rigor se aplica principalmente a este modo.
• Concurrencia: dispara sin pausa a una concurrencia fija para llevar el rendimiento al máximo, adecuado para probar “el límite de lo que puede soportar”.

Parámetros configurables

• Solicitud: método (GET / POST / PUT / PATCH / DELETE / HEAD), URL (protocolo opcional, se rellena https automáticamente), tabla de parámetros Query, tabla de cabeceras, cuerpo (JSON / formulario / bruto).
• Presión: tasa (1–100000 req/s), concurrencia / conexiones (1–2000), duración (1–3600 segundos, por duración en lugar de un total fijo de solicitudes).
• Avanzado: seguir redirecciones, omitir la verificación TLS.
• Conexiones: reutilización automática de conexiones (keep-alive); intenta automáticamente HTTP/2 para los objetivos HTTPS.

Resultados en tiempo real

• Rendimiento: un número grande de RPS en vivo más un gráfico de líneas de rendimiento en vivo.
• Recuentos: enviadas / éxitos / errores / tiempo transcurrido.
• Percentiles de latencia (milisegundos): p50 / p90 / p95 / p99 / p99.9 / máximo.
• Distribución de códigos de estado: etiquetas con código de color por 2xx / 3xx / 4xx / 5xx / error.

Se puede detener en cualquier momento; cerrar la ventana detiene automáticamente la prueba de carga en curso.

---

4. Edición de solicitudes igual de potente

Tanto en la reproducción de sesiones como en la prueba de carga, la edición de solicitudes sigue el mismo linaje que el compositor de solicitudes (Compositor): admite variables de entorno y valores dinámicos (UUID, marca de tiempo, nonce, Base64, MD5 / SHA, firma HMAC, codificación URL, y más). Así, esas APIs privadas que solo te dejan pasar con una firma / marca de tiempo aún se pueden reproducir de forma masiva y someter a prueba de carga, sin calcular la firma a mano.

---

Volver a Captura con proxy · Relacionado: Componer y reproducir