Assertionstyper

Kanonisk referanse for assertions som kjøres i en provisjonert test-VM. Med mindre annet er angitt, er målet primary. Hver assertion krever også et lesbart felt description.

Stabile gjest-assertions

Type	Påkrevde `params`	Valgfri oppførsel
`user_exists`	`username`	Kjører `id`
`user_password`	`username`	Verifiserer at en ulåst passordhash finnes; forsøker ikke interaktiv innlogging
`user_in_group`	`username`, `group`	Aksepterer Vyatta-administrative ekvivalenter ved sjekk av `sudo`/`admin`
`file_exists`	`path`	Aksepterer fil eller mappe
`file_contains`	`path`, `pattern` eller `content`	Bruker `grep`; verdien er et grep-mønster, ikke utelukkende literal sammenligning
`file_permissions`	`path`, `mode`	Sammenligner oktalmodus rapportert av `stat`
`service_running`	`service`	Sjekker systemd active state; kjenner et lite sett alias på tvers av distroer
`service_enabled`	`service`	Sjekker systemd enablement
`package_installed`	`package`	Sjekker gjestens støttede pakkebehandlerdatabase
`port_listening`	`port`	`protocol` kan være `tcp` eller `udp`; standard er TCP
`command_succeeds`	`command`	Exit code må være null; `timeout_seconds`/`timeout` begrenses til 1–1 800 sekunder
`command_output`	`command` pluss regex i `expected_pattern`, `pattern`, `expected`, eller assertion-level `expected`	Matcher stdout med Python regular-expression-semantikk
`network_reachable`	`host`	`count` standard 3; bruker ICMP ping
`http_responds`	`url`	`status` standard 200

Eksempel:


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

Kommandoen og fanget output kan bli testbevis. Ikke embed hemmeligheter.

GUI-assertions

GUI-sjekker avhenger av en fungerende displaysession og runnerens skjermdump- eller inndatahjelpere. De er mer miljøfølsomme enn gjestekommando-sjekker.

Type	Hovedparametre	Hva som sjekkes
`gui_application_opens`	`application` (kanonisk); handler aksepterer også startspesifikke valg	Starter et program og leter etter et vindu
`gui_window_visible`	vindustittel- eller matchparametre brukt av handleren	Leter etter et eksisterende vindu
`gui_execute_command`	`command`	Kjører en skrivebordskommando; kan ta en skjermdump
`gui_application_process`	`process_name`	Leter etter prosessen som headless fallback
`gui_screenshot_matches`	`reference_id`; valgfri `threshold`, crop/mask-regioner	Sammenligner gjeldende skjermdump med lagret referanse
`gui_wallpaper_matches`	`wallpaper_path`; valgfrie terskler og regioner	Sjekker konfigurert bakgrunnsbildesti og visuelt resultat
`desktop_wallpaper_matches`	`wallpaper_path`	Kjører den strengere desktop-bakgrunnsbilde provenance/configuration/visual-sjekken
`gui_click_element`	`x`, `y`	Sender koordinatbasert pekerinndata
`gui_form_fill`	`fields`	Fyller koordinatbeskrevne skjemafelt
`gui_text_visible`	`text`, `contains`, eller `ocr_contains`	Bruker OCR på skjermen eller en valgt region

Executoren aksepterer også kompatibilitetsalias for noen OCR- og bakgrunnstyper. Foretrekk de kanoniske navnene over i nye recipes. Koordinattester er oppløsningsfølsomme; bruk OCR eller resultatsjekker der det er mulig.

Benchmark-sjekker er et separat format

cis_benchmark finnes i oppskriftens historiske assertion-ordforråd, men den vanlige assertion-dispatcheren har ingen cis_benchmark-handler. CIS og andre benchmark-sjekker leveres som benchmark-poster med audit_script og kjøres via benchmark-runneren. Bruk CIS benchmark-workflow, ikke en custom assertion med type: "cis_benchmark".

Tolkning av resultat

Manglende påkrevde data gir error, eller planleggeren kan droppe assertionen med advarsel før kjøring.
Utilgjengelig on_vm-mål gir skipped.
Ikke matchende resultat gir failed.
Bare passed er bekreftende bevis for den assertionen.

Se Custom assertions for veiledning ved authoring.