Skip to Content
TestingTest og applikationsverifikation

Test og applikationsverifikation

OpenFactory har to relaterede flader:

  • billedscenarier, der starter en bygget artefakt og kører afgrænsede guest assertions; og
  • en app-platform preview, der opretter immutable app variants plus UI-test- og walker-workflows.

Tilgængelighed varierer meget på tværs af app-platform-moduler. Læs status på hver side, før du bruger dem.

Tilgængelighed app-platform

EmneAktuel grænse
App DeploymentSætter en Git-kilde i kø via immutable variant pipeline; følg asynkront deployment og health evidence.
App UI TestingGemmer og kører afgrænsede semantic scenarios mod reachable targets; resultater beviser kun angivne actions og assertions.
Prompt-assisted deploymentKræver eksisterende template Git URL; briefen er provenance, ikke source generation.
App environment variablesEncrypted storage og deployment handoff er implementeret, når required keys/tokens er konfigureret; rotation og runtime evidence er stadig operatørernes ansvar.
Managed DatabasesKun stub contract; ingen database provisioned.
Object StorageKun stub contract; ingen bucket provisioned.
Custom DomainsKun Public-DNS ownership verification; custom TLS serving/routing er ikke aktivt.
CheckpointsKun stub identifiers; der findes ingen recoverable snapshot.
ObservabilityManual event storage og VM allocation er reelle; ingest, probes, samples, logs og dashboard er ufuldstændige.
Web IDEKun stub binding; ingen editor eller private route provisioned.
App AuthKun stub binding; ingen identity provider, issuer eller real token flow provisioned.
Templates and RemixOpretter app records fra manifests eller eligible source lineage; deployer ikke og opretter ikke declared services automatisk.
Autonomous WalkerAfgrænset UI discovery med vigtige grænser for coverage, authorization og side effects.
Walker DiffsSammenligner stored walks og eksporterer ticket-shaped payloads; opretter ikke external tickets selv.
Walk and FixOpretter fix intent; legacy live-VM patching er i konflikt med immutable deployment model.

Kæd ikke en stub adapter ind i et produktionsworkflow, fordi dens API returnerede success.

Billedscenarier

Image tests kører kun, når den valgte build/scenario aktiverer dem, og required test infrastructure er tilgængelig. Hold disse tilstande adskilt:

  1. artifact construction;
  2. guest provisioning og boot;
  3. assertion execution;
  4. evidence finalization; og
  5. certification or publication policy.

En build kan lykkes, mens tests er disabled, pending, failed eller incomplete.

Testdesign

Indbyggede tests

Indbyggede navne som boot, login, packages, network og services giver en baseline. Se Default Tests for deres præcise begrænsninger.

Custom assertions

Brug Custom Assertions til service, port, HTTP, file, command, process og understøttede GUI observations. Hver assertion bør indeholde description, expected result, target, timeout og failure meaning.

Benchmarks

Benchmark catalogs er strukturerede check sets, ikke compliance determinations. Match præcis OS/version, behold applicability og failures, og læs CIS benchmark evidence.

Evidence checklist

For en run, der bærer en beslutning, behold:

  • recipe, source, build, artifact, VM, scenario og run IDs;
  • præcise artifact og source digests;
  • test environment og runner version;
  • hvert assertion result og raw output;
  • screenshots kun hvor det er berettiget og håndteres sikkert;
  • missing, skipped eller not-applicable checks;
  • timestamps og terminal status; og
  • reviewer disposition og approval for den angivne beslutning.

Når en test fejler, diagnosticer det fejlende lag, før du bygger igen. En duplicate build kan skjule en fejl i ownership, deployment, test-runner eller evidence finalization i stedet for at rette den.