Assertionstyper

Kanonisk referens för assertions som körs i en provisionerad test-VM. Om inget annat anges är målet primary. Varje assertion kräver också ett läsbart fält description.

Stabila gäst-assertions

Typ	Obligatoriska `params`	Valfritt beteende
`user_exists`	`username`	Kör `id`
`user_password`	`username`	Verifierar att en olåst lösenordshash finns; försöker inte interaktiv inloggning
`user_in_group`	`username`, `group`	Accepterar Vyatta-administrativa motsvarigheter vid kontroll av `sudo`/`admin`
`file_exists`	`path`	Accepterar fil eller katalog
`file_contains`	`path`, `pattern` eller `content`	Använder `grep`; värdet är ett grep-mönster, inte enbart literal jämförelse
`file_permissions`	`path`, `mode`	Jämför oktalt läge som `stat` rapporterar
`service_running`	`service`	Kontrollerar systemd active state; känner till en liten mängd alias mellan distributioner
`service_enabled`	`service`	Kontrollerar systemd enablement
`package_installed`	`package`	Kontrollerar gästens stödda pakethanterardatabas
`port_listening`	`port`	`protocol` kan vara `tcp` eller `udp`; standard är TCP
`command_succeeds`	`command`	Exit code måste vara noll; `timeout_seconds`/`timeout` begränsas till 1–1 800 sekunder
`command_output`	`command` plus regex i `expected_pattern`, `pattern`, `expected`, eller assertion-level `expected`	Matchar stdout med Python regular-expression-semantik
`network_reachable`	`host`	`count` standard 3; använder ICMP ping
`http_responds`	`url`	`status` standard 200

Exempel:


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

Kommandot och den fångade utdata kan bli testbevis. Bädda inte in hemligheter.

GUI-assertions

GUI-kontroller beror på en fungerande displaysession och runnerns skärmdumps- eller inmatningshjälpare. De är mer miljökänsliga än gästkommandokontroller.

Typ	Huvudparametrar	Vad som kontrolleras
`gui_application_opens`	`application` (kanonisk); handlern accepterar även startspecifika alternativ	Startar ett program och letar efter ett fönster
`gui_window_visible`	fönstertitel- eller matchparametrar som handlern använder	Letar efter ett befintligt fönster
`gui_execute_command`	`command`	Kör ett skrivbordskommando; kan ta en skärmdump
`gui_application_process`	`process_name`	Letar efter processen som headless-reserv
`gui_screenshot_matches`	`reference_id`; valfritt `threshold`, crop/mask-regioner	Jämför aktuell skärmdump med lagrad referens
`gui_wallpaper_matches`	`wallpaper_path`; valfria trösklar och regioner	Kontrollerar konfigurerad bakgrundsbildssökväg och visuellt resultat
`desktop_wallpaper_matches`	`wallpaper_path`	Kör den strängare kontrollen av desktop-bakgrundsbild provenance/configuration/visual
`gui_click_element`	`x`, `y`	Skickar koordinatbaserad pekarinmatning
`gui_form_fill`	`fields`	Fyller koordinatbeskrivna formulärfält
`gui_text_visible`	`text`, `contains`, eller `ocr_contains`	Använder OCR på skärmen eller en vald region

Exekutorn accepterar också kompatibilitetsalias för vissa OCR- och bakgrundstyper. Använd de kanoniska namnen ovan i nya recipes. Koordinattester är upplösningskänsliga; använd OCR eller resultatkontroller där det går.

Benchmark-kontroller är ett separat format

cis_benchmark finns i receptets historiska assertion-ordförråd, men den vanliga assertion-dispatchern har ingen cis_benchmark-handler. CIS och andra benchmark-kontroller levereras som benchmark-poster med audit_script och körs via benchmark-runnern. Använd CIS benchmark-arbetsflödet, inte en custom assertion med type: "cis_benchmark".

Tolkning av resultat

Saknade obligatoriska data ger error, eller planeraren kan ta bort assertionen med varning före körning.
Otillgängligt on_vm-mål ger skipped.
Icke matchande resultat ger failed.
Endast passed är bekräftande bevis för den assertionen.

Se Custom assertions för vägledning vid skrivande.