Tipi asserzione

Riferimento canonico per asserzioni eseguite dentro una VM test provisionata. Salvo diversa indicazione, il target è primary. Ogni asserzione richiede anche una description leggibile.

Asserzioni guest stabili

Tipo	`params` richiesti	Comportamento opzionale
`user_exists`	`username`	Esegue `id`
`user_password`	`username`	Verifica che esista un hash password sbloccato; non tenta login interattivo
`user_in_group`	`username`, `group`	Accetta equivalenti amministrativi Vyatta quando controlla `sudo`/`admin`
`file_exists`	`path`	Accetta file o directory
`file_contains`	`path`, `pattern` o `content`	Usa `grep`; il valore è un pattern grep, non solo confronto letterale
`file_permissions`	`path`, `mode`	Confronta mode ottale riportata da `stat`
`service_running`	`service`	Controlla stato active systemd; conosce un piccolo set alias cross-distro
`service_enabled`	`service`	Controlla abilitazione systemd
`package_installed`	`package`	Controlla database package manager supportato del guest
`port_listening`	`port`	`protocol` può essere `tcp` o `udp`; default TCP
`command_succeeds`	`command`	Exit code deve essere zero; `timeout_seconds`/`timeout` è limitato a 1–1.800 secondi
`command_output`	`command` più regex in `expected_pattern`, `pattern`, `expected` o `expected` a livello asserzione	Abbina stdout con semantica regex Python
`network_reachable`	`host`	`count` default 3; usa ping ICMP
`http_responds`	`url`	`status` default 200

Esempio:


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

Comando e output catturato possono diventare evidenza test. Non incorporare segreti.

Asserzioni GUI

Controlli GUI dipendono da sessione display funzionante e helper screenshot o input del runner. Sono più sensibili all’ambiente dei controlli comando guest.

Tipo	Parametri principali	Cosa controlla
`gui_application_opens`	`application` (canonico); handler accetta anche opzioni launch-specifiche	Avvia applicazione e cerca finestra
`gui_window_visible`	titolo finestra o parametri matching usati dall’handler	Cerca finestra esistente
`gui_execute_command`	`command`	Esegue comando desktop; può catturare screenshot
`gui_application_process`	`process_name`	Cerca processo come fallback headless
`gui_screenshot_matches`	`reference_id`; opzionali `threshold`, regioni crop/mask	Confronta screenshot corrente con riferimento memorizzato
`gui_wallpaper_matches`	`wallpaper_path`; soglie e regioni opzionali	Controlla path wallpaper configurato e risultato visivo
`desktop_wallpaper_matches`	`wallpaper_path`	Esegue controllo provenienza/configurazione/visivo wallpaper desktop più stretto
`gui_click_element`	`x`, `y`	Invia input puntatore basato su coordinate
`gui_form_fill`	`fields`	Compila input form descritti per coordinate
`gui_text_visible`	`text`, `contains` o `ocr_contains`	Usa OCR su schermo o regione selezionata

L’executor accetta anche alias compatibilità per alcuni tipi OCR e wallpaper. Preferisci i nomi canonici sopra nelle nuove ricette. Test coordinate sono sensibili alla risoluzione; usa OCR o controlli esito dove possibile.

I controlli benchmark sono un formato separato

cis_benchmark compare nel vocabolario asserzione storico della ricetta, ma il dispatcher asserzione ordinario non ha handler cis_benchmark. Controlli CIS e altri benchmark sono forniti come record benchmark con audit_script ed eseguiti tramite runner benchmark. Usa il workflow benchmark CIS, non asserzione custom con type: "cis_benchmark".

Interpretazione risultato

Dati richiesti mancanti producono error, o il planner può scartare l’asserzione con warning prima dell’esecuzione.
Target on_vm non disponibile produce skipped.
Risultato non corrispondente produce failed.
Solo passed è evidenza affermativa per quella asserzione.

Vedi Asserzioni personalizzate per guida authoring.