Tests par défaut

Les tests sont activés par défaut dans une recette normalisée, avec quatre noms de test prédéfinis : boot, login, packages et network. Ce sont de petites vérifications invité, pas une suite d’acceptation complète. Une recette peut désactiver les tests ou remplacer la liste, et certains types d’artefact utilisent un contrat plus étroit.

Ce que les défauts prouvent réellement

Test	Vérification exécutée	Ne prouve pas
`boot`	`uptime` se termine avec succès via l’agent invité QEMU	Chaque chemin bootloader, boot matériel ou absence d’avertissements noyau
`login`	`whoami` peut s’exécuter via le canal agent invité root	Connexion interactive mot de passe, clé SSH, PAM, greeter bureau ou connexion utilisateur final
`packages`	L’un de `dpkg --list`, `rpm -qa` ou `pacman -Q` réussit	Que chaque paquet demandé par l’invite est installé
`network`	DNS résout `example.com` et une connexion TCP vers le port 443 réussit après retries bornés	Santé internet générale, contenu HTTP, chaque interface ou une conception air-gapped

Le chemin CIS Ubuntu 24.04 retire la vérification réseau générique et utilise à la place son assertion fonctionnalité avec attente de disponibilité. Une recette sans route internet attendue peut voir un échec réseau générique converti en avertissement.

Vérifications fonctionnalité et capacité

Le runner fusionne aussi les vérifications fournies par métadonnées de fonctionnalités activées, anciens fichiers de test hook, plan de capacité figé, tests personnalisés explicites et tests benchmark. Les assertions en double sont retirées. Les assertions avec paramètres connus manquants sont abandonnées avec un avertissement serveur ; relisez le plan de test résultant pour ne pas confondre une vérification abandonnée avec un succès.

Les exemples incluent le port SSH configuré, l’état de service, un paquet demandé ou un artefact propre à la recette. La couverture dépend de la fonctionnalité activée : inclure une fonctionnalité ne garantit pas à elle seule un ensemble d’assertions complet pour cette fonctionnalité.

Lire le résultat

Utilisez les lignes d’assertion et les preuves, pas seulement le badge agrégé :

passed signifie que la vérification exécutable a renvoyé le résultat attendu.
failed signifie que la vérification a tourné et contredit l’attente.
error signifie que le harness n’a pas pu produire un verdict.
skipped signifie que la vérification n’a pas tourné, par exemple parce que sa VM cible était absente.

Erreurs et skips ne sont pas des succès. Une image terminée et une exécution de test réussie sont des états séparés ; la certification est une troisième porte.

Définir des critères d’acceptation plus forts

Pour une charge réelle, ajoutez des assertions pertinentes à l’invite. Par exemple :


{
  "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 }
    }
  ]
}

Inspectez ensuite l’image construite dans la console et, pour des affirmations liées au matériel, testez sur du matériel représentatif. Voir Assertions personnalisées et Types d’assertion.