Test default

Il testing è abilitato di default in una ricetta normalizzata, con quattro nomi test predefined: boot, login, packages e network. Sono piccoli controlli guest, non una suite accettazione completa. Una ricetta può disabilitare testing o sostituire l’elenco, e alcuni tipi artefatto usano un contratto più stretto.

Cosa provano davvero i default

Test	Controllo eseguito	Non prova
`boot`	`uptime` esce con successo tramite guest agent QEMU	Ogni percorso bootloader, boot hardware o assenza warning kernel
`login`	`whoami` può girare tramite canale guest-agent root	Login interattivo password, chiave SSH, PAM, greeter desktop o login utente finale
`packages`	Uno tra `dpkg --list`, `rpm -qa` o `pacman -Q` riesce	Che ogni pacchetto richiesto dal prompt sia installato
`network`	DNS risolve `example.com` e connessione TCP porta 443 riesce dopo retry delimitati	Salute internet generale, contenuto HTTP, ogni interfaccia o design air-gapped

Il percorso CIS Ubuntu 24.04 rimuove il controllo rete generico e usa invece l’asserzione feature gated readiness. Una ricetta senza route internet attesa può avere un controllo rete generico fallito convertito in warning.

Controlli feature e capacità

Il runner unisce anche controlli forniti da metadati feature abilitate, file test hook legacy, piano capacità congelato, test custom espliciti e test benchmark. Asserzioni duplicate sono rimosse. Asserzioni con parametri mancanti noti sono scartate con warning server; rivedi il piano test risultante così un controllo scartato non viene scambiato per pass.

Esempi includono controllo porta SSH configurata, stato servizio, pacchetto richiesto o artefatto specifico ricetta. La copertura dipende dalla feature abilitata: includere una feature non garantisce da sola che quella feature abbia un set asserzioni completo.

Leggere il risultato

Usa righe asserzione ed evidenza, non solo il badge aggregato:

passed significa che il controllo eseguibile ha restituito il risultato atteso.
failed significa che il controllo è girato e ha contraddetto l’aspettativa.
error significa che l’harness non ha prodotto un verdetto.
skipped significa che il controllo non è girato, ad esempio perché la VM target era assente.

Errori e skip non sono pass. Un’immagine completata e una run test superata sono stati separati; la certificazione è un terzo gate.

Definire criteri accettazione più forti

Per un carico reale, aggiungi asserzioni rilevanti al prompt. Ad esempio:


{
  "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 }
    }
  ]
}

Poi ispeziona l’immagine buildata nella console e, per affermazioni legate hardware, testa su hardware rappresentativo. Vedi Asserzioni personalizzate e Tipi asserzione.