Checklist de pruebas de rendimiento de API: 12 cosas que los equipos olvidan

Tu corrida en staging alcanzó 500 usuarios concurrentes y checkout quedó en verde—así que el release salió. Dos días después p99 en producción se duplicó porque la prueba nunca ejercitó refresh de token OAuth, filas compartidas del sandbox colisionaron bajo escritura y nadie etiquetó peticiones por ruta. Las pruebas de carga serias de API dependen menos de «cuántos VUs» y más de si la pregunta, el entorno y las métricas coinciden con el riesgo de producción.

Este checklist recoge doce comprobaciones que los equipos olvidan antes de escalar tráfico—sobre todo cuando stakeholders leerán el resultado. Combínalo con stress vs carga vs spike para la forma de tráfico correcta y con ejemplos de umbrales k6 al definir pass/fail.

Por qué los checklists fallan sin estructura ejecutable

La mayoría de postmortems de rendimiento vuelven a los mismos huecos:

• Decisiones sin nombre: las corridas ocurren porque «debemos probar carga», no porque un gate de release necesite una respuesta concreta.
• Entornos que mienten: staging sin volumen de datos realista, caché caliente o path de red produce gráficos en los que no hay que confiar.
• Métricas sin tags: http_req_duration agregado oculta qué endpoint regresó.
• Sin dueño de abort: la saturación sale del sandbox y sorprende a seguridad o on-call de plataforma.

Un checklist solo ayuda cuando mapea a escenarios k6, umbrales y parámetros archivados—no a decks. Las secciones siguientes convierten cada ítem en algo verificable en script y resumen.

Implementación práctica en k6: checklist codificado en options

El script de ejemplo incorpora ítems del checklist como tags, umbrales y hooks de setup para que pass/fail sea objetivo—no opinión de reunión.

Script de ejemplo (ilustrativo—no es una prueba lista para producción). Adapta URLs, auth, datasets y umbrales a tu entorno.

Qué demuestra este ejemplo:

• Tag de decisión: decision:release-gate-checkout documenta por qué existe la corrida.
• Umbrales por ruta: checkout recibe SLO más estrictos que un health probe.
• Aislamiento en setup: setup() obtiene token de tenant de prueba dedicado en lugar de reutilizar credenciales compartidas.
• Duración smoke-first: ramp de dos minutos antes de la etapa principal—ítem 6 del checklist.

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

const BASE = __ENV.API_BASE || 'https://staging.example.com';
const DECISION = __ENV.TEST_DECISION || 'release-gate-checkout';

export function setup() {
  // Checklist #3: congelar credenciales — tenant dedicado por corrida
  const authRes = http.post(`${BASE}/oauth/token`, {
    grant_type: 'client_credentials',
    client_id: __ENV.CLIENT_ID,
    client_secret: __ENV.CLIENT_SECRET,
    scope: 'checkout:write',
  });
  check(authRes, { 'token issued': (r) => r.status === 200 });
  return { token: authRes.json('access_token') };
}

export const options = {
  tags: { decision: DECISION, env: __ENV.ENV_NAME || 'staging' },
  scenarios: {
    smoke_auth: {
      executor: 'constant-vus',
      vus: 5,
      duration: '2m',
      tags: { phase: 'smoke', route: 'checkout' },
      exec: 'checkout',
    },
    load_checkout: {
      executor: 'ramping-vus',
      startVUs: 0,
      stages: [
        { duration: '3m', target: 40 },
        { duration: '10m', target: 40 },
        { duration: '2m', target: 0 },
      ],
      tags: { phase: 'load', route: 'checkout' },
      exec: 'checkout',
      startTime: '2m',
    },
  },
  thresholds: {
    'http_req_duration{route:checkout}': ['p(95)<800', 'p(99)<1200'],
    'http_req_failed{route:checkout}': ['rate<0.01'],
    'checks{phase:smoke}': ['rate>0.99'],
  },
};

export function checkout(data) {
  const idempotencyKey = `load-${__VU}-${__ITER}-${Date.now()}`;
  const body = JSON.stringify({ sku: 'SKU-100', qty: 1 });

  const res = http.post(`${BASE}/v2/checkout`, body, {
    headers: {
      'Content-Type': 'application/json',
      Authorization: `Bearer ${data.token}`,
      'Idempotency-Key': idempotencyKey,
    },
    tags: { route: 'checkout', decision: DECISION },
  });

  check(res, {
    'checkout 2xx': (r) => r.status >= 200 && r.status < 300,
    'no timeout': (r) => r.status !== 0,
  });
  sleep(0.5);
}

Pro tip (comando de ejemplo): archiva parámetros con la corrida para el ítem 11 del checklist.

TEST_DECISION=release-gate-checkout ENV_NAME=staging-v4 k6 run checkout-checklist.js --summary-export=run-evidence.json

Las 12 comprobaciones: tabla de decisión

Usa umbrales estrictos en rutas de ingreso (ítems 7–9). Usa gates más ligeros en admin interno salvo que la decisión cubra explícitamente esas rutas.

Usa staging smoke-first (ítems 5–6) antes de soak o stress (errores comunes).

Usa correlación (ítem 10) con análisis de cuellos de botella cuando exista APM en la misma ventana.

Checklist pre-corrida (copia antes de escalar)

Antes de arrancar el escenario principal:

• Frase de decisión escrita: «Después de esta prueba aprobaremos/rechazaremos ______ porque medimos ______.»
• Huecos de entorno documentados (volumen de datos, caché, path de red).
• URL base, flujo OAuth y tenant por VU en archivo env—no en chat.
• Plan de aislamiento de datos confirmado con plataforma (prefijos, resets, idempotencia).
• Tags definidos por ruta bajo prueba (route:checkout, etc.).
• Escenario smoke programado con umbrales de check estrictos.
• Umbrales k6 codifican riesgo de producto, no mejores números de fin de semana.
• Dueño de abort nombrado con autoridad para detener y avisar on-call.
• Dashboards servidor abiertos en la misma ventana (si la política lo permite).
• Ruta de export elegida para JSON de resumen + identificadores git/build.

El material SRE de Google enmarca incentivos alineados entre SLIs y dolor real de usuario—tu contrato de entorno y checklist deben reflejarlo (alerting on SLOs).

Cómo Performate ayuda a ejecutar este checklist

El boilerplate mata el cumplimiento de ítems 1–12. Abajo un ejemplo de flujo concreto para el gate de release checkout de este artículo.

Ejemplo: ejecutar el checklist sobre una colección Postman sin perder tags ni evidencia

1. Importa la colección que producto ya usa en tests funcionales. Problema resuelto: ítem 3—URLs y formas de auth alineadas con QA diario.
2. Añade tags por petición en el panel de escenario: route:checkout, decision:release-gate-checkout. Problema resuelto: ítem 5—resúmenes cortan latencia por endpoint.
3. Configura smoke y luego load como dos escenarios—2 minutos a 5 VUs, luego ramp a 40. Problema resuelto: ítem 6 sin editar bloques executor a mano.
4. Define umbrales en la UI según SLO negociado (p95, tasa de error). Problema resuelto: ítem 7—pass/fail objetivo antes del export.
5. Corre y abre el reporte integrado; separa errores por tipo (timeouts vs 5xx). Problema resuelto: ítems 9 y 11 en una vista.
6. Exporta script k6 + resumen para CI y adjunta git SHA de tu rama de release. Problema resuelto: la evidencia sobrevive la reunión; reruns comparan manzanas con manzanas.

¿Partes de Postman? Sigue primero Postman a k6 paso a paso para no saltar variables críticas.

Ese flujo encaja con el cta de este post: ejecutar el checklist con escenarios repetibles, reportes y exports en un flujo de escritorio.

Cierre

Una prueba de carga sin decisión, tags y parámetros archivados es un demo—no evidencia. Recorre las doce comprobaciones antes de escalar; codifica las importantes en options de k6 para que pass/fail sobreviva la reunión de release.

Corre smoke en tu próximo build candidato esta semana—y confirma tags de checkout, umbrales y dueño de abort antes de que pidan «cinco minutos más al doble de tráfico».

Try Performate free | Book a demo | k6 scenarios documentation