Skip to Content
TestingTestes default

Testes default

Testes estão habilitados por default em receita normalizada, com quatro nomes de teste predefined: boot, login, packages e network. São checagens pequenas no guest, não suíte completa de aceitação. Receita pode desabilitar testes ou substituir lista, e alguns tipos de artefato usam contrato mais estreito.

O que os defaults de fato provam

TestExecuted checkDoes not prove
bootuptime exits successfully through the QEMU guest agentEvery bootloader path, hardware boot, or absence of kernel warnings
loginwhoami can run through the root guest-agent channelInteractive password, SSH-key, PAM, desktop-greeter, or end-user login
packagesOne of dpkg --list, rpm -qa, or pacman -Q succeedsThat every package requested by the prompt is installed
networkDNS resolves example.com and a TCP connection to port 443 succeeds after bounded retriesGeneral internet health, HTTP content, every interface, or an air-gapped design

Caminho CIS Ubuntu 24.04 remove checagem genérica de rede e usa asserção de feature com gate de readiness. Receita sem rota de internet esperada pode ter checagem genérica de rede failed convertida em aviso.

Checagens de feature e capacidade

Runner também mescla checagens de metadados de feature habilitados, arquivos de teste de hook legados, plano de capacidade congelado, custom tests explícitos e testes de benchmark. Asserções duplicadas são removidas. Asserções com parâmetros faltando conhecidos são descartadas com aviso server-side; revise plano de teste resultante para checagem descartada não ser confundida com pass.

Exemplos incluem checar porta SSH configurada, estado de serviço, pacote solicitado ou artefato específico da receita. Cobertura depende do feature habilitado: inclusão de feature não garante por si conjunto completo de asserções.

Ler o resultado

Use linhas de asserção e evidência, não só badge agregado:

  • passed significa que checagem executável retornou resultado esperado.
  • failed significa que checagem rodou e contradisse expectativa.
  • error significa que harness não produziu veredicto.
  • skipped significa que checagem não rodou, por exemplo porque VM alvo estava ausente.

Errors e skips não são passes. Imagem concluída e run de teste passed são estados separados; certificação é terceiro gate.

Defina critérios de aceitação mais fortes

Para workload real, adicione asserções relevantes ao prompt. Por exemplo:

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

Depois inspecione imagem construída no console e, para afirmações ligadas a hardware, teste em hardware representativo. Veja Asserções personalizadas e Tipos de asserção.