Ancora «element not found»? Come testare quando selettori e locator falliscono
«Element not found»?Perché selettori e locator si rompono (id dinamici, shadow DOM, iframe, canvas) e come testare senza un solo locator da mantenere.
«Element not found» significa che il vostro test ha cercato un elemento con un locator e nulla ha corrisposto in tempo.La soluzione è raramente un locator migliore: è un test che controlla ciò che vede l'utente.
Ogni QA engineer conosce quella mattina: venti test rossi e nemmeno un bug vero.Uno sviluppatore ha rinominato una classe, il team di design ha spostato un banner, un aggiornamento del framework ha cambiato gli id.Questo articolo spiega perché i locator si rompono, come correggere l'errore quando arriva, dove si fermano le soluzioni abituali e come testare senza un selettore da mantenere.
Che cosa significa «element not found»?
Definizione
Un errore «element not found» significa che il test ha chiesto un elemento con un locator e nulla nella pagina ha corrisposto prima del timeout.
- Un locator, chiamato anche selettore, è l'indirizzo che il test usa per l'elemento: un id, un selettore CSS, un XPath, un ruolo e un nome, un testo.
- Selenium solleva NoSuchElementException, Playwright chiude l'azione con un timeout, e ogni altro framework ha il suo nome per questo.
Alla fine il messaggio è sempre lo stesso: il test ha perso l'elemento, che l'utente l'abbia perso o no.
La pagina di risoluzione dei problemi di Selenium indica tre cause probabili: cercate nel posto sbagliato, cercate nel momento sbagliato, oppure il locator è cambiato da quando avete scritto il codice.Solo l'ultima riguarda il locator stesso, ed è quella che cresce a ogni rilascio.
#save-8f3a2c
Una nuova build genera un altro id
.btn-primary
Un restyling rinomina la classe
text=Save
La versione francese dice Enregistrer
//div[3]/form/button[2]
Un banner viene aggiunto sopra il modulo
Sullo schermo
SaveInvariato per l'utente
Perché selettori e locator si rompono?
Un locator è un'ipotesi su come è costruita l'applicazione.Qualsiasi cosa cambi la costruzione senza cambiare ciò che vede l'utente può romperlo.
| Che cosa è cambiato | Quali locator si rompono | L'utente se n'è accorto? |
|---|---|---|
| Id e nomi di classe generati | Un id o una classe scritti dal framework, diversi a ogni build o caricamento di pagina | No |
| Un restyling o un refactoring | Le catene CSS e gli XPath che seguono la struttura della pagina | Spesso no |
| Un test A/B | Qualsiasi locator della variante che il vostro test non si aspettava | Solo gli utenti di quella variante |
| Una traduzione | I locator per testo visibile o nome accessibile | No, se la traduzione è corretta |
| Shadow DOM e iframe | I locator che non riescono a entrare nel componente o nel frame | No |
| Una lista virtualizzata | I locator di una riga che non viene disegnata finché non la si fa scorrere in vista | No |
| Un canvas, un gioco o un'app senza albero di accessibilità | Tutti i locator: dentro non c'è niente da indicare | No |
Id dinamici e nomi di classe generati
Molti framework scrivono i propri id e nomi di classe, come save-8f3a2c o css-1x7hq.Sono unici, il che li fa sembrare locator perfetti, e cambiano alla build successiva.Un test registrato su di essi passa oggi e fallisce dopo il prossimo deploy, su una pagina che nessuno ha toccato.
Restyling, refactoring e test A/B
Un selettore CSS come .form > div:nth-child(3) button o un XPath come //div[3]/form/button[2] descrive un percorso attraverso la pagina.Racchiudete il modulo in un nuovo contenitore, aggiungete un banner sopra o invertite due campi, e il percorso porta altrove.Un test A/B fa lo stesso di proposito: metà dei visitatori riceve una pagina per cui i vostri locator non sono stati scritti.
La documentazione di Playwright lo dice chiaramente: i selettori XPath e CSS possono essere legati alla struttura del DOM, e possono rompersi quando questa cambia.
Localizzazione e locator basati sul testo
I locator per testo, etichetta o nome accessibile sopravvivono a un restyling, ed è per questo che sono consigliati.Non sopravvivono a una traduzione.Un pulsante trovato con il nome Save non viene trovato quando la versione francese dice Enregistrer, quindi un prodotto localizzato ha bisogno di un locator per lingua, o di un test id.
Shadow DOM e iframe
Un iframe è una pagina dentro la pagina, e un componente web tiene i suoi elementi interni in una shadow root.Selenium conosce solo gli elementi del documento di primo livello, quindi a un test a codice bisogna dire di entrare prima nel frame, altrimenti segnala che l'elemento non esiste.Alcuni localizzatori, come XPath, non possono entrare affatto in un componente.
Liste e griglie virtualizzate
Una tabella di diecimila righe è veloce perché non le disegna tutte.AG Grid, una griglia di dati molto usata, spiega che disegna solo ciò che si vede sullo schermo, più una piccola riserva di righe sopra e sotto.La riga 500 non è nella pagina finché qualcuno non scorre fino a lei, quindi un locator non la trova, mentre una persona semplicemente scorrerebbe.
Come correggere un errore «element not found»
In Selenium, Playwright o Cypress correggere l'errore è lavoro vostro, e torna a ogni rilascio.In GUI Test Studio non c'è nessun localizzatore da correggere.
| Cosa è andato storto | In un framework a codice | In GUI Test Studio |
|---|---|---|
| L'elemento compare tardi | Scrivete un'attesa sulla condizione giusta | Ogni controllo attende da solo fino al suo timeout |
| L'elemento sta in un frame o in una shadow root | Scrivete il passaggio nel frame o nel componente | L'elemento viene trovato dove è disegnato sullo schermo |
| Un redesign ha cambiato gli id o la struttura | Riscrivete il localizzatore, spesso in molti test | Niente da riscrivere: un'altra via, o la sua immagine, lo trova |
| L'elemento è cambiato di proposito | Modificate il codice del test | Un clic nel report accetta il nuovo aspetto |
Quando un test di GUI Test Studio si ferma davvero su un elemento, questi cinque passaggi risolvono la questione, senza scrivere codice.
- 1
Aprite il Report di affidabilità dell'esecuzione
Il report si apre dopo ogni esecuzione, sul primo errore.Mostra l'immagine attesa accanto allo schermo nel momento in cui il controllo si è arreso, così vedete se l'elemento mancava, era coperto o si trovava altrove.
- 2
Controllate dove è iniziata l'esecuzione
Un test parte dalla schermata da cui è partita la sua registrazione.Se l'applicazione era su un'altra pagina o conteneva altri dati, rimettetela com'era ed eseguite di nuovo il test.
- 3
Allargate l'area di ricerca se l'elemento si è spostato lontano
Quando non viene trovato nulla nell'area di ricerca di un controllo, la ricerca si allarga già da sola a tutto lo schermo.Se ora l'elemento si trova stabilmente altrove, fate clic su Allargare l'area di ricerca nel report e impostate la nuova area in GUI Test Studio.
- 4
Accettate una modifica voluta
Se l'elemento ha un aspetto diverso perché il design è cambiato, fate clic su Accetta l'effettivo come atteso nel Report di affidabilità e salvate.Il test è aggiornato, senza codice da modificare.
- 5
Segnalate il bug se l'elemento è davvero sparito
Se l'elemento non c'è più, il test ha fatto il suo lavoro.Fate clic su Segnalazione di bug per registrarlo come PDF o come issue di Jira, con le immagini allegate.
CSS, XPath, ruolo o test id: ogni localizzatore ha il suo punto debole
I team che scrivono test a codice scelgono un localizzatore per ogni elemento che toccano.Ogni tipo fallisce a modo suo.
| Locator | Esempio | Si rompe quando | Sopravvive a |
|---|---|---|---|
| Id o classe generati | #save-8f3a2c | La build successiva | Quasi nulla |
| Selettore CSS | .form button.primary | Cambiano le classi o la struttura | Un nuovo testo o una traduzione |
| XPath | //div[3]/form/button[2] | Qualcosa viene aggiunto sopra o intorno | Una nuova classe |
| Ruolo e nome accessibile | role=button, name=Save | L'etichetta cambia o viene tradotta | Restyling e refactoring |
| Test id | data-testid=save-order | Uno sviluppatore lo rimuove o lo rinomina | Restyling, traduzioni, refactoring |
Ogni strategia sposta il rischio invece di eliminarlo.
- Un ruolo e un nome dipendono dalle parole, che cambiano a ogni traduzione e a ogni ritocco dei testi.
- Un test id dipende da un'abitudine: ogni sviluppatore deve aggiungerlo, mantenerlo e non riutilizzarlo mai, in ogni componente, per tutta la vita del prodotto.
- CSS e XPath dipendono dalla struttura, che è esattamente ciò che i refactoring cambiano.
XPath o selettore CSS è la domanda più frequente, e conta meno di quanto sembri.CSS è più corto e più facile da leggere; XPath può risalire la pagina e cercare un testo.Entrambi descrivono come è costruita la pagina, quindi entrambi si rompono allo stesso modo.
In GUI Test Studio nessuno sceglie un localizzatore.Un test registrato conserva da solo diverse vie verso ogni elemento, come mostrano le sezioni seguenti.
L'automazione dei test con self-healing corregge i locator rotti?
Gli strumenti di self-healing conservano dettagli extra su ogni elemento mentre un test passa.Quando il locator principale smette di corrispondere, cercano l'elemento con quei dettagli e proseguono.
Il self-healing è utile, con tre limiti da conoscere.
Parte sempre da un locator, quindi ha bisogno di un elemento nella pagina verso cui correggersi.
Trasforma un cambiamento in un successo, quindi ogni correzione va rivista da una persona, altrimenti dietro si nasconde un cambiamento reale.
Non può aiutare dove non c'è alcun elemento: un canvas, un gioco, uno schermo remoto.
Dove ogni locator si ferma: canvas, giochi e app senza albero di accessibilità
Tutte le strategie qui sopra presuppongono che l'applicazione descriva i suoi elementi.Molte non lo fanno, e non c'è nessun locator da scrivere, buono o cattivo.
| Applicazione | Che cosa può raggiungere un locator |
|---|---|
| Un canvas, un grafico, una mappa, una scena WebGL | Un solo elemento che contiene un'immagine |
| Un gioco | Una sola finestra: il gioco disegna da sé i suoi menu |
| Flutter sul web | Nulla finché l'app non attiva la sua accessibilità: Flutter disegna la sua interfaccia su un canvas, e la sua accessibilità sul web è da attivare |
| Qt, Java Swing, Delphi e altre app desktop disegnate su misura | Poco o nulla, a seconda di come è disegnato ogni controllo |
| Citrix, Desktop remoto e macchine virtuali | Una sola finestra di pixel sul vostro computer |
Per le app desktop Windows, Alternative a WinAppDriver per app senza albero di accessibilità elenca quali programmi si descrivono e quali no.
Se il vostro test vede solo ciò che l'applicazione descrive, un'applicazione che non descrive nulla non si può testare.L'utente, invece, vede ogni pulsante.
Automazione dei test senza selettori da mantenere
GUI Test Studio, che automatizza i test end-to-end su Windows, prende un'altra strada: nessuno scrive o mantiene un selettore.Registrate il test eseguendo voi stessi il flusso, o lo descrivete in un prompt, e ogni controllo riguarda ciò che vede l'utente.
| Il controllo | Che cosa controlla |
|---|---|
| Asserzione visiva | Un elemento è sullo schermo e ha l'aspetto atteso: la sua immagine, trovata e confrontata |
| Asserzione testuale | Un testo è sullo schermo, letto dove deve essere |
| Asserzione testuale dinamica | Un valore ha la forma giusta, come una data, un importo o un numero d'ordine, qualunque sia il valore |
| Asserzione di layout | Gli elementi stanno dove devono stare gli uni rispetto agli altri |
Per trovare ogni elemento, il GTS Engine + AI usa due vie.Interroga prima l'applicazione: le informazioni di accessibilità che un'app Windows dà sui suoi controlli, o gli elementi propri di una pagina web.Quando l'applicazione non dice nulla, trova l'elemento a vista, sullo schermo.Come GUI Test Studio trova gli elementi sullo schermo spiega entrambe le vie in dettaglio.
In una pagina web: più vie verso un elemento
Per un test web, GUI Test Studio conserva più vie verso ogni elemento su cui agisce, in ordine: il suo test id, il suo id, il suo ruolo e nome, la sua etichetta, il suo testo segnaposto, il suo testo e, per ultima, la sua posizione nella pagina.Un id che sembra generato da un framework viene spostato verso la fine dell'elenco, dopo tutto ciò che una persona può leggere.
Le vie verso il pulsante Save, provate in ordine
- 1Il suo test iddata-testid="save"Rimosso in un refactoring
- 2Il suo ruolo e nomerole=button · name=SaveTrovato
- 3Il suo testoSaveNon serve
- 4La sua posizione nella paginaform > button:nth-of-type(2)Non serve
Così un test id rimosso o una classe rinominata non fermano il test: la via successiva trova comunque l'elemento.Le stesse vie raggiungono gli elementi dentro una shadow root, e permettono a un test generato per un telefono di aprire il menu che lì nasconde un link.
È proprio questo che permette a un solo test web registrato di girare in Chrome, Edge, Firefox e su telefoni emulati, come mostrano i test cross-browser da una sola registrazione.
In un'app desktop: prima il controllo, poi lo schermo
In un'app Windows, un controllo fatto su un pulsante conserva ciò che l'app ha detto di quel pulsante: il nome, il tipo, la posizione.A ogni esecuzione, il motore chiede prima quel pulsante all'app in esecuzione, e cerca la sua immagine dentro il riquadro indicato dall'app.Tra più pulsanti identici, prende quello più vicino alla posizione di quello registrato.
Un controllo del testo chiede all'app che cosa dice l'elemento prima di leggere le parole sullo schermo, quindi una parola difficile da leggere sullo schermo viene comunque verificata rispetto a ciò che l'app dice davvero.
Ovunque altro: a vista
Un gioco, un canvas, una sessione Citrix o un programma senza albero di accessibilità si testa a vista, senza aggiungere nulla all'applicazione.Il controllo cerca l'immagine dell'elemento nella sua area di ricerca, e un controllo del testo legge le parole sullo schermo.
Una dashboard disegna il grafico delle vendite su un canvas, quindi nessun locator può raggiungere una barra o una legenda.Registrate un clic sulla barra di marzo e aggiungete un'asserzione visiva della legenda.Il clic viene mirato attraverso l'immagine della barra, e la legenda viene verificata come la vede l'utente.
Che cosa succede quando l'elemento si sposta o cambia
Un test che non dipende da un solo locator deve comunque affrontare il cambiamento.Ecco che cosa fa GUI Test Studio a ogni passo.
Chiedere
L'applicazione dice dov'è l'elemento
Guardare
Oppure la sua immagine viene trovata nella sua area di ricerca
Allargare
Niente lì: tutto lo schermo
Riferire
Dove è stato trovato, e perché
Ogni passo copre un tipo diverso di cambiamento.
- Una finestra spostata, un layout slittato o una lista scorsa: l'applicazione dice dov'è ora l'elemento, oppure lì viene trovata la sua immagine.
- Un elemento uscito dalla sua area di ricerca: quando lì non si trova nulla, la ricerca si allarga a tutto lo schermo, e il report di affidabilità indica che l'elemento è stato trovato fuori dalla sua area, con un link per allargarla.
- Una parola che il riconoscimento del testo legge male: un controllo del testo chiede all'applicazione che cosa dice l'elemento.
- Un elemento web il cui primo locator si è rotto: la via successiva lo trova, e l'esecuzione annota quale via è cambiata.
Anche i clic seguono l'elemento: ogni clic viene mirato attraverso il controllo che lo precede, quindi quando il pulsante si sposta, il clic si sposta con lui.Vedete i controlli visivi e i controlli del testo per come si imposta ciascuno.
Che cosa richiede ancora voi
Nessun approccio rende gratuito ogni cambiamento.Ecco i casi in cui decide una persona.
| Situazione | Che cosa fare |
|---|---|
| L'aspetto di un elemento è cambiato di proposito | Il controllo fallisce con l'immagine attesa e quella effettiva fianco a fianco.Fate clic su Accetta l'effettivo come atteso nel report di affidabilità e salvate. |
| Le dimensioni dello schermo o il ridimensionamento differiscono dalla registrazione | Un controllo a vista confronta immagini, quindi eseguitelo con le stesse dimensioni dello schermo e lo stesso ridimensionamento, oppure tenete un profilo di baseline per ciascuno. |
| L'app non parte da dove è partita la registrazione | Riportate l'applicazione nello stato da cui è partita la registrazione: la stessa pagina, gli stessi dati, le stesse finestre aperte. |
| Un test A/B serve un'altra variante | Fissate la variante nel vostro ambiente di test, oppure tenete un profilo di baseline per ogni variante. |
| L'elemento è davvero scomparso | È un bug.Il test fallisce, e il report mostra che cosa era atteso e dove. |
Accettare un nuovo aspetto illustra l'aggiornamento con un clic, e test instabili e falsi positivi spiega come un controllo distingue il rumore innocuo da un cambiamento reale.
Per i bug visivi che un controllo basato sui locator lascia passare senza vederli, leggete i bug visivi che i vostri test automatici non vedono.
Punti chiave
- 1«Element not found» di solito è un problema del test, non un bug: il locator, il momento o il contesto sono sbagliati più spesso dell'applicazione.
- 2I locator si rompono per motivi ordinari: id generati, restyling, test A/B, traduzioni, shadow DOM, iframe e liste virtualizzate.
- 3Ogni strategia sposta il rischio: CSS e XPath dipendono dalla struttura, ruoli e nomi dalle parole, i test id da un'abitudine del team, il self-healing da una revisione.
- 4Alcune app non danno nulla a un locator: canvas, giochi, sessioni Citrix e app senza albero di accessibilità si possono testare solo a vista.
- 5GUI Test Studio non ha selettori né locator da mantenere: interroga prima l'applicazione, trova l'elemento a vista quando l'applicazione non lo dice, e controlla ciò che vede l'utente.
Domande
Che cosa significa «element not found» nell'automazione dei test?
Significa che il test ha chiesto un elemento con un locator, come un id, un selettore CSS o un XPath, e nulla nella pagina ha corrisposto in tempo.In Selenium compare come NoSuchElementException, in Playwright come timeout.L'elemento può mancare, ma più spesso sono sbagliati il locator, il momento o il contesto.
Perché il mio test trova l'elemento in locale ma non in CI?
Di solito perché è diversa l'esecuzione, non il codice.Un agente di build più lento mostra l'elemento più tardi del vostro portatile, uno schermo più piccolo lo nasconde dietro un menu, altri dati di test ne cambiano il testo, oppure un test A/B serve un'altra variante.Guardate lo screenshot o il video dell'esecuzione fallita prima di cambiare il locator.
È meglio XPath o un selettore CSS?
Nessuno dei due è sicuro da solo.Entrambi descrivono come è costruita la pagina, quindi entrambi si rompono quando la sua struttura cambia, come avverte la documentazione di Playwright.Un ruolo con un nome o un test id durano di più, ma vanno comunque scritti e tenuti aggiornati a mano.In GUI Test Studio nessuno scrive né l'uno né l'altro: il test conserva le proprie vie verso ogni elemento.
Come gestire gli id dinamici in Selenium o Playwright?
Non costruitevi sopra un test: un id che cambia a ogni build o a ogni caricamento della pagina non può trovare due volte lo stesso elemento.In un test a codice significa scrivere e mantenere a mano un altro localizzatore.In GUI Test Studio non c'è niente da scrivere: un test web sposta un id che sembra generato in fondo alla sua lista di vie verso l'elemento, dopo tutto ciò che una persona può leggere.
L'automazione dei test con self-healing funziona?
Aiuta quando un attributo cambia e l'elemento è ancora lì.Non può recuperare un elemento davvero sparito, e parte comunque da un localizzatore che qualcuno ha scritto e deve mantenere.Rivedete ogni riparazione, o potrebbe nascondere un cambiamento reale.
Come si testa un'app che non ha un albero di accessibilità?
A vista, sullo schermo.Giochi, canvas, grafici, sessioni Citrix e Desktop remoto e molti programmi disegnati su misura non espongono nulla che un locator possa raggiungere.GUI Test Studio trova i loro elementi dalla loro immagine e verifica il testo letto sullo schermo, senza cambiare nulla nell'applicazione.
Si possono automatizzare test end-to-end senza selettori né locator?
Sì.In GUI Test Studio registrate un test o lo descrivete in un prompt, e non ci sono selettori né locator da mantenere.Ogni controllo è un'immagine, un testo, la forma di un valore o una disposizione sullo schermo, e il GTS Engine + AI trova ogni elemento interrogando prima l'applicazione, e a vista quando questa non lo dice.
Che cosa succede quando un pulsante cambia di proposito?
Il controllo fallisce e mostra l'immagine attesa e quella effettiva fianco a fianco.Se il cambiamento è voluto, fate clic su Accetta l'effettivo come atteso nel report di affidabilità e salvate: il test è aggiornato, senza codice da modificare.
Selenium, Playwright, Cypress, AG Grid, Flutter, Qt, Java, Delphi, Citrix, Chrome, Edge, Firefox e Windows sono marchi dei rispettivi proprietari.
Continua a leggere
Tutti gli articoli
Affidabilità dei test
Test instabili: cause, costi e come fermare i falsi positivi
12 min di lettura
Test visivi
Test di screenshot pixel perfect: perché fallisce e che cosa scopre i veri bug visivi
12 min di lettura
Automazione dei test
Test manuali e test automatizzati: perché i test manuali non bastano per i test end-to-end
15 min di lettura