Skip to Content
ReferenceAssertietypen

Assertietypen

Canonieke referentie voor assertions die in een ingerichte test-VM worden uitgevoerd. Tenzij anders vermeld, is het doel primary. Elke assertion vereist ook een leesbare description.

Stabiele guest-assertions

TypeVereiste paramsOptioneel gedrag
user_existsusernameVoert id uit
user_passwordusernameControleert of er een ontgrendelde wachtwoordhash bestaat; er wordt geen interactieve login geprobeerd
user_in_groupusername, groupAccepteert Vyatta-beheerequivalenten bij controle op sudo/admin
file_existspathAccepteert een bestand of map
file_containspath, pattern of contentGebruikt grep; de waarde is een grep-patroon, geen puur letterlijke vergelijking
file_permissionspath, modeVergelijkt de octale modus die stat rapporteert
service_runningserviceControleert systemd active state; kent een kleine cross-distro aliass set
service_enabledserviceControleert systemd enablement
package_installedpackageControleert de ondersteunde package-managerdatabase van de guest
port_listeningportprotocol kan tcp of udp zijn; standaard is TCP
command_succeedscommandExitcode moet nul zijn; timeout_seconds/timeout wordt begrensd tot 1–1.800 seconden
command_outputcommand plus een regex in expected_pattern, pattern, expected, of assertion-level expectedMatcht stdout met Python-regular-expression-semantiek
network_reachablehostcount standaard 3; gebruikt ICMP ping
http_respondsurlstatus standaard 200

Voorbeeld:

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

Het commando en de vastgelegde output kunnen testbewijs worden. Embed geen geheimen.

GUI-assertions

GUI-controles hangen af van een werkende displaysessie en de screenshot- of inputhelpers van de runner. Ze zijn gevoeliger voor de omgeving dan guest-commandocontroles.

TypeBelangrijkste parametersWat wordt gecontroleerd
gui_application_opensapplication (canoniek); handler accepteert ook launch-specifieke optiesStart een applicatie en zoekt een venster
gui_window_visiblevenstertitel- of matchparameters die de handler gebruiktZoekt een bestaand venster
gui_execute_commandcommandVoert een desktopcommando uit; kan een screenshot vastleggen
gui_application_processprocess_nameZoekt het proces als headless fallback
gui_screenshot_matchesreference_id; optioneel threshold, crop/mask-regio’sVergelijkt het huidige screenshot met een opgeslagen referentie
gui_wallpaper_matcheswallpaper_path; optionele drempels en regio’sControleert het geconfigureerde wallpaperpad en het visuele resultaat
desktop_wallpaper_matcheswallpaper_pathVoert de strengere desktop-wallpaper provenance/configuration/visual check uit
gui_click_elementx, yStuurt coördinaatgebaseerde pointerinput
gui_form_fillfieldsVult coördinaatbeschreven formuliervelden in
gui_text_visibletext, contains, of ocr_containsGebruikt OCR op het scherm of een geselecteerde regio

De executor accepteert ook compatibiliteitsaliassen voor sommige OCR- en wallpapertypes. Gebruik in nieuwe recipes bij voorkeur de canonieke namen hierboven. Coördinaattests zijn resolutiegevoelig; gebruik waar mogelijk OCR of outcome-checks.

Benchmark-checks zijn een apart formaat

cis_benchmark staat in het historische assertion-vocabulaire van het recipe, maar de gewone assertion-dispatcher heeft geen cis_benchmark-handler. CIS en andere benchmark-checks worden geleverd als benchmarkrecords met een audit_script en lopen via de benchmark-runner. Gebruik de CIS benchmark-workflow, geen custom assertion met type: "cis_benchmark".

Resultaatinterpretatie

  • Ontbrekende verplichte gegevens geven error, of de planner laat de assertion vallen met een waarschuwing vóór uitvoering.
  • Een niet-beschikbaar on_vm-doel geeft skipped.
  • Een niet-passend resultaat geeft failed.
  • Alleen passed is bevestigend bewijs voor die assertion.

Zie Custom assertions voor richtlijnen bij het schrijven.