Eseguire i test nella pipeline

Un test, qualsiasi pipeline

gtr-cli, lo strumento di esecuzione da riga di comando, esegue un test esattamente come il pulsante Esegui test: stessi controlli, stesso report, stessa cronologia.Aggiunge ciò che serve a una pipeline: un codice di uscita, file di risultati che il vostro strumento di CI comprende, e ogni prova di un errore in un'unica cartella.

jobs:  gui-tests:    runs-on: [self-hosted, windows]    steps:      - run: gtr-cli run tests --format github --junit results.xml

Preparare la macchina di build

Un test di interfaccia grafica viene riprodotto su uno schermo reale, quindi la macchina che lo esegue deve averne uno.

Create la chiave nella pagina del vostro account, sotto Chiavi macchina, poi eseguite questo una volta sull'agente, con l'account Windows usato dalla pipeline:

gtr-cli login --key GTS-XXXX-XXXX-XXXX-XXXX

gtr-cli whoami indica se l'agente ha effettuato l'accesso e fino a quando.Senza accesso, un'esecuzione non parte: stampa una riga che inizia con COULD NOT RUN e termina con il codice di uscita 3.

Agenti di build: chiavi macchina

Il primo comando

In un terminale sulla macchina di build, eseguite tutti i test di una cartella:

gtr-cli run tests --countdown 0 --junit results\junit.xml --artifacts results\artifacts

--countdown 0 avvia subito (non c'è nessuno davanti allo schermo), --junit scrive il file dei risultati che il vostro strumento di CI legge, e --artifacts raccoglie video, report e immagini degli errori in un'unica cartella.

gtr-cli check tests

Cosa riceve la pipeline

Le esecuzioni finiscono anche nella cartella dei risultati di ogni test, così la Cronologia di GUI Test Runner-Recorder mostra le esecuzioni della pipeline accanto alle vostre.

Esempi pronti all'uso

jobs:
  gui-tests:
    runs-on: [self-hosted, windows]
    steps:
      - uses: actions/checkout@v4
      - run: gtr-cli run tests --countdown 0 --format github --junit results\junit.xml --summary results\summary.md --artifacts results\artifacts
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: gui-test-results
          path: results

Costruire un comando senza digitarlo

In entrambe le app, Riga di comando e CI/CD (nel menu File di GUI Test Studio, nel menu Test di GUI Test Runner-Recorder) costruisce il comando per voi: spuntate le opzioni che volete, copiate il risultato, oppure copiate il frammento già pronto per il vostro strumento di CI con i vostri percorsi reali.La sua scheda Riferimento spiega ogni opzione.

Ingrandisci

Opzioni che userete

gtr-cli help

Segnalare gli errori a Jira

Un test non superato può diventare da solo un ticket Jira: i passaggi per riprodurre, le immagini attesa e trovata con ciò che è cambiato evidenziato, la segnalazione di bug in PDF e le prove.Lo stesso difetto visto di nuovo, in un'altra build, su un altro browser o dispositivo, aggiunge un commento al suo ticket aperto invece di aprirne un secondo.

gtr-cli run tests --countdown 0 --jira on-failure --jira-project SCRUM --jira-labels ui-regression

La connessione viene dall'ambiente, quindi il token non compare mai in una riga di comando né in un log di build: JIRA_BASE_URL (il vostro sito Jira), JIRA_USER_EMAIL e JIRA_API_TOKEN.Nel vostro strumento di CI, conservate il token come segreto o come parametro password.Su un computer in cui GUI Test Runner-Recorder è connesso a Jira, viene usata invece la sua connessione salvata.

L'intero flusso, con una issue reale e un build reale: Collegare Jira al rapporto di affidabilità.

Le app web su una macchina di build

Un test registrato su un'app web apre il proprio browser da sé, in modalità kiosk a schermo intero, e lo chiude alla fine.Su una macchina di build questo richiede la dimensione dello schermo e il ridimensionamento della registrazione, un desktop con accesso effettuato e sbloccato, e un'esecuzione che termini per il proprio limite di tempo.Apri app web dice che cosa succede altrimenti e che cosa fare.

Le stesse note si trovano nello strumento stesso:

gtr-cli help web-apps

Ogni browser e ogni dispositivo, nella pipeline

Un test web creato per più browser e dispositivi li esegue tutti con --branch all, ciascuno con la propria voce nel file JUnit e la propria cronologia.I telefoni, i tablet e gli altri rami senza finestra vengono eseguiti affiancati, quindi non hanno bisogno di uno schermo proprio.gtr-cli info elenca il nome di ciascuno, e gtr-cli generate crea quelli ancora mancanti.Vedete Ogni browser e ogni dispositivo da una sola registrazione.

gtr-cli generate tests --branch missing
gtr-cli run tests --branch all --countdown 0 --junit results\junit.xml

Condividere i test senza la registrazione

Un file di test contiene la sua registrazione, che serve per modificarlo ma non per eseguirlo.File, Esporta come test leggero di sola esecuzione (.GTR) in GUI Test Studio scrive lo stesso test senza di essa: un file molto più piccolo per una macchina di build o per un collega che esegue soltanto i test. gtr-cli e GUI Test Runner-Recorder eseguono i file .GTR come qualsiasi test.

Quando usare un test di sola esecuzione

Usatelo ovunque un test venga solo eseguito: una macchina di build, il computer di un tester, un insieme di test che deve viaggiare o essere conservato con il vostro codice.L'esecuzione di un test di sola esecuzione dà lo stesso risultato e lo stesso report del suo test.

Conservate il test originale

Un test di sola esecuzione non può essere modificato: GUI Test Studio non lo apre.Conservate il .GTS come originale, modificatelo lì ed esportate di nuovo dopo una modifica.Anche GUI Test Runner-Recorder può esportarne uno, dal suo menu Test o dal pulsante di esportazione nella pagina del test.

Un test web con più browser e dispositivi

L'esportazione chiede cosa includere.Tutti i browser e dispositivi mette ogni ramo generato in un unico file, pronto per --branch all.Solo la registrazione, o solo il ramo che state mostrando, crea un test di sola esecuzione di quello soltanto.Un test di sola esecuzione può solo essere eseguito: i nuovi browser e dispositivi si creano dal .GTS.

Tenere i test con il codice

I test sono file ordinari: teneteli nel vostro repository accanto al codice che testano, e ogni branch porta con sé i test adatti.