Tests in Ihrer Pipeline ausführen

Ein Test, jede Pipeline

gtr-cli, der Befehlszeilen-Runner, führt einen Test genau wie die Schaltfläche „Test ausführen“ aus: dieselben Prüfungen, derselbe Bericht, derselbe Verlauf.Es ergänzt, was eine Pipeline braucht: einen Exitcode, Ergebnisdateien, die Ihr CI-Tool versteht, und jeden Nachweis eines Fehlschlags in einem Ordner.

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

Den Build-Rechner vorbereiten

Ein GUI-Test wird auf einem echten Bildschirm wiedergegeben, also braucht der Rechner, der ihn ausführt, einen.

Erstellen Sie den Schlüssel auf Ihrer Kontoseite unter Maschinenschlüssel und führen Sie dies einmal auf dem Agenten aus, mit dem Windows-Konto, das die Pipeline nutzt:

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

gtr-cli whoami sagt, ob der Agent angemeldet ist und bis wann.Ohne Anmeldung startet kein Lauf: Er gibt eine Zeile aus, die mit COULD NOT RUN beginnt, und endet mit dem Exit-Code 3.

Build-Agenten: Maschinenschlüssel

Ihr erster Befehl

Führen Sie in einem Terminal auf dem Build-Rechner jeden Test eines Ordners aus:

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

--countdown 0 startet sofort (niemand sitzt am Bildschirm), --junit schreibt die Ergebnisdatei, die Ihr CI-Tool liest, und --artifacts sammelt Videos, Berichte und Fehlerbilder in einem Ordner.

gtr-cli check tests

Was Ihre Pipeline zurückbekommt

Die Läufe landen auch im Ergebnisordner jedes Tests, sodass der Verlauf des GUI Test Runner-Recorder die Pipeline-Läufe neben Ihren eigenen zeigt.

Fertige Beispiele

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

Einen Befehl bauen, ohne ihn zu tippen

In beiden Apps baut Befehlszeile & CI/CD (in GUI Test Studio im Menü „Datei“, im GUI Test Runner-Recorder im Menü „Test“) den Befehl für Sie: Haken Sie die gewünschten Optionen an, kopieren Sie das Ergebnis oder kopieren Sie das fertige Snippet für Ihr CI-Tool mit Ihren echten Pfaden.Die Registerkarte „Referenz“ erklärt jede Option.

Vergrößern

Optionen, die Sie brauchen werden

gtr-cli help

Fehlschläge an Jira melden

Ein fehlgeschlagener Test kann von selbst zu einem Jira-Vorgang werden: die Schritte zur Reproduktion, das erwartete und das tatsächliche Bild mit den markierten Änderungen, der Fehlerbericht als PDF und die Nachweise.Wird derselbe Fehler erneut gesehen, in einem anderen Build, Browser oder Gerät, erhält sein offener Vorgang einen Kommentar statt eines zweiten Vorgangs.

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

Die Verbindung kommt aus der Umgebung, sodass das Token nie in einer Befehlszeile oder einem Build-Protokoll erscheint: JIRA_BASE_URL (Ihre Jira-Site), JIRA_USER_EMAIL und JIRA_API_TOKEN.Bewahren Sie das Token in Ihrem CI-Tool als geheimen Parameter oder Passwortparameter auf.Auf einem Computer, auf dem der GUI Test Runner-Recorder mit Jira verbunden ist, wird stattdessen dessen gespeicherte Verbindung verwendet.

Der ganze Ablauf mit einem echten Vorgang und einem echten Build: Jira mit dem Vertrauensbericht verbinden.

Web-Apps auf einem Build-Rechner

Ein auf einer Web-App aufgezeichneter Test öffnet seinen Browser selbst, im Vollbild-Kioskmodus, und schließt ihn am Ende.Auf einem Build-Rechner braucht das die Bildschirmgröße und Anzeigeskalierung der Aufzeichnung, einen angemeldeten und entsperrten Desktop und einen Lauf, der durch sein eigenes Zeitlimit endet.Web-App öffnen sagt, was sonst passiert und was zu tun ist.

Dieselben Hinweise stehen im Werkzeug selbst:

gtr-cli help web-apps

Jeder Browser und jedes Gerät in der Pipeline

Ein Webtest, der für mehrere Browser und Geräte erstellt wurde, führt mit --branch all alle aus, jeden mit eigenem Eintrag in der JUnit-Datei und eigener Historie.Smartphones, Tablets und die anderen Zweige ohne Fenster laufen nebeneinander, sie brauchen also keinen eigenen Bildschirm.gtr-cli info listet den Namen jedes einzelnen auf, und gtr-cli generate erstellt die noch fehlenden.Siehe Jeder Browser und jedes Gerät aus einer einzigen Aufzeichnung.

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

Tests ohne ihre Aufzeichnung weitergeben

Eine Testdatei enthält ihre Aufzeichnung, die Sie zum Bearbeiten brauchen, aber nicht zum Ausführen.Datei, Als schlanken Runner-Test exportieren (.GTR) in GUI Test Studio schreibt denselben Test ohne sie: eine viel kleinere Datei für einen Build-Rechner oder für Kolleginnen und Kollegen, die Tests nur ausführen. gtr-cli und der GUI Test Runner-Recorder führen .GTR-Dateien wie jeden Test aus.

Wann ein Runner-Test sinnvoll ist

Nutzen Sie ihn überall, wo ein Test nur läuft: auf einer Build-Maschine, am Computer eines Testers, für eine Testsammlung, die weitergegeben oder bei Ihrem Code aufbewahrt wird.Der Lauf eines Runner-Tests liefert dasselbe Ergebnis und denselben Bericht wie sein Test.

Den Test selbst behalten

Ein Runner-Test lässt sich nicht bearbeiten: GUI Test Studio öffnet ihn nicht.Behalten Sie die .GTS als Original, bearbeiten Sie dort und exportieren Sie nach einer Änderung erneut.Auch GUI Test Runner-Recorder kann einen exportieren, über sein Menü Test oder die Export-Schaltfläche auf der Seite des Tests.

Ein Webtest mit mehreren Browsern und Geräten

Der Export fragt, was er enthalten soll.Alle Browser und Geräte legt jeden erzeugten Zweig in die eine Datei, bereit für --branch all.Nur die Aufzeichnung oder nur der angezeigte Zweig ergibt einen Runner-Test allein davon.Ein Runner-Test kann nur ausgeführt werden: Neue Browser und Geräte werden aus der .GTS erstellt.

Tests bei Ihrem Code aufbewahren

Tests sind gewöhnliche Dateien: Bewahren Sie sie in Ihrem Repository neben dem Code auf, den sie testen, und jeder Branch trägt die Tests, die zu ihm passen.