Cómo leer reportes de pruebas de carga y convertir resultados en acción

El deck muestra gráficos verdes de p95—pero nadie anotó VUs objetivo, iteraciones descartadas ni qué ruta tenía la cola. Liderazgo aprueba el release; producción sigue doliendo en /cart/checkout porque el reporte respondió «¿la latencia fue alta?» en lugar de «¿simulamos checkout pico y dónde falló?».

Un reporte útil responde tres preguntas: ¿Simulamos el tráfico que queríamos? ¿El comportamiento visible para el usuario se mantuvo aceptable? Si no, ¿qué subsistema merece la próxima hora de investigación?

El resumen integrado de k6 agrega métricas HTTP, checks y umbrales (metrics, results output). En esta guía verás cómo leer ese resumen en orden, detectar patrones clásicos de fallo y exportar narrativas accionables sin hype.

Calienta con p95 vs p99 latencia y contrasta la metodología con errores comunes en pruebas de carga. Si el dimensionado aún es difuso, combina con cuántos usuarios virtuales k6.

Por qué el orden del reporte importa más que otro gráfico

Las métricas interactúan. Un http_req_failed alto distorsiona percentiles de latencia. Iteraciones descartadas en modo arrival-rate significan que mediste carga por debajo del objetivo, no «rápido en pico».

Los checks pueden pasar mientras fallan umbrales—respuestas válidas pero lentas. Leer promedios antes de la fidelidad del escenario invita falsa confianza.

Piensa en el reporte como línea de tiempo de incidente:

1. Fidelidad del escenario — duración, ejecutor, stages, VUs/iteraciones alcanzados.
2. Tasa de fallos — http_req_failed y fallos de checks por tag.
3. Forma de latencia — p95/p99 segmentados por ruta o journey.
4. Throughput — http_reqs vs subida de latencia (firma de saturación).

Saltar el paso uno es diagnosticar producción sin saber qué deploy estaba vivo.

El tamaño de muestra importa para percentiles. Un p99 en smoke de dos minutos con pocas peticiones es ruido; documenta duración mínima y conteo de iteraciones junto a las slides de percentiles para que nadie persiga fantasmas. Si dudas, extiende el stage estable o sube la tasa de llegada modestamente hasta que rutas etiquetadas tengan muestras suficientes—luego relee colas (p95 vs p99).

Cuando percentiles bonitos ocultan la prueba equivocada

Equipos presentan http_req_duration agregado mientras checkout era el 10 % del tráfico. Páginas de marketing dominan el promedio; las colas de checkout desaparecen. Etiqueta escenarios (route, journey, version) para alinear resúmenes con análisis de cuellos de botella.

Implementación práctica con k6: umbrales, checks y rutas etiquetadas

Codifica gates SLO en umbrales; codifica corrección lógica en checks. Exporta resúmenes con tendencias de percentiles para comparar builds.

Script de ejemplo (ilustrativo—no listo para producción). Números SLO ficticios; adapta a tu servicio.

Qué demuestra este ejemplo:

• Checks en status y fragmento JSON; umbrales en p95/p99 etiquetados.
• Rutas agrupadas para partir browse vs checkout en el resumen.
• Metadatos de escenario vía tags (build, env) para nombres de artefactos en CI.
• Tasa de fallos estricta antes de gates de latencia para que las colas sean significativas.

import http from 'k6/http';
import { check, group, sleep } from 'k6';

const BASE = __ENV.API_BASE || 'https://staging.example.com';
const BUILD = __ENV.BUILD_SHA || 'local';

export const options = {
  scenarios: {
    report_demo: {
      executor: 'ramping-vus',
      stages: [
        { duration: '1m', target: 10 },
        { duration: '5m', target: 40 },
        { duration: '1m', target: 0 },
      ],
      tags: { build: BUILD, env: __ENV.ENV || 'staging' },
    },
  },
  thresholds: {
    http_req_failed: ['rate<0.01'],
    'http_req_duration{route:browse}': ['p(95)<450', 'p(99)<800'],
    'http_req_duration{route:checkout}': ['p(95)<900', 'p(99)<1400'],
    checks: ['rate>0.99'],
  },
};

export default function () {
  group('browse', () => {
    const res = http.get(`${BASE}/catalog`, { tags: { route: 'browse' } });
    check(res, {
      'browse status 2xx': (r) => r.status >= 200 && r.status < 300,
      'browse has items': (r) => r.body && r.body.includes('items'),
    });
    sleep(1);
  });

  group('checkout', () => {
    const body = JSON.stringify({ sku: 'SKU-1', qty: 1 });
    const res = http.post(`${BASE}/checkout`, body, {
      headers: { 'Content-Type': 'application/json' },
      tags: { route: 'checkout' },
    });
    check(res, {
      'checkout status 2xx': (r) => r.status >= 200 && r.status < 300,
    });
    sleep(0.5);
  });
}

Patrones que funcionan

• Leer http_req_failed primero, luego percentiles; segmentar por tags presentes en el script.
• Adjuntar parámetros de escenario (ejecutor, stages, tasas, env) a cada PDF o slide.
• Usar --summary-trend-stats="p(95),p(99)" en CI para colas comparables corrida a corrida.
• Traducir a historias de usuario para ejecutivos: «El 4 % de sesiones simuladas de checkout esperó >1 s.»

Antipatrones a evitar

• Capturas sin contexto de VU/RPS—stakeholders comparan corridas incompatibles.
• Celebrar checks que pasan cuando fallaron umbrales (válido pero lento).
• Ignorar iteraciones descartadas en ejecutores arrival-rate (arrival-rate tracking).

Pro tip (comando de ejemplo):

k6 run report-demo.js --summary-export=summary.json --summary-trend-stats="p(95),p(99)"

Qué demuestra este comando: JSON de resumen legible por máquina para dashboards más tendencias de percentiles para diff de builds.

Marco de decisión: qué métrica escalar primero

Escala tasa de fallos primero cuando http_req_failed supera el presupuesto—los percentiles mienten en cuerpos de error.

Escala p99 etiquetado cuando journeys visibles al usuario tienen SLO de cola estrictos (checkout, pagos).

Escala fidelidad del escenario cuando VUs o iteraciones no alcanzaron objetivos documentados.

Comunica hacia arriba sin hype

Traduce métricas a historias: «Bajo tráfico simulado de checkout pico, el 4 % de las sesiones esperó más de un segundo—principalmente en /cart/checkout.» Adjunta parámetros del escenario para que nadie confunda corridas. Para vocabulario de trade-offs, comparte throughput vs latencia junto al anexo del reporte.

Checklist pre-release

• El export incluye modelo de ejecutor, stages, duración y carga alcanzada (VUs/RPS).
• Resumen segmentado por tags de ruta/journey usados en el script.
• Tabla de umbrales copiada con pass/fail y valores reales de p95/p99.
• Checks y http_req_failed revisados antes de que latencia vaya a liderazgo.
• SHA de build o tag de release registrado junto al nombre del reporte.

Cómo Performate estandariza reportes que ingeniería y producto confían

La salida cruda de k6 basta para desarrolladores; producto y liderazgo necesitan los mismos gráficos con contexto de escenario incorporado.

Ejemplo: de corrida k6 a export listo para stakeholders

1. Correr el escenario desde la app de escritorio con tags ya aplicados en el editor visual. Problema resuelto: splits de ruta/journey coinciden con cómo piensa QA.
2. Abrir el reporte integrado y filtrar por route:checkout (o tu convención de tags). Problema resuelto: colas visibles sin parsear logs a mano.
3. Fijar el panel de escenario (VUs, stages, tasas) en el pie del export. Problema resuelto: debates de «gráfico verde» terminan cuando los parámetros viajan con el PDF.
4. Comparar build anterior lado a lado en p95/p99 de tags críticos. Problema resuelto: regresiones obvias sin rearmar hojas de cálculo.
5. Compartir un export a ingeniería y producto—mismos números, mismas etiquetas.
6. Exportar k6 + summary JSON para artefactos CI cuando fallen gates (pruebas de carga en CI/CD).

Cierre

Los reportes son accionables cuando fidelidad → fallos → colas etiquetadas → historia es explícito. Los umbrales codifican gates; los checks codifican corrección; los tags codifican ownership.

Tras tu próxima corrida, escribe tres frases: carga pretendida, peor p99 etiquetado y subsistema que on-call debería abrir primero—antes de que pidan «la slide verde».

Try Performate free | Book a demo | k6 metrics reference