Skip to Content
TestingTestare și verificarea aplicațiilor

Testare și verificarea aplicațiilor

OpenFactory are două suprafețe înrudite:

  • image scenarios care pornesc un artifact construit și rulează guest assertions limitate; și
  • previzualizarea app-platform care creează immutable app variants plus workflow-uri UI-test și walker.

Disponibilitatea diferă mult între modulele app-platform. Citiți starea de pe fiecare pagină înainte de utilizare.

Disponibilitate app-platform

SubiectLimită actuală
App DeploymentPune Git source în coadă prin immutable variant pipeline; urmăriți deployment-ul asincron și health evidence.
App UI TestingStochează și rulează semantic scenarios limitate față de targets accesibile; rezultatele dovedesc doar actions și assertions declarate.
Prompt-assisted deploymentNecesită un template Git URL existent; brief-ul este provenance, nu source generation.
App environment variablesEncrypted storage și deployment handoff sunt implementate când keys/tokens necesare sunt configurate; rotation și runtime evidence rămân responsabilitatea operatorului.
Managed DatabasesDoar stub contract; nu se provisionează nicio bază de date.
Object StorageDoar stub contract; nu se provisionează niciun bucket.
Custom DomainsDoar Public-DNS ownership verification; custom TLS serving/routing nu este activ.
CheckpointsDoar stub identifiers; nu există recoverable snapshot.
ObservabilityManual event storage și VM allocation sunt reale; ingest, probes, samples, logs și dashboard sunt incomplete.
Web IDEDoar stub binding; nu se provisionează editor sau private route.
App AuthDoar stub binding; nu se provisionează identity provider, issuer sau real token flow.
Templates and RemixCreează app records din manifeste sau eligible source lineage; nu deployează și nu creează automat declared services.
Autonomous WalkerUI discovery limitat, cu limite importante la coverage, authorization și side effects.
Walker DiffsCompară stored walks și exportă ticket-shaped payloads; nu deschide singur tickets externe.
Walk and FixCreează fix intent; legacy live-VM patching intră în conflict cu immutable deployment model.

Nu înlănțuiți un stub adapter într-un workflow de producție doar pentru că API-ul său a returnat success.

Image scenarios

Image tests rulează doar când build/scenario selectat le activează și test infrastructure necesară este disponibilă. Păstrați aceste stări separate:

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

Un build poate reuși în timp ce testele sunt disabled, pending, failed sau incomplete.

Proiectarea testelor

Teste integrate

Numele integrate precum boot, login, packages, network și services oferă o bază. Limitările exacte sunt în Default Tests.

Custom assertions

Folosiți Custom Assertions pentru service, port, HTTP, file, command, process și observații GUI suportate. Fiecare assertion ar trebui să includă descriere, expected result, target, timeout și semnificația eșecului.

Benchmarks

Benchmark catalogs sunt seturi structurate de verificări, nu compliance determinations. Potriviți OS/version exact, păstrați applicability și failures și citiți CIS benchmark evidence.

Listă de verificare evidence

Pentru un run care susține o decizie, păstrați:

  • recipe, source, build, artifact, VM, scenario și run IDs;
  • digests exacte pentru artifact și source;
  • test environment și runner version;
  • fiecare rezultat assertion și raw output;
  • screenshots doar unde este justificat și gestionat în siguranță;
  • verificări lipsă, skipped sau not-applicable;
  • timestamps și terminal status; și
  • reviewer disposition și aprobare pentru decizia declarată.

Când un test eșuează, diagnosticați stratul care eșuează înainte de rebuild. Un build duplicat poate ascunde un defect de ownership, deployment, test-runner sau evidence finalization în loc să îl remedieze.