Teste implicite

Testarea este activată implicit într-o rețetă normalizată, cu patru nume de test predefinite: boot, login, packages și network. Acestea sunt verificări mici în guest, nu un set complet de acceptare. O rețetă poate dezactiva testarea sau înlocui lista, iar unele tipuri de artefacte folosesc un contract mai restrâns.

Ce dovedesc de fapt testele implicite

Test	Verificare executată	Nu dovedește
`boot`	`uptime` iese cu succes prin QEMU guest agent	Fiecare cale de bootloader, boot pe hardware sau absența avertismentelor de kernel
`login`	`whoami` poate rula prin canalul root guest-agent	Parolă interactivă, cheie SSH, PAM, desktop greeter sau autentificarea utilizatorului final
`packages`	Una dintre `dpkg --list`, `rpm -qa` sau `pacman -Q` reușește	Că fiecare pachet cerut în prompt este instalat
`network`	DNS rezolvă `example.com` și o conexiune TCP la portul 443 reușește după reîncercări limitate	Starea generală a internetului, conținut HTTP, fiecare interfață sau un design air-gapped

Calea Ubuntu 24.04 CIS elimină verificarea generică de rețea și folosește în loc assertion-ul de feature legat de readiness. Pentru o rețetă fără rută internet așteptată, o verificare generică de rețea eșuată poate fi convertită în avertisment.

Verificări de feature și capabilities

Runner-ul combină și verificările furnizate de metadatele feature activate, legacy hook test files, frozen capability plan, custom tests explicite și eventuale benchmark tests. Assertions duplicate sunt eliminate. Assertions cu parametri lipsă cunoscuți sunt eliminate cu avertisment de server; revizuiți planul de test rezultat ca o verificare eliminată să nu fie confundată cu un succes.

Exemple: portul SSH configurat, starea serviciului, un pachet cerut sau un artefact specific rețetei. Acoperirea depinde de feature-ul activat: includerea unui feature nu garantează de una singură un set complet de assertions pentru acel feature.

Citirea rezultatului

Folosiți rândurile assertion și evidence, nu doar insigna agregată:

passed înseamnă că verificarea executabilă a returnat rezultatul așteptat.
failed înseamnă că verificarea a rulat și a contrazis așteptarea.
error înseamnă că harness-ul nu a putut produce un verdict.
skipped înseamnă că verificarea nu a rulat, de exemplu pentru că VM-ul țintă lipsea.

Erorile și omiterile nu sunt succese. O imagine finalizată și un test run reușit sunt stări separate; certificarea este a treia poartă.

Definiți criterii de acceptare mai stricte

Pentru o sarcină reală, adăugați assertions relevante pentru prompt. De exemplu:


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

Apoi inspectați imaginea construită în consolă și, pentru afirmații legate de hardware, testați pe hardware reprezentativ. Vedeți Assertions personalizate și Tipuri de assertions.