Assertion-Typen

Kanonische Referenz für Assertions, die innerhalb einer provisionierten Test-VM ausgeführt werden. Sofern nicht anders angegeben, ist das Ziel primary. Jede Assertion braucht außerdem eine lesbare description.

Stabile Gast-Assertions

Typ	Erforderliche `params`	Optionales Verhalten
`user_exists`	`username`	Führt `id` aus
`user_password`	`username`	Prüft, dass ein entsperrter Passwort-Hash existiert; kein interaktiver Login
`user_in_group`	`username`, `group`	Akzeptiert Vyatta-Admin-Äquivalente bei `sudo`/`admin`
`file_exists`	`path`	Akzeptiert Datei oder Verzeichnis
`file_contains`	`path`, `pattern` oder `content`	Nutzt `grep`; der Wert ist ein grep-Pattern, kein reiner Literalvergleich
`file_permissions`	`path`, `mode`	Vergleicht den von `stat` gemeldeten Oktal-Mode
`service_running`	`service`	Prüft systemd active state; kennt kleines Cross-Distro-Alias-Set
`service_enabled`	`service`	Prüft systemd enablement
`package_installed`	`package`	Prüft die unterstützte Package-Manager-Datenbank des Gasts
`port_listening`	`port`	`protocol` kann `tcp` oder `udp` sein; Default ist TCP
`command_succeeds`	`command`	Exit-Code muss null sein; `timeout_seconds`/`timeout` ist auf 1–1.800 Sekunden begrenzt
`command_output`	`command` plus Regex in `expected_pattern`, `pattern`, `expected` oder assertion-level `expected`	Matcht stdout mit Python-Regular-Expression-Semantik
`network_reachable`	`host`	`count` default 3; nutzt ICMP ping
`http_responds`	`url`	`status` default 200

Beispiel:


{
  "type": "command_output",
  "description": "Application reports the expected release",
  "params": {
    "command": "/opt/acme/bin/acme --version",
    "expected_pattern": "^acme 2\\.4\\.[0-9]+$"
  }
}

Befehl und erfasste Ausgabe können Test-Evidenz werden. Keine Geheimnisse einbetten.

GUI-Assertions

GUI-Checks hängen von funktionierender Display-Session und Screenshot-/Input-Helfern des Runners ab. Sie sind umgebungssensitiver als Gast-Befehls-Checks.

Typ	Hauptparameter	Was geprüft wird
`gui_application_opens`	`application` (kanonisch); Handler akzeptiert launch-spezifische Optionen	Startet Anwendung und sucht Fenster
`gui_window_visible`	Fenstertitel- oder Match-Parameter des Handlers	Sucht bestehendes Fenster
`gui_execute_command`	`command`	Führt Desktop-Befehl aus; kann Screenshot erfassen
`gui_application_process`	`process_name`	Sucht Prozess als headless Fallback
`gui_screenshot_matches`	`reference_id`; optional `threshold`, Crop/Mask-Regionen	Vergleicht aktuellen Screenshot mit gespeicherter Referenz
`gui_wallpaper_matches`	`wallpaper_path`; optional Thresholds und Regionen	Prüft konfigurierten Wallpaper-Pfad und visuelles Ergebnis
`desktop_wallpaper_matches`	`wallpaper_path`	Strengere Desktop-Wallpaper-Provenienz/Konfiguration/Visuell-Prüfung
`gui_click_element`	`x`, `y`	Sendet koordinatenbasierten Pointer-Input
`gui_form_fill`	`fields`	Füllt koordinatenbeschriebene Formular-Inputs
`gui_text_visible`	`text`, `contains` oder `ocr_contains`	Nutzt OCR auf Bildschirm oder ausgewählter Region

Der Executor akzeptiert Kompatibilitäts-Aliase für manche OCR- und Wallpaper-Typen. Bevorzugen Sie in neuen Rezepten die kanonischen Namen oben. Koordinaten-Tests sind auflösungssensitiv; nutzen Sie OCR oder Outcome-Checks wo möglich.

Benchmark-Checks sind ein separates Format

cis_benchmark erscheint im historischen Assertion-Vokabular des Rezepts, aber der gewöhnliche Assertion-Dispatcher hat keinen cis_benchmark-Handler. CIS und andere Benchmark-Checks kommen als Benchmark-Records mit audit_script und laufen über den Benchmark-Runner. Nutzen Sie den CIS-Benchmark-Workflow, nicht eine Custom Assertion mit type: "cis_benchmark".

Ergebnisinterpretation

Fehlende Pflichtdaten ergeben error, oder der Planner droppt die Assertion mit Warnung vor Ausführung.
Nicht verfügbares on_vm-Target ergibt skipped.
Nicht passendes Ergebnis ergibt failed.
Nur passed ist affirmativer Nachweis für diese Assertion.

Siehe Eigene Assertions für Authoring-Hinweise.