Guadagni:
- Capacità di produrre un robusto codice di test dell'interfaccia utente con intelligenza artificiale, inclusi data-testid, open wait e assert che verifica il risultato dell'utente reale
- Capacità di evitare test fragili (selettore errato, attesa cieca) e di rendere i test facili da mantenere nella struttura del modello a oggetti della pagina
- Possibilità di testare ogni test dell'interfaccia utente prodotto violando il codice e rilevare e correggere i test falsamente superati
Ogni clic, ogni compilazione di modulo, ogni transizione di pagina effettuata da un utente in un browser non può essere testata più e più volte manualmente: ecco perché esiste l'automazione dei test dell'interfaccia utente (interfaccia utente; questi test imitano il comportamento dell'utente guidando a livello di codice un browser reale). Selenio, Drammaturgo e Cipresso sono gli strumenti più comuni per questo lavoro. L'intelligenza artificiale (AI) è altamente abile nello scrivere il codice per questi strumenti: tu descrivi un caso di test, l'AI ti fornisce una bozza di uno script di automazione realizzabile. Ma qui entra di nuovo in gioco l’avvertimento centrale di questo modulo: il codice di test dell’interfaccia utente prodotto dall’intelligenza artificiale può spesso essere test fragili che “si illuminano di verde ma verificano la cosa sbagliata” o sventolano al vento. Il tuo compito non è eseguire questo codice, ma assicurarti che verifichi effettivamente in modo affidabile la cosa giusta.
In questa unità miriamo a produrre test dell'interfaccia utente robusti, mantenibili e realmente validanti con l'intelligenza artificiale; Imparerai a evitare le prove fragili.
I tre pilastri di un solido test dell'interfaccia utente
1. Localizzatore elemento corretto. Un test utilizza un selettore per trovare l'elemento sulla pagina. L'intelligenza artificiale spesso produce selettori fragili: lunghi percorsi XPath (indirizzo eccessivamente dipendente dalla struttura della pagina), selettori basati su nomi di classi CSS (si interrompono quando cambia la progettazione). Il modo robusto è costituito da attributi stabili come data-testid che lo sviluppatore ha aggiunto per il test. Imporre questo esplicitamente all’intelligenza artificiale.
2. Attesa esplicita. La principale fonte di vulnerabilità nei test dell'interfaccia utente è la tempistica. Il sonno costante(3) (l'attesa cieca) è una cattiva pratica: a volte non basta, a volte fa perdere tempo. Il modo corretto è utilizzare l'attesa esplicita, che dice "attendi finché non appare questo elemento". Il drammaturgo lo fa in gran parte automaticamente; In Selenium bisogna richiederlo esplicitamente.
3. Affermazione significativa. Il test dovrebbe verificare il risultato che l'utente vedrà effettivamente, ad esempio "il numero dell'ordine è apparso sullo schermo", non solo "la pagina caricata". Se il test prodotto dall'IA non contiene un'asserzione o non è importante, quel test produce uno pseudo-promosso (1a unità).
Attenzione: quando vedi per la prima volta un test dell'interfaccia utente generato dall'intelligenza artificiale, controlla al massimo tre cose: i selettori sono impegnati (data-testid), sono in attesa (nessuna sospensione cieca) e l'asserzione verifica il risultato effettivo dell'utente? Se questi tre sono OK, il test è probabilmente solido.
Modello oggetto pagina
Man mano che i test diventano più grandi, scrivere selettori all'interno di ciascun test diventa un incubo per la manutenzione. Page Object Model (POM — modello di progettazione che raccoglie selettori e azioni per ogni pagina/schermata in un'unica classe) mantiene il selettore in un unico posto; Quando l'interfaccia cambia, la aggiorni in un unico file. Fare in modo che l’IA produca i test in una struttura POM, anziché direttamente; Ciò rende la manutenzione radicalmente più semplice.
Prompt debole / Prompt forte
Debole: "Scrivi un test Selenium per la pagina di accesso."
Forte: "Scrivi un test del flusso di accesso con Playwright (TypeScript). I selettori utilizzano solo data-testid; non utilizzare il controllo di ciò che vede l'utente, non del titolo della pagina."
Prompt potente; Lo strumento fornisce il linguaggio, la politica di selezione, la strategia di attesa, l'architettura (POM) e l'aspettativa di asserzione espressiva.
Testare l'indipendenza dei dati e dell'ambiente
Un solido test dell'interfaccia utente non solo è scritto correttamente, ma crea e pulisce anche i propri dati di test. I test generati dall'intelligenza artificiale spesso si collegano a un utente o a un record che si presume esista già nell'ambiente ("accedi come utente amministratore"). Questo presupposto viene meno quando il test viene eseguito in un altro ambiente o dopo un altro test (problema di dipendenza dall'ordine nell'unità 9). La verità è che ogni test crea i dati di cui ha bisogno all'inizio del test (o li prepara con una chiamata API) e li pulisce alla fine. Indicare esplicitamente all'IA di "impostare tutti i dati da cui dipende questo test all'interno del test; non assumere dati già pronti dall'esterno".
Un altro punto critico è non eseguire test dell'interfaccia utente con dati utente reali. Se nell'ambiente di test viene utilizzata una copia del database di produzione, questi record sono dati di persone reali; screenshot e registrazioni di prova potrebbero rivelare questi dati. Utilizzare conti di prova sintetici (fittizi); protegge la riservatezza e rende i test riproducibili. Effettuare un test di "annullamento dell'ordine" con un conto cliente reale è un errore sia etico che operativo.
Suggerimento: mantieni il minor numero possibile di test dell'interfaccia utente; Lascia la verifica effettiva all'API e ai test unitari, che sono veloci e stabili. Il test dell'interfaccia utente è costoso e fragile: utilizzalo solo per convalidare il flusso di utenti veramente end-to-end (testare la logica piramidale).
Confronto dei veicoli
caratteristica
selenio
drammaturgo
cipresso
lingue
Java, C#, Python, JS
JS/TS, Python, .NET, Java
JavaScript/TypeScript
standby automatico
No (a mano)
Sì (forte)
Sì
Multibrowser
largo
Chromium/Firefox/WebKit
Cromo dominante
tendenza alla fragilità
Alto (standby manuale)
basso
basso
Facilità di apprendimento
medio
facile
facile
funzionamento parallelo
Griglia richiesta
integrato
Residente/pagato
Quando si richiede un codice ad AI indicare chiaramente a quale veicolo appartiene; In caso contrario, potrebbe produrre codice confuso e non funzionante.
Quattro modelli copiabili
1) Generazione di test dell'interfaccia utente solida:
Il tuo ruolo: ingegnere senior dell'automazione dei test. Scrivi test con [strumento + linguaggio] per il seguente flusso: [flusso]. Regole: - Solo selettori data-testid; Utilizzo della classe XPath/CSS. - Nessun sonno cieco; Utilizza l'attesa esplicita/automatica. - Applica il modello a oggetti della pagina. - Lascia che ciascuna asserzione verifichi il risultato effettivo dell'utente. Commenta all'inizio di ogni test quali criteri di accettazione stai convalidando.
2) Controllo della fragilità:
Esaminare il seguente test dell'interfaccia utente per verificare la fragilità: - È presente un selettore instabile (long
3) Conversione in oggetto pagina:
Converti il seguente codice di test semplice nella struttura del modello a oggetti di pagina. Sposta selettori e azioni nelle classi di pagina; Lascia che il file di test legga solo il flusso dello scenario. [Strumento/lingua].Codice: [incolla codice]
4) Prova di pseudo-transizione:
Dimostrare che questo test dell'interfaccia utente è effettivamente valido: quale singola modifica apporto al codice dell'applicazione che renderà ROSSO questo test? Se non riesci a trovare un cambiamento che interrompa il test, il test è inadeguato; aggiungi asserzioni mancanti.Test: [incolla test]
tre mini custodie
Caso 1 – Liberazione dal selettore fragile. Dei 40 test prodotti da un team con l'intelligenza artificiale, il 70% non è riuscito a funzionare dopo un aggiornamento dell'interfaccia; nessuno di loro era un vero e proprio bug, erano tutti fragili selettori XPath. Il team ha convertito i test in una base di dati-testid con il modello di "controllo della fragilità". Nei successivi tre aggiornamenti dell'interfaccia, il numero di false interruzioni è sceso a zero; il tempo di manutenzione è diminuito da 6 ore a 30 minuti a settimana.
Caso 2: test dell'interfaccia utente con superamento falso. L'intelligenza artificiale ha prodotto un test "aggiungi al carrello"; il test era verde. Quando è stato eseguito il modello "fake-proof-of-passage", il test sembrava controllare solo i clic sui pulsanti e il titolo della pagina, senza mai verificare se il contatore del carrello fosse aumentato o meno. Anche se la logica del carrello era completamente rotta, il test è stato superato. Aggiunta asserzione vera (il badge del carrello è "1").
Caso 3 – Trappola di attesa cieca. Nel test del selenio prodotto dall'IA, dopo ogni passo c'era il sonno(2); 60 test hanno richiesto 14 minuti e occasionalmente si rompevano ancora. Dopo essere passato all'attesa aperta (attendere che l'elemento sia cliccabile) il tempo è sceso a 5 minuti e la fragilità è scomparsa. L'attesa cieca era lenta e inaffidabile.
Errori comuni
- Accettare i selezionatori fragili. Utilizzando i lunghi XPath generati dall'IA così come sono; I test si bloccano al primo cambio di interfaccia.
- Uscire dal "sonno" cieco. "Risolvere" le tempistiche con un'attesa fissa; sia lento che indeciso.
- Affermazione banale. Basta verificare che la pagina sia stata caricata; non controllare il risultato effettivo dell'utente (falso passaggio).
- Crescere senza POM. Distribuire i selettori a ciascun test; Aggiornamento manuale di dozzine di file quando l'interfaccia cambia.
- Non specificando lo strumento. Non dire all'IA quale strumento/linguaggio desideri; ottenere codice disordinato e non funzionante.
- Fidarsi quando si esegue il codice generato e si passa. Non testare infrangendo il codice.
In sintesi
L'automazione dei test dell'interfaccia utente verifica il comportamento dell'utente guidando il browser effettivo con il programma. L'intelligenza artificiale genera questo codice rapidamente, ma ci sono due grandi insidie: test fragili (selettore errato, attesa cieca) e test di passaggio falso (asserzione incompleta/banale). I tre pilastri di un solido test dell'interfaccia utente sono il selettore di commit (data-testid), l'attesa esplicita e l'asserzione che verifica il risultato effettivo dell'utente. Avere test generati nel Page Object Model semplifica radicalmente la manutenzione. Testa ogni test generato con la domanda "quale cambiamento lo interromperà?"
Compito dell'applicazione
Seleziona un flusso utente dal tuo progetto (ad esempio accedi o cerca). Chiedi all'IA di scrivere test con il modello di "generazione di test dell'interfaccia utente robusta". Quindi: (1) controlla e aggiusta i selettori e attende con un "controllo di fragilità", (2) prova che ogni test effettivamente valida con una "prova di pseudo-superamento", (3) infrangi il codice e osserva che il test diventa rosso. Riporta il numero di test prodotti e corretti e il numero di vulnerabilità e pseudo-pass riscontrati.
lista di controllo
- [] Ho fornito chiaramente all'intelligenza artificiale lo strumento, il linguaggio, la politica di selezione e l'architettura (POM).
- [ ] Ho verificato che i selettori siano data-testid.
- [] Mi sono assicurato di utilizzare l'attesa esplicita/automatica invece del sonno cieco.
- [] Ho verificato che ogni asserzione verifica il risultato effettivo dell'utente.
- [ ] Ho testato ogni test decifrando il codice; L'ho visto diventare rosso.
- [ ] Ho raccolto i test nella struttura del Page Object Model.