---
title: "Línea base vs regresión: construir un benchmark de rendimiento repetible para APIs"
description: "Bloquea líneas base con escenarios idénticos, detecta regresiones con umbrales k6 y compara builds sin charts ruidosos peras con manzanas."
publishDate: "2026-07-23"
draft: false
keyword: "linea base regresion rendimiento api"
intent: "MOFU"
cta: "Usa Performate para guardar corridas comparables y resultados de umbrales entre releases."
tags: ["k6", "pruebas-de-carga", "rendimiento-api", "rendimiento", "linea-base"]
translationOf: api-performance-baseline-regression
---

El release 412 “se veía bien” en QA hasta que `p99` de checkout subió 180 ms sobre el sobre acordado en marzo—porque nadie reejecutó el **mismo** escenario k6 con los **mismos** datos y tags. Una **línea base** es el sobre aceptado de latencia y error para un escenario bajo un contrato de entorno conocido. Una **regresión** es una deriva significativa de ese sobre tras un cambio. Sin ADN de escenario congelado, comparas ficción.

En esta guía verás qué bloquear en un bundle de línea base, cómo codificar gates con [thresholds](https://k6.io/docs/using-k6/thresholds/) de k6, cuándo resetear líneas base tras cambios de infra y cómo guardar corridas comparables para que la rotación de ingenieros no borre la memoria.

## Por qué fallan las líneas base antes que los umbrales

Los equipos copian un script, ajustan VUs “por las dudas” y se preguntan por qué los gráficos nocturnos no coinciden. Deriva pequeña invalida comparaciones:

- **Executor distinto** (`constant-vus` vs arrival-rate) cambia quién espera en colas.
- **Deriva de payload o auth** altera CPU y tamaño de respuesta sin cambio en el servicio bajo prueba.
- **Cambio de fingerprint de entorno** (snapshot DB, caché caliente, flags) mueve colas independiente del merge.

La práctica de la industria ata niveles de servicio a SLIs que el usuario siente ([Google SRE workbook](https://sre.google/workbook/implementing-slos/)); k6 los codifica como umbrales etiquetados en [`http_req_duration`](https://k6.io/docs/using-k6/metrics/) y `http_req_failed`. Revisa [errores comunes en pruebas de carga](/es/blog/errores-comunes-pruebas-de-carga) antes de confiar en un umbral rojo e integra smoke gates en [pruebas de carga en CI/CD](/es/blog/pruebas-de-carga-en-ci-cd) cuando la línea base esté estable.

Empareja disciplina de línea base con [ejemplos de umbrales k6](/es/blog/ejemplos-umbrales-k6) al añadir rutas o dependencias.

## Implementación práctica en k6: ADN congelado, tags de build y gates

Trata el script de línea base como artefacto versionado: parámetros de escenario, variables de entorno, datasets y líneas de umbral viajan juntos.

**Script de ejemplo (ilustrativo—no listo para producción).** API checkout ficticia y números de sobre.

**Qué demuestra este ejemplo:**

- **Fingerprint por env** `BUILD_ID` en tags para comparar corridas de CI.
- **Escenario dorado único** con constant arrival rate—presión de requests estable semana a semana.
- **Umbrales** que fallan la corrida cuando colas o errores rompen el sobre registrado.
- **Duración** apta para smoke nocturno; extiende para re-baselining trimestral.

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

const BASE = __ENV.API_BASE || 'https://staging.example.com';
const BUILD = __ENV.BUILD_ID || 'local';
const body = JSON.stringify({ sku: 'SKU-100', qty: 1, currency: 'USD' });

export const options = {
  scenarios: {
    baseline_checkout: {
      executor: 'constant-arrival-rate',
      rate: Number(__ENV.BASELINE_RPS || 25),
      timeUnit: '1s',
      duration: __ENV.BASELINE_DURATION || '10m',
      preAllocatedVUs: 25,
      maxVUs: 100,
      tags: { route: 'checkout', profile: 'baseline' },
      exec: 'checkout',
    },
  },
  thresholds: {
    'http_req_duration{route:checkout}': ['p(95)<750', 'p(99)<1100'],
    http_req_failed: ['rate<0.008'],
  },
};

export function checkout() {
  const res = http.post(`${BASE}/v2/checkout`, body, {
    headers: {
      'Content-Type': 'application/json',
      Authorization: `Bearer ${__ENV.TOKEN}`,
    },
    tags: { route: 'checkout', build: BUILD, profile: 'baseline' },
  });
  check(res, { 'checkout 2xx': (r) => r.status >= 200 && r.status < 300 });
  sleep(0.35);
}
```

**Patrones que funcionan**

- Guardar JSON de resumen crudo + git SHA + fingerprint de env junto a cada captura verde.
- Fallar merges por breach de umbral; usar revisión más suave de delta `p95` en weeklies con muestra suficiente—smokes cortos son ruidosos.
- Etiquetar `build` en requests para comparaciones en Performate o k6 Cloud ([k6 observabilidad métricas y tags](/es/blog/k6-observabilidad-metricas-tags)).
- Documentar **renovación de línea base** en el changelog cuando infra o trades intencionales muevan el sobre.

**Antipatrones a evitar**

- Cambiar RPS y duración la misma semana que comparas builds—un solo eje por experimento.
- Resetear umbrales en silencio tras un run fallido “para quedar verde”.
- Comparar línea base de staging con forma de tráfico de producción sin anotación.

**Pro tip (comando de ejemplo):** export JSON para archivo y diffs.

```bash
k6 run baseline-checkout.js -e BUILD_ID=$CI_COMMIT_SHA -o baseline-summary.json
```

**Qué demuestra este comando:** salida legible por máquina adjunta al registro del build para diffs, no debates de capturas.

## Marco de decisión: captura vs gate de regresión vs reset

| Situación | Acción recomendada |
|:---|:---|
| Nueva ruta crítica en el journey de línea base | Extender script; re-capturar sobre; actualizar umbrales en un PR |
| Candidato a release semanal | Mismo ADN de escenario; fallar CI en breach de umbral |
| Upgrade de infra (DB mayor, topología de caché) | Programar renovación de línea base; anotar dashboards con fecha efectiva |
| Trade intencional de latencia (validación más pesada) | Sign-off de producto + nuevo sobre; no ensanchar umbrales en silencio |
| Smoke corto ruidoso en CI | Menor duración/RPS pero mismos tags y expresiones relativas |

**Captura línea base nueva si** cambiaste ADN del escenario a propósito y los stakeholders aceptan un sobre nuevo.

**Trata como regresión si** el ADN no cambió y colas o errores etiquetados cruzan umbrales—investiga antes de ensanchar gates.

**Resetea dashboards solo tras** notas de renovación explícitas—si no, on-call persigue números de marzo en infra de julio.

## Observabilidad, documentación y próximos pasos

Antes del próximo tren de releases:

- [ ] Congelar documento de ADN: executor, duración, RPS, mix de payload, think time, versión de dataset.
- [ ] Registrar fingerprint de entorno (id snapshot DB, flags, procedimiento de caché).
- [ ] Archivar JSON de resumen verde con git SHA al capturar líneas base.
- [ ] Conectar fallo de umbral a bloqueo de merge en CI para el escenario dorado.
- [ ] Comparar deltas `p95`/`p99` entre corridas nocturnas con reglas de muestra mínima.
- [ ] Registrar eventos de renovación de línea base con dueño y motivo.

## Cómo Performate mantiene líneas base comparables entre releases

Definiciones de escenario dispersas en laptops no sobreviven rotación. Centraliza el path dorado y los exports.

**Ejemplo: línea base de checkout por build**

1. **Importar el flujo Postman dorado** (u operación OpenAPI) usado en la captura de marzo. *Problema resuelto:* una definición para local, CI y revisiones.
2. **Configurar constant arrival rate** al `BASELINE_RPS` registrado (p. ej. 25 req/s) y duración 10m en el editor. *Problema resuelto:* ADN del escenario en un workspace, no cinco forks.
3. **Aplicar tags** `route:checkout`, `profile:baseline` y pasar `BUILD_ID` desde env de CI en scripts exportados. *Problema resuelto:* vistas de comparación filtran las mismas dimensiones.
4. **Introducir umbrales** del sobre archivado (`p95`, `p99`, tasa de error). *Problema resuelto:* edición visual de gates sin deriva entre copias del script.
5. **Ejecutar en cada candidato a release** y abrir comparación histórica en el reporte integrado. *Problema resuelto:* producto e ingeniería debaten un export por build.
6. **Exportar k6** para smoke en pipeline a menor duración/RPS con **mismos tags y expresiones de umbral**—escala tiempo, no forma.

Ese flujo cumple el `cta`: guardar corridas comparables y resultados de umbrales entre releases sin gráficos pera con manzana.

## Cierre

La disciplina de **línea base de rendimiento de API** es ADN de escenario congelado más umbrales honestos. La detección de **regresión** solo es confiable cuando forma de tráfico, datos, tags y fingerprint coinciden con el run verde capturado—luego deja que k6 falle el build cuando las colas se muevan.

Reejecuta tu escenario dorado de checkout en el candidato actual con `BUILD_ID`—anota si necesitas un fix o una renovación documentada de línea base.

[Try Performate free](https://performate.app) | [Book a demo](/demo) | [k6 results output](https://k6.io/docs/getting-started/results-output/)