Prima l'accessibilità, la visione quando l'app non dice nulla: come GUI Test Studio trova ogni elemento
La maggior parte dei test end-to-end si rompe perché non riesce più a trovare un elemento.Il GTS Engine + AI trova ogni elemento in due modi: interroga l'applicazione tramite le sue informazioni di accessibilità, e trova l'elemento a vista quando l'applicazione non lo dice.Perché due strade verso lo stesso elemento rendono un test robusto, senza alcun locator da scrivere o mantenere.
6 min di letturaDal team di GUI Test Studio
Perché i test end-to-end si rompono
Chiedete a un team perché i suoi test end-to-end sono rossi, e la risposta raramente è un bug.Più spesso, un test non riusciva più a trovare un pulsante: uno sviluppatore ha rinominato una classe, un aggiornamento del framework ha cambiato la struttura della pagina, una finestra di dialogo si è aperta un po' più in basso, un tema ha cambiato un colore.L'applicazione andava bene; il test no.
I test basati sul codice trovano gli elementi con dei locator: un id, un selettore CSS, un XPath, una posizione.Ognuno è un'ipotesi su come è costruita l'applicazione, e ogni riprogettazione ne rompe qualcuno.Gli strumenti basati sulle immagini hanno la debolezza opposta: vedono lo schermo, ma non sanno nulla di ciò che l'applicazione dice di esso.
Due strade verso lo stesso elemento
Il GTS Engine + AI, il motore dietro ogni controllo di GUI Test Studio, non sceglie tra i due.Trova ogni elemento in due modi, e usa quello che funziona sullo schermo che ha davanti.
Chiedere
L'applicazione dice dove si trova l'elemento
Vedere
Oppure il motore lo trova a vista
Confrontare
Ciò che c'è, rispetto a ciò che vi aspettate
Riferire
L'esito, in parole semplici
Prima: chiedere all'applicazione
La maggior parte delle applicazioni descrive la propria interfaccia a Windows: ogni pulsante, campo, elenco ed etichetta con il suo nome, il suo ruolo e la sua posizione sullo schermo.Sono le informazioni di accessibilità che usano i lettori di schermo, e sono precise e immediate.Una pagina web fa lo stesso tramite i propri elementi.
Quando un test viene registrato, o descritto in un prompt, GUI Test Studio conserva ciò che l'applicazione ha detto di ogni elemento da cui è stato creato un controllo.Quando il test viene eseguito, il motore chiede prima di tutto quell'elemento all'applicazione dal vivo: dove si trova ora, se è visibile, se qualcosa lo copre.Un'asserzione testuale chiede all'applicazione cosa dice l'elemento prima di leggere le parole sullo schermo.
| Ciò che dice l'applicazione | Cosa dà al test |
|---|---|
| Il nome e il ruolo dell'elemento | Lo stesso pulsante viene ritrovato, anche tra altri che gli somigliano |
| La sua posizione sullo schermo | L'elemento viene trovato dove si è spostato, subito |
| Se è visibile o coperto | Una finestra di dialogo o un menu davanti a esso viene notato, e nessun clic ci passa attraverso |
| Ciò che dice | Un'asserzione testuale ottiene le parole esatte, mai una lettura sbagliata |
Poi: trovarlo a vista
Alcune applicazioni non dicono nulla.Un gioco disegna da sé i propri menu.Un canvas, un grafico o una mappa sono un'unica immagine per Windows.Un desktop remoto, una macchina virtuale o un telefono mostrato sul vostro schermo sono un'unica finestra senza nulla dentro.I programmi più vecchi disegnati dal proprio toolkit sembrano un unico riquadro vuoto.
Lì il GTS Engine trova l'elemento a vista, sullo schermo dal vivo, come fa una persona: cerca l'immagine dell'elemento nella sua area di ricerca, tollera le piccole differenze che ogni schermo presenta, e distingue gli elementi simili dalla loro posizione.Interviene anche quando la risposta dell'applicazione non regge: un elemento che segnala ma che è nascosto, coperto o lontano da dove dovrebbe essere.
Perché due strade rendono un test robusto
Ogni modo copre il punto debole dell'altro.Alle informazioni di accessibilità non importa come appare un elemento, quindi un nuovo tema, un carattere o un ridimensionamento dello schermo diverso non lo fanno perdere.Alla visione non importa come è stata costruita l'applicazione, quindi una classe rinominata, un nuovo framework o un'app senza alcuna informazione di accessibilità non lo fanno perdere nemmeno loro.
| Cosa è cambiato | Cosa trova ancora l'elemento |
|---|---|
| Il codice dietro il pulsante è stato riscritto | Entrambi: l'applicazione lo nomina ancora, e ha ancora lo stesso aspetto |
| La finestra si è spostata, o il layout è cambiato | L'applicazione dice dove si trova ora, e la visione lo trova lì |
| Un nuovo colore o tema | Le informazioni di accessibilità dell'applicazione |
| Un gioco, un canvas, un desktop remoto | La visione |
| Diversi pulsanti identici | I nomi dati dall'applicazione e la posizione dell'elemento li distinguono |
Il risultato è un test che continua a trovare ciò che cerca mentre la vostra applicazione cambia intorno a lui, e che fallisce per un solo motivo: ciò che vedrebbe l'utente è sbagliato.
Trovare è metà del controllo
Una volta trovato l'elemento, il GTS Engine confronta ciò che c'è sullo schermo con ciò che vi aspettate: l'immagine, le parole, la disposizione.Ignora il rumore che ogni schermo ha, anti-aliasing e compressione, e individua le regressioni reali, ciò che una persona chiamerebbe un cambiamento: un colore sbagliato, un'icona mancante, una parola che è passata da maiuscole a minuscole.
Quando un controllo non viene superato, l'analisi intelligente con IA, il lato IA facoltativo del motore, può dare un secondo sguardo e spiegare la differenza in parole semplici, con un modello nel cloud e la vostra chiave o un modello locale sul vostro computer, uno nostro o uno vostro.Vedete Analisi intelligente con IA.
Niente da configurare
Non c'è alcun locator da scrivere, nessuna impostazione di accessibilità da attivare, nessuna modalità da scegliere.Registrate il test voi stessi, oppure descrivetelo in un prompt a Claude, a ChatGPT o a un modello di IA sul vostro computer: GUI Test Studio conserva ciò che gli serve di ogni elemento, e a ogni esecuzione il motore decide quale strada lo trova.Tutto gira sul vostro computer.
Domande
GUI Test Studio usa l'albero di accessibilità?
Sì.Il GTS Engine + AI chiede prima all'applicazione dove si trova un elemento, tramite le sue informazioni di accessibilità su Windows, o tramite gli elementi propri della pagina web in un browser.Trova l'elemento a vista sullo schermo solo quando l'applicazione non lo dice.
E se la mia applicazione non ha informazioni di accessibilità?
Il test funziona comunque.I giochi, le aree di disegno, i desktop remoti e i programmi disegnati dal proprio toolkit non espongono nulla, quindi il GTS Engine trova i loro elementi a vista, sullo schermo, come fa una persona.
Devo scrivere locator o selettori?
No.GUI Test Studio conserva da solo ciò che gli serve di ogni elemento quando il test viene registrato o descritto in un prompt.Non c'è alcun locator, selettore o id di elemento da scrivere o mantenere.
Il controllo resta visivo quando l'elemento viene trovato tramite l'accessibilità?
Sì.Trovare l'elemento è la prima metà di un controllo.La seconda metà confronta sempre ciò che è sullo schermo con ciò che vi aspettate, così un test rileva ciò che i vostri utenti vedrebbero, come un colore sbagliato o un'icona mancante.
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.