Cos'è il test di regressione? Test end-to-end senza codice
Cos'è il test di regressione e perché i test di regressione end-to-end trovano ciò che sfugge ai test unitari: cosa coprire, quando eseguirli e come automatizzarli senza codice.
11 min di letturaDal team di GUI Test Studio
Cos'è il test di regressione?
Definizione
Il test di regressione controlla che una modifica a un'applicazione non abbia rotto qualcosa che già funzionava.
- Una nuova funzionalità, la correzione di un bug, l'aggiornamento di una libreria o una nuova versione del browser possono rompere ciascuno una parte dell'applicazione che nessuno ha toccato.
- Gli stessi test vengono eseguiti di nuovo dopo la modifica, e un test che prima passava e ora fallisce ha trovato una regressione.
La parola indica un passo indietro: l'applicazione è regredita, oggi funziona peggio di ieri.È questo che rende una regressione così frustrante per gli utenti.Qualcosa su cui facevano affidamento ha semplicemente smesso di funzionare.
Le regressioni avvengono perché le parti di un'applicazione dipendono l'una dall'altra in modi che nessuno tiene a mente.Uno stile condiviso, una regola di arrotondamento, un campo rinominato in un'API: una piccola modifica in un punto arriva a schermate lontane.Chi ha fatto la modifica ha controllato ciò che ha cambiato, e aveva ragione.Il guasto è altrove.
Test di regressione e retest a confronto
I due vengono spesso confusi, e rispondono a domande diverse.
| Domanda | Retest | Test di regressione |
|---|---|---|
| Cosa controlla? | Che il bug che avete corretto sia davvero corretto. | Che la correzione, o qualsiasi altra modifica, non abbia rotto nient'altro. |
| Dove guarda? | Nel punto del bug. | In tutto il resto, soprattutto in ciò su cui contano gli utenti. |
| Quali test? | I passaggi che hanno mostrato il bug. | La stessa suite, eseguita di nuovo dopo ogni modifica. |
| Quando? | Una volta, dopo la correzione. | Dopo ogni modifica, per tutta la vita dell'applicazione. |
Test di regressione unitari, di integrazione ed end-to-end
I test di regressione esistono a ogni livello di un'applicazione, e ogni livello ne vede una parte diversa.
Quanta parte dell'applicazione vede ogni test
Test unitari
Una funzione, da sola
Intercetta: Un calcolo che restituisce il valore sbagliato
Test di integrazione
Due o tre parti insieme
Intercetta: Un servizio che non risponde più come si aspetta quello successivo
Test end-to-end
L'intera applicazione, attraverso il suo schermo
Intercetta: Un totale, un pulsante, una pagina o un messaggio che l'utente vede rotto
I test unitari e di integrazione sono rapidi e precisi, e ogni team dovrebbe averli.Ma controllano il codice così come lo pensa lo sviluppatore.Un utente non chiama mai una funzione: fa clic su un pulsante, legge un totale e si aspetta che si apra la pagina successiva.
Alcune regressioni esistono solo sullo schermo, dove i test unitari non guardano mai.
- Una modifica di stile nasconde il pulsante Paga dietro un banner.
- Un totale è calcolato bene e mostrato con la valuta sbagliata.
- Una finestra di dialogo si apre dietro la finestra.
- Una traduzione è troppo lunga e l'etichetta viene tagliata.
Ecco perché il test di regressione end-to-end conta più di tutti: un test end-to-end guida l'intera applicazione attraverso la sua interfaccia, come la percorre un utente, e controlla ciò che l'utente vede.Per il quadro completo, vedete che cos'è il test end-to-end.
I vostri utenti non eseguono i vostri test unitari.Usano la vostra applicazione, schermata dopo schermata.
Test di regressione funzionali e non funzionali
Il test funzionale controlla cosa fa l'applicazione: l'ordine viene effettuato, il report viene esportato, il messaggio di errore compare quando un campo è vuoto.Il test non funzionale controlla come lo fa: con quale velocità, con quale aspetto, come si comporta su un altro dispositivo o su una rete lenta.
Regressione funzionale
Il checkout effettua ancora l'ordine, e la conferma mostra ancora il numero d'ordine.
Regressione visiva
Lo schermo ha ancora l'aspetto di prima: nessuna icona mancante, nessuna parola tagliata, nessun pulsante del colore sbagliato.
Regressione non funzionale
La pagina si carica ancora in tempo, e il layout regge ancora su un telefono e su una connessione lenta.
La maggior parte delle suite di regressione è funzionale, e la maggior parte dei guasti visivi e di layout passa tra le loro maglie perché un controllo funzionale chiede se un elemento esiste, non se una persona può vederlo.Bug visivi che i vostri test automatici non colgono spiega perché.
Cosa mettere in una suite di regressione end-to-end?
Una suite di regressione che cerca di coprire tutto non è mai finita e non ispira mai fiducia.Iniziate in piccolo, con ciò che farebbe più male se si rompesse.
- 1
Elencare i percorsi di cui gli utenti non possono fare a meno
Registrazione, accesso, ricerca, checkout, il report che i vostri clienti esportano ogni lunedì.Da cinque a dieci percorsi, ciascuno dal primo clic al risultato che l'utente si aspetta.
- 2
Aggiungere ciò che si è già rotto
Ogni bug arrivato una volta agli utenti merita un test, così non potrà mai tornare inosservato.È così che una suite di regressione impara.
- 3
Pesare in base al rischio, non al numero di schermate
Una schermata usata da ogni cliente ogni giorno conta più di dieci pagine di impostazioni.Denaro, dati e accesso vengono prima di tutto.
- 4
Controllare i risultati, non solo i clic
Un test che attraversa il checkout a colpi di clic senza mai controllare il totale dimostra poco.Ogni percorso termina su ciò per cui l'utente è venuto, e il test lo verifica: il totale, la conferma, il file esportato.
- 5
Mantenerla abbastanza veloce da eseguirla a ogni modifica
Contrassegnate una manciata di percorsi come suite di smoke test, quelli che vengono eseguiti su ogni pull request in pochi minuti.Il resto viene eseguito ogni notte.
Quando eseguire i test di regressione?
Prima si trova una regressione, meno costa: la modifica è ancora fresca nella mente dello sviluppatore, e non vi è ancora stato costruito sopra nulla.
| Quando | Cosa viene eseguito | Perché |
|---|---|---|
| Ogni pull request o build | La suite di smoke test: i percorsi critici. | Un guasto viene intercettato prima del merge, finché la modifica è piccola. |
| Ogni notte | L'intera suite. | Tutto viene controllato una volta al giorno, senza rallentare nessuno. |
| Prima di un rilascio | L'intera suite, su ogni browser e dispositivo che supportate. | Ciò che gli utenti riceveranno davvero viene controllato là dove lo riceveranno. |
| Dopo un aggiornamento che non controllate | L'intera suite. | Una nuova versione del browser, del sistema operativo o di una libreria può rompere l'applicazione senza che cambi una riga del vostro codice. |
Percorso di checkout, ultime otto build
- #38
- #39
- #40
- #41
- #42
- Ha iniziato a fallire#43
- #44
- #45
#42 l'ultima esecuzione superata#43 la modifica da guardare per prima#45 corretto, e controllato di nuovo
Perché le suite di regressione automatizzate vengono abbandonate
La maggior parte dei team concorda sul fatto che il test di regressione vada automatizzato.Molti ci hanno provato, e molte suite automatizzate finiscono disattivate o ignorate.I motivi sono quasi sempre gli stessi.
La suite costa più da mantenere di quanto faccia risparmiare.
- I test in codice trovano i pulsanti tramite selettori, e ogni riprogettazione ne rompe decine in un colpo solo.
- Solo gli sviluppatori possono correggerli, e gli sviluppatori stanno costruendo funzionalità.
- I test falliscono per motivi innocui, una sfumatura di colore o un pixel di anti-aliasing, così le persone smettono di leggere i risultati.
- La suite completa richiede ore, quindi viene eseguita una volta alla settimana, e le regressioni aspettano giorni prima di essere trovate.
Automatizzare i test di regressione end-to-end senza codice
GUI Test Studio è costruito per il test di regressione end-to-end di app web, app desktop Windows, telefoni e giochi, attraverso la loro interfaccia, senza codice di test da scrivere né da mantenere.
Registrare ogni percorso una volta
Fate clic su Registra in GUI Test Runner-Recorder e seguite il percorso nella vostra applicazione reale, come farebbe un utente.I clic, la digitazione e i controlli di ciò che è comparso diventano un test.Potete anche descrivere il percorso in un prompt al vostro assistente IA, e il test viene creato per voi.
Il test controlla ciò che mostra lo schermo, non il codice che c'è dietro.
- Un'asserzione visiva confronta l'immagine di un elemento, un'asserzione testuale ne legge le parole.
- Il GTS Engine + AI trova ogni elemento prima tramite le informazioni di accessibilità dell'applicazione, e a vista quando l'applicazione non lo dice, così una riprogettazione del codice dietro un pulsante non rompe il test.
Modificarlo come un video
Ogni test si apre in GUI Test Studio su una timeline: i suoi passaggi come blocchi, i suoi controlli accanto, la registrazione sopra.Cambiate un controllo, aggiungete un'attesa, raggruppate i passaggi di un percorso: niente codice, e chiunque nel team può farlo.Vedete la timeline.
Eseguirlo a ogni build
gtr-cli esegue la suite su una macchina di build Windows e risponde come si aspetta una pipeline: un test non superato fa fallire la build, un file JUnit riempie la scheda dei test, e ogni immagine di ciò che non è riuscito viene conservata.
gtr-cli run tests\regression --countdown 0 --junit results\junit.xml --artifacts results\artifactsFunziona in TeamCity, Jenkins, GitHub Actions, GitLab e Azure DevOps.Vedete Eseguire i test nella pipeline.
Una vera regressione, o rumore innocuo?
Ogni esecuzione termina con un report di affidabilità.Per ogni controllo, dice se l'elemento è stato trovato e se ha ancora l'aspetto con cui è stato registrato, con le immagini attesa e trovata affiancate e la differenza evidenziata.
Il rumore viene ignorato e le regressioni vengono intercettate.
- Le lievi differenze di rendering che nessuna persona noterebbe non vengono contate.
- Una parola cambiata, un badge mancante o un pulsante diventato grigio fanno fallire il controllo.
- Quando un'immagine differisce, l'analisi intelligente con IA può dare un secondo sguardo e dire cosa è cambiato in parole semplici.
Una modifica voluta si accetta con un clic
Non ogni differenza è una regressione: a volte la nuova schermata è quella giusta.Nel report di affidabilità, accettate ciò che l'esecuzione ha trovato come nuova immagine attesa, e l'esecuzione successiva farà il confronto con quella.Per le schermate che differiscono di proposito, una modalità scura o un'altra lingua, le baseline conservano una versione per ambiente.
Sapere quando è cominciato
Ogni esecuzione viene conservata nella Cronologia del test.Quando un percorso inizia a fallire, la Cronologia mostra l'ultima esecuzione superata e la prima non superata, e due esecuzioni si possono confrontare controllo per controllo.
Ogni browser e dispositivo, e un bug nel vostro tracker
Un test web registrato una volta viene eseguito in Chrome, Edge e Firefox, su telefoni e tablet, in altre lingue e con altre dimensioni dello schermo: vedete il test cross-browser.E un'esecuzione non superata può diventare da sola un ticket Jira, con i passaggi per riprodurla e le immagini: vedete i test non superati come bug Jira.
Una modifica viene inviata
Una funzionalità, una correzione, un aggiornamento
La build viene eseguita
gtr-cli esegue la suite
Report di affidabilità
Regressione o rumore, con le immagini
Merge, o prima la correzione
Un fallimento blocca la modifica
Da fare
- Una piccola suite di percorsi critici a ogni build
- Controlli di ciò che l'utente vede alla fine di ogni percorso
- Un test per ogni bug arrivato agli utenti
- Ogni browser e dispositivo prima di un rilascio
Da evitare
- Una suite così grande da essere eseguita solo una volta alla settimana
- Test che attraversano un percorso a colpi di clic senza verificare nulla
- Fallimenti che nessuno legge perché metà sono rumore
- Test che solo gli sviluppatori possono modificare
Punti chiave
- 1Il test di regressione controlla che una modifica non abbia rotto nulla che funzionava. Gli stessi test, eseguiti di nuovo dopo ogni modifica.
- 2Il retest dimostra una correzione; il test di regressione dimostra che la correzione non è costata nient'altro.
- 3I test di regressione end-to-end intercettano ciò che avvertono gli utenti: i totali, i pulsanti, le pagine e i messaggi che i test unitari non vedono mai.
- 4Iniziate in piccolo: da cinque a dieci percorsi critici a ogni build, la suite completa ogni notte, ogni browser e dispositivo prima di un rilascio.
- 5Una suite deve distinguere una regressione dal rumore, e costare poco da mantenere, altrimenti verrà abbandonata.
Domande
Cos'è il test di regressione?
Il test di regressione controlla che una modifica a un'applicazione non abbia rotto qualcosa che già funzionava.Dopo una nuova funzionalità, la correzione di un bug o un aggiornamento, gli stessi test vengono eseguiti di nuovo, e ogni test che prima passava e ora fallisce indica una regressione.
Qual è la differenza tra test di regressione e retest?
Il retest controlla che un bug che avete corretto sia davvero corretto.Il test di regressione controlla che la correzione, o qualsiasi altra modifica, non abbia rotto il resto dell'applicazione.Il retest guarda un solo punto, il test di regressione guarda tutto il resto.
Che cos'è il test di regressione end-to-end?
Il test di regressione end-to-end esegue i percorsi importanti di un'applicazione attraverso la sua interfaccia, come li segue un utente, dopo ogni modifica.Intercetta i guasti che si vedono solo sullo schermo: un totale sbagliato, un pulsante che non apre più la sua finestra di dialogo, una pagina che non si carica.
Il test di regressione è funzionale o non funzionale?
Entrambe le cose.La maggior parte dei test di regressione è funzionale: controlla che le funzionalità facciano ancora ciò che devono.Una regressione può anche essere non funzionale, come una pagina diventata lenta o un layout che si è rotto su un telefono, e queste meritano test propri.
Ogni quanto eseguire i test di regressione?
Eseguite una breve suite di percorsi critici su ogni pull request o a ogni build, la suite completa ogni notte, e la suite completa su ogni browser e dispositivo prima di un rilascio.Prima si intercetta una regressione, meno costa correggerla.
Il test di regressione si può automatizzare senza scrivere codice?
Sì.Con GUI Test Studio registrate un percorso una volta usando l'applicazione, oppure lo descrivete in un prompt, e il test viene creato per voi.Viene eseguito di nuovo a ogni build con gtr-cli, e nessuno deve mantenere codice di test.
Che cos'è il test di regressione visiva?
Il test di regressione visiva confronta ciò che lo schermo mostra ora con ciò che mostrava prima, per intercettare i cambiamenti che un utente vedrebbe: un'icona mancante, una parola tagliata, un pulsante del colore sbagliato.È un tipo di controllo di regressione end-to-end.
OpenAI, Anthropic, Jira, TeamCity, Jenkins, GitHub, GitLab, Azure DevOps, Chrome, Edge e Firefox sono marchi dei rispettivi proprietari.
Pronti a registrare il vostro primo test?
Tutte le funzionalità, per 15 giorni.
Preferite vederlo sul tipo di app che testate?Prenotate una chiamata gratuita di 30 minuti con il nostro team.