Testing e verifica applicazioni
OpenFactory ha due superfici correlate:
- scenari immagine che avviano un artefatto buildato ed eseguono asserzioni guest delimitate; e
- un’anteprima app-platform che crea varianti app immutabili più flussi UI-test e walker.
La disponibilità differisce in modo sostanziale tra moduli app-platform. Leggi lo stato su ogni pagina prima dell’uso.
Disponibilità app-platform
| Argomento | Confine attuale |
|---|---|
| App Deployment | Accoda sorgente Git tramite pipeline varianti immutabili; segui evidenza deploy asincrono e health. |
| App UI Testing | Memorizza ed esegue scenari semantici delimitati su target raggiungibili; i risultati provano solo azioni e asserzioni dichiarate. |
| Deploy assistito da prompt | Richiede un URL template Git esistente; il brief è provenienza, non generazione sorgente. |
| Variabili ambiente app | Storage cifrato e handoff deploy sono implementati quando chiavi/token produttore richiesti sono configurati; rotazione ed evidenza runtime restano preoccupazioni operatore. |
| Database gestiti | Solo contratto stub; nessun database è provisionato. |
| Object Storage | Solo contratto stub; nessun bucket è provisionato. |
| Domini personalizzati | Solo verifica ownership DNS pubblico; serving/routing TLS personalizzato non è attivo. |
| Checkpoint | Solo identificatori stub; nessuno snapshot recuperabile esiste. |
| Observability | Storage eventi manuale e allocazione VM sono reali; ingest, probe, sample, log e dashboard sono incompleti. |
| Web IDE | Solo binding stub; nessun editor o route privata è provisionato. |
| App Auth | Solo binding stub; nessun provider identità, issuer o flusso token reale è provisionato. |
| Template e Remix | Crea record app da manifest o lineage sorgente eleggibile; non deploya né crea automaticamente servizi dichiarati. |
| Walker autonomo | Discovery UI delimitata con limiti importanti su copertura, autorizzazione ed effetti collaterali. |
| Walker Diffs | Confronta walk memorizzate ed esporta payload a forma ticket; non apre ticket esterni da solo. |
| Walk and Fix | Crea intent fix; patching VM live legacy confligge con modello deploy immutabile. |
Non concatenare un adapter stub in un workflow produzione perché la sua API ha restituito success.
Scenari immagine
I test immagine girano solo quando build/scenario selezionati li abilitano e l’infrastruttura test richiesta è disponibile. Tieni separati questi stati:
- costruzione artefatto;
- provisioning e boot guest;
- esecuzione asserzioni;
- finalizzazione evidenza; e
- policy certificazione o pubblicazione.
Una build può riuscire mentre i test sono disabilitati, pending, falliti o incompleti.
Design test
Test integrati
Nomi integrati come boot, login, packages, network e services forniscono una baseline. Ispeziona Test default per i loro limiti precisi.
Asserzioni personalizzate
Usa Asserzioni personalizzate per osservazioni servizio, porta, HTTP, file, comando, processo e GUI supportate. Ogni asserzione dovrebbe includere descrizione, risultato atteso, target, timeout e significato del fallimento.
Benchmark
I cataloghi benchmark sono insiemi di controlli strutturati, non determinazioni conformità. Abbina OS/versione esatti, conserva applicabilità e fallimenti, e leggi Evidenza benchmark CIS.
Checklist evidenza
Per una run che supporta decisione, conserva:
- ID ricetta, sorgente, build, artefatto, VM, scenario e run;
- digest artefatto e sorgente esatti;
- ambiente test e versione runner;
- ogni risultato asserzione e output grezzo;
- screenshot solo dove giustificato e gestito in sicurezza;
- controlli mancanti, saltati o non applicabili;
- timestamp e stato terminale; e
- disposizione revisore e approvazione per la decisione dichiarata.
Quando un test fallisce, diagnostica lo strato fallito prima di rebuildare. Una build duplicata può nascondere un difetto ownership, deploy, test-runner o finalizzazione evidenza invece di correggerlo.