---
title: "Flujos multipaso: la IA cablea requests—la prueba de concurrencia sigue siendo tuya"
description: "OAuth, carritos y APIs multipaso bajo carga k6: cómo la IA puede armar flujos y por qué aislamiento de sesión y correlación siguen necesitando verificación de ingeniería."
publishDate: "2026-10-13"
draft: false
keyword: "flujos multipaso ia k6 concurrencia"
intent: "MOFU"
cta: "Usa el flujo de escritorio de Performate: imports, corridas k6 y análisis asistido por IA según tu plan, para publicar más rápido sin saltarte la validación."
tags: ["k6", "pruebas-de-carga", "ia", "performate", "flujo"]
translationOf: multi-step-flows-ai-k6-concurrency
---

Tu script k6 generado por IA pasa con un solo usuario virtual: el login funciona, el carrito se llena, el checkout devuelve 200. Subes a cincuenta VUs y el mismo script empieza a lanzar 401, conflictos 409 y cargos duplicados. El modelo cableó bien la secuencia HTTP—nunca demostró que **cada usuario concurrente tiene una sesión aislada**.

Las pruebas de workflows API con IA brillan en **plomería**: convertir un diagrama de secuencia en llamadas `http` ordenadas con bloques `check()`. Fallan en **verdad de concurrencia**—tokens compartidos, sesiones sticky, bloqueo optimista y condiciones de carrera solo aparecen bajo carga paralela. En esta guía verás dónde termina el andamiaje de IA, cómo cablear flujos como espera tu gateway y una escalera de verificación que atrapa bugs de sesión antes de que lleguen a staging a escala.

## Por qué los flujos multipaso se rompen bajo carga—no con VU=1

Con un solo usuario virtual, los requests secuenciales parecen un test de integración feliz. Bajo concurrencia, el mismo script ejercita modos de fallo distintos:

- **Estado de auth compartido** cuando un refresh token o API key se reutiliza entre todos los VUs—aceptable con VU=1, catastrófico a escala.
- **Bloqueo optimista** en carritos o filas de inventario causando ráfagas 409 cuando muchos usuarios mutan el mismo recurso lógico.
- **Colisiones de claves de idempotencia** cuando las claves se generan con patrones de índice VU o timestamp que se repiten bajo carga—consulta [idempotencia en flujos de pago](/es/blog/pruebas-carga-idempotencia-flujos-pago).
- **Sesiones sticky y routing por tenant** cuando el edge espera cookies o headers que la IA omitió en la cadena generada.
- **Gaps de think time** que ocultan acumulación en colas hasta que el arrival rate supera lo que cualquier smoke secuencial vio.

Piensa en una carrera de relevos donde todos los corredores comparten un solo testigo. Los relevos se ven fluidos cuando una sola persona recorre el circuito.

### Cuando el cableado funcional pasa pero la concurrencia falla

La IA puede producir una cadena login → browse → checkout correcta desde una colección Postman o una lista numerada. Rara vez valida que **cada VU usa credenciales, cookies e IDs de correlación distintos**. Combina el diseño del workflow con [tipos de escenario k6](/es/blog/tipos-escenarios-k6-explicados) para que el executor (carga estable vs rampa) coincida con la pregunta de concurrencia que haces—no solo con la historia funcional.

Documenta **cookie jars**, **headers Host** y **seguimiento de redirects** de forma explícita. Los modelos suelen emitir cadenas optimistas de un solo request mientras tu edge espera sesiones sticky o headers de routing por tenant—compara con cómo [Postman a k6](/es/blog/postman-a-k6-paso-a-paso) preserva el comportamiento de colección.

_Para ayuda opcional de modelos en planes soportados, alimenta ejemplos redactados; cookies de sesión reales no van en prompts._

## Implementación práctica con k6: aislamiento de sesión y tags por paso

Modela cada journey de usuario como una función que posee su estado de sesión. Impulsa usuarios distintos desde un `SharedArray` o un pool generado en setup—no desde un token en variable de entorno compartido por todos los VUs.

**Script de ejemplo (ilustrativo—no es una prueba lista para producción).** El snippet usa URLs, tokens y datos de usuario ficticios. Adapta base URL, auth, payloads y umbrales a tu entorno.

**Qué demuestra este ejemplo:**

- **Aislamiento de usuario por VU:** cada iteración elige una fila de usuario por `__VU` y `__ITER`, no un token global.
- **Estado capturado entre pasos:** login guarda `accessToken` y `cartId` en el scope de la función para requests posteriores.
- **Tags por paso:** `step:login`, `step:add_item`, `step:checkout` para partir latencia y fallos por paso bajo carga.
- **Think time realista:** sleep aleatorio entre pasos para evitar ráfagas irreales back-to-back.

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

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

const users = new SharedArray('users', function () {
  return JSON.parse(open('./users.json')); // [{ email, password }, ...]
});

export const options = {
  scenarios: {
    checkout_flow: {
      executor: 'ramping-vus',
      startVUs: 0,
      stages: [
        { duration: '1m', target: 5 },
        { duration: '3m', target: 25 },
        { duration: '1m', target: 0 },
      ],
      tags: { journey: 'checkout' },
      exec: 'checkoutJourney',
    },
  },
  thresholds: {
    'http_req_duration{step:checkout}': ['p(95)<900'],
    'http_req_failed{step:login}': ['rate<0.02'],
    http_req_failed: ['rate<0.01'],
  },
};

export function checkoutJourney() {
  const user = users[(__VU + __ITER) % users.length];
  let accessToken;
  let cartId;

  const loginRes = http.post(
    `${BASE}/auth/login`,
    JSON.stringify({ email: user.email, password: user.password }),
    {
      headers: { 'Content-Type': 'application/json' },
      tags: { step: 'login', journey: 'checkout' },
    }
  );
  check(loginRes, { 'login 2xx': (r) => r.status >= 200 && r.status < 300 });
  accessToken = loginRes.json('accessToken');

  sleep(Math.random() * 2 + 1);

  const cartRes = http.post(`${BASE}/carts`, null, {
    headers: { Authorization: `Bearer ${accessToken}` },
    tags: { step: 'create_cart', journey: 'checkout' },
  });
  check(cartRes, { 'cart created': (r) => r.status === 201 });
  cartId = cartRes.json('id');

  sleep(Math.random() * 2 + 1);

  const addRes = http.post(
    `${BASE}/carts/${cartId}/items`,
    JSON.stringify({ sku: 'SKU-100', qty: 1 }),
    {
      headers: {
        'Content-Type': 'application/json',
        Authorization: `Bearer ${accessToken}`,
      },
      tags: { step: 'add_item', journey: 'checkout' },
    }
  );
  check(addRes, { 'item added': (r) => r.status >= 200 && r.status < 300 });

  sleep(Math.random() * 2 + 1);

  const checkoutRes = http.post(
    `${BASE}/carts/${cartId}/checkout`,
    JSON.stringify({ idempotencyKey: `${__VU}-${__ITER}-${Date.now()}` }),
    {
      headers: {
        'Content-Type': 'application/json',
        Authorization: `Bearer ${accessToken}`,
      },
      tags: { step: 'checkout', journey: 'checkout' },
    }
  );
  check(checkoutRes, { 'checkout 2xx': (r) => r.status >= 200 && r.status < 300 });
}
```

**Patrones que funcionan**

- **Escalera de verificación:** 1 VU para corrección → 2–5 VUs para independencia de sesión → rampa para composición de 401/409/429.
- **Usuarios únicos por VU** cuando el negocio exige carritos o cuotas aislados; pools compartidos solo al emular kiosk o workers batch—y etiquétalo en el reporte.
- **Tags por paso** en cada request para que fallos a mitad de rampa muestren si checkout o inventario domina—patrones de [observabilidad k6](/es/blog/k6-observabilidad-metricas-tags) ayudan.
- **Flujos de compensación:** si los workflows incluyen ramas cancel o refund, decide si la mezcla de carga las incluye.

**Anti-patrones a evitar**

- Reutilizar un refresh token o API key entre todos los VUs porque el smoke con VU=1 pasó.
- Omitir cookie jar cuando el gateway espera sesiones sticky.
- Hand-waving de firma criptográfica, replay de nonce o flujos ligados a dispositivo—los modelos adivinan; ganan las specs.

**Tip pro (comando de ejemplo):** filtra el summary por tag de paso al depurar picos a mitad de rampa.

```bash
k6 run checkout-flow.js --summary-trend-stats="p(95),p(99)" --tag step:checkout
```

**Qué demuestra este comando:** tendencias de percentiles acotadas al paso checkout aíslan latencia de cola en el último salto sin promediar ruido de login o carrito.

## Marco de decisión: andamiaje IA vs flujos a mano

| Situación | Acción recomendada |
|:---|:---|
| Secuencia REST estándar desde colección | Andamiaje IA + escalera de verificación; corrige aislamiento de sesión en review |
| OAuth con rotación de refresh | Codea refresh a mano; la IA solo borra estructura |
| Bloqueo optimista en recursos compartidos | Usuario/datos distintos por VU; vigila tasa 409 en umbrales |
| Auth criptográfica o ligada a dispositivo | Codea a mano; no confíes en lógica de firma generada |
| Fan-out async tras HTTP (webhooks) | Extiende con [webhooks e idempotencia](/es/blog/pruebas-carga-webhooks-reintentos-idempotencia) |

**Usa andamiaje IA si** el flujo es una secuencia REST documentada y ejecutarás la escalera de verificación antes de cualquier gate de alta concurrencia.

**Usa flujos a mano si** la auth implica firma, nonces o tokens ligados a hardware que los modelos alucinan con frecuencia.

**Usa tags por paso y umbrales segmentados si** los fallos suben a mitad de rampa y necesitas saber qué salto se rompió—no solo que `http_req_failed` subió.

## Observabilidad, documentación y siguientes pasos

Las pruebas de carga multipaso solo sirven si las reglas de sesión sobreviven al próximo sprint. Antes de escalar tráfico:

- [ ] Documenta si cada VU usa un usuario único, un pool compartido o un patrón kiosk sintético.
- [ ] Exporta snippets HAR-lite redactados por paso al preguntar a modelos por qué el paso tres se estanca—el contexto gana a prompts solo en prosa.
- [ ] Configura alertas sobre composición 401/409, no solo tasa de error agregada.
- [ ] Añade teardown o llamadas compensatorias para que tenants de staging queden limpios entre corridas repetidas.
- [ ] Archiva versión del pool de usuarios, git SHA y max VUs por release para audit trail.

Para flujos con mucha auth a escala, cruza con [k6 OAuth2 y concurrencia con API key](/es/blog/k6-oauth2-api-key-concurrencia).

## Cómo Performate simplifica pruebas de workflows multipaso

Mantener scripts multipaso en repos dispersos no escala. Abajo hay un **ejemplo concreto de flujo** para el mismo journey de checkout que trata este artículo—adapta nombres de carpetas y pools de usuarios a tu entorno.

**Ejemplo: armar un flujo y demostrar concurrencia en un solo workspace**

1. **Importa una colección Postman** con requests login, carrito y checkout en orden. *Problema resuelto:* una sola fuente de verdad en lugar de prompts solo en prosa que omiten cookies y redirects.
2. **Corre a 1 VU en el runner de escritorio** para confirmar que IDs de correlación y variables capturadas fluyen entre pasos. *Problema resuelto:* cableado funcional validado antes de que alguien suba concurrencia.
3. **Adjunta un archivo de usuarios parametrizado** y mapea credenciales a usuarios virtuales en el panel de escenario. *Problema resuelto:* aislamiento de sesión pasa a ser un problema de datos, no un token copy-paste en cada request.
4. **Añade tags por paso** (`step:login`, `step:checkout`) alineados al ejemplo k6 de arriba. *Problema resuelto:* los reportes muestran qué salto se rompió cuando los 409 suben a mitad de rampa.
5. **Rampa de 5 a 25 VUs** en el editor visual y abre la vista de comparación filtrada por paso. *Problema resuelto:* QA y backend debaten un solo export, no tres hojas bifurcadas.
6. **Exporta el script k6 generado** para smoke gates en CI ([pruebas de carga en CI/CD](/es/blog/pruebas-de-carga-en-ci-cd)) y mantener alineadas iteración local y pipeline.

Ese flujo conecta directo con el `cta` de este post: publicar más rápido con imports y andamiaje IA opcional—sin saltarte la prueba de concurrencia que solo ingeniería puede firmar.

## Cierre

Las pruebas de workflows API con IA compran velocidad de cableado; la prueba de concurrencia sigue siendo obligación de ingeniería. La IA convierte diagramas de secuencia en requests ordenados—no demuestra que cincuenta usuarios virtuales tienen cada uno una sesión aislada.

Ejecuta la escalera de verificación en tu próximo script multipaso antes de la rampa—y anota en qué paso aparece primero el cambio de composición 401 o 409.

[Try Performate free](https://performate.app) | [Book a demo](/demo) | [k6 scenarios](https://k6.io/docs/using-k6/scenarios/)