Test instabili e falsi positivi: perché i test falliscono senza motivo

Una build rossa dovrebbe voler dire una sola cosa: l'applicazione è rotta.Troppo spesso vuol dire altro: un test ha cliccato troppo presto, un carattere è stato disegnato con una sfumatura diversa, un indicatore di caricamento girava ancora.Sono i test instabili e i falsi positivi, e sono uno dei motivi principali per cui i team smettono di fidarsi dei propri test end-to-end.

Questa guida spiega da dove vengono nei test scritti in codice e in quelli visivi, e come fermare i falsi positivi senza lasciar passare i bug veri.

Cosa sono i test instabili (flaky) e i falsi positivi?

Un falso positivo è un test che fallisce mentre l'applicazione funziona come deve.I tester lo chiamano anche falso fallimento o falso allarme.Il test dà l'allarme, qualcuno indaga, e non c'è niente che non va.

Un test instabile (flaky) è un test che passa e fallisce con lo stesso codice, senza che nulla cambi tra un'esecuzione e l'altra.Ogni fallimento instabile è un falso positivo.Non ogni falso positivo è instabile, però: un test che fallisce ogni volta perché la sua immagine attesa è superata è sbagliato, non instabile.

L'errore opposto è il falso negativo: un test che passa mentre un bug vero è sullo schermo.È il più pericoloso dei due, perché nessuno guarda due volte un test verde.

Quanto costano i falsi positivi a un team

Un falso allarme costa un'indagine.Qualcuno apre i log, rilancia il test e non trova niente.

Il costo vero arriva dopo.Quando la maggior parte delle build rosse è rumore, nessuno le legge più: è l'affaticamento da allerta.Poi arrivano le abitudini che nascondono i bug: rilanciare un test finché diventa verde, accettare ogni nuovo screenshot come baseline senza guardarlo, disattivare il test che fallisce sempre.

Ognuna di queste abitudini trasforma il falso positivo di oggi nel falso negativo di domani.Il bug per cui il test era stato scritto passa, perché nessuno crede più al test.

Cosa rende instabili i test end-to-end?

I test end-to-end guidano un'intera applicazione attraverso la sua interfaccia, quindi incontrano tutto ciò che incontra un utente vero: server lenti, animazioni, altre finestre.I test scritti in codice aggiungono cause proprie.

Le tempistiche vengono prima per un motivo.La documentazione stessa di Selenium chiama la corsa tra il test e il browser una delle cause principali dei test instabili.

Perché i test di regressione visiva producono falsi positivi

Il test di regressione visiva confronta un'immagine dell'applicazione con un'immagine di baseline approvata.Coglie ciò che le asserzioni scritte in codice non vedono: un colore sbagliato, un'etichetta che ne copre un'altra, un'icona mancante.Vede anche differenze che nessuno chiamerebbe un cambiamento.

Un confronto rigido, pixel per pixel, fallisce su ognuno di questi casi.Uno largo lascia passare bug veri.L'arte del test visivo è distinguere le due cose.

Come i team correggono oggi i test instabili

Nei test scritti in codice

Playwright attende prima di ogni azione che l'elemento sia visibile, stabile, abilitato e non coperto da un altro elemento, e altrimenti fallisce allo scadere del tempo massimo.

Cypress ripete le sue query e le sue asserzioni finché passano, per un massimo di 4 secondi per impostazione predefinita.Può anche ripetere un intero test fallito, cosa disattivata per impostazione predefinita.

Selenium offre attese esplicite che interrogano l'applicazione finché una condizione è soddisfatta, e la sua documentazione sconsiglia di mescolarle con le attese implicite.

I tentativi ripetuti servono anche a individuare l'instabilità.Playwright segnala come flaky un test che è fallito e poi è passato a un nuovo tentativo, e Cypress Cloud contrassegna un test simile con un badge Flaky.Un nuovo tentativo rende verde la build, ma non elimina la causa.

Nei test visivi

In Playwright, toHaveScreenshot accetta una soglia di colore per pixel, 0.2 per impostazione predefinita, e un maxDiffPixels assoluto oppure un maxDiffPixelRatio.Può mascherare le aree dinamiche, e per impostazione predefinita ferma le animazioni e nasconde il cursore di testo.

BackstopJS ammette una percentuale di pixel diversi, 0.1 per impostazione predefinita, e può nascondere o rimuovere gli elementi che indicate prima di acquisire le sue immagini.

Chromatic ignora per impostazione predefinita i pixel smussati, e il suo diffThreshold, 0.063 per impostazione predefinita, stabilisce quanto cambiamento tollera.

Argos stabilizza ogni screenshot per impostazione predefinita: attende i caratteri e le immagini, nasconde il cursore di testo e le barre di scorrimento, e segnala gli screenshot che cambiano da un'esecuzione all'altra.

Percy congela le animazioni e gli altri elementi dinamici, e i cambiamenti si approvano per build, per gruppo o uno snapshot alla volta.Il suo Visual Review Agent evidenzia i cambiamenti che ritiene significativi.

Applitools Eyes confronta con livelli di corrispondenza.Strict mira a ignorare ciò che l'occhio umano non vedrebbe, Layout controlla solo la disposizione, e Dynamic accetta qualsiasi data, indirizzo email o URL validi.

Ognuna di queste soluzioni aiuta.Ognuna vi chiede anche di scegliere un numero, una maschera o un livello, test per test, e di rivedere a mano le nuove immagini.Per vedere questi strumenti fianco a fianco, leggete lo studio comparativo.

Perché una tolleranza più ampia non è la risposta

Una tolleranza è una promessa: tanta differenza è rumore.La domanda è in che cosa si misura quel tanto.

Un rapporto cresce con l'immagine.Su uno schermo intero di 1920 × 1080 pixel, lo 0.1% è circa 2000 pixel, più di una parola cambiata.Su un pulsante di 100 × 40 pixel, sono 4 pixel, meno di un solo bordo disegnato in modo diverso.

Un conteggio assoluto non cresce con l'immagine, ma somma il rumore sparso su tutta l'immagine come se fosse un solo cambiamento.Una maschera nasconde il rumore, e nasconde anche qualsiasi bug dentro la maschera.

Come GUI Test Studio ferma i falsi positivi senza lasciar passare i bug

GUI Test Studio è una suite di automazione dei test end-to-end per applicazioni web, applicazioni desktop Windows, Android e giochi.Registrate un test una volta, o lo descrivete in un prompt, lo modificate su una timeline e lo eseguite a ogni build.I suoi controlli seguono una regola: un test fallisce quando una persona vedrebbe un problema, e solo allora.

Gli elementi vengono trovati in due modi, senza selettori che si rompono

Il GTS Engine + AI chiede prima all'applicazione dove si trova un elemento, attraverso le sue informazioni di accessibilità in Windows, o gli elementi della pagina stessa in un browser.Quando l'applicazione non lo dice, trova l'elemento a vista, sullo schermo.Non c'è nessun localizzatore da scrivere, quindi una classe rinominata o un nuovo framework non rompono un test.Vedete come GUI Test Studio trova ogni elemento.

I controlli attendono lo schermo, mai un timer

Ogni controllo continua a cercare finché ciò che si aspetta è sullo schermo, entro il suo tempo massimo di 5 secondi per impostazione predefinita, e il test prosegue nel momento in cui c'è.Un'asserzione visiva di assenza attende che un indicatore di caricamento scompaia, così una pagina lenta viene attesa, non indovinata.

Quando un'asserzione visiva o un'asserzione testuale non ha trovato il suo elemento nella sua area di ricerca dopo un secondo, cerca anche in tutto lo schermo, così una finestra spostata non fa fallire il test.Prima che un'esecuzione inizi, GUI Test Runner-Recorder confronta il vostro schermo con il primo momento della registrazione e trattiene l'esecuzione quando l'applicazione è su un'altra pagina.Vedete le impostazioni di un controllo.

La Fase di verifica conta ciò che è cambiato, e dove

Una volta trovato l'elemento, la Fase di verifica lo confronta con ciò che vi aspettate.Conta i pixel cambiati chiaramente nella piccola area dell'elemento dove i cambiamenti si concentrano di più: un numero assoluto, mai una percentuale dell'immagine.

Il rumore è sparso: un bordo più morbido qui, una sfumatura più chiara là.Un cambiamento vero è concentrato in un punto: una lettera, una cifra, un'icona.Per questo la stessa regola funziona su una piccola icona come su un'intera finestra di dialogo.

Ogni controllo ha una Severità della verifica: Esatta, Rigorosa, Standard o Permissiva.Standard va bene per i pulsanti, le etichette e le icone di tutti i giorni, e Permissiva per le aree grandi e gli schermi affollati.Vedete le asserzioni visive.

Il momento giusto, con il puntatore dov'era

Un elemento viene spesso trovato mentre lo schermo si sta ancora assestando: un menu che compare in dissolvenza, una pagina ancora in caricamento.La passata di accuratezza avanzata guarda i fotogrammi che seguono la corrispondenza, tiene quello in cui l'elemento appare al meglio, e si ferma dove inizia il passaggio successivo del test.Vedete la passata di accuratezza avanzata.

In un test registrato, l'esecuzione riporta il puntatore del mouse dov'era quando l'immagine è stata acquisita.Un pulsante è quindi evidenziato nell'esecuzione esattamente quando lo era nella registrazione.

Un test che avete appena registrato, e non ancora modificato, riceve un aiuto in più.Quando un elemento non compare come è stato registrato, l'esecuzione adatta il test in modo intelligente per trovarlo, e non lo fa mai per nascondere una differenza vera.

Diversi di proposito: i profili di baseline

Alcune differenze sono vere e volute: la modalità scura, lo schermo di un portatile invece di un monitor 4K, un'altra versione di Windows, l'applicazione in un'altra lingua.Un profilo di baseline tiene una versione attesa di un controllo per ogni ambiente, così un solo test li serve tutti.Dove cercare, quanto attendere e quanto essere severi restano condivisi da tutte le versioni.Vedete i profili di baseline.

L'analisi intelligente con IA dà il verdetto finale

Quando un controllo trova pixel cambiati, l'analisi intelligente con IA può dare una seconda occhiata e decidere, con un modello nel cloud e la vostra chiave, o con un modello di IA locale sul vostro computer, uno nostro o uno vostro.È disattivata finché non la attivate.

Fa passare un controllo quando trova solo differenze minori che un utente potrebbe non notare, mentre una parola, un numero o un valore che cambiano, o un'icona o un badge mancanti, non sono mai minori e fanno fallire il controllo.Il report dice di quale caso si trattava.

Il puntatore del mouse e il cursore di testo lampeggiante non contano mai come differenza, mentre una lettera o un'icona cambiata conta sempre.Potete anche dare a un controllo delle istruzioni per l'IA con parole vostre, ad esempio: la data nell'angolo cambia ogni giorno.Vedete l'analisi intelligente con IA.

Ingrandisci

Un report che dice cosa è cambiato

Il Report di affidabilità mostra ogni asserzione visiva in due fasi.La Fase di ricerca risponde se l'elemento è stato trovato, e la Fase di verifica se appare come previsto.Pulsazione evidenzia sullo schermo ciò che è cambiato, e il verdetto lo dice in parole semplici.

Ingrandisci

I suoi punti deboli indicano i controlli superati con il margine più piccolo, quelli che più probabilmente falliranno dopo.La Cronologia mostra quando un controllo ha iniziato a fallire.Quando un cambiamento è voluto, accettate il nuovo aspetto nel report, e niente viene scritto finché non salvate.Vedete il Report di affidabilità.

Interrompere o continuare: decidete voi cosa significa un fallimento

Ogni controllo dice cosa comporta il suo fallimento: interrompere il test, o continuarlo.Un controllo da cui dipendono i clic successivi interrompe il test per impostazione predefinita, perché cliccare senza di lui colpirebbe il punto sbagliato.Un controllo che conferma soltanto ciò che è sullo schermo continua, così un'esecuzione segnala ogni problema che incontra.

In una pipeline, gtr-cli può eseguire ancora una volta un test fallito con la sua opzione dei tentativi ripetuti.Usatela come ultima risorsa: ciò che va corretto sono le cause descritte sopra.

Una checklist contro i falsi positivi

Volete vederlo sulla vostra applicazione?Il test visivo con GUI Test Studio mostra tutta l'idea in una pagina.

Domande

Selenium, Playwright, Cypress, BackstopJS, Chromatic, Argos, Percy e Applitools Eyes sono marchi dei rispettivi proprietari.