Aller au contenu

Projet indépendant de R&D · Cologne

Vérification

Ce que chaque type de test peut démontrer, et ce qu'aucun test n'établit.

Non normatif

Version du Companion
1.0
Se rapporte à COADF Core
2.2
Statut
À jour
Dernière relecture

Ce que chaque type de test peut prouver

Une propriété se vérifie au niveau qui peut la voir. Un test unitaire ne peut pas voir un déploiement ; un test d'admission ne peut pas voir la réponse d'un modèle. Le tableau indique, pour chaque niveau, ce qu'il prouve, ce qu'il ne peut pas prouver et où le Companion l'utilise.

Niveaux de vérification : ce que chacun prouve, ce que chacun ne peut pas prouver et où le Companion l'utilise
NiveauProuveNe peut pas prouverUtilisé pour
Test unitaireUn composant refuse ce qu'il doit refuserQue le composant se trouve sur le cheminSchémas de frontière, fabriques de vérification, règles de politique
Test d'architectureLe graphe de dépendances ne contient aucune arête interditeLes chemins de données qui ne sont pas des importsFrontière probabiliste, isolation des normes
Test de contratDeux côtés s'accordent sur une forme, provenance requise compriseQue les deux côtés soient déployés dans des versions compatiblesContrats de proposition et de décision
Test d'intégrationLa propriété tient face à la dépendance réelleLe comportement sous une autre configurationPrivilèges de la piste d'audit, propagation du contexte, révisions de politique
Test de bout en boutUn état interdit ne peut pas atteindre une sortieLes chemins que le test n'exerce pasValeurs non vérifiées, le fence de publication
Test de déploiement ou d'admissionLa plateforme refuse une charge de travail qui enfreint une règleTout ce qui se trouve à l'intérieur de la charge de travailImages épinglées, révisions nommées, isolation réseau
Preuve manuelleUne personne nommée a exécuté une procédure écriteQu'elle sera exécutée de nouveauRevues de licences, rejeux de décisions historiques

Dans les deux sens : le chemin positif et la preuve de dents

Chaque propriété du Companion a un contrôle positif (voici à quoi ressemble une réussite) et un contrôle négatif (ce défaut, une fois planté, est refusé). Une suite qui n'a que la moitié positive peut perdre toutes ses contraintes et rester au vert. C'est la moitié négative qui montre que le contrôle se trouve sur le chemin.

Les cinq étapes d'une preuve de dents figurent sur la page Fences exécutables, et le profil Python et FastAPI les exécute : un import planté rompt un contrat, une contrainte supprimée fait passer un test au rouge, une sentinelle plantée fait échouer le fence de publication, et chaque restauration est comparée octet par octet.

Compter ce qui a été exécuté

Un résultat n'est pas « vert ». Un résultat, c'est : quels contrôles ont été exécutés, combien d'assertions ont tourné, dans quelle exécution identifiée, avec quelle issue. Le modèle de rapport de contrôles de COADF dit la même chose des contrôles : un contrôle ignoré, une réussite antérieure ou une sélection qui n'a exécuté aucun test ne constitue pas une vérification actuelle.

  • Une sélection de tests qui ne correspond à rien peut réussir. Vérifier le nombre de tests par une assertion.
  • Un test ignoré faute de base de données n'est pas un test réussi. Le signaler comme non exécuté.
  • Un job ignoré peut être signalé comme réussi. Exiger le contrôle qui ne peut pas être ignoré.

Quand le contrôle est une personne

Certains contrôles sont tenus par une personne qui exécute une procédure écrite : une revue de licence, le rejeu d'un échantillon de décisions historiques, une décision au moment de la fusion. Les signaler comme manuels, avec le nom de la personne et la procédure, jamais comme automatisés. Un contrôle manuel signalé honnêtement vaut plus qu'un contrôle automatisé signalé approximativement.

Ce que la vérification n'établit pas

Les tests établissent que des tests ont réussi. Ils n'établissent ni la conformité réglementaire, ni une certification, ni une évaluation de la conformité, et une suite complète pour chaque propriété de ce Companion n'établit rien de tout cela non plus. Les gardes automatisées sur le texte et le code sont nécessaires et non suffisantes : elles ne peuvent pas voir un mécanisme exprimé par le flot de contrôle, par des identifiants renommés ou par la géométrie d'un schéma, et la revue humaine reste une partie de la vérification.

COADF Engineering Companion 1.0 · non normatif · se rapporte à COADF Core 2.2

Droits de publication réservés. Aucune licence publique n'est accordée à ce jour pour le COADF Engineering Companion 1.0 ni pour ses exemples de référence.

Statut de propriété intellectuelle et de publication