Vos tests restent en Playwright, Selenium et pytest. Nous ne les remplaçons pas. Nous les adaptons aux exigences de l'entreprise, et vous conservez l'entière propriété : code, preuves et historique.
Un test échoué. Tout ce qu'il a laissé sur votre disque.
Une vraie exécution, pas une maquette : TC92 le 2026-09-30, sans interface graphique, dans Chromium, Firefox et WebKit. Elle ouvre example.com, suit Learn more vers IANA et s'attend à ce que le titre indique Example Domain. La page affiche Example Domains. Voici les fichiers de l'exécution Chromium, leurs tailles réelles et ce que contient chacun.
dans le dossier de l'exécution, plus une ligne dans l'historique
531.2 kB
le dossier entier, vidéo incluse
32 champs
dans metadata.json, pour les machines
9 sections
dans report.md, le rapport forensique
Ce qu'un seul échec laisse derrière lui
Que conserve l'Evidence Locker lorsqu'un test échoue ?
Un test en échec archive un dossier contenant son rapport d'expertise médico-légale, ses métadonnées, le journal brut et une capture d'écran du cadre où il a échoué, ainsi que la vidéo pour un échec réel. La ligne 23 de TC92_Iana_heading.js s'attend à ce que le titre indique Example Domain. La page de l'IANA indique Example Domains : en 10000 ms, le localisateur a résolu 23 fois et a lu le pluriel à chaque fois. BREACHED, sur les trois moteurs. Voici le cadre sur lequel il a échoué, ainsi que chaque fichier qu'il a écrit.
https://www.iana.org/help/example-domains
screenshot.png · 89,8 ko · une capture d'écran de la zone d'affichage de l'image finale, 1280×720 : ce qu'un utilisateur aurait vu lors de l'exécution de la vérification
Dans l'Evidence Locker, le même enregistrement s'ouvre sur cinq onglets :
ReportMetadataTelemetryRaw LogAI Analysis
report.md5.3 kB
Le rapport forensique, en Markdown : il se lit sans le Studio.
Incident summary
Root cause analysis
Network telemetry
Failure timeline
Historical stability
Self-healing log
Evidence artifacts
Performance budget
Lazy-loading audit
Utilisez-le pour créer un ticket : le résumé de l'incident indique le test, le navigateur, la page et l'impact métier, et l'analyse de la cause racine indique la vérification en échec, le sélecteur, les valeurs attendues et reçues ainsi que la ligne source.
Utilisez-le pour filtrer les échecs avec un script plutôt qu'avec un analyseur Markdown. C'est également le fichier que la chaîne de traçabilité scelle : un dossier contenant un fichier metadata.json constitue un enregistrement.
raw-data.json5.1 kB
Le journal brut : chaque ligne de console, erreur réseau, problème de sécurité et erreur de page de l'exécution, ainsi que les échantillons de performance.
Utilisez-le pour voir ce que la page a fait au moment de l'échec. Une réussite FLAKY ou AUTO_RECOVER conserve le fichier raw-data.json de la tentative ayant échoué, de sorte qu'une nouvelle tentative ayant masqué l'échec laisse toujours son journal.
Telemetrymesuré
Mesuré à la fin du test, par rapport à vos budgets. La barre représente la mesure par rapport à son budget.
LCP992 / 2500 ms
FCP992 / 1800 ms
CLS0.0295 / 0.1
TTFB727 / 800 ms
TBT0 / 200 ms
DOM114 / 1500 nodes
Heap5 / 50 MB
INPnot measured
Tous dans les limites du budget, et le rapport signale que le TTFB en est proche. L'INP affiche non mesuré, jamais une réussite : rien n'a été cliqué ni saisi sur la page mesurée. L'audit de chargement différé a attribué à la page un score de 85 sur 100, note B : une image sans attributs width et height.
Utilisez-le pour distinguer une page lente d'une assertion erronée.
video.webm428.8 kB
0:08 sur 0:16
La session complète, 16,6 secondes : example.com, le clic sur Learn more, puis la page IANA pendant que la vérification effectuait une nouvelle tentative. Conservée car l'exécution était BREACHED, et elle est disponible dans l'Evidence Locker. Un vrai échec conserve sa vidéo : BREACHED, BREACHED_FLAKY et CHAOS_BREACHED par défaut, TIMEOUT et BLOCKED lorsque vous les activez dans les Paramètres. CRASHED et UNREACHABLE ne sont jamais proposés, car cet enregistrement ressort corrompu ou vide. Seules les exécutions Playwright web et mobile émulé enregistrent : un vrai téléphone Android, une exécution Selenium et un test API n'enregistrent pas.
Utilisez-le pour voir comment la page est parvenue à la vérification en échec, étape par étape ; la capture d'écran ci-dessus est la dernière image.
Analyse IAvotre IA
Activée par défaut, avec votre IA connectée. Avec un modèle Ollama local, le modèle par défaut, ou un autre fournisseur de votre choix, le moteur ajoute quatre rubriques au rapport : Diagnostic, Cause probable, Impact et Action recommandée. Lorsque votre propre outil en ligne de commande IA est activé dans le rédacteur IA, il lit report.md après l'exécution à la place, pour un maximum de cinq échecs par exécution, et ajoute une cinquième rubrique :
Diagnosis
Classification (outil en ligne de commande uniquement)
Probable cause
Impact
Recommended action
La classification est exactement l'une des suivantes : APP_BUG, APP_CHANGE, TEST_AUTHORSHIP, TEST_SETUP ou INFRA_FLAKY. Aucune IA connectée : pas d'analyse, et les cinq fichiers restent identiques.
trace.zip est un sixième fichier. Avec l'option Enregistrer une trace médico-légale en cas d'échec activée, ce qui est le cas par défaut, un dossier BREACHED archive également une trace Playwright (instantanés du DOM, captures d'écran et sources), que l'on ouvre avec npx playwright show-trace trace.zip. Elle n'est pas enregistrée sur un véritable téléphone Android. TC92 a été exécuté avant que le traçage ne devienne la valeur par défaut, son dossier contient donc les cinq fichiers ci-dessus.
Ce qu'un échec consigne
TC91 sur chromium, 2026-09-30 13:26 TIMEOUT
Le dossier réel de l'exécution rejouée dans la démo en haut de la page d'accueil, un test délibérément monté contre l'ancien texte de lien d'example.com, tel que l'Evidence Locker l'ouvre : bug-reports/chromium/TC91 - Example more info/2026-09-30_13-26 [TIMEOUT].
https://example.com/
screenshot.png · 12.6 kB · l'image exacte au moment de l'échec
report.md4.9 kBRésumé de l'incident, cause première, télémétrie réseau, chronologie de l'échec, stabilité historique, journal d'auto-guérison, artefacts de preuve, budget de performance et audit du lazy-loading.
metadata.json2.3 kB32 champs, parmi lesquels le sélecteur, le délai d'expiration de 30000ms, la stabilité CRITICAL, les échecs consécutifs, la tentative 2 sur 2, le mode furtif et le score de lazy-loading (100, A).
raw-data.json4.2 kBLe journal brut : lignes de console, erreurs réseau, problèmes de sécurité (ici 2 : CSP manquante), erreurs JS et métriques de performance.
Telemetrydans le rapportLCP 156 ms · FCP 156 ms · CLS 0.0018 · TTFB 122 ms · TBT 0 ms · 808 nœuds DOM · tas de 2 MB. INP non mesuré : rien à chronométrer.
video.webméchecs réelsEnregistré pour un échec réel. Un TIMEOUT comme celui-ci n'en conserve aucun, car TIMEOUT est désactivé par défaut, et le rapport l'indique.
Analyse IAvotre IALorsque votre IA est connectée, elle ajoute au rapport un diagnostic, la cause probable, l'impact et une action recommandée ; via votre propre outil d'IA en ligne de commande, elle classifie également l'échec.
Verdicts
Quels sont les 14 verdicts, et que devez-vous faire ensuite ?
Chacun des 14 verdicts désigne à qui revient le tour : personne, le test, l'application, l'environnement ou le banc d'essai. Le verdict figure dans le nom du dossier : celui de TC92 se termine par [BREACHED]. Le classificateur lit un échec dans un ordre fixe : le banc d'essai d'abord, puis un crash, un blocage, un hôte inaccessible et un délai d'expiration, et seulement ensuite BREACHED_FLAKY ou BREACHED. Un BREACHED est donc un échec qu'aucun modèle environnemental n'explique. Chaque carte indique à qui revient le tour et ce que ce verdict archive.
SECUREPersonne
Réussi de lui-même : aucune nouvelle tentative, aucun sélecteur réparé. Rien à faire. Classé dans evidence-passed-test, les 5 plus récents par test et navigateur.
screenshot.pngmetadata.json
CHAOS_RESILIENTPersonne
Réussi alors qu'une défaillance était injectée, l'application a donc tenu bon. Classé dans chaos-runs, séparément des rapports de bogues, afin que le chaos ne fausse jamais les chiffres de stabilité.
Vert, mais pas sans aide : l'auto-réparateur a remplacé un sélecteur défaillant. Le localisateur dans le test est mort, et la prochaine modification du DOM cassera réellement la suite. Corrigez le localisateur. raw-data.json apparaît lorsqu'une nouvelle tentative a été nécessaire, et il s'agit de celui de la tentative ayant échoué.
screenshot.pngmetadata.jsonraw-data.json
FLAKYTest ou application
Échec, puis une nouvelle tentative l'a validé, et rien n'a été réparé. Il s'agit d'une instabilité inexpliquée dans l'application ou le test, et non d'un correctif. Consultez le raw-data.json de la tentative ayant échoué, puis la tendance de l'historique.
screenshot.pngmetadata.jsonraw-data.json
PERFORMANCE_DEGRADEDApp
Les assertions ont réussi et la page était trop lente : un budget Web Vitals ou de lazy-loading a été dépassé. Consultatif jusqu'à ce que vous rendiez la vérification stricte.
screenshot.pngmetadata.json
A11Y_VIOLATIONApp
Les assertions ont réussi, mais pas l'accessibilité. metadata.json répertorie chaque règle axe-core déclenchée, avec son impact et le nombre de nœuds. Informatif jusqu'à ce que vous rendiez la vérification stricte.
screenshot.pngmetadata.json
SECURITY_VIOLATIONApp
Les assertions ont réussi, mais pas les en-têtes de sécurité (une CSP manquante, par exemple). Corrigez les en-têtes de réponse. Informatif jusqu'à ce que vous rendiez la vérification stricte.
screenshot.pngmetadata.json
BREACHEDApp
Une assertion a échoué et aucun modèle d'environnement ou de harnais n'explique l'erreur. Lisez Attendu et Reçu dans report.md, regardez la vidéo, puis marquez-le comme Véritable bogue ou Fausse alerte, avec un motif.
Échec lors de la dernière tentative après un nouvel essai préalable : l'échec lui-même est incohérent. Comparez les tentatives avant de signaler un bogue. Sa vidéo est conservée par défaut.
S'est interrompu lors d'une injection de faute. Une observation de résilience, conservée à part des rapports de bogues fonctionnels ; le rapport consigne la faute appliquée et l'impact sur l'utilisateur. La rétention ne supprime jamais une exécution interrompue. Sa vidéo est conservée par défaut.
N'a jamais répondu à temps, ce qui ne prouve pas que l'application est défaillante. Vérifiez la rapidité de la page dans Telemetry avant de modifier un paramètre : une limite plus longue ne masque pas un élément défectueux, elle échoue plus tard. Sa vidéo est désactivée par défaut ; activez-la dans Paramètres, sous Conserver la vidéo d'échec pour.
L'hôte n'a pas pu être joint du tout : le DNS ou la connexion a échoué avant qu'aucune page n'ait pu être observée. Vérifiez l'URL, le réseau et la disponibilité de la cible. Il ne s'agit pas d'une observation concernant l'application. Aucune page ne s'est chargée, sa vidéo serait donc vide et aucune n'est proposée.
Le site s'est défendu : une erreur 403, 429, une page de blocage ou un challenge anti-bot. metadata.json nomme la défense lorsqu'elle était présente à l'écran. Il ne s'agit pas d'une observation concernant l'application, et Jira ne signale jamais de blocage. Sa vidéo est désactivée par défaut ; activez-la dans Paramètres, sous Conserver la vidéo d'échec pour.
Le navigateur ou le processus s'est arrêté inopinément : une page fermée, une erreur de protocole DevTools, une session WebDriver inactive. Cela concerne l'infrastructure, pas l'application. Examinez la machine et le pilote. L'enregistrement d'un navigateur arrêté inopinément est corrompu, aucun n'est donc proposé.
Non inclus parmi les 14 : CONFIG_ERROR (le harnais n'a pas pu lancer le test : un import corrompu, une valeur .env manquante), SKIPPED et INTERRUPTED. Aucun n'est un résultat concernant votre application, aucun ne génère donc de dossier de preuves ou de ligne d'historique. Une CONFIG_ERROR est tout de même enregistrée dans son intégralité, avec un conseil, dans un journal sous .run-cache/config-errors/, afin que le test défaillant puisse être corrigé. Les tests d'API disposent de sept verdicts qui leur sont propres : Tests d'API.
History
Qu'enregistre l'historique pour chaque exécution ?
À côté du dossier, chaque exécution ajoute une ligne à history/<browser>/<test>/runs.json : les 50 dernières exécutions de chaque test sur chaque navigateur, par défaut. Voici les trois lignes de TC92, une par navigateur, telles qu'écrites. Le même error_signature sur les trois indique qu'il s'agit d'une seule erreur, et non de trois.
Une valeur que le navigateur ne peut pas mesurer est écrite comme null, jamais comme zéro : WebKit ne rapporte aucun TTFB ici. Les horodatages des lignes sont en UTC, tels qu'ils sont écrits ; les noms de dossiers utilisent l'heure locale de la machine, UTC−5 sur celle-ci.
perf contient LCP, FCP, CLS, TTFB, TBT, INP, les longues tâches, la taille du DOM, le tas mémoire, chaque page visitée et le score de chargement différé. raw_log_ref et evidence_ref pointent vers le dossier ci-dessus.
Ce que le moteur en affiche
TC92 chromium BREACHED 13.7s
expect(locator).toHaveText(expected) failed
at TC92_Iana_heading.js:23 waiting for getByRole('heading', { level: 1 })
stability CRITICAL 0% · 0/1 runs · 1 failed in a row
# TC91, la démonstration en scène sur la page d'accueil : un BREACHED, puis un TIMEOUT
stability CRITICAL 0% · 0/2 runs · 2 failed in a row
La durée de la ligne, 12291 ms, correspond au test lui-même, tel que Playwright l'a mesuré, lors du second de ses deux essais.
Les mêmes lignes alimentent la section Stabilité historique du rapport, les tendances de l'écran Historique (Regressed, Recovered, Still broken, Slower) ainsi que le classement par risque, où rien n'est qualifié d'instable en dessous de cinq exécutions.
Combien de preuves Nexus Studio conserve-t-il, et pendant combien de temps ?
Un succès conserve une capture d'écran et ses métadonnées, un échec conserve tout ce qui est nécessaire pour le reproduire, et les fichiers les plus anciens disparaissent en premier. Une suite qui s'exécute chaque nuit remplit un disque. Le moteur plafonne chaque dossier qu'il écrit, par test et par navigateur, et conserve toutes les preuves ensemble selon un budget unique, 20 GB par défaut, tandis que le disque conserve 10 GB d'espace libre, de sorte que le disque cesse de croître à la taille que vous choisissez. Un échec conserve toujours ce qu'il faut pour le reproduire : l'erreur avec son sélecteur et ses valeurs, l'URL de la page, le cadre, les lignes de la console, du réseau et des erreurs de page, le runtime et la plateforme, ainsi que le contexte de l'exécution, les éléments par rapport auxquels elle a été mesurée. Les plafonds et le budget sont définis dans les Paramètres, sous Evidence & Retention.
Le dossier complet ci-dessus : 531,2 ko pour TC92 sur Chromium, dont 428,8 ko pour la vidéo. trace.zip s'ajoute par-dessus lorsque le traçage est activé.
Les mêmes fichiers sans l'enregistrement, car TIMEOUT est désactivé par défaut pour la vidéo : 23,9 ko pour le TIMEOUT de TC91, la démonstration en scène sur la page d'accueil.
Un succès
screenshot.pngmetadata.json
Classées séparément des rapports de bugs, les 5 plus récentes par test et navigateur. La capture d’écran sert de référence pour la régression visuelle. Un succès FLAKY ou AUTO_RECOVER conserve également son dossier, avec le fichier raw-data.json de la tentative échouée, tant que l'option Conserver les preuves d'un succès FLAKY / AUTO_RECOVER est activée.
Paramètres · Preuves & Conservation · valeurs par défaut
Bug reports kept per test20NEXUS_BUGREPORT_RETAIN
Passing screenshots kept5NEXUS_PASSED_RETAIN
Keep evidence of a FLAKY / AUTO_RECOVER passonNEXUS_RECOVERED_RETAIN
Raw run history window50 runsNEXUS_HISTORY_RETAIN
Smart Monkey sessions kept10NEXUS_MONKEY_RETAIN
Run contexts kept (what each run tested against)100NEXUS_RUN_CONTEXT_RETAIN
Record failure videoonNEXUS_VIDEO_ENABLED
Keep failure video for3 verdictsNEXUS_VIDEO_VERDICTS=BREACHED,BREACHED_FLAKY,CHAOS_BREACHED
Record a forensic trace on failureonNEXUS_TRACE_ENABLED
Ces trois lignes ont suivi l’exécution de TC92. Les fichiers temporaires de télémétrie de l'exécution ne constituent jamais des preuves : ils sont placés dans un zip, les copies isolées sont supprimées, et au maximum 2 zips de 7 jours au plus sont conservés, dans la limite de 500 MB. Ces trois limites correspondent à NEXUS_CACHE_ZIPS, NEXUS_CACHE_RETENTION_DAYS et NEXUS_CACHE_MAX_MB dans .env, et non à des champs dans Paramètres.
Dans Paramètres, Vider le cache supprime les dossiers test-results et playwright-report de l'espace de travail et ferme tout navigateur laissé ouvert par une exécution interrompue ou arrêtée de force. Cette action est refusée lorsqu'une patrouille est en cours.
Espace de travail · Disque · la limite actuelle de chaque dossier
area limit today
Bug reports newest 20 runs per test and browser
Passed tests newest 5 runs per test and browser
API evidence newest 20 passing runs per test; failures kept
Chaos runs newest 20 held runs; runs that broke kept
Smart Monkey newest 10 sessions
Visual regressions newest 10 per test and checkpoint
Run context newest 100 runs
Run history newest 50 runs per test and browser
Chain of custody append-only, never trimmed
Archive no automatic limit
Le panneau Disque répertorie chaque dossier dans lequel une exécution écrit, du plus volumineux au plus petit, avec sa taille, son nombre de fichiers et sa date la plus ancienne, ainsi que l'espace total et disponible sur le disque. Tout dossier sans limite automatique est signalé. L'option Nettoyer n'est proposée que là où cela ne présente aucun risque : le cache d'exécution, les versions de fichiers de test de plus de 14 jours et les rapports Exécutifs de plus de 30 jours. Elle ne touche jamais aux preuves ni à l'archive.
En plus des limites, toutes les preuves partagent un budget unique, 20 Go par défaut, et le disque conserve 10 Go d'espace libre. Après chaque exécution, le moteur vérifie les deux conditions et, si l'une d'elles est dépassée, supprime les exécutions les plus anciennes, les réussites avant les échecs, jusqu'à ce que les deux soient respectées ; l'exécution la plus récente de chaque test et navigateur est toujours conservée. Le panneau affiche les preuves par rapport au budget, l'espace libre par rapport au seuil minimal et ce que le dernier passage a libéré, avec Exécuter la maintenance maintenant.
Evidence Locker · conservez ce qui compte, libérez le reste
Archiver… copie exactement les éléments que vous cochez (Capture d'écran et Rapport cochés par défaut) dans Affichage → Archive. La copie se trouve à côté du dossier de preuves, et non à l'intérieur, afin qu'aucun balayage de rétention ne l'affecte, et l'exécution dans le Locker reste intacte.
Restaurer, sur l'écran Archive, replace un enregistrement là où il se trouvait et le réintègre dans le décompte. Si son dossier a été libéré, les éléments archivés sont réécrits dans l'Evidence Locker. Un verdict de Fausse alerte le maintient toutefois hors du décompte.
Libérer de l'espace envoie un dossier à la corbeille. Lorsque l'enregistrement est scellé, le moteur enregistre d'abord la disposition, afin que nexus verify indique PURGED et non TAMPERED. La rétention procède de même lorsqu'elle supprime le dossier le plus ancien, et le registre continue de prouver le hachage du dossier, qui l'a supprimé et à quel moment. Le scellement est optionnel : jusqu'au premier verdict de Vrai bug ou Fausse alerte, ou nexus verify --seal, le Locker affiche UNVERIFIED.
Observez ce que vos propres échecs laissent derrière eux.
Gratuit pendant 30 jours, avec toutes les fonctionnalités, sur vos machines. Aucune carte requise.
Nexus Studio
