Pruebas por defecto

Las pruebas están habilitadas por defecto en una receta normalizada, con cuatro nombres predefinidos: boot, login, packages y network. Son comprobaciones pequeñas en guest, no una suite de aceptación completa. Una receta puede deshabilitar pruebas o reemplazar la lista, y algunos tipos de artefacto usan un contrato más estrecho.

Qué prueban realmente los valores por defecto

Test	Executed check	Does not prove
`boot`	`uptime` exits successfully through the QEMU guest agent	Every bootloader path, hardware boot, or absence of kernel warnings
`login`	`whoami` can run through the root guest-agent channel	Interactive password, SSH-key, PAM, desktop-greeter, or end-user login
`packages`	One of `dpkg --list`, `rpm -qa`, or `pacman -Q` succeeds	That every package requested by the prompt is installed
`network`	DNS resolves `example.com` and a TCP connection to port 443 succeeds after bounded retries	General internet health, HTTP content, every interface, or an air-gapped design

La ruta CIS Ubuntu 24.04 elimina la comprobación genérica de red y usa en su lugar la aserción de feature con puerta de readiness. Una receta sin ruta de internet esperada puede convertir un fallo de red genérico en advertencia.

Comprobaciones de feature y capacidad

El runner también fusiona comprobaciones suministradas por metadatos de feature habilitadas, archivos de prueba hook legacy, el plan de capacidad congelado, pruebas personalizadas explícitas y pruebas de benchmark. Las aserciones duplicadas se eliminan. Las aserciones con parámetros faltantes conocidos se descartan con advertencia del servidor; revisa el plan de prueba resultante para no confundir una comprobación descartada con un pass.

Ejemplos incluyen comprobar el puerto SSH configurado, estado del servicio, un paquete solicitado o un artefacto específico de receta. La cobertura depende de la feature habilitada: incluir una feature no garantiza por sí sola que la feature tenga un conjunto completo de aserciones.

Leer el resultado

Usa las filas de aserción y la evidencia, no solo la insignia agregada:

passed significa que la comprobación ejecutable devolvió su resultado esperado.
failed significa que la comprobación se ejecutó y contradijo la expectativa.
error significa que el harness no pudo producir un veredicto.
skipped significa que la comprobación no se ejecutó, por ejemplo porque su VM destino estaba ausente.

Errores y skips no son passes. Una imagen completada y una ejecución de prueba superada son estados separados; la certificación es una tercera puerta.

Definir criterios de aceptación más fuertes

Para una carga de trabajo real, añade aserciones relevantes al prompt. Por ejemplo:


{
  "description": "Nginx serves the local health endpoint",
  "assertions": [
    {
      "type": "service_running",
      "description": "Nginx is active",
      "params": { "service": "nginx" }
    },
    {
      "type": "http_responds",
      "description": "Health endpoint returns 200",
      "params": { "url": "http://localhost/health", "status": 200 }
    }
  ]
}

Luego inspecciona la imagen compilada en el console y, para afirmaciones ligadas a hardware, prueba en hardware representativo. Consulta Aserciones personalizadas y Tipos de aserción.