---
title: "Checklist de pruebas de rendimiento de API: 12 cosas que los equipos olvidan"
description: "Doce comprobaciones concretas antes y durante pruebas de carga de API—realismo de entorno, auth, seguridad de datos, métricas y puertas—con k6 y práctica de release."
publishDate: "2026-05-10"
draft: false
coverImage: "/images/performate-ai-report-summary.png"
coverImageAlt: "Resumen de reporte de rendimiento con IA destacando cuellos de botella accionables en API"
keyword: "checklist pruebas rendimiento api"
intent: "BOFU"
cta: "Descarga Performate para ejecutar este checklist con escenarios repetibles, reportes y exports."
tags: ["rendimiento-api", "checklist", "pruebas-de-carga", "k6"]
translationOf: api-performance-testing-checklist
---

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](/es/blog/stress-vs-carga-vs-spike-testing) para la forma de tráfico correcta y con [ejemplos de umbrales k6](/es/blog/ejemplos-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.

```javascript
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.

```bash
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

| # | Comprobación | Señal de pass | Fallo habitual |
|:---|:---|:---|:---|
| 1 | Nombra la decisión que debe soportar la corrida | Gate de una frase documentado en tags o README | «Veamos cómo aguanta carga» |
| 2 | Alinea fidelidad del entorno con la pregunta | Fidelidad faltante listada en notas | Tratar gráficos staging como forecast prod |
| 3 | Congela URLs, tenants y credenciales | Env vars registradas; sin sandboxes misteriosos | Rotar keys a mitad de corrida |
| 4 | Aísla o resetea datos de prueba | Idempotency keys o prefijos dedicados | Filas compartidas → «regresiones» flaky |
| 5 | Etiqueta peticiones para diagnosticar después | `http_req_duration` por ruta en resumen | Una sola línea de latencia agregada |
| 6 | Smoke antes del maratón | Escenario corto pasa checks primero | Depurar bugs de script a escala |
| 7 | Liga umbrales al riesgo de producto | SLO más estricto en checkout vs admin | Números héroe de vanidad |
| 8 | Separa funcional de prueba de carga | Contract tests en CI; carga responde concurrencia | Funcional verde = ship |
| 9 | Vigila errores por tipo | Timeouts vs 5xx vs fallos de negocio separados | Un agregado único de `http_req_failed` |
| 10 | Correlaciona con señales servidor si puedes | Ventana APM = duración de prueba | Optimizar scripts, no sistemas |
| 11 | Captura parámetros de escenario con reporte | Modelo VU, duración, git SHA archivados | Gráfico sin contexto |
| 12 | Asigna dueño de abort | Contacto nombrado + path a on-call | Saturación sorpresa |

**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](/es/blog/errores-comunes-pruebas-de-carga)).

**Usa correlación** (ítem 10) con [análisis de cuellos de botella](/es/blog/analisis-cuellos-de-botella-api) 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](https://sre.google/workbook/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](/es/blog/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](https://performate.app) | [Book a demo](/demo) | [k6 scenarios documentation](https://k6.io/docs/using-k6/scenarios/)