Blog

Automatisierte nächtliche API-Tests mit GitHub Actions, GitLab und Jenkins einrichten

Richten Sie einen nächtlichen Build für Ihre APIs ein: Planen Sie automatisierte Regressionstests in der CI mit der Apidog CLI. Kopieren und fügen Sie GitHub Actions-, GitLab- und Jenkins-Cron-Konfigurationen ein, um Fehler bis zum Morgen abzufangen.

Ashley Innocent

Ashley Innocent

15 June 2026

Automatisierte nächtliche API-Tests mit GitHub Actions, GitLab und Jenkins einrichten

enterprise.banner.title

enterprise.banner.feature1

enterprise.banner.feature2

enterprise.banner.feature3

enterprise.banner.ctaB

Ihre API-Tests bestehen bei jedem Pull Request. Der Build ist grün. Sie liefern aus. Dann um 9 Uhr morgens meldet jemand in einer anderen Zeitzone, dass der Checkout einen 500er-Fehler zurückgibt, obwohl niemand den Checkout-Code geändert hat. Was sich geändert hatte, war eine Sandbox eines Drittanbieters für Zahlungen, eine Datenbankmigration, die über Nacht lief, oder ein Token, das stillschweigend abgelaufen war. Ihre Pro-Commit-Tests haben dies nie erkannt, da sich in Ihrem Repository nichts bewegt hat.

Dies ist die Lücke, die ein Nightly Build schließt. Ein Nightly Build ist ein geplanter, vollständiger Testlauf, der einmal täglich, normalerweise in den frühen Morgenstunden, gegen Ihre realen Dienste und Umgebungen ausgeführt wird, anstatt nur bei Codeänderungen. Er fängt Fehler ab, die zwischen den Commits liegen: Daten-Drift, wackelige Integrationen, abgelaufene Anmeldeinformationen, langsame Leistungslecks und Vertragsbrüche, die durch Dienste verursacht werden, die Sie nicht kontrollieren. Speziell für APIs ist ein nächtlicher Regressionstestlauf das günstigste Frühwarnsystem, das Sie einrichten können.

Dieser Leitfaden führt Sie Schritt für Schritt durch den Aufbau dieses Systems mit Apidog. Sie entwerfen eine Regression Suite, generieren einen Befehlszeilenlauf mit der Apidog CLI, binden diesen in einen geplanten CI-Job in GitHub Actions, GitLab und Jenkins ein und erhalten einen Bericht, der vor dem Standup auf Sie wartet. Wenn Sie jemals einen Ausfall debuggt haben, den ein nächtlicher Lauf Stunden zuvor gemeldet hätte, ist dies der Workflow, der Ihnen diese Stunden zurückgibt.

Button

Warum Tests pro Commit nicht ausreichen

Continuous Integration hat uns gelehrt, bei jedem Push zu testen. Das ist gut, und Sie sollten es weiterhin tun. Aber Tests pro Commit beantworten eine enge Frage: „Hat diese Änderung etwas kaputt gemacht?“ Sie laufen schnell, sie laufen oft, und sie sind darauf ausgelegt, Entwickler nicht zu blockieren. Genau diese Beschränkung ist der Grund, warum sie eine ganze Klasse von Problemen übersehen.

Ein Nightly Build beantwortet eine umfassendere Frage: „Ist das System im Moment noch intakt, unabhängig davon, ob jemand es angefasst hat?“ Der Unterschied ist wichtig, denn die Produktion hat bewegliche Teile, die Ihre Commits niemals sehen.

Das Muster ist also zweistufig, nicht entweder/oder. Schnelle Smoke-Tests schützen jeden Commit. Eine tiefere Regression Suite läuft nach einem Zeitplan. Die Nightly-Ebene ist der Ort, an dem Sie alles platzieren, was zu langsam, zu breit oder zu sehr von der Live-Umgebung abhängig ist, um in den inneren Schleife zu gehören.

Was gehört in eine nächtliche API-Regression Suite

Bevor Sie etwas planen, entscheiden Sie, was der nächtliche Lauf tatsächlich überprüft. Eine Nightly Suite ist breiter als Ihre Commit-Gate-Smoke-Tests und gründlicher als ein schneller Gesundheits-Ping. Streben Sie eine Abdeckung an, die Ihnen peinlich wäre, wenn sie stillschweigend kaputt ginge.

Eine solide nächtliche API-Suite deckt ab:

Wenn Sie noch nie strukturierte Fälle wie diese geschrieben haben, ist die API-Testfallvorlage und das Beispiel ein guter Ausgangspunkt, und API-Assertions behandelt, wie man den Antworttext, Status, Header und das Timing präzise validiert.

Schritt 1: Erstellen Sie die Regression Suite in Apidog

Apidog behandelt Tests als integralen Bestandteil des API-Lebenszyklus, nicht als Anbau. Sie entwerfen Endpunkte und verketten diese dann zu Testszenarien, die reale Workflows widerspiegeln. Ein Szenario ist eine geordnete Liste von Schritten, wobei jeder Schritt eine API-Anfrage mit Assertions ist und Daten von einem Schritt zum nächsten fließen.

Hier ist die Form eines Checkout-Regressionstestszenarios:

  1. POST /auth/login: Anmeldeinformationen senden, 200 bestätigen, accessToken aus der Antwort in eine Variable extrahieren.
  2. POST /carts: einen Warenkorb mit dem Token erstellen, 201 bestätigen, cartId extrahieren.
  3. POST /carts/{cartId}/items: ein Produkt hinzufügen, 200 bestätigen, bestätigen, dass der Gesamtbetrag des Antworttextes dem erwarteten Preis entspricht.
  4. POST /checkout: den Warenkorb absenden, 200 bestätigen, bestätigen, dass order.status "confirmed" ist.
  5. GET /orders/{orderId}: die Bestellung zurücklesen, bestätigen, dass sie mit den richtigen Positionen gespeichert wurde.

In Apidog erstellen Sie dies visuell. Jeder Schritt erhält Assertions, ohne Boilerplate-Code schreiben zu müssen: eine visuelle Assertion wie „Antwortstatus ist 200“ oder „JSONPath $.order.status entspricht confirmed.“ Für die Schemakonformität kann Apidog die Antwort automatisch gegen die gespeicherte OpenAPI-Definition des Endpunkts validieren, sodass Sie nicht für jedes Feld eine manuelle Überprüfung schreiben müssen.

Einige Designregeln halten eine Nightly Suite wartbar:

Wenn Sie von einem anderen Tool kommen, passt dies sauber zu Konzepten, die Sie kennen. Das größere Bild des Verknüpfens von Szenarien finden Sie im Leitfaden zur API-Testorchestrierung, und wenn Sie noch nie einen strukturierten Test in Apidog ausgeführt haben, ist wie man eine API mit Apidog testet der schrittweise Ausgangspunkt. Laden Sie Apidog herunter und erstellen Sie ein Szenario, bevor Sie weiterlesen; der Rest dieses Leitfadens geht davon aus, dass Sie eine Suite zum Ausführen haben.

Schritt 2: Führen Sie die Suite über die Befehlszeile aus

Ein Nightly Build läuft unbeaufsichtigt, daher benötigt er einen Headless Runner. Das ist die Apidog CLI, ein npm-Paket, das Ihre gespeicherten Testszenarien von jedem Terminal aus ausführt, ohne dass eine GUI erforderlich ist. Es wurde genau dafür entwickelt: automatisierte Läufe innerhalb einer CI/CD-Pipeline.

npm install -g apidog-cli

Installieren Sie es global. Die CLI benötigt Node.js v16 oder höher.

Um ein Online-Szenario auszuführen (eines, das in Ihrem Apidog-Projekt lebt), benötigen Sie zwei Dinge: ein Zugriffstoken und die Szenario- oder Suite-ID. Generieren Sie das Token in Apidog unter den CI/CD-Einstellungen, wo sich ein „Zugriffstoken hinzufügen“-Button befindet. Behandeln Sie dieses Token wie ein Passwort; es gehört in ein Geheimnis, niemals in Ihr Repo.

Der Befehl zum Ausführen eines einzelnen Testszenarios sieht so aus:

apidog run \
  --access-token $APIDOG_ACCESS_TOKEN \
  -t 123456 \
  -e 789 \
  -r cli,html \
  --out-dir ./apidog-reports

Flag für Flag, unter Verwendung der realen Apidog CLI-Optionen:

Andere Flags verdienen ihren Platz in einem nächtlichen Lauf. -n, --iteration-count <n> wiederholt den Lauf, um Flakiness aufzudecken. -d, --iteration-data <path> speist eine CSV- oder JSON-Datei ein, sodass ein Szenario über viele Datenzeilen ausgeführt wird; perfekt für Grenztests. --env-var "key=value" und --global-var "key=value" injizieren Werte zur Laufzeit, wodurch Sie Anmeldeinformationen aus dem gespeicherten Szenario heraushalten.

Das müssen Sie sich nicht merken. Apidog generiert den genauen Befehl für Sie: Öffnen Sie das CI/CD-Panel im Client, wählen Sie Ihr Szenario oder Ihre Suite aus und kopieren Sie die vorgefertigte apidog run-Zeile direkt in Ihre Pipeline-Konfiguration. Führen Sie es zuerst einmal lokal aus, um zu bestätigen, dass es grün ist, bevor Sie es planen.

Schritt 3: Planen Sie es als Nightly Build

Ein Nightly Build ist dieser Befehl auf einem Timer. Jede CI-Plattform unterstützt geplante Jobs über Cron-Syntax. Das Muster ist bei allen identisch: ein täglicher Trigger, das Zugriffstoken aus einem Geheimnis, der CLI-Lauf und der Bericht, der als Artefakt archiviert wird.

GitHub Actions

GitHub Actions unterstützt einen Zeitplan-Trigger mit Standard-Cron. Dieser Workflow läuft täglich um 02:00 Uhr UTC und bietet auch einen manuellen Button über workflow_dispatch.

name: Nightly API Regression

on:
  schedule:
    - cron: '0 2 * * *'   # 02:00 UTC täglich
  workflow_dispatch:        # manuelle Läufe zulassen

jobs:
  regression:
    runs-on: ubuntu-latest
    steps:
      - name: Node einrichten
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Apidog CLI installieren
        run: npm install -g apidog-cli

      - name: Nächtliche Regression Suite ausführen
        run: |
          apidog run \
            --access-token $APIDOG_ACCESS_TOKEN \
            --test-suite ${{ vars.APIDOG_SUITE_ID }} \
            -e ${{ vars.APIDOG_ENV_ID }} \
            -r cli,html \
            --out-dir ./apidog-reports
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}

      - name: HTML-Bericht hochladen
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: apidog-nightly-report
          path: ./apidog-reports

Das if: always() beim Upload-Schritt ist wichtig: Sie möchten den Bericht auch dann archivieren, wenn der Lauf fehlschlägt, denn ein Fehler ist genau der Zeitpunkt, an dem Sie ihn lesen müssen. Beachten Sie, dass die geplanten Jobs von GitHub in UTC ausgeführt werden und während Spitzenlast verzögert werden können, planen Sie also nichts, was zu einer exakten Sekunde ausgelöst werden muss.

GitLab CI/CD

GitLab plant Pipelines über die UI (CI/CD > Zeitpläne) und nicht in der YAML, dann wird Ihr Job durch eine Regeln-Bedingung ausgelöst, sodass er nur nach Zeitplan läuft, nicht bei jedem Push.

nightly-regression:
  image: node:20
  rules:
    - if: '$CI_PIPELINE_SOURCE == "schedule"'
  before_script:
    - npm install -g apidog-cli
  script:
    - apidog run
        --access-token "$APIDOG_ACCESS_TOKEN"
        --test-suite "$APIDOG_SUITE_ID"
        -e "$APIDOG_ENV_ID"
        -r cli,html
        --out-dir ./apidog-reports
  artifacts:
    when: always
    paths:
      - apidog-reports/
    expire_in: 30 days

Legen Sie APIDOG_ACCESS_TOKEN als maskierte, geschützte CI/CD-Variable fest und erstellen Sie dann einen Pipeline-Zeitplan mit einem Cron-Ausdruck wie 0 2 * * *. Der rules-Block verhindert, dass dieser Job bei gewöhnlichen Commits ausgeführt wird.

Jenkins

In Jenkins erledigt eine pipeline mit einem Cron-Trigger dieselbe Aufgabe. Speichern Sie das Token als Anmeldeinformation und ziehen Sie es mit withCredentials herein.

pipeline {
    agent any
    triggers {
        cron('H 2 * * *')   // um 02:00 Uhr, H verteilt die Last
    }
    stages {
        stage('CLI installieren') {
            steps { sh 'npm install -g apidog-cli' }
        }
        stage('Nächtliche Regression') {
            steps {
                withCredentials([string(credentialsId: 'apidog-token',
                                        variable: 'APIDOG_ACCESS_TOKEN')]) {
                    sh '''
                        apidog run \
                          --access-token $APIDOG_ACCESS_TOKEN \
                          --test-suite $APIDOG_SUITE_ID \
                          -e $APIDOG_ENV_ID \
                          -r cli,html \
                          --out-dir ./apidog-reports
                    '''
                }
            }
        }
    }
    post {
        always {
            archiveArtifacts artifacts: 'apidog-reports/**', allowEmptyArchive: true
        }
    }
}

Das H in H 2 * * * ist eine Besonderheit von Jenkins: Es wählt eine stabile Minute innerhalb der Stunde aus, damit nicht alle Ihre nächtlichen Jobs genau um 02:00 Uhr gleichzeitig starten.

Dieses Cron-Feld ist auf allen drei Plattformen dasselbe. 0 2 * * * bedeutet Minute 0, Stunde 2, jeden Tag. Möchten Sie es zweimal pro Nacht, um Probleme früher zu erkennen? 0 2,14 * * *. Nur an Wochentagen? 0 2 * * 1-5. Wählen Sie eine Zeit, in der Ihre Staging-Umgebung ruhig ist und externe Sandboxes aktiv sind.

Schritt 4: Machen Sie Fehler unmöglich zu ignorieren

Ein nächtlicher Lauf, der in einem Log fehlschlägt, das niemand liest, ist schlimmer als kein nächtlicher Lauf; er schafft falsches Vertrauen. Der ganze Sinn ist die Warnung. Leiten Sie das Ergebnis dorthin, wo Ihr Team bereits hinschaut.

Der Exit-Code der CLI ist Ihr Hook. apidog run beendet sich mit einem Wert ungleich Null, wenn ein Szenario fehlschlägt, sodass CI den Job automatisch rot färbt. Von dort aus:

Eine Disziplin hält Nightly Builds vertrauenswürdig: Behandeln Sie einen Fehler als echten Bug, bis das Gegenteil bewiesen ist. Der schnellste Weg, eine Nightly Suite zu töten, ist, durch wackelige Tests jeden dazu zu bringen, das Rote zu ignorieren. Wenn ein Szenario sporadisch fehlschlägt, beheben Sie den Test oder die Umgebung; spielen Sie es nicht herunter. Das Ausführen mit -n zur Wiederholung eines Szenarios oder die Stabilisierung der Daten, von denen Ihr Szenario abhängt, deckt normalerweise die wahre Ursache der Instabilität auf.

Warum Apidog zum Nightly-Muster passt

Sie können eine nächtliche API-Pipeline aus einzelnen Teilen zusammenstellen: ein Tool zum Entwerfen, ein weiteres zum Schreiben von Tests, ein drittes zum Headless-Ausführen und ein angeflanschter Schema-Validator. Viele Teams arbeiten so, und es funktioniert, bis die Teile auseinanderdriften. Die Reibung zeigt sich um 2 Uhr morgens, wenn der Test, den der Runner ausführt, nicht mehr der tatsächlich ausgelieferten API entspricht.

Apidog fasst das in einem einzigen Workflow zusammen. Der Endpunkt, den Sie entwerfen, das Szenario, das Sie testen, das Schema, gegen das Sie validieren, und der Befehl, den Sie planen, verweisen alle auf dieselbe Quelle der Wahrheit. Wenn Sie einen Endpunkt ändern, bewegen sich das Szenario und die Schemaüberprüfung mit. Es gibt keinen Exportschritt, keine Sammlung, die stillschweigend veraltet, keine zweite Kopie des Vertrags, die synchron gehalten werden muss. Wenn Sie den Schmerz von Postman-Collections, die keine echte Quelle der Wahrheit sind, gespürt haben, ist dieses Single-Source-Design der Unterschied.

Die CLI ist dieselbe Engine wie die GUI, sodass ein Szenario, das Sie visuell an Ihrem Schreibtisch debuggen, in CI um 2 Uhr morgens identisch läuft. Sie erstellen und korrigieren Tests mit voller Sichtbarkeit und führen sie dann mit einem Befehl headless aus. Diese Symmetrie macht einen Nightly Build zu etwas, dem Sie vertrauen, anstatt etwas, das Sie beaufsichtigen müssen.

Häufig gestellte Fragen

Was ist der Unterschied zwischen einem Nightly Build und Continuous Integration?

Continuous Integration führt Tests bei jeder Codeänderung aus, um Regressionen in neuen Commits zu erkennen. Ein Nightly Build läuft nach einem festen Zeitplan, normalerweise über Nacht, unabhängig davon, ob sich etwas geändert hat. CI fängt das ab, was Ihr Team kaputt macht; der nächtliche Lauf fängt das ab, was die Außenwelt kaputt macht: abgelaufene Tokens, abgedriftete Abhängigkeiten, Datenänderungen und schleichende Leistungsverschlechterung. Ausgereifte Pipelines führen beides aus. Schnelle Smoke-Tests schützen jeden Commit, und eine breitere Regression Suite läuft nächtlich.

Wann sollte ein Nightly Build laufen?

Wählen Sie ein Zeitfenster, in dem Ihre Testumgebung ungenutzt ist und die externen Dienste, von denen Sie abhängen, erreichbar sind. Für viele Teams ist das 1 bis 4 Uhr morgens Ortszeit. Wenn Ihre APIs Sandboxen von Drittanbietern aufrufen, bestätigen Sie, dass diese zu dieser Stunde aktiv sind; einige Anbieter drosseln oder pausieren über Nacht. Vermeiden Sie es, genau zur vollen Stunde auf einer gemeinsam genutzten CI zu planen, wo Tausende von Jobs gleichzeitig ausgelöst werden; eine Verschiebung um ein paar Minuten (oder die Verwendung der H-Syntax von Jenkins) verteilt die Last.

Kann ich eine Nightly Suite gegen die Produktion laufen lassen?

Führen Sie Read-only-Überprüfungen sicher gegen die Produktion aus. Für alles, was Daten schreibt, richten Sie die Nightly Suite auf eine dedizierte Staging- oder Vorproduktionsumgebung mit realistischen Daten aus oder verwenden Sie idempotente Operationen und einen Bereinigungsschritt. Ein häufiges Muster ist ein vollständiger Read-Write-Regressionstestlauf gegen Staging plus ein kleiner Read-only-Smoke-Testlauf gegen die Produktion, um zu bestätigen, dass das Live-System erreichbar ist und korrekt reagiert.

Wie unterscheidet sich das von Monitoring?

Uptime-Monitoring beantwortet die Frage „Ist die API verfügbar?“ Eine nächtliche Regression Suite beantwortet die Frage „Ist die API korrekt?“ Monitoring pingt einen Endpunkt an und prüft auf einen 200er-Status. Ein Regressionstestlauf durchläuft vollständige Workflows, validiert Antworttexte gegen Ihr Schema, prüft Authentifizierungsgrenzen und bestätigt Geschäftsregeln. Sie ergänzen sich; Monitoring ist kontinuierlich und oberflächlich, nächtliches Testen ist periodisch und tiefgreifend.

Muss ich Code schreiben, um API-Tests zu planen?

Nein. Sie erstellen Szenarien visuell in Apidog ohne Skripte und kopieren dann den generierten apidog run-Befehl aus dem CI/CD-Panel. Der einzige „Code“ sind die wenigen Zeilen YAML- oder Pipeline-Konfiguration, die Ihrer CI-Plattform mitteilen, wann sie ausgeführt werden soll, und das sind die oben genannten Vorlagen. Wenn Sie lieber sehen möchten, wie Kommandozeilen-Runner im Allgemeinen abschneiden, behandeln Postman CLI vs Newman und Collections in CI ohne Newman ausführen die Alternativen.

Richten Sie Ihren ersten Nightly Run ein

Fangen Sie klein an. Wählen Sie einen kritischen Workflow, Ihren Anmeldeablauf oder Ihren Checkout-Pfad, und erstellen Sie ihn als einzelnes Apidog-Szenario mit echten Assertions. Führen Sie es lokal mit der CLI aus, bis es grün ist. Fügen Sie den generierten Befehl in einen geplanten Job ein, indem Sie eine der oben genannten Vorlagen verwenden. Leiten Sie den Fehler an Ihren Team-Chat weiter. Das ist ein funktionierender Nightly Build an einem Nachmittag.

Von dort aus erweitern Sie die Suite. Fügen Sie Szenarien für die nächstwichtigeren Abläufe hinzu, aktivieren Sie die Schema-Validierung durchgängig und legen Sie Performance-Budgets für Ihre stark frequentierten Endpunkte fest. Innerhalb einer Woche haben Sie ein Regressionstestnetz, das Fehler abfängt, die Ihre Pro-Commit-Tests nie erkennen sollten, und Sie werden um 2 Uhr morgens über diese in einer Chat-Nachricht informiert, anstatt um 9 Uhr von einem Kunden.

Button

Praktizieren Sie API Design-First in Apidog

Entdecken Sie eine einfachere Möglichkeit, APIs zu erstellen und zu nutzen

Kostenlos registrierenHerunterladen