Blog

Wie man automatisierte API-Tests in Bamboo CI ausführt

Integrieren Sie automatisierte API-Tests in Atlassian Bamboo CI. Erstellen Sie schema-basierte Tests in Apidog, führen Sie diese mit dem Apidog CLI aus und lassen Sie den Build fehlschlagen, wenn ein Vertrag verletzt wird.

Ashley Innocent

Ashley Innocent

15 June 2026

Wie man automatisierte API-Tests in Bamboo CI ausführt

Apidog für Unternehmen

On-Premises Bereitstellung

SSO & RBAC

SOC 2 konform

Apidog Enterprise entdecken

Ihr Build ist grün. Komponententests bestehen, das JAR ist gepackt, das Artefakt ist bereitgestellt. Dann trifft die erste echte Anfrage die Staging-API und ein nachgeschalteter Dienst gibt einen 500er-Fehler zurück, weil jemand vor zwei Commits ein Antwortfeld geändert hat. Der Build sagte, alles sei in Ordnung. War es aber nicht. Er hat die API einfach nie überprüft.

Dies ist die Lücke, die die meisten Bamboo CI-Pipelines aufweisen. Atlassian Bamboo ist gut darin, Code zu kompilieren, JUnit-Suites auszuführen und Artefakte zu versenden. Was es nicht von selbst tut, ist zu überprüfen, ob Ihre HTTP-Endpunkte sich immer noch so verhalten, wie es Ihr Vertrag verspricht. Wenn Sie dieses Sicherheitsnetz möchten, müssen Sie automatisierte API-Tests als Stufe in der Pipeline hinzufügen. Dieser Leitfaden zeigt Ihnen genau, wie das geht, indem Sie Apidog verwenden, um die Tests zu erstellen, und die Apidog CLI, um sie in einem Bamboo-Job auszuführen.

Am Ende haben Sie einen Bamboo-Plan, der bei jedem Push Ihre Endpunkte aufruft, Statuscodes prüft, Antwortkörper gegen Ihr Schema validiert und den Build fehlschlagen lässt, sobald ein Vertrag bricht. Keine Postman-Lizenz pro Platz, keine manuell geschriebenen Assertions-Skripte zur Wartung und ein echter HTML-Testbericht, der jedem Build beigefügt ist. Laden Sie Apidog herunter, wenn Sie mitmachen möchten; der CLI-Teil ist kostenlos und quelloffen.

Button

Warum API-Tests in Bamboo gehören, nicht danach

Viele Teams testen ihre APIs manuell oder, schlimmer noch, in der Produktion. Jemand klickt vor einer Veröffentlichung eine Sammlung gespeicherter Anfragen durch und begutachtet die Antworten. Das funktioniert, bis es nicht mehr funktioniert. Leute vergessen es. Veröffentlichungen finden an einem Freitag statt. Der eine Endpunkt, den niemand erneut überprüfen wollte, ist derjenige, der kaputtgeht.

Bamboo CI

CI existiert, um diese menschliche Variable zu eliminieren. Der ganze Sinn eines Build-Servers ist es, dass dieselben Prüfungen jedes Mal auf die gleiche Weise automatisch ablaufen, ohne dass sich jemand daran erinnern muss, sie auszuführen. Ihre Komponententests sind bereits dort. Ihre Integrationstests wahrscheinlich auch. API-Tests verdienen die gleiche Behandlung, und das aus einigen konkreten Gründen:

Der tiefere Kontext ist derselbe Grund, warum Teams überhaupt CI/CD einführen: Probleme frühzeitig erkennen, wenn sie günstig zu beheben sind, anstatt spät, wenn sie teuer und peinlich sind. API-Tests sind nur die Schicht dieser Strategie, die die meisten Pipelines überspringen.

Wie API-Tests in einen Bamboo-Plan passen

Bevor wir zur Schritt-für-Schritt-Anleitung kommen, ist es hilfreich zu verstehen, wo dies im Bamboo-Modell angesiedelt ist. Bamboo organisiert die Arbeit in Pläne, und jeder Plan enthält eine oder mehrere Stufen, die nacheinander ausgeführt werden. Jede Stufe enthält Jobs, und jeder Job ist eine Abfolge von Aufgaben. Aufgaben sind die eigentlichen Befehle: Checkout, Kompilieren, ein Skript ausführen.

Bamboo task

Ihre API-Tests werden zu einer Aufgabe innerhalb eines Jobs innerhalb einer Phase. Die natürliche Platzierung ist eine dedizierte Phase, die nach dem Erstellen und Bereitstellen Ihrer Anwendung in einer Testumgebung ausgeführt wird, da Sie etwas Live-fähiges benötigen, um Anfragen darauf zu senden. Ein typischer Plan sieht dann so aus:

Plan: Zahlungsdienst
├── Phase: Build
│   └── Job: Kompilieren & Komponententest
│       ├── Aufgabe: Quellcode-Checkout
│       └── Aufgabe: Maven, clean package
├── Phase: Bereitstellung auf Staging
│   └── Job: Bereitstellen
│       └── Aufgabe: Artefakt auf Staging bereitstellen
└── Phase: API-Tests          <- das ist, was Sie hinzufügen
    └── Job: API-Suite ausführen
        ├── Aufgabe: Quellcode-Checkout
        ├── Aufgabe: Skript, Apidog CLI installieren & ausführen
        └── Aufgabe: Final, Testbericht veröffentlichen

Wenn eine Aufgabe in der API-Testphase mit einem von Null verschiedenen Code beendet wird, markiert Bamboo die Phase als fehlgeschlagen und den gesamten Build als rot. Das ist genau das Verhalten, das Sie wünschen; ein gebrochener Vertrag sollte die Ausführung stoppen und nicht durchrutschen.

Das Tool, das die eigentliche Arbeit in dieser Skriptaufgabe erledigt, ist die Apidog CLI, ein Kommandozeilen-Runner, der Testszenarien ausführt, die Sie visuell in Apidog entwerfen. Sie erstellen den Test einmal, in einer GUI, ohne Code, und derselbe Test läuft unverändert in Ihrem Terminal und in Bamboo. Dies ist das gleiche Muster, das Teams verwenden, um API-Tests in jedem CI/CD-System zu automatisieren; Bamboo ist nur ein Ziel unter vielen.

Schritt 1: Erstellen Sie Ihre API-Tests in Apidog

Sie können keine Tests in CI ausführen, bevor Sie keine Tests haben. Apidog ist der Ort, an dem Sie sie entwerfen, und das Design ist visuell, sodass ein QA-Ingenieur, der keinen Code schreibt, die gleiche Suite erstellen kann wie ein Backend-Entwickler.

Öffnen Sie Apidog und erstellen Sie ein Testszenario. Ein Szenario ist eine geordnete Abfolge von API-Anfragen, die von oben nach unten ausgeführt werden, wobei jeder Schritt Daten aus den vorhergehenden Schritten wiederverwenden kann. Ein realistisches Szenario für einen Zahlungsdienst könnte sein:

  1. POST /auth/login mit gültigen Anmeldeinformationen, dann den Bearer-Token aus der Antwort extrahieren.
  2. POST /orders mit diesem Token, eine neue Bestellung erstellen, dann die zurückgegebene orderId speichern.
  3. GET /orders/{orderId} und bestätigen, dass die Bestellung mit dem richtigen Status angezeigt wird.
  4. DELETE /orders/{orderId} zur Bereinigung.

Fügen Sie für jede Anfrage Zusicherungen hinzu. Dies ist der Teil, der eine Anfrage in einen Test verwandelt. Apidog ermöglicht es Ihnen, visuell zu bestätigen, ohne Skripting:

Schema-basierte Zusicherungen sind erwähnenswert. Da Apidog Schema-First ist, kennt es bereits die Form, die Ihr Endpunkt in seiner API-Definition versprochen hat. Sie können mit einem Klick bestätigen, dass „diese Antwort ihrem Schema entspricht“, und diese einzige Prüfung schützt vor einer ganzen Kategorie von Vertragsabweichungen, umbenannten Feldern, falschen Typen, gelöschten Eigenschaften, ohne dass Sie eine einzige Zeile Code schreiben müssen. Wenn Sie von einem Skript-lastigen Tool kommen, beseitigt dies allein schon viel Wartungsaufwand. Es ist dasselbe visuelle Assertions-Modell, das Apidog zu einer gängigen Postman-Alternative für API-Tests macht.

Gruppieren Sie verwandte Szenarien in einer Testsuite, wenn Sie viele haben. Eine Suite ist einfach eine Sammlung von Szenarien, die Sie zusammen ausführen können, was Ihren CI-Befehl einfach hält; Sie weisen den Runner auf eine Suite anstatt auf zwanzig Szenarien.

Verwenden Sie Umgebungsvariablen für alles, was sich zwischen lokalen, Staging- und Produktionsumgebungen ändert: Basis-URLs, Anmeldeinformationen, API-Schlüssel. Definieren Sie eine Staging-Umgebung in Apidog mit baseUrl, die auf Ihren Staging-Host eingestellt ist. Sie werden der CLI zur Laufzeit mitteilen, welche Umgebung verwendet werden soll, sodass genau dasselbe Szenario gegen Staging in Bamboo und gegen Localhost auf Ihrem Laptop ausgeführt wird.

Schritt 2: Generieren Sie einen Apidog-Zugriffstoken und holen Sie sich die IDs

Bamboo läuft headless auf einem Build-Agent. Es kann sich nicht über einen Browser in Ihr Apidog-Konto einloggen, daher authentifiziert sich die CLI stattdessen mit einem Zugriffstoken.

Öffnen Sie in Ihrem Testszenario den CI/CD-Tab. Klicken Sie auf „Zugriffstoken hinzufügen“ und dann auf „Token generieren“. Kopieren Sie den Wert kurz an einen sicheren Ort; Sie werden ihn in Kürze als Bamboo-Variable speichern, nicht in ein Skript einfügen. Der Token ermöglicht es einem Build-Agent, die Tests Ihres privaten Projekts abzurufen und auszuführen.

Während Sie sich in diesem CI/CD-Tab befinden, generiert Apidog den vollständigen Ausführungsbefehl für Sie. Wählen Sie „Command line“ als Anbieter aus, und es wird etwas angezeigt, das Sie direkt kopieren können, wobei Ihre Testszenario-ID und Projekt-ID bereits ausgefüllt sind. Dieser kopierte Befehl ist die Grundlage Ihrer Bamboo-Aufgabe. Die Teile, die Sie interessieren:

Halten Sie diesen generierten Befehl bereit. Die nächsten Schritte passen ihn für Bamboo an.

Schritt 3: Speichern Sie den Token als Bamboo-Planvariable

Hinterlegen Sie niemals einen Token fest in einer Skriptaufgabe. Jeder, der Lesezugriff auf den Plan hat, und jeder, der Build-Logs liest, würde ihn sehen.

Gehen Sie in Bamboo zu Ihrem Plan, öffnen Sie die Plan-Konfiguration und suchen Sie den Tab „Variablen“. Fügen Sie eine neue Variable hinzu. Nennen Sie sie etwas Klares wie APIDOG_ACCESS_TOKEN und fügen Sie den Token als Wert ein. Bamboo maskiert Variablen, deren Namen password, secret oder token enthalten, also benennen Sie sie entsprechend, und der Wert wird in Logs und der Benutzeroberfläche ausgeblendet.

Zur Laufzeit macht Bamboo Planvariablen Skripten als Umgebungsvariablen zugänglich, präfixiert und in Großbuchstaben, wobei Punkte zu Unterstrichen werden. Eine Variable namens APIDOG_ACCESS_TOKEN ist für Ihre Shell-Aufgabe als $bamboo_APIDOG_ACCESS_TOKEN verfügbar. Sie werden diese Referenz verwenden, niemals den rohen Token, im Build-Skript.

Diese gleiche Hygiene gilt für alle anderen Geheimnisse, die Ihre Tests benötigen; Datenbankpasswörter, API-Schlüssel von Drittanbietern, Signaturgeheimnisse. Definieren Sie diese als maskierte Bamboo-Variablen und lesen Sie sie über das bamboo_-Umgebungspräfix aus.

Schritt 4: Fügen Sie die API-Testphase und eine Skriptaufgabe hinzu

Verbinden Sie es nun mit dem Plan. Fügen Sie in der Plan-Konfiguration eine neue Phase hinzu und nennen Sie sie „API-Tests“. Fügen Sie ihr einen Job hinzu und dann die Aufgaben in dieser Reihenfolge zum Job.

Aufgabe 1, Quellcode-Checkout. Auch wenn die Tests in der Apidog-Cloud liegen, bietet das Auschecken Ihres Repos dem Agenten ein sauberes Arbeitsverzeichnis und ermöglicht es Ihnen, lokale Datendateien (z.B. CSV-Iterationsdaten) zusammen mit Ihrem Code zu committen.

Aufgabe 2, Skript. Das ist der Kern der Sache. Wählen Sie eine Skriptaufgabe, stellen Sie den Interpreter auf Shell (oder /bin/sh) ein und verwenden Sie einen Inline-Skriptkörper. Das Skript installiert die Apidog CLI auf dem Agenten und führt Ihr Szenario aus.

Die Apidog CLI ist ein npm-Paket, daher benötigt der Agent Node.js v16 oder höher. Wenn Ihre Agenten bereits Node haben, können Sie die Installationszeile überspringen; andernfalls stellen Sie es über Bamboos Fähigkeiten oder einen Docker-basierten Agenten bereit. Hier ist ein vollständiger Skriptkörper:

#!/bin/sh
set -e

# Install the Apidog CLI globally on the agent
# Apidog CLI global auf dem Agenten installieren
npm install -g apidog-cli

# Run the test scenario against staging, output an HTML + CLI report
# Das Testszenario gegen Staging ausführen, HTML- + CLI-Bericht ausgeben
apidog run \
  --access-token "$bamboo_APIDOG_ACCESS_TOKEN" \
  -t 637132 \
  -e 358171 \
  -r cli,html \
  --out-dir ./apidog-reports

Ersetzen Sie 637132 durch Ihre tatsächliche Testszenario-ID und 358171 durch Ihre Staging-Umgebungs-ID, die Werte aus dem Befehl, den Apidog in Schritt 2 generiert hat. Einige Anmerkungen dazu, was jedes Flag bewirkt:

Das set -e oben ist wichtig. Es bewirkt, dass die Shell beim ersten fehlschlagenden Befehl beendet wird. Die Apidog CLI gibt bereits einen von Null verschiedenen Exit-Code zurück, wenn eine Zusicherung fehlschlägt, und dieser von Null verschiedene Code teilt Bamboo mit, den Build fehlschlagen zu lassen. Zusammen garantieren sie, dass ein gebrochener API-Vertrag den Build rot färbt, anstatt in den Logs begraben zu werden.

Wenn Sie API-Tests schon einmal in GitHub Actions integriert haben, wird Ihnen dies vertraut vorkommen; der Runner und die Flags sind identisch, nur der YAML-versus-Bamboo-UI-Wrapper unterscheidet sich.

Schritt 5: Veröffentlichen Sie den Testbericht als Bamboo-Artefakt

Ein roter Build sagt Ihnen, dass etwas kaputt ist. Der HTML-Bericht sagt Ihnen, was kaputt ist. Richten Sie es so ein, dass jeder Build den Bericht behält.

Gehen Sie im selben Job zum Tab „Artefakte“ und definieren Sie ein neues freigegebenes Artefakt:

Nach jedem Build sammelt Bamboo alles im Verzeichnis apidog-reports und hängt es an das Buildergebnis an. Öffnen Sie einen beliebigen Build, gehen Sie zum Tab „Artefakte“, und Sie können den HTML-Bericht herunterladen oder anzeigen; Ergebnisse Anfrage für Anfrage, die ausgeführten Zusicherungen und der genaue Antwortkörper für alles, was fehlgeschlagen ist. Dieser letzte Teil spart echte Debugging-Zeit. Anstatt die fehlgeschlagene Anfrage manuell erneut auszuführen, lesen Sie die erfasste Antwort direkt aus dem Build.

Für eine umfassendere Anzeige in Bamboo ist der junit-Reporter ebenfalls nützlich. Fügen Sie junit zur Liste -r hinzu und fügen Sie dann eine JUnit Parser-Aufgabe hinzu, die auf die JUnit-XML-Datei verweist. Bamboo rendert dann Testanzahlen, Erfolgs-/Fehlerraten und Fehlertrends nativ in der Build-Zusammenfassung, genau wie es Ihre Komponententestergebnisse anzeigt.

Schritt 6: Ausführen und Ergebnis lesen

Lösen Sie den Plan für den ersten Lauf manuell aus; in Bamboo wählen Sie „Plan ausführen“ von der Planseite. Beobachten Sie das Build-Log für die API-Testphase. Sie sehen, wie npm die CLI installiert, dann den Apidog-Lauf-Output, Szenarioname, jede Anfrage, jede Zusicherung und eine abschließende Zusammenfassungszeile mit Gesamtwerten.

Zwei Ergebnisse:

Alle Zusicherungen bestehen. Die CLI beendet mit 0, die Phase wird grün, der Build ist erfolgreich, und der HTML-Bericht wird trotzdem als Artefakt angehängt, sodass Sie einen Datensatz haben. Gut. Machen Sie es nun automatisch; stellen Sie den Plan so ein, dass er bei jedem Commit in Ihrem Hauptzweig ausgelöst wird (Plan-Konfiguration, Trigger, Repository-Polling oder ein Webhook). Von nun an führt jeder Push Ihre API-Suite ohne menschliches Zutun aus.

Eine Zusicherung schlägt fehl. Die CLI beendet mit einem von Null verschiedenen Code, set -e stoppt das Skript, die Phase wird rot und der Build schlägt fehl. Öffnen Sie das Artefakt, finden Sie die fehlgeschlagene Anfrage und lesen Sie die erfasste Antwort. Vielleicht hat sich ein Feld geändert. Vielleicht hat Staging einen 502-Fehler zurückgegeben, weil eine Abhängigkeit ausgefallen ist. So oder so wissen Sie innerhalb ein oder zwei Minuten nach dem Commit, der es eingeführt hat, was der gesamte Nutzen ist.

Eine realistische Konsolenzusammenfassung sieht so aus:

┌──────────────┬──────────┬──────────┐
│              │ executed │   failed │
├──────────────┼──────────┼──────────┤
│   iterations │        1 │        0 │
├──────────────┼──────────┼──────────┤
│     requests │        4 │        0 │
├──────────────┼──────────┼──────────┤
│   assertions │       11 │        1 │
└──────────────┴──────────┴──────────┘

  1 assertion failed:
    GET /orders/{orderId}
      expected $.data.status to equal "pending" but got "failed"

Diese eine fehlgeschlagene Zusicherung ist der ganze Grund, warum diese Phase existiert. Sie hat eine Vertragsregression abgefangen, die sauber kompiliert wurde und jeden Komponententest bestanden hat.

Die Suite in CI zuverlässig machen

Ein fehlerhafter API-Test ist schlimmer als kein Test, weil er das Team dazu bringt, rote Builds zu ignorieren. Ein paar Gewohnheiten halten die Suite vertrauenswürdig.

Testdaten isolieren. Jeder Lauf sollte das erstellen, was er benötigt, und sich danach selbst bereinigen, wie der oben genannte Erstellen-dann-Löschen-Bestellablauf. Tests, die von einem Datensatz abhängen, den jemand letzten Dienstag erstellt hat, werden in dem Moment fehlschlagen, in dem dieser Datensatz geändert wird. Führen Sie Tests gegen eine dedizierte Staging- oder Testumgebung aus, niemals gegen die Produktion.

Verwenden Sie datengesteuerte Läufe für Abdeckung ohne Duplikation. Wenn Sie denselben Endpunkt mit zwanzig verschiedenen Eingaben testen müssen, erstellen Sie nicht zwanzig Szenarien. Verwenden Sie ein einzelnes Szenario mit --iteration-data path/to/data.csv (oder -d), und die CLI führt es einmal pro Zeile aus. Committen Sie die CSV-Datei in Ihr Repo, damit sie zusammen mit dem Code ausgecheckt wird. Dies ist dasselbe datengesteuerte Testmuster, das Sie lokal verwenden würden, nur von einer Datei in CI gesteuert.

Die CLI-Version festlegen. npm install -g apidog-cli holt die neueste Version. Für reproduzierbare Builds legen Sie eine bekannte Version fest, npm install -g apidog-cli@<version>, damit ein CLI-Update das Verhalten zwischen zwei Builds desselben Commits nicht stillschweigend ändert.

Angemessene Timeouts festlegen. Fügen Sie --timeout-request 10000 hinzu, um bei einem hängenden Endpunkt schnell fehlzuschlagen, anstatt den Build hängen zu lassen, bis Bamboos eigenes Timeout ihn beendet. Eine klare Meldung „Anfrage-Timeout“ ist besser als ein vager, festgefahrener Build.

Bereitstellungen an der API-Phase absichern. Da die API-Testphase vor jeder Produktionsbereitstellungsphase läuft und eine fehlgeschlagene Phase den Plan stoppt, kann ein gebrochener Vertrag die Produktion nicht erreichen. Diese Reihenfolge ist Ihr Release-Gate. Es ist die praktische Version des Aufbaus einer echten CI/CD-Pipeline anstatt eines Builds, der nur kompiliert.

Szenarien schnell und fokussiert halten. Eine CI-Suite, die zwanzig Minuten dauert, wird nicht bei jedem Commit ausgeführt; die Leute werden sie auf nächtliche Läufe verschieben und das schnelle Feedback verlieren. Halten Sie die Pro-Commit-Suite auf Ihre kritischen Pfade, Authentifizierung, Kern-CRUD, Zahlungsfluss beschränkt und führen Sie die umfassende Edge-Case-Suite nach einem Zeitplan aus.

Zusammenfassung

Bamboo schützt Sie bereits vor Code, der nicht kompiliert, und Komponententests, die nicht bestehen. Das Hinzufügen einer API-Testphase erweitert diesen Schutz auf die Verträge, die Ihre Dienste tatsächlich über das Netzwerk offenlegen – die Ebene, auf der die meisten „aber es hat lokal funktioniert“-Vorfälle tatsächlich auftreten.

Die Einrichtung ist kurz: Erstellen Sie visuelle, schema-bewusste Tests in Apidog, generieren Sie einen Zugriffstoken, speichern Sie ihn als maskierte Bamboo-Variable und fügen Sie eine Skriptaufgabe hinzu, die apidog run mit Ihren Szenario- und Umgebungs-IDs ausführt. Veröffentlichen Sie den Bericht als Artefakt, sichern Sie Ihre Bereitstellungsphase damit ab und lösen Sie den Plan bei jedem Commit aus. Danach läuft alles automatisch. Jeder Push überprüft Ihre API, und ein gebrochener Vertrag färbt den Build rot, bevor er zu einem Ausfall führen kann.

Laden Sie Apidog herunter und erstellen Sie Ihr erstes Testszenario, dann fügen Sie den generierten CLI-Befehl in eine Bamboo-Skriptaufgabe ein. Das erste Mal, wenn es eine Regression abfängt, die sauber kompiliert wurde, hat sich die Phase für die zehn Minuten, die die Einrichtung dauerte, bezahlt gemacht.

Button

Praktizieren Sie API Design-First in Apidog

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

Kostenlos registrierenHerunterladen
Wie man automatisierte API-Tests in Bamboo CI ausführt