Métricas de rendimiento Allure 3

Además de los resultados de prueba, Allure Report 3 puede recopilar métricas de rendimiento numéricas de tu ejecución de prueba: tiempos de carga de página, tiempos de respuesta de API, throughput, uso de memoria, tamaños de bundle o cualquier otra medición. El reporte las muestra en una sección dedicada de Métricas y las compara con ejecuciones anteriores, y los quality gates pueden hacer fallar la ejecución cuando una métrica empeora. Consulta Ver métricas en el reporte para saber dónde encontrar la sección de Métricas y qué muestra.

TIP

Esta funcionalidad no está relacionada con Exportar métricas, que describe cómo exportar estadísticas de prueba de Allure Report 2 a InfluxDB o Prometheus.

Escribir métricas en el directorio de resultados

Allure lee métricas de archivos en el directorio de resultados de prueba, junto a los archivos de resultados de prueba:

• cualquier archivo cuyo nombre termine en -perf.json, por ejemplo, a1b2c3d4-perf.json;
• un archivo llamado performance.json.

Cada archivo contiene un array JSON de mediciones:

[
  {
    "id": "home-page",
    "key": "page.load",
    "value": 1240,
    "start": 1792065109697,
    "stop": 1792065110937
  },
  {
    "id": "search-page",
    "key": "page.load",
    "value": 1515,
    "start": 1792065110937,
    "stop": 1792065112452
  }
]

Campo	Tipo	Descripción
id	string	Identificador del objeto medido, por ejemplo, la página o el endpoint. Mantenlo igual a través de las ejecuciones.
key	string	Nombre de la métrica. Las mediciones con la misma key se agregan en el reporte, y la key se usa en la configuración y en las reglas de quality gate.
value	number	El valor medido.
start	number	Hora de inicio de la medición, como un timestamp Unix en milisegundos.
stop	number	Hora de finalización de la medición, como un timestamp Unix en milisegundos.

Todos los campos son obligatorios. Allure ignora las mediciones con campos faltantes o un value no numérico.

Las integraciones de Allure no escriben archivos de métricas, por lo que debes producirlos tú mismo: desde tus pruebas, desde un script separado o convirtiendo la salida de una herramienta de pruebas de rendimiento. Por ejemplo, este script de Node.js mide cuánto tardan dos páginas en cargar y guarda los resultados como un archivo de métricas:

import { randomUUID } from "node:crypto";
import { mkdirSync, writeFileSync } from "node:fs";

const resultsDir = "allure-results";
const metrics = [];

const measure = async (id, key, action) => {
  const start = Date.now();
  await action();
  const stop = Date.now();
  metrics.push({ id, key, value: stop - start, start, stop });
};

await measure("home-page", "page.load", () => fetch("https://example.com/"));
await measure("search-page", "page.load", () => fetch("https://example.com/?q=allure"));

mkdirSync(resultsDir, { recursive: true });
writeFileSync(`${resultsDir}/${randomUUID()}-perf.json`, JSON.stringify(metrics));

Configurar métricas

Las métricas se muestran en el reporte incluso sin ninguna configuración: bajo sus keys, en el grupo Sin configurar. Para darles títulos legibles y unidades, y para agrupar métricas relacionadas, agrega la sección performance al archivo de configuración:

allurerc.mjs

import { defineConfig } from "allure";

export default defineConfig({
  performance: {
    groups: {
      web: { title: "Páginas web" },
      api: { title: "API" },
    },
    metrics: {
      "page.load": { title: "Carga de página", unit: "ms", better: "lower", group: "web" },
      "api.rps": { title: "Throughput de API", unit: "req/s", better: "higher", group: "api" },
    },
  },
});

allurerc.json

{
  "performance": {
    "groups": {
      "web": { "title": "Páginas web" },
      "api": { "title": "API" }
    },
    "metrics": {
      "page.load": { "title": "Carga de página", "unit": "ms", "better": "lower", "group": "web" },
      "api.rps": { "title": "Throughput de API", "unit": "req/s", "better": "higher", "group": "api" }
    }
  }
}

allurerc.yaml

performance:
  groups:
    web:
      title: Páginas web
    api:
      title: API
  metrics:
    page.load:
      title: Carga de página
      unit: ms
      better: lower
      group: web
    api.rps:
      title: Throughput de API
      unit: req/s
      better: higher
      group: api

• groups - los grupos en los que mostrar las métricas. Cada key es un ID de grupo, y title es el nombre del grupo mostrado en el reporte.
• metrics - configuración para cada key de métrica:
  • title - el nombre de la métrica mostrado en el reporte.
  • unit - la unidad agregada a los valores, por ejemplo, ms o req/s.
  • better - lower si los valores más pequeños son mejores (duraciones, tamaños), o higher si los valores más grandes son mejores (throughput, puntuaciones). El reporte lo usa para resaltar cambios para peor, y las reglas delta de quality gate lo usan para ignorar cambios para mejor.
  • group - el ID de un grupo de groups.

Ver métricas en el reporte

Cuando el reporte contiene métricas, el menú Reporte en la esquina superior izquierda obtiene el elemento Métricas:

Esto abre una tabla para cada grupo, con una fila para cada métrica:

• Count - el número de mediciones con esta key en la ejecución actual.
• Total, Avg, Min, Max - la suma, el promedio, el mínimo y el máximo de los valores.
• Delta - cuánto ha cambiado el valor promedio desde el reporte anterior. Según la configuración de better, un cambio para peor se resalta en rojo, y un cambio para mejor en verde.
• Trend - una línea en miniatura (sparkline) de los valores promedio en los reportes anteriores y el actual.

Haz clic en una fila para ver el Historial de métrica: el valor y el cambio para cada reporte anterior. La lista de Valores actuales en la parte inferior muestra cada medición individual de la ejecución actual, junto con el archivo del que fue leída.

Seguimiento de métricas a lo largo del tiempo

Para comparar métricas con ejecuciones anteriores, Allure necesita el historial de pruebas: ya sea un archivo de historial habilitado con la opción historyPath, o Allure Report Storage. Para cada reporte, Allure guarda el valor promedio de cada key de métrica en el historial. Las columnas Delta y Trend, el historial de métricas y las reglas delta de quality gate se basan en estos valores guardados.

Con Allure Report Storage, el historial se mantiene por rama, y una rama que no tiene suficientes reportes propios obtiene los reportes de la rama principal agregados a su historial (consulta Profundidad del historial y ramas). Como resultado, los primeros reportes de una rama nueva comparan sus métricas con el último reporte de la rama principal. En un pipeline de pull request o merge request, Allure usa el historial de la rama destino en su lugar, en cada ejecución (consulta Profundidad del historial y ramas), de modo que las reglas delta verifican si el cambio hizo que las métricas empeoraran respecto a la rama destino.

Verificar métricas con quality gates

Allure Report tiene cuatro reglas de quality gate para métricas. Pueden hacer fallar una ejecución de prueba si una métrica excede un límite o cambia demasiado desde la ejecución anterior:

import { defineConfig } from "allure";

export default defineConfig({
  historyPath: "./history.jsonl",
  qualityGate: {
    rules: [
      {
        metricMax: { key: "page.load", value: 1500 },
        metricMaxDeltaPercent: { key: "api.rps", value: 10 },
      },
    ],
  },
});

Consulta Reglas de métricas para más detalles.

Métricas en builds multietapa

Los archivos de volcado almacenan las métricas recopiladas durante cada etapa, y el reporte construido a partir de los archivos de volcado muestra las métricas de todas las etapas.