Esegui i tuoi test end-to-end a ogni build: un esempio con TeamCity che funziona con qualsiasi strumento CI/CD
L'automazione dei test end-to-end nella tua pipeline: aggiungi i tuoi test GUI Test Studio a un build TeamCity in un passo con gtr-cli e leggi ogni test, i fallimenti, il video e le immagini in TeamCity.Lo stesso comando esegue i tuoi test di interfaccia, funzionali e di regressione in Jenkins, GitHub Actions, GitLab, Azure DevOps o qualsiasi script.
7 min di letturaDal team di GUI Test Studio
Perché eseguire test end-to-end a ogni build
Un test end-to-end guida la tua applicazione come farebbe un utente: la apre, fa clic e digita lungo un intero flusso, e verifica cosa mostra lo schermo alla fine.È il test che coglie ciò che i test unitari non possono: un pulsante rotto, un modulo che non si invia più, una pagina che ha perso il suo contenuto.
Un test end-to-end che viene eseguito solo quando qualcuno si ricorda di lanciarlo coglie questi problemi tardi.Eseguilo invece a ogni modifica, e una regressione viene colta pochi minuti dopo il push, mentre la modifica è ancora fresca nella mente dello sviluppatore.
GUI Test Studio include un runner a riga di comando fatto proprio per questo: gtr-cli.Si installa con le app.Esegue i test end-to-end dell'interfaccia che hai registrato e modificato, senza aprire una finestra, e risponde come si aspetta una pipeline: un codice di uscita, un file JUnit, un log che il tuo strumento di CI capisce.
Uno sviluppatore fa un push
Qualsiasi branch
TeamCity avvia una build
Un solo passaggio di build
gtr-cli esegue i test
Sullo schermo della macchina di build, o senza finestra
Leggete il risultato
Test, log, video e immagini
Cosa serve
| Cosa | Perché | Dove trovarlo |
|---|---|---|
| Un test creato con GUI Test Studio | Il test end-to-end che la pipeline esegue, conservato nel tuo repository come qualsiasi file | Il vostro primo test, passo dopo passo |
| Una macchina di build Windows con GUI Test Studio installato | gtr-cli è incluso nel programma di installazione e riproduce il test su quella macchina | Installare e configurare |
| TeamCity (o un altro strumento di CI) | Avvia una build a ogni modifica e ne mostra i risultati | TeamCity di JetBrains |
Passo 1: preparare la macchina di build
Un test end-to-end riproduce clic e digitazione su uno schermo reale, quindi l'agente di build ha bisogno di un desktop su cui lavorare.
- 1
Installare GUI Test Studio e accedere una volta
Il programma di installazione mette gtr-cli nel PATH.Accedete alle app una volta su quella macchina, con l'account con cui viene eseguito l'agente.
- 2
Eseguire l'agente in una sessione Windows con accesso effettuato
Avviate l'agente TeamCity da una sessione utente con accesso effettuato, non come servizio Windows: un servizio non ha uno schermo su cui riprodurre un test.Mantenete la dimensione dello schermo e il ridimensionamento della registrazione.Vedete Preparare la macchina di build.
- 3
Oppure eseguire i test web senza finestra
Un test di un'app web può essere eseguito del tutto senza finestra del browser, con
--headless on.Non ha quindi bisogno di uno schermo libero, e più browser e dispositivi vengono eseguiti affiancati.
Passo 2: costruire il comando
Non dovete imparare le opzioni.In entrambe le app, aprite la finestra Riga di comando e CI/CD, spuntate ciò che volete e copiate il comando, oppure il frammento già pronto per il vostro strumento di CI con i vostri percorsi reali.
Questo è il comando che esegue la nostra pipeline di esempio:
gtr-cli run tests\Checkout\Checkout.GTS --branch all --countdown 0 --format teamcity ^
--junit ci-out\junit.xml --json ci-out\result.json ^
--artifacts ci-out\artifacts --bug-report pdf| Opzione | Cosa fa |
|---|---|
| --branch all | Esegue il test su ogni browser e dispositivo per cui è stato creato |
| --countdown 0 | Avvia subito: non c'è nessuno alla macchina di build che debba lasciare il mouse |
| --format teamcity | Scrive ogni test e ogni errore nel linguaggio di log proprio di TeamCity |
| --junit / --json | Scrive i risultati in file che qualsiasi strumento può leggere |
| --artifacts | Conserva il video dell'esecuzione, il suo report e le immagini di ogni errore |
| --bug-report pdf | Scrive una segnalazione di bug compilata per ogni test non superato |
Ogni opzione è spiegata in Eseguire i test nella pipeline e da gtr-cli help su qualsiasi computer in cui GUI Test Studio è installato.
Passo 3: aggiungere il passaggio di build in TeamCity
Create una configurazione di build per il vostro repository, aggiungete un passaggio di build e dategli il comando.Funzionano sia un passaggio PowerShell sia uno Command Line.Nel nostro esempio il passaggio esegue un piccolo script del repository che avvia il negozio, poi chiama gtr-cli.
Aggiungete un trigger VCS, così ogni push su ogni branch avvia una build.Questa è tutta la configurazione: TeamCity non ha bisogno di alcun plugin, perché gtr-cli parla il suo linguaggio di log.
Passo 4: leggere i risultati in TeamCity
Fate il push di una modifica e osservate.Ogni browser e dispositivo è un test a sé, quindi vedete a colpo d'occhio dove non ha funzionato.
Il log di build
gtr-cli scrive una riga per passaggio e dice chiaramente cosa non è stato superato: quale controllo, su quale browser e dispositivo, e perché.
La build non superata
La panoramica della build indica i test non superati e il loro motivo, senza aprire il log.
I test
La scheda Tests elenca ogni test della build.Poiché ogni risultato viene riportato come un test, TeamCity ne conserva anche la cronologia, la durata e quante volte non è stato superato.
Le prove
Gli artefatti contengono tutto ciò che l'esecuzione ha visto: una cartella per browser e dispositivo con il video dell'esecuzione, il suo report e la sua segnalazione di bug e, per ogni errore, le immagini attesa e trovata con ciò che è cambiato evidenziato in rosso.Aprite la stessa esecuzione in GUI Test Runner-Recorder per il report di affidabilità completo.
Ogni browser e ogni dispositivo in una sola build
Un test web può essere creato una volta ed eseguito su più browser e dispositivi: Chrome, Edge e Firefox, desktop, telefoni e tablet.Nella pipeline, --branch all li esegue tutti in una sola build, e quelli senza finestra vengono eseguiti affiancati.Leggete Ogni browser e ogni dispositivo da una sola registrazione.
Non usate TeamCity?Lo stesso comando ovunque
gtr-cli non è legato a nessuno strumento.È un programma che esegue test e restituisce un codice di uscita, quindi tutto ciò che può lanciare un comando può lanciare i tuoi test end-to-end: un server CI, un'attività pianificata, uno script di release.Test funzionali, test di regressione, smoke test, test di accettazione: comunque tu chiami i test che guidano la tua applicazione attraverso la sua interfaccia, vengono eseguiti allo stesso modo.
| Il vostro strumento | Cosa aggiungere al comando |
|---|---|
| TeamCity | --format teamcity |
| Azure DevOps | --format azure |
| GitHub Actions | --format github |
| Jenkins, GitLab, Bamboo e gli altri | --junit results\junit.xml, letto dal report dei test dello strumento |
| Uno script vostro | Nulla: leggete il codice di uscita, o il file --json |
- name: End-to-end tests
run: gtr-cli run tests --countdown 0 --format github --junit results\junit.xml --artifacts results\artifacts| Codice di uscita | Significa |
|---|---|
| 0 | Tutti i test sono stati superati |
| 1 | Un test non è stato superato |
| 2 | Il comando stesso era sbagliato |
| 3 | Un test non ha potuto essere eseguito, per esempio per un file mancante |
| 4 | L'esecuzione è stata interrotta |
Dove andare dopo
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.