Testing og applikasjonsverifisering
OpenFactory har to relaterte flater:
- bildescenarier som starter en bygget artefakt og kjører avgrensede guest assertions; og
- en app-platform preview som oppretter immutable app variants pluss UI-test- og walker-workflows.
Tilgjengelighet varierer mye mellom app-platform-moduler. Les status på hver side før du bruker dem.
Tilgjengelighet app-platform
| Emne | Aktuell grense |
|---|---|
| App Deployment | Setter en Git-kilde i kø via immutable variant pipeline; følg asynkront deployment og health evidence. |
| App UI Testing | Lagrer og kjører avgrensede semantic scenarios mot reachable targets; resultater beviser bare angitte actions og assertions. |
| Prompt-assisted deployment | Krever eksisterende template Git URL; briefen er provenance, ikke source generation. |
| App environment variables | Encrypted storage og deployment handoff er implementert når required keys/tokens er konfigurert; rotation og runtime evidence er fortsatt operatørers ansvar. |
| Managed Databases | Bare stub contract; ingen database provisioned. |
| Object Storage | Bare stub contract; ingen bucket provisioned. |
| Custom Domains | Bare Public-DNS ownership verification; custom TLS serving/routing er ikke aktivt. |
| Checkpoints | Bare stub identifiers; det finnes ingen recoverable snapshot. |
| Observability | Manual event storage og VM allocation er reelle; ingest, probes, samples, logs og dashboard er ufullstendige. |
| Web IDE | Bare stub binding; ingen editor eller private route provisioned. |
| App Auth | Bare stub binding; ingen identity provider, issuer eller real token flow provisioned. |
| Templates and Remix | Oppretter app records fra manifests eller eligible source lineage; deployer ikke og oppretter ikke declared services automatisk. |
| Autonomous Walker | Avgrenset UI discovery med viktige grenser for coverage, authorization og side effects. |
| Walker Diffs | Sammenligner stored walks og eksporterer ticket-shaped payloads; oppretter ikke external tickets selv. |
| Walk and Fix | Oppretter fix intent; legacy live-VM patching er i konflikt med immutable deployment model. |
Ikke kjed en stub adapter inn i en produksjonsworkflow fordi API-en returnerte success.
Bildescenarier
Image tests kjører bare når valgt build/scenario aktiverer dem og required test infrastructure er tilgjengelig. Hold disse tilstandene atskilt:
- artifact construction;
- guest provisioning og boot;
- assertion execution;
- evidence finalization; og
- certification or publication policy.
En build kan lykkes mens tester er disabled, pending, failed eller incomplete.
Testdesign
Innebygde tester
Innebygde navn som boot, login, packages, network og services gir en baseline. Se Default Tests for deres presise begrensninger.
Custom assertions
Bruk Custom Assertions for service, port, HTTP, file, command, process og støttede GUI observations. Hver assertion bør inneholde description, expected result, target, timeout og failure meaning.
Benchmarks
Benchmark catalogs er strukturerte check sets, ikke compliance determinations. Match nøyaktig OS/version, behold applicability og failures, og les CIS benchmark evidence.
Evidence checklist
For en run som bærer en beslutning, behold:
- recipe, source, build, artifact, VM, scenario og run IDs;
- nøyaktige artifact og source digests;
- test environment og runner version;
- hvert assertion result og raw output;
- screenshots bare der det er berettiget og håndteres trygt;
- missing, skipped eller not-applicable checks;
- timestamps og terminal status; og
- reviewer disposition og approval for den angitte beslutningen.
Når en test feiler, diagnostiser det feilende laget før du bygger på nytt. En duplicate build kan skjule en feil i ownership, deployment, test-runner eller evidence finalization i stedet for å rette den.