Eine erfolgreiche Testsuite hilft nur, wenn sie weiterhin erfolgreich ist. Ihr Checkout-Workflow funktioniert heute, aber eine Abhängigkeit liefert um 2 Uhr morgens eine bahnbrechende Änderung aus, ein Zertifikat läuft am Wochenende ab, oder eine Konfigurationsabweichung legt den Zahlungs-Endpunkt an einem Sonntag lahm. Sie erfahren davon von einem verärgerten Kunden statt von einem Testlauf. Die Lösung ist langweilig und zuverlässig: Führen Sie Ihre API-Tests nach einem Zeitplan aus, ohne dass ein Mensch auf einen Knopf klickt, und lassen Sie sich sofort benachrichtigen, wenn etwas kaputtgeht.
Apidog verfügt genau dafür über eine integrierte Funktion für geplante Aufgaben (Scheduled Tasks). Sie weisen sie auf bereits erstellte Testszenarien, legen eine Häufigkeit fest, wählen eine Maschine aus, auf der sie ausgeführt werden sollen, und richten Benachrichtigungen ein. Dieser Leitfaden führt Sie ehrlich durch alles, einschließlich der aktuellen Grenzen. Wenn Sie neu im Ausführen unbeaufsichtigter Prüfungen an Live-Endpunkten sind, erklärt unser Leitfaden zu API-Monitoring den breiteren Kontext, und die Apidog-Dokumentation für geplante Aufgaben ist die Referenz für die Benutzeroberfläche.
Ein kurzer Hinweis, bevor Sie beginnen. Die Funktion für geplante Aufgaben ist derzeit als Beta gekennzeichnet, und die genaue Anzahl der geplanten Ausführungen, die Ihr Konto erhält, hängt von Ihrem Plan ab. Beachten Sie beides beim Lesen.
Was geplante Aufgaben tun (und wie sie sich von geplanten Scrapern unterscheiden)
Eine geplante Aufgabe in Apidog führt ein oder mehrere gespeicherte Testszenarien in einem wiederkehrenden Zyklus aus. Denken Sie an eine nächtliche Regression Ihrer Kern-API, einen Smoke-Test alle paar Stunden gegen die Staging-Umgebung oder einen Wochenend-Gesundheitssweep. Die Aufgabe merkt sich, welche Szenarien ausgeführt werden sollen, welche Umgebung verwendet werden soll, wie oft sie ausgelöst werden soll, welche Maschine die Arbeit ausführt und wer bei einem Fehlschlag benachrichtigt werden soll.
Wenn Sie den Ausdruck „geplante Aufgaben“ im Zusammenhang mit Web-Scraping oder Datenerfassung gesehen haben, handelt es sich um etwas anderes. Bei dieser Funktion geht es nicht darum, Seiten nach einem Zeitplan zu crawlen. Sie befindet sich im Testmodul und steuert Ihre API-Testszenarien: Zusicherungen, verkettete Anfragen, extrahierte Variablen, alles. Die Ausgabe ist ein Bestanden- oder Fehlgeschlagen-Bericht über Ihren API-Vertrag, kein gescrapter Datensatz.
Diese Unterscheidung ist wichtig, da sie ändert, was Sie konfigurieren. Sie schreiben keine Selektoren oder Crawl-Regeln. Sie wählen bestehende Testszenarien aus und teilen Apidog mit, wann und wo diese ausgeführt werden sollen.
Bevor Sie beginnen: einen selbst gehosteten Runner konfigurieren
Hier ist die Voraussetzung, die viele stolpern lässt. Um geplante Aufgaben auszuführen, müssen Sie zuerst einen selbst gehosteten Runner konfigurieren. Die Dokumentation ist diesbezüglich eindeutig.
Ein Runner ist eine Maschine, die die Testsuite ausführt. Wenn eine geplante Aufgabe ausgelöst wird, führt Apidog die Anfragen nicht in Ihrem Desktop-Client aus; es übergibt den Auftrag an den von Ihnen ausgewählten Runner, und jede Anfrage in der Suite wird von dieser Maschine gesendet. Eine CI-Box, ein kleiner, ständig aktiver Server oder eine dedizierte VM funktionieren alle gut. Was auch immer Sie wählen, es bleibt wach und erreichbar gemäß dem von Ihnen gewünschten Zeitplan.
Das Feld für das Runner-Ziel bietet zwei Auswahlmöglichkeiten: Apidog Cloud, gekennzeichnet als „bald verfügbar“, oder einen selbst gehosteten Runner. Da Apidog Cloud noch nicht verfügbar ist, ist ein selbst gehosteter Runner die einzige funktionierende Option heute. Planen Sie keine Cloud-Ausführung, bevor sie nicht ausgeliefert wurde.
Da Anfragen von der Maschine des Runners stammen, beeinflusst dessen Netzwerkumgebung Ihre Ergebnisse. Ein Runner hinter einem Unternehmens-VPN, in einer anderen Region oder einem Subnetz mit Firewall sieht möglicherweise andere Antworten als Ihr Laptop. Das ist normalerweise das, was Sie für eine realistische Überwachung wünschen, aber es ist gut zu wissen, wenn eine geplante Ausführung von einer lokalen abweicht.
Schritt für Schritt: eine geplante Aufgabe erstellen
Nachdem ein Runner registriert wurde, geschieht der Rest im Client. Das unten stehende Beispiel ist eine nächtliche Regressionstestsuite für eine E-Commerce-API, die Benutzerregistrierung, Produktlisten, Warenkorb und einen durch Stripe unterstützten Checkout abdeckt.
1. Geplante Aufgaben im Testmodul öffnen
Öffnen Sie das Testmodul im Apidog-Client. Klicken Sie in der Testordnerstruktur auf „Geplante Aufgaben“ (Scheduled Tasks), um jede geplante Aufgabe im Projekt anzuzeigen und zu verwalten. Alle Aufgaben im gesamten Projekt werden hier unter dem Abschnitt „Geplante Aufgaben“ angezeigt, dies ist also Ihr einziger Ort, um zu sehen, was wann läuft.
2. Die Aufgabe erstellen
Klicken Sie auf „+ Neu“, um eine neue geplante Aufgabe zu erstellen. Sie können hier auch einen Ordner erstellen, um verwandte Aufgaben zu gruppieren, was praktisch ist, sobald Sie separate Suiten für Staging und Produktion oder für verschiedene Dienste haben.
Geben Sie der Aufgabe einen klaren Aufgabenamen und eine Beschreibung. Diese dienen dazu, Aufgaben zu unterscheiden und ihren Zweck zu erklären, damit Ihr zukünftiges Ich weiß, was „Nächtliche Regression, Prod“ tatsächlich abdeckt, ohne sie öffnen zu müssen. Jede Aufgabe verfügt auch über einen Aktivierungs-/Deaktivierungs-Schalter, und Aufgaben in der Baumstruktur können jederzeit aktiviert oder deaktiviert werden.
3. Die auszuführenden Testszenarien auswählen
Wählen Sie unter „Testszenario“ (Test Scenario) ein oder mehrere Szenarien aus, die einbezogen werden sollen. Für das E-Commerce-Beispiel könnten Sie „Registrierung und Anmeldung“ (Signup and login), „Stöbern und zum Warenkorb hinzufügen“ (Browse and add to cart) und „Checkout mit Stripe-Testkarte“ (Checkout with Stripe test card) auswählen, sodass eine einzelne Aufgabe den gesamten kritischen Pfad abdeckt.
Jedes Szenario kann eigene Ausführungseinstellungen enthalten: Umgebung, Testdaten, Iterationen, Verzögerung und ob Anfragen und Antworten gespeichert werden sollen. Wenn Sie nicht jedes einzeln anpassen möchten, aktivieren Sie „Gleiche Ausführungskonfiguration verwenden“ (Use same execution config), um eine einzige Laufzeitkonfiguration auf alle ausgewählten Szenarien gleichzeitig anzuwenden. Das hält eine große Suite konsistent und schnell einrichtbar.
Die Umgebungsauswahl ist die Einstellung, die den meisten Menschen am wichtigsten ist. Richten Sie einen nächtlichen Produktionsmonitor auf Ihre Produktionsumgebung und einen Pre-Release-Smoke-Test auf Staging. Da jedes Szenario seine eigene Umgebung festlegen kann, kann eine Aufgabe sogar Ziele mischen, wenn Sie dies benötigen, obwohl es sauberer ist, eine Aufgabe auf eine einzige Umgebung zu beschränken.
4. Den Ausführungszyklus festlegen
Stellen Sie das Feld „Ausführungsplan“ (run-schedule) auf die gewünschte Frequenz ein. Je nachdem, auf welchem Bildschirm Sie sich befinden, wird dieses Feld als „Ausführungszyklus“ (Run Cycle) oder „Ausführungsmodus“ (Run Mode) bezeichnet; es ist dieselbe Einstellung, und die Bezeichnung variiert in der Benutzeroberfläche. Die Dokumentation enthält konkrete Beispiele, die Sie übernehmen können: jeden Sonntag um 23 Uhr, alle 6 Stunden oder alle 8 Stunden.
Für die nächtliche Regression hält ein täglicher Lauf spät in der Nacht die Geräusche gering und fängt Probleme vor dem Arbeitstag ab. Für einen Staging-Smoke-Test erhalten Sie alle 6 Stunden schnelleres Feedback, ohne die Umgebung zu überlasten.
5. Wählen Sie, wo es ausgeführt wird
Stellen Sie das Runner-Feld auf Ihren selbst gehosteten Runner ein. Wie das Zeitplanfeld ist dieses Feld auf verschiedenen Bildschirmen inkonsistent als „Läuft auf“ (Runs on), „Ausführen auf“ (Run On) oder „Läuft auf“ (Runs On) beschriftet; sie bedeuten alle dasselbe, die Maschine, die die Suite ausführt. Apidog Cloud erscheint hier auch, ist aber bald verfügbar, wählen Sie also Ihren selbst gehosteten Runner. Wenn Sie mehrere Allzweck-Runner registriert haben, wählen Sie den spezifischen aus, den Sie möchten, zum Beispiel einen Runner, der sich im selben VPC wie Ihre API befindet.
Denken Sie daran, dass alle in der Testsuite initiierten Anfragen von der hier angegebenen Maschine gesendet werden. Wählen Sie daher einen Runner, dessen Netzwerk Ihre API so sieht, wie es echter Datenverkehr tut.
6. Benachrichtigungen aktivieren
Aktivieren Sie „Benachrichtigung“ (Notification), damit die Aufgabe Sie informiert, wenn etwas kaputtgeht. Die Dokumentation empfiehlt dies für geplante Aufgaben, und es ist der Sinn von unbeaufsichtigten Läufen: Stille sollte Erfolg bedeuten, und ein Fehler sollte Sie schnell erreichen.
Apidog unterstützt diese Kanäle namentlich: Slack, Teams, Webhook, Jenkins und E-Mail. Für E-Mail werden Adressen von Projektmitgliedern automatisch vervollständigt, und Sie können Nicht-Mitglieder-Adressen manuell für eine Bereitschaftsrotation oder einen gemeinsamen Posteingang eingeben. Slack leitet Fehler direkt in Ihren Teamkanal; die Webhook-Option ermöglicht es Ihnen, Benachrichtigungen an alles andere zu verteilen, was Sie betreiben, von PagerDuty bis zu einem benutzerdefinierten Endpunkt.
Sie wählen auch, wann Benachrichtigungen ausgelöst werden: nach jedem Lauf oder nur bei Fehlern. Für eine gesunde nächtliche Suite hält „nur bei Fehlern“ den Kanal ruhig, bis es darauf ankommt. Während eines wackeligen Rollouts gibt „jeder Lauf“ Ihnen einen Herzschlag, der bestätigt, dass der Job überhaupt ausgeführt wird.
7. Speichern und aktivieren
Aktivieren Sie den Schalter der Aufgabe, um sie zu aktivieren, und sie beginnt im von Ihnen festgelegten Takt zu laufen. Sie können sie später deaktivieren, ohne sie zu löschen, was während eines geplanten Ausfalls oder eines lärmenden Migrationsfensters nützlich ist.
8. Die Ausführungshistorie lesen
Nach jeder Ausführung werden die Ergebnisse automatisch vom Runner zurück zum Server hochgeladen. Öffnen Sie den Abschnitt „Geplante Aufgaben – Ausführungshistorie“ (Scheduled Tasks - Run History) im Client, um sie anzuzeigen. Dies ist Ihr Audit-Trail: welcher Lauf bestanden hat, welcher fehlgeschlagen ist, welche Assertion gebrochen wurde und wann. Wenn eine Warnung in Slack landet, ist die Ausführungshistorie der Ort, an dem Sie die Details dazu einsehen können.
Erweiterte Einstellungen und Variationen
Sobald die grundlegende Aufgabe läuft, machen ein paar Optionen sie robuster.
Variablenbereich. Wenn Ihre Szenarien Daten zwischen den Läufen übergeben, bietet Apidog drei Freigabestufen, von der kleinsten zur größten: „Nur im aktuellen Testszenario teilen“ (Share only in the current test scenario), das eine Variable in einer dedizierten Datei für dieses eine Szenario speichert; „Über alle Testszenarien in der aktuellen geplanten Aufgabe teilen“ (Share across all test scenarios in the current scheduled task), das Szenarien in derselben Aufgabe ermöglicht, die Werte des anderen zu lesen; und „Über alle geplanten Aufgaben im aktuellen Ordner der geplanten Aufgaben teilen“ (Share across all scheduled tasks in the current scheduled task folder), der breiteste Bereich. Wählen Sie den kleinsten Bereich, der immer noch Ihren Datenfluss ermöglicht, damit ein Auth-Token aus einem Szenario nicht in ein nicht verwandtes gelangt.
Variablenpersistenz. Werte werden nur von einem Lauf zum nächsten übernommen, wenn die Option „Variablenwerte beibehalten“ (Keep variable values) auf der Test-Szenario-Designseite aktiviert ist. Wenn Ihr nächtlicher Lauf die erfasste Bestell-ID von gestern oder ein aktualisiertes Token benötigt, schalten Sie dies ein. Ohne diese Einstellung beginnt jeder Lauf sauber und jede annahmeübergreifende Annahme bricht stillschweigend.
Gruppierung mit Ordnern. Wenn Ihre Suite wächst, erstellen Sie Ordner unter „Geplante Aufgaben“ (Scheduled Tasks), um beispielsweise Produktionsmonitore von Pre-Release-Prüfungen zu trennen. Ein variabler Bereich auf Ordnerebene ermöglicht es dann einer Gruppe verwandter Aufgaben, die Einrichtung sauber zu teilen.
Planbeschränkungen. Die Anzahl der geplanten Ausführungen, die Sie erhalten, hängt von Ihrem Abonnement ab. Die Dokumentation verweist auf die Apidog-Preisseite für die genauen Zahlen, überprüfen Sie also Ihren Plan, bevor Sie eine aggressive stündliche Frequenz einstellen. Wenn Sie eine tiefere Abdeckung von Gruppierungen und intensiveren Zeitplanmustern benötigen, geht unser Leitfaden zu erweiterten geplanten Aufgaben noch weiter, und der verwandte Leitfaden zu bedingter Logik in API-Testszenarien hilft Ihnen, Szenarien zu erstellen, die überhaupt erst geplant werden sollten. Für Teams, die ihre ersten unbeaufsichtigten Prüfungen einrichten, passt der Artikel über nächtliche API-Testläufe in CI gut zu diesem.
Den Workflow mit der Apidog CLI automatisieren
Die Benutzeroberfläche für geplante Aufgaben (Scheduled Tasks UI) ist ein Weg. Die Apidog CLI ist der dritte und ein echter: Sie führen ein gespeichertes Szenario ohne Benutzeroberfläche aus und lassen dann cron oder Ihren CI-Anbieter die Frequenz handhaben. Um es klarzustellen, die CLI hat keinen nativen Zeitplanbefehl; die Zeitplanung erfolgt außerhalb von Apidog in dem Tool, dem Sie bereits für cron vertrauen.
Installieren und authentifizieren Sie sich, dann führen Sie ein Szenario anhand der ID gegen eine ausgewählte Umgebung aus. Der Apidog CLI Installationsleitfaden behandelt die Token-Einrichtung vollständig:
npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>
apidog run --access-token $APIDOG_ACCESS_TOKEN -t <SCENARIO_ID> -e <ENV_ID> -r cli,junit
Hier ist -t die ID des Testszenarios, -e ist die ID der Umgebung und -r ist der Reporter (cli, html oder junit, durch Kommas getrennt für mehrere). Um es nächtlich mit cron auszuführen, fügen Sie eine Zeile hinzu:
0 2 * * * cd /srv/api-tests && apidog run --access-token $APIDOG_ACCESS_TOKEN -t 4471 -e 88 -r junit >> run.log 2>&1
Oder lösen Sie es über einen geplanten GitHub Actions Job aus. In jedem Fall landet der JUnit-Bericht in Ihren bestehenden Pipeline-Dashboards. Den vollständigen Aufbau, einschließlich cron und GitHub Actions Zeitplan-Trigger, finden Sie unter Apidog CLI in Ihrer CI/CD-Pipeline.
FAQ
Kann ich heute geplante Tests in der Apidog Cloud ausführen? Noch nicht. Das Runner-Ziel listet Apidog Cloud als „bald verfügbar“ auf, daher ist ein selbst gehosteter Runner vorerst die einzige funktionierende Ausführungsmaschine. Registrieren Sie zuerst einen Runner und wählen Sie ihn dann in der Aufgabe aus.
Wie oft können geplante Aufgaben ausgeführt werden? So oft es Ihr Plan erlaubt. Die Frequenz selbst ist flexibel, mit dokumentierten Beispielen wie alle 6 Stunden oder jeden Sonntag um 23 Uhr, aber die Anzahl der geplanten Ausführungen wird durch Ihr Abonnement begrenzt. Überprüfen Sie die Apidog-Preisseite für die genaue Begrenzung Ihrer Stufe, anstatt eine Zahl anzunehmen.
Wie werde ich nur benachrichtigt, wenn ein Test fehlschlägt? Wählen Sie in den Benachrichtigungseinstellungen der Aufgabe die Option „nur bei Fehlern“ anstelle von „jedem Lauf“ und fügen Sie dann einen Kanal hinzu: Slack, Teams, Webhook, Jenkins oder E-Mail. Dies hält Ihren Kanal in „grünen“ Nächten ruhig und laut, wenn etwas kaputtgeht. Kombinieren Sie dies mit einem leichten API-Gesundheitscheck für ein schnelles Liveness-Signal neben der tiefergehenden Regressionstestsuite.
Warum unterscheiden sich meine geplanten Ergebnisse von meinen lokalen Testläufen? Weil die Anfragen von der Maschine des Runners stammen, nicht von Ihrem Laptop. Das Netzwerk, die Region und eventuelle VPNs oder Firewalls beeinflussen die Antworten. Das ist zu erwarten und oft die realistischere Ansicht dessen, was Ihre Benutzer erleben.
Meine Variablen werden bei jedem Lauf zurückgesetzt. Was habe ich übersehen? Die Option „Variablenwerte beibehalten“ (Keep variable values) auf der Test-Szenario-Designseite. Aktivieren Sie diese, damit erfasste Werte von einem Lauf zum nächsten bestehen bleiben. Ohne diese Option beginnt jeder geplante Lauf von Neuem, und jede laufübergreifende Abhängigkeit schlägt fehl.
Zusammenfassung
Geplante Tests verwandeln „wir glauben, dass die API funktioniert“ in „wir wissen es, und wir hätten es längst erfahren, wenn dies nicht der Fall wäre“. Erstellen Sie Ihre Szenarien einmal, registrieren Sie einen selbst gehosteten Runner, legen Sie einen Ausführungszyklus fest, richten Sie Slack oder E-Mail bei Fehlern ein und lassen Sie es laufen, während Sie schlafen. Wenn Sie die gleichen Prüfungen innerhalb einer Pipeline wünschen, bietet die CLI plus cron den dritten Weg ohne zusätzliche Tools. Laden Sie Apidog herunter, um Ihre erste geplante Regressionstestsuite einzurichten. Der Start ist kostenlos, keine Kreditkarte erforderlich.