Test¶
Qu’est-ce qu’une preuve suffisante de fonctionnement ?
Une réponse HTTP acceptée indique le début d’une opération, pas sa réussite. Il faut observer son état terminal, lire le livrable, contrôler les contraintes et vérifier la dépense réellement enregistrée.
Du besoin à la preuve¶
flowchart TB
B[Brief et attendus écrits] --> E[Une tentative identifiée]
E --> O[Observation jusqu’au résultat]
O --> L[Lecture métier et registre]
L --> D[Verdict avec portée explicite]Niveaux complémentaires¶
| Niveau | Ce qu’il vérifie | Ce qu’il ne prouve pas seul |
|---|---|---|
| Tests hors réseau | Contrats, permissions, comptes, reprises, états | Disponibilité réelle des fournisseurs |
| Construction des images | Sources incluses, dépendances, chemins | Parcours utilisateur complet |
| Vérification de pile | Santé, lien, persistance, sauvegarde/restauration | Qualité créative ou cognition sans clé |
| Parcours réel | Contenu et coût sur un cas identifié | Réussite générale sur tout un métier |
| Vue navigateur | Lisibilité, focus, action et contenu effectivement accessibles | Performance statistique |
Résultats connus et limites¶
La cohorte exploratoire de douze cas couvre quatre métiers et trois niveaux de complexité. Cinq cas étaient conformes au premier passage. Après reprises et corrections, dix ont un résultat conforme ; deux restent en échec, fabrication invalide et production trop longue. Ces nombres ne constituent pas une estimation statistique de fiabilité. Les récupérations, dont certaines hors protocole temporel initial, ne sont jamais rebaptisées réussites du premier passage.
Les textes seuls et un parcours mixte avec image ont été exercés en réel. La qualification média reste incomplète pour l’audio et la vidéo. Certaines suites historiques conservent des défauts de test ou d’environnement ; ne pas annoncer une suite globale verte à partir d’un sous-ensemble.
Protocole et critères¶
Fixer les attendus avant exécution, garder tous les cas au bilan et séparer : réussite initiale, échec technique, contenu non conforme, récupération et cas non tenté. Une contrainte chiffrée se compte réellement ; la présence d’un mot interdit dans une négation n’est pas automatiquement un échec.
Pour une migration, prendre deux instantanés distincts avant toute nouvelle opération. Comparer les identifiants, les phases et les registres ; un volume vivant peut changer sans perte de données.
Livrables¶
Un plan de test exécutable, des résultats attribués à leurs cas, les limites et les preuves directes. Pour le portail : construction stricte, treize routes, desktop/mobile, liens, recherche, agrandissement et inspection visuelle. Aucun appel métier n’est nécessaire à cette vérification documentaire.