Ir al contenido

Umbrales de aprobado/fallo

Los umbrales de aprobado/fallo fijan los límites que debe respetar una prueba de carga, por ejemplo un tiempo de respuesta máximo. Los defines una vez en una prueba y cada ejecución se evalúa automáticamente: un PASS verde o un FAIL rojo, comparando cada límite con los números reales de la ejecución. Los umbrales funcionan igual para pruebas cloud, JMeter y k6.

En la página de nueva prueba, abre Más opciones, haz clic en la fila Criterios de éxito/fallo y rellena cualquiera de estos:

  • Tiempo de respuesta P95 máximo (ms): la ejecución falla si el tiempo de respuesta del percentil 95 supera este valor.
  • Tiempo de respuesta P99 máximo (ms): lo mismo, para el percentil 99.
  • Tasa de errores máxima (%): la ejecución falla si la tasa de error global supera este valor.
  • Rendimiento mínimo (req/s): la ejecución falla si el rendimiento queda por debajo.

Deja un campo vacío para omitir esa comprobación. Marca Activar umbrales de éxito/fallo para activar el veredicto. Los umbrales se guardan por prueba y por equipo, así que los defines una vez y se aplican a todas las ejecuciones futuras.

Dos campos opcionales comparan una ejecución con la que marcaste como línea base en su página de resultados: Aumento máximo de P95 frente a la línea base y Aumento máximo de la tasa de errores frente a la línea base (puntos porcentuales). Mientras no haya línea base, estas comprobaciones se omiten, así que una puerta que solo tenga estos límites falla como "no evaluada".

Abre cualquier resultado de una prueba con umbrales activados. El resumen muestra una insignia PASS o FAIL con una línea por comprobación: el valor real, el objetivo y si pasó. La insignia se evalúa con los mismos números globales que se muestran en la página de resultados.

La pestaña Trend representa el tiempo de respuesta P95, la tasa de error y el rendimiento a lo largo de las últimas ejecuciones de la prueba, con tus umbrales dibujados como líneas y cada ejecución coloreada de verde (aprobado) o rojo (fallo). Se construye a partir de tu historial de ejecuciones, así que una regresión progresiva es fácil de detectar.

El veredicto también está disponible para la automatización, de modo que una prueba de carga puede bloquear un despliegue defectuoso:

  • GitHub Actions: el workflow de la página API de pruebas de carga ejecuta una prueba, espera a que termine, lee el veredicto y hace fallar el job cuando se incumple un umbral o no se puede evaluar.
  • API de veredicto: GET /api/v1/{loadtests|k6tests|jmetertests}/verdict?testrunname=<nombre>&testrunid=<id> (con tu clave de API loadfocus-auth) devuelve { verdict, checks, metrics, ... } para que cualquier pipeline pueda condicionar según el resultado. Llámala en una ejecución finalizada.
  • API de umbrales: define o actualiza los límites de una prueba desde un pipeline (SLOs como código) con PUT /api/v1/{loadtests|k6tests|jmetertests}/thresholds (cuerpo JSON { "testrunname": "...", "p95Ms": 500, "errorRatePct": 1, "minRps": 50 }, con tu clave de API loadfocus-auth; también se aceptan p99Ms y enabled). Un PUT reemplaza todo el conjunto, así que un campo que omitas se borra. GET en la misma ruta los lee y DELETE los borra.
  • API de análisis: GET /api/v1/{loadtests|k6tests|jmetertests}/analysis?testrunname=<nombre>&testrunid=<id> devuelve las cifras detrás del veredicto como JSON (percentiles exactos, Apdex, tipos de error, métricas por petición y por región). Consulta API de análisis de resultados.

Si una ejecución se queda colgada y nunca termina, LoadFocus envía un correo automáticamente al propietario del equipo, para que una ejecución atascada nunca pase desapercibida.