Default Tests

Testing ist in einem normalisierten Rezept standardmäßig aktiviert, mit vier vordefinierten Testnamen: boot, login, packages und network. Das sind kleine Gast-Checks, keine vollständige Abnahme-Suite. Ein Rezept kann Testing deaktivieren oder die Liste ersetzen, und manche Artefakttypen nutzen einen engeren Vertrag.

Was die Defaults tatsächlich beweisen

Test	Ausgeführter Check	Beweist nicht
`boot`	`uptime` exitiert erfolgreich über den QEMU guest agent	Jeden Bootloader-Pfad, Hardware-Boot oder Fehlen von Kernel-Warnungen
`login`	`whoami` kann über den root guest-agent channel laufen	Interaktives Passwort, SSH-Key, PAM, Desktop-Greeter oder End-User-Login
`packages`	Eines von `dpkg --list`, `rpm -qa` oder `pacman -Q` gelingt	Dass jedes vom Prompt angeforderte Paket installiert ist
`network`	DNS löst `example.com` auf und TCP-Verbindung zu Port 443 gelingt nach begrenzten Retries	Allgemeine Internet-Gesundheit, HTTP-Inhalt, jedes Interface oder air-gapped Design

Der Ubuntu-24.04-CIS-Pfad entfernt den generischen Network-Check und nutzt stattdessen seine readiness-gated feature assertion. Ein Rezept ohne erwartete Internet-Route kann failed generic network check in warning umgewandelt bekommen.

Feature- und Capability-Checks

Der Runner merged auch Checks aus enabled feature metadata, legacy hook test files, frozen capability plan, explicit custom tests und benchmark tests. Duplikate werden entfernt. Assertions mit bekannt fehlenden Parametern werden mit Server-Warnung gedroppt; resultierenden Test-Plan prüfen, damit dropped check nicht für pass gehalten wird.

Beispiele: konfigurierter SSH-Port, Service-Zustand, angefordertes Paket oder rezept-spezifisches Artefakt. Coverage hängt vom enabled feature ab: Feature-Inclusion garantiert nicht selbst ein vollständiges Assertion-Set.

Ergebnis lesen

Assertion rows und Evidenz nutzen, nicht nur aggregate badge:

passed bedeutet, der ausführbare Check lieferte das erwartete Ergebnis.
failed bedeutet, der Check lief und widersprach der Erwartung.
error bedeutet, der Harness konnte kein Verdict produzieren.
skipped bedeutet, der Check lief nicht, z. B. weil target VM fehlte.

Errors und skips sind keine passes. Abgeschlossenes Image und passed test run sind getrennte Zustände; Zertifizierung ist ein drittes Gate.

Stärkere Abnahmekriterien definieren

Für echte Workload prompt-relevante Assertions hinzufügen. Beispiel:


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

Dann gebautes Image in der Konsole inspizieren und für hardware-bound claims auf repräsentativer Hardware testen. Siehe Eigene Assertions und Assertion types.