Testy domyślne

Testowanie jest domyślnie włączone w znormalizowanym przepisie, z czterema predefiniowanymi nazwami testów: boot, login, packages i network. To małe kontrole gościa, a nie pełny zestaw akceptacyjny. Przepis może wyłączyć testowanie lub zastąpić listę, a niektóre typy artefaktów stosują węższy kontrakt.

Czego domyślne testy faktycznie dowodzą

Test	Wykonana kontrola	Nie dowodzi
`boot`	`uptime` kończy się powodzeniem przez QEMU guest agent	Każdej ścieżki bootloadera, bootu sprzętowego ani braku ostrzeżeń jądra
`login`	`whoami` może działać przez kanał root guest-agent	Interaktywnego hasła, klucza SSH, PAM, greetera pulpitu ani logowania użytkownika końcowego
`packages`	Jedno z poleceń `dpkg --list`, `rpm -qa` lub `pacman -Q` kończy się powodzeniem	Że każdy pakiet żądany w prompcie jest zainstalowany
`network`	DNS rozwiązuje `example.com`, a połączenie TCP do portu 443 udaje się po ograniczonej liczbie ponowień	Ogólnego stanu internetu, treści HTTP, każdego interfejsu ani projektu air-gapped

Ścieżka Ubuntu 24.04 CIS usuwa ogólną kontrolę sieci i zamiast tego używa swojej readiness-gated feature assertion. Przepis bez oczekiwanej trasy do internetu może zamienić nieudaną ogólną kontrolę sieci na ostrzeżenie.

Kontrole funkcji i capability

Runner łączy też kontrole dostarczone przez metadane włączonych funkcji, legacy hook test files, frozen capability plan, jawne custom tests oraz benchmark tests. Zduplikowane assertions są usuwane. Assertions ze znanymi brakującymi parametrami są odrzucane z ostrzeżeniem serwera; przejrzyj wynikowy plan testów, aby odrzucona kontrola nie została uznana za sukces.

Przykłady obejmują skonfigurowany port SSH, stan usługi, żądany pakiet lub artefakt specyficzny dla przepisu. Zakres zależy od włączonej funkcji: dołączenie funkcji samo w sobie nie gwarantuje pełnego zestawu assertions dla tej funkcji.

Interpretacja wyniku

Korzystaj z wierszy assertion i dowodów, nie tylko z aggregate badge:

passed oznacza, że wykonywalna kontrola zwróciła oczekiwany wynik.
failed oznacza, że kontrola się wykonała i przeczyła oczekiwaniu.
error oznacza, że harness nie mógł wydać verdict.
skipped oznacza, że kontrola się nie wykonała, na przykład dlatego, że docelowa VM była nieobecna.

Błędy i pominięcia to nie sukcesy. Ukończony obraz i udany test run to osobne stany; certyfikacja to trzecia brama.

Definiowanie mocniejszych kryteriów akceptacji

Dla rzeczywistego obciążenia dodaj assertions istotne dla promptu. Na przykład:


{
  "description": "Nginx serves the local health endpoint",
  "assertions": [
    {
      "type": "service_running",
      "description": "Nginx is active",
      "params": { "service": "nginx" }
    },
    {
      "type": "http_responds",
      "description": "Health endpoint returns 200",
      "params": { "url": "http://localhost/health", "status": 200 }
    }
  ]
}

Następnie sprawdź zbudowany obraz w konsoli i dla twierdzeń związanych ze sprzętem przetestuj na reprezentatywnym sprzęcie. Zobacz Własne asercje i Typy asercji.