Test di regressione visiva

Il test di regressione visiva è un metodo automatico che confronta gli screenshot di un'interfaccia prima e dopo una modifica, per rilevare differenze grafiche involontarie.

Related workflow terms: Browser headless, Playwright.

Come funziona

Il processo segue un ciclo di acquisizione, confronto e revisione. Per prima cosa viene creato uno screenshot di riferimento per ogni stato dell'interfaccia: una pagina, un componente o una determinata viewport. L'immagine rappresenta l'aspetto previsto.

Dopo una modifica al codice, vengono acquisiti di nuovo gli stessi screenshot. Lo strumento confronta ogni nuova immagine con quella di riferimento, pixel per pixel o tramite un algoritmo percettivo, ed evidenzia le differenze.

Se ne trova, una persona le esamina. Le modifiche volute, come un pulsante riprogettato o un nuovo colore, vengono approvate e diventano il nuovo riferimento. Quelle involontarie, come un elemento disallineato o un'impaginazione danneggiata, sono segnalate come regressioni da correggere.

Il ciclo viene eseguito automaticamente nelle pipeline CI/CD, così i difetti visivi vengono individuati prima di arrivare in produzione.

Dove si usa

• Sistemi di progettazione — controllano che gli aggiornamenti dei componenti in una libreria condivisa non alterino quelli usati in più applicazioni.
• Test tra browser — acquisiscono la stessa pagina in Chrome, Firefox, Safari ed Edge per verificare una resa coerente.
• Impaginazioni responsive — confrontano screenshot a diverse larghezze della viewport per individuare punti di interruzione che si comportano in modo inatteso.
• Cambi di tema — verificano che la modalità scura, un nuovo colore del marchio o un carattere diverso non producano effetti indesiderati nel resto dell'interfaccia.
• Verifiche di accessibilità — rilevano cambiamenti che potrebbero ridurre leggibilità, contrasto o visibilità degli indicatori di stato attivo.

Confronto dei pixel e confronto percettivo

I due metodi principali operano a livello di pixel oppure in base alla percezione visiva.

Il primo confronta le immagini pixel per pixel e segnala ogni differenza, per quanto piccola. È preciso ma produce molto rumore: antialiasing, resa subpixel dei caratteri e minime variazioni nei tempi delle animazioni possono generare falsi positivi. Di solito è possibile impostare una soglia di tolleranza per ridurli.

Il confronto percettivo prova invece a valutare le differenze come farebbe l'occhio umano. Ignora variazioni impercettibili, per esempio una sfumatura di colore o uno spostamento subpixel del testo, e segnala quelle che una persona noterebbe. Produce meno falsi positivi, ma può non rilevare regressioni molto lievi.

In pratica, molti gruppi iniziano dal confronto dei pixel con una tolleranza bassa, quindi passano a quello percettivo quando la suite cresce e i falsi positivi diventano difficili da gestire.

Le suite più affidabili abbinano i test visivi a condizioni stabili: caratteri fissi, dati deterministici e aree dinamiche mascherate. Senza questa disciplina, il gruppo smette di fidarsi delle differenze e il test perde utilità.

Errori comuni

• Non stabilizzare i contenuti dinamici. Date, dati in tempo reale, contenuti casuali e annunci cambiano tra un'acquisizione e l'altra e producono falsi positivi. Maschera queste aree o simula dati fissi.
• Eseguire i test in ambienti diversi. Uno screenshot creato su macOS differisce da uno su Linux per la resa dei caratteri, l'antialiasing e le impostazioni predefinite del browser. Per coerenza, esegui tutte le acquisizioni nello stesso ambiente containerizzato.
• Impostare una tolleranza troppo alta. Una soglia elevata riduce i falsi positivi, ma nasconde anche regressioni reali. Parti da un valore basso e adattalo al rumore effettivo della pipeline.
• Trascurare la manutenzione delle immagini di riferimento. Con l'evoluzione dell'interfaccia diventano obsolete. Esaminale e aggiornale regolarmente; la loro approvazione deve essere una scelta consapevole, non l'accettazione automatica di ogni modifica.