Testes e verificação de aplicativo
O OpenFactory tem duas superfícies relacionadas:
- cenários de imagem que inicializam artefato construído e rodam asserções limitadas no guest; e
- preview de plataforma de app que cria variants imutáveis de app mais workflows de UI-test e walker.
Disponibilidade difere substancialmente entre módulos da plataforma de app. Leia o status em cada página antes de usar.
Disponibilidade da plataforma de app
| Tópico | Limite atual |
|---|---|
| App Deployment | Enfileira origem Git pelo pipeline de variant imutável; siga evidência assíncrona de deployment e saúde. |
| App UI Testing | Armazena e executa cenários semânticos limitados contra alvos alcançáveis; resultados provam só ações e asserções declaradas. |
| Deployment assistido por prompt | Exige URL Git de template existente; o brief é proveniência, não geração de origem. |
| Variáveis de ambiente de app | Storage criptografado e handoff de deployment implementados quando chaves/tokens exigidos estão configurados; rotação e evidência de runtime permanecem preocupação do operador. |
| Managed Databases | Contrato stub apenas; nenhum banco é provisionado. |
| Object Storage | Contrato stub apenas; nenhum bucket é provisionado. |
| Custom Domains | Verificação de ownership DNS público apenas; serving/routing TLS custom não está ativo. |
| Checkpoints | Identificadores stub apenas; nenhum snapshot recuperável existe. |
| Observability | Storage manual de eventos e alocação de VM são reais; ingest, probes, samples, logs e dashboard estão incompletos. |
| Web IDE | Binding stub apenas; nenhum editor ou rota privada é provisionado. |
| App Auth | Binding stub apenas; nenhum provedor de identidade, issuer ou fluxo real de token é provisionado. |
| Templates e Remix | Cria registros de app a partir de manifests ou linhagem de origem elegível; não faz deploy nem cria serviços declarados automaticamente. |
| Autonomous Walker | Descoberta de UI limitada com limites importantes de cobertura, autorização e efeitos colaterais. |
| Walker Diffs | Compara walks armazenados e exporta payloads no formato de ticket; não abre tickets externos sozinho. |
| Walk and Fix | Cria fix intent; patching legado em VM ao vivo conflita com modelo de deployment imutável. |
Não encadeie adapter stub em workflow de produção porque a API retornou success.
Cenários de imagem
Testes de imagem rodam só quando o build/cenário selecionado os habilita e a infraestrutura de teste necessária está disponível. Mantenha estes estados separados:
- construção de artefato;
- provisionamento e boot do guest;
- execução de asserção;
- finalização de evidência; e
- política de certificação ou publicação.
Build pode succeeder enquanto testes estão desabilitados, pending, failed ou incompletos.
Design de teste
Testes embutidos
Nomes embutidos como boot, login, packages, network e services fornecem baseline. Inspecione Testes default para limitações precisas.
Asserções personalizadas
Use Asserções personalizadas para observações de serviço, porta, HTTP, arquivo, comando, processo e GUI suportadas. Toda asserção deve incluir descrição, resultado esperado, alvo, timeout e significado de falha.
Benchmarks
Catálogos de benchmark são conjuntos estruturados de checagens, não determinações de conformidade. Combine OS/versão exatos, retenha aplicabilidade e falhas, e leia Evidência de benchmark CIS.
Checklist de evidência
Para execução que sustenta decisão, retenha:
- IDs de receita, origem, build, artefato, VM, cenário e run;
- digests exatos de artefato e origem;
- ambiente de teste e versão do runner;
- todo resultado de asserção e saída bruta;
- screenshots só onde justificado e tratado com segurança;
- checagens missing, skipped ou not-applicable;
- timestamps e status terminal; e
- disposição do revisor e aprovação para a decisão declarada.
Quando teste falha, diagnostique a camada com falha antes de reconstruir. Build duplicado pode esconder defeito de propriedade, deployment, test-runner ou finalização de evidência em vez de corrigi-lo.