Questo test è instabile, o è un vero bug?

Un test instabile fallisce e poi viene superato al tentativo successivo senza che nessuno corregga nulla, mentre un vero bug causa un fallimento per un motivo che nessun nuovo tentativo cambia. Nexus Studio, di Verdict System LLC, li distingue registrando ogni nuovo tentativo: FLAKY per un fallimento seguito da un tentativo riuscito, BREACHED per un problema reale e BREACHED_FLAKY per un fallimento che è esso stesso incostante. Un nuovo tentativo non trasforma mai un difetto in un'esecuzione con esito positivo.

A cura del gruppo di lavoro di Nexus Studio, Verdict System LLC. 7 ottobre 2026.

Che cos'è un test instabile?

Un test instabile è un test i cui tentativi hanno esiti discordanti: fallisce una volta e viene superato in un altro tentativo, senza modifiche al codice o al test. In Nexus Studio il termine ha un solo significato. FLAKY indica un test che è fallito, poi è stato superato a un nuovo tentativo, senza alcuna riparazione automatica. Qualcosa è instabile, nell'applicazione o nel test, e nulla è stato corretto.

Un fallimento sistematico che si verifica a ogni tentativo non è instabile, nemmeno quando la fase di riparazione automatica ha provato senza successo a riparare un selettore. Una versione precedente del motore classificava questo caso come FLAKY. I team interpretano FLAKY come "il test è difettoso" e passano oltre, così un'applicazione malfunzionante veniva rilasciata perché il problema era scambiato per rumore di fondo. Il motore non lo fa più.

I nuovi tentativi nascondono i veri bug?

Possono farlo, e il motivo è il numero di stati. Con i soli esiti positivo e negativo, un nuovo tentativo riuscito trasforma un'esecuzione rossa in verde, e un difetto intermittente dell'applicazione diventa invisibile. È uno dei tipi di bug più costosi da individuare. Quando il rosso può anche indicare una breve interruzione di rete o un browser bloccato, il team impara a rieseguire i test rossi anziché analizzarli, e la suite perde credibilità.

Nexus Studio mantiene visibile il nuovo tentativo. Un test che è fallito e poi è stato superato non è SECURE. Restituisce il codice di uscita 0 in CI, quindi non interrompe la compilazione, ma compare nel rapporto e nella Cronologia come FLAKY, un esito positivo con riserva. Consulta come vengono determinati i 14 verdetti per l'ordine completo delle verifiche.

Qual è la differenza tra FLAKY, BREACHED e BREACHED_FLAKY?

• FLAKY: il test è fallito, poi è stato superato a un nuovo tentativo, e nulla è stato riparato. Leggi il file raw-data.json del tentativo fallito, poi l'andamento nella Cronologia. Restituisce il codice di uscita 0.
• BREACHED: il test è fallito in un unico tentativo, e nessuna condizione riconducibile all'ambiente o all'infrastruttura di test spiega l'errore. Un'asserzione non è stata soddisfatta. Questa è la segnalazione del bug, e restituisce il codice di uscita 1.
• BREACHED_FLAKY: il test è fallito all'ultimo tentativo dopo un precedente nuovo tentativo, e nessuna condizione riconducibile all'ambiente o all'infrastruttura di test lo spiega. Il fallimento stesso è incostante. Confronta i tentativi prima di segnalare un bug. Restituisce il codice di uscita 1.

Due stati affini mantengono fedele il quadro. AUTO_RECOVER è un esito positivo in cui la riparazione automatica ha sostituito un selettore, quindi il localizzatore dell'autore non funziona più e il test non è privo di problemi. Un primo tentativo fallito solo per il superamento del tempo limite e poi superato a un nuovo tentativo è SECURE, perché indica latenza, non instabilità.

Prima che un fallimento possa essere BREACHED o BREACHED_FLAKY, il classificatore esclude le altre spiegazioni in un ordine fisso: un errore dell'infrastruttura di test, un arresto anomalo, un blocco, un host irraggiungibile e un timeout. Solo un fallimento che nessuna di queste cause spiega costituisce un problema rilevato. Ecco perché un timeout o un CAPTCHA non vengono segnalati come bug.

Come vengono conteggiati i nuovi tentativi?

Il motore legge il numero del tentativo dell'esecuzione. Un test superato con un numero di nuovi tentativi maggiore di zero è FLAKY, a meno che un selettore non sia stato riparato automaticamente, nel qual caso è AUTO_RECOVER. Un test fallito o scaduto per timeout con un numero di nuovi tentativi maggiore di zero, senza spiegazioni legate all'ambiente, è BREACHED_FLAKY. Un esito positivo senza problemi richiede zero nuovi tentativi e nessun selettore riparato automaticamente.

FLAKY significa che i tentativi hanno avuto esiti discordanti, e nient'altro. Un fallimento in un unico tentativo, senza nuovi tentativi, non viene mai etichettato come instabile. Ogni riga della Cronologia registra anche retry_attempt e attempts, così il conteggio resta associato all'esecuzione.

Quali prove lascia ciascun verdetto?

• FLAKY: screenshot.png, metadata.json e raw-data.json. La cartella conserva il file raw-data.json del tentativo fallito, quindi un nuovo tentativo che ha nascosto il fallimento ne lascia comunque il registro. Questo comportamento segue l'impostazione Conserva le prove di un esito positivo FLAKY / AUTO_RECOVER, attiva per impostazione predefinita.
• BREACHED_FLAKY: report.md, metadata.json, raw-data.json e screenshot.png, e il video del fallimento viene conservato per impostazione predefinita.
• BREACHED: gli stessi file, con il video conservato per impostazione predefinita.

Il verdetto è nel nome della cartella delle prove, per esempio un nome che termina con [BREACHED]. La pagina Prove segue un test fallito attraverso ciascun file.

Come fa la Cronologia a individuare un test che cambia esito?

La cronologia conserva una riga per ogni esecuzione di ciascun test e browser o dispositivo, con il verdetto, il tentativo di riesecuzione e la firma dell'errore. Da queste righe ricava le tendenze per sessione, giorno o settimana: Peggiorato, Ripristinato, Ancora non funzionante e Più lento. Un test che passa dal verde al rosso e poi di nuovo al verde compare lì, anziché perdersi nelle riesecuzioni.

La classifica del rischio, in Evidence Locker e in Patrol, ordina i test in base alla frequenza con cui cambiano esito, falliscono o fanno perdere tempo. Mostra anche una previsione del rischio basata su una regressione logistica dei dati storici, ricorrendo a una EWMA quando i dati sono scarsi. Nessun test viene definito instabile prima di cinque esecuzioni, perché una o due non bastano a individuare uno schema.

Limiti

• I tentativi successivi distinguono FLAKY da SECURE e BREACHED_FLAKY da BREACHED. Se i tentativi successivi sono disattivati, un errore intermittente viene classificato come BREACHED.
• FLAKY indica che i tentativi hanno dato esiti discordanti. Non ne spiega il motivo. Individuare la causa nell'applicazione o nel test resta un compito umano.
• La classificazione legge il testo dell'errore, quindi un messaggio di asserzione personalizzato che contiene parole come 403 o Forbidden può essere interpretato come un problema dell'ambiente. Apri metadata.json quando un verdetto ti sorprende.
• Prima di cinque esecuzioni, la cronologia e la classifica del rischio non definiscono instabile alcun test.

Come proseguire

La pagina delle evidenze mostra tutti i file lasciati da un test fallito, mentre Come Nexus Studio determina i 14 verdetti dei test spiega l'ordine dei controlli. La prova di 30 giorni esegue lo stesso motore sui tuoi test.

Per eseguire prima la verifica sul tuo computer, Come distinguere un vero bug da un test instabile? contiene un esempio eseguibile.