Skip to Content
TestingTestování a ověřování aplikací

Testování a ověřování aplikací

OpenFactory nabízí dvě související oblasti:

  • image scenarios, které bootují sestavený artifact a spouštějí omezené guest assertions; a
  • náhled app-platform, který vytváří immutable app variants a workflowy UI-test a walker.

Dostupnost se mezi moduly app-platform výrazně liší. Před použitím si na každé stránce přečtěte stav.

Dostupnost app-platform

TémaAktuální hranice
App DeploymentZařadí Git source do immutable variant pipeline; sledujte asynchronní deployment a health evidence.
App UI TestingUkládá a spouští omezené semantic scenarios proti dosažitelným targets; výsledky dokazují jen uvedené actions a assertions.
Prompt-assisted deploymentVyžaduje existující template Git URL; brief je provenance, ne source generation.
App environment variablesEncrypted storage a deployment handoff jsou implementované, když jsou nakonfigurované požadované keys/tokens; rotation a runtime evidence zůstávají na operátorovi.
Managed DatabasesPouze stub contract; žádná databáze se neprovisionuje.
Object StoragePouze stub contract; žádný bucket se neprovisionuje.
Custom DomainsPouze Public-DNS ownership verification; custom TLS serving/routing není aktivní.
CheckpointsPouze stub identifiers; neexistuje recoverable snapshot.
ObservabilityManual event storage a VM allocation jsou skutečné; ingest, probes, samples, logs a dashboard jsou neúplné.
Web IDEPouze stub binding; neprovisionuje se editor ani private route.
App AuthPouze stub binding; neprovisionuje se identity provider, issuer ani real token flow.
Templates and RemixVytváří app records z manifestů nebo eligible source lineage; nedeployuje ani automaticky nevytváří declared services.
Autonomous WalkerOmezené UI discovery s důležitými limity coverage, authorization a side effects.
Walker DiffsPorovnává stored walks a exportuje ticket-shaped payloads; externí tickets nezakládá samo.
Walk and FixVytváří fix intent; legacy live-VM patching je v konfliktu s immutable deployment model.

Nepřipojujte stub adapter do produkčního workflow jen proto, že jeho API vrátilo success.

Image scenarios

Image tests běží jen když je zvolený build/scenario zapne a je k dispozici požadovaná test infrastructure. Držte tyto stavy odděleně:

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

Build může uspět, i když jsou testy vypnuté, pending, failed nebo incomplete.

Návrh testů

Vestavěné testy

Vestavěná jména jako boot, login, packages, network a services dávají základ. Přesná omezení najdete v Default Tests.

Custom assertions

Pro service, port, HTTP, file, command, process a podporovaná GUI pozorování použijte Custom Assertions. Každá assertion by měla mít popis, expected result, target, timeout a význam selhání.

Benchmarks

Benchmark catalogs jsou strukturované sady kontrol, ne compliance determinations. Shodujte přesné OS/version, uchovejte applicability a failures a přečtěte si CIS benchmark evidence.

Kontrolní seznam evidence

U běhu, který má nést rozhodnutí, uchovejte:

  • recipe, source, build, artifact, VM, scenario a run IDs;
  • přesné artifact a source digests;
  • test environment a runner version;
  • každý výsledek assertion a raw output;
  • screenshots jen kde je to odůvodněné a bezpečně zpracované;
  • chybějící, skipped nebo not-applicable checks;
  • timestamps a terminal status; a
  • reviewer disposition a schválení pro uvedené rozhodnutí.

Když test selže, nejdřív diagnostikujte selhávající vrstvu, až potom rebuild. Duplicitní build může skrýt chybu v ownership, deployment, test-runner nebo evidence finalization místo toho, aby ji opravil.