Tests et vérification applicative
OpenFactory a deux surfaces liées :
- scénarios d’image qui démarrent un artefact construit et exécutent des assertions invité bornées ; et
- un aperçu plateforme app qui crée des variants app immuables plus workflows UI-test et walker.
La disponibilité diffère fortement entre modules plateforme app. Lisez le statut sur chaque page avant usage.
Disponibilité plateforme app
| Sujet | Frontière actuelle |
|---|---|
| Déploiement app | Met en file une source Git via le pipeline variant immuable ; suivez les preuves de déploiement asynchrone et de santé. |
| Tests UI app | Stocke et exécute des scénarios sémantiques bornés contre cibles joignables ; les résultats ne prouvent que les actions et assertions énoncées. |
| Déploiement assisté par invite | Exige une URL Git de modèle existante ; le brief est de la provenance, pas de la génération source. |
| Variables d’environnement app | Stockage chiffré et remise au déploiement sont implémentés lorsque clés/jetons requis sont configurés ; rotation et preuves runtime restent des préoccupations opérateur. |
| Bases de données gérées | Contrat stub uniquement ; aucune base n’est provisionnée. |
| Stockage objet | Contrat stub uniquement ; aucun bucket n’est provisionné. |
| Domaines personnalisés | Vérification de propriété DNS public uniquement ; service/routage TLS personnalisé n’est pas actif. |
| Checkpoints | Identifiants stub uniquement ; aucun instantané récupérable n’existe. |
| Observabilité | Stockage d’événements manuel et allocation VM sont réels ; ingest, sondes, échantillons, journaux et tableau de bord sont incomplets. |
| Web IDE | Liaison stub uniquement ; aucun éditeur ni route privée n’est provisionné. |
| App Auth | Liaison stub uniquement ; aucun fournisseur d’identité, issuer ni flux de jeton réel n’est provisionné. |
| Modèles et Remix | Crée des enregistrements app depuis manifestes ou lignée source éligible ; ne déploie pas ni ne crée automatiquement les services déclarés. |
| Walker autonome | Découverte UI bornée avec limites importantes de couverture, autorisation et effets de bord. |
| Diffs Walker | Compare des walks stockés et exporte des charges type ticket ; ne dépose pas de tickets externes à lui seul. |
| Walk and Fix | Crée une intention de correctif ; l’ancien patching VM live entre en conflit avec le modèle de déploiement immuable. |
Ne chaînez pas un adaptateur stub dans un workflow de production parce que son API a renvoyé success.
Scénarios d’image
Les tests d’image ne tournent que lorsque le build/scénario sélectionné les active et que l’infrastructure de test requise est disponible. Gardez ces états séparés :
- construction d’artefact ;
- provisionnement et boot invité ;
- exécution d’assertions ;
- finalisation des preuves ; et
- politique de certification ou publication.
Un build peut réussir tandis que les tests sont désactivés, en attente, en échec ou incomplets.
Conception de tests
Tests intégrés
Des noms intégrés comme boot, login, packages, network et services fournissent une baseline. Inspectez Tests par défaut pour leurs limites précises.
Assertions personnalisées
Utilisez Assertions personnalisées pour observations service, port, HTTP, fichier, commande, processus et GUI supportées. Chaque assertion devrait inclure description, résultat attendu, cible, délai et signification de l’échec.
Benchmarks
Les catalogues benchmark sont des ensembles de vérifications structurés, pas des déterminations de conformité. Faites correspondre l’OS/version exact, conservez applicabilité et échecs, et lisez Preuves benchmark CIS.
Liste de preuves
Pour une exécution porteuse de décision, conservez :
- ID recette, source, build, artefact, VM, scénario et run ;
- digests exacts d’artefact et source ;
- environnement de test et version du runner ;
- chaque résultat d’assertion et sortie brute ;
- captures d’écran seulement lorsque justifiées et traitées en sécurité ;
- vérifications manquantes, ignorées ou non applicables ;
- horodatages et statut terminal ; et
- disposition du relecteur et approbation pour la décision énoncée.
Lorsqu’un test échoue, diagnostiquez la couche en échec avant de rebuilder. Un build en double peut masquer un défaut de propriété, déploiement, runner de test ou finalisation de preuves plutôt que le corriger.