Ein automatisiertes Testskript zu schreiben ist einfach. Eines zu schreiben, das auch sechs Monate später noch seinen Zweck erfüllt, ist der schwierige Teil. Viele Testskripte werden geschrieben, laufen einmal grün und verrotten dann stillschweigend, brechen bei nicht verwandten Änderungen, bestätigen nichts Sinnvolles und trainieren das Team, rote Builds zu ignorieren. Ein gutes Testskript ist präzise, isoliert und langlebig.
Dieser Leitfaden behandelt, was ein automatisiertes Testskript ist, die Struktur, die es zuverlässig macht, zwei Möglichkeiten, API-Testskripte zu schreiben, und eine Schritt-für-Schritt-Erstellung in Apidog.
Was ein automatisiertes Testskript ist
Ein automatisiertes Testskript ist ein definierter, wiederholbarer Satz von Anweisungen, der einen Teil Ihrer Software ausführt und das Ergebnis überprüft, ohne dass ein Mensch die Schritte ausführt. Das Skript sendet eine Eingabe, führt eine Aktion aus und vergleicht das Ergebnis mit einer Erwartung. Wenn sie übereinstimmen, ist es erfolgreich. Wenn nicht, schlägt es fehl und meldet den Grund.
Ein Testskript ist die ausführbare Form eines Testfalls. Der Testfall beschreibt die Absicht, die Eingabe, Aktion und das erwartete Ergebnis in menschlicher Sprache. Das Skript wandelt diese Absicht in etwas um, das eine Maschine bei jedem Commit ausführt. Ein Testfall kann zu einem Skript werden; ein Testszenario besteht normalerweise aus mehreren miteinander verketteten Skripten.
Der ganze Wert eines automatisierten Testskripts besteht darin, dass es jedes Mal auf die gleiche Weise ausgeführt wird. Das gilt nur, wenn das Skript deterministisch geschrieben ist. Ein Skript, das von der Reihenfolge anderer Skripte oder von Daten abhängt, die bei einer früheren Ausführung zurückgelassen wurden, ist keine zuverlässige Automatisierung; es ist eine fehleranfällige Belastung.
Die Struktur eines zuverlässigen Testskripts
Fast jedes gut geschriebene Testskript, in jeder Sprache oder jedem Tool, folgt der gleichen vierteiligen Struktur. Es wird oft als Arrange-Act-Assert bezeichnet, mit hinzugefügter Bereinigung.
Arrange (Vorbereiten). Richten Sie alles ein, was der Test benötigt: die Eingabedaten, Authentifizierung, alle Vorbedingungen. Das Skript sollte seinen eigenen Zustand erstellen, anstatt davon auszugehen, dass er existiert. Wenn der Test einen Benutzer benötigt, erstellt er einen oder verwendet eine bekannte Fixture, nicht was auch immer zufällig in der Datenbank ist.
Act (Ausführen). Führen Sie die eine zu testende Aktion aus. Ein gutes Skript testet ein Verhalten. Eine Anfrage senden, eine Funktion aufrufen, ein Ereignis auslösen – das ist die Aktion, und es sollte genau eine davon pro Skript geben.
Assert (Bestätigen). Überprüfen Sie das Ergebnis anhand der Erwartungen. Dies ist der Teil, in den Teams zu wenig investieren. Ein Skript, das nur „kein Fehler wurde geworfen“ oder „Status war 200“ bestätigt, testet kaum etwas. Starke Bestätigungen überprüfen die tatsächlichen Werte: den Antwortkörper, das Schema, die Nebenwirkungen, das Timing.
Cleanup (Bereinigen). Machen Sie rückgängig, was das Skript erstellt hat, damit es wieder von einem sauberen Zustand aus ausgeführt werden kann. Ein Skript, das Testdaten zurücklässt, wird schließlich mit sich selbst oder mit einem anderen Skript kollidieren.
Drei Gewohnheiten unterscheiden dauerhafte Skripte von anfälligen. Testen Sie eine Sache pro Skript, damit ein Fehler eine offensichtliche Ursache hat. Halten Sie Skripte unabhängig, damit sie in beliebiger Reihenfolge ausgeführt werden können. Und bestätigen Sie stabile Werte, niemals flüchtige Daten wie generierte IDs oder Zeitstempel, die ein Skript ohne wirklichen Grund fehlschlagen lassen.
Zwei Wege, API-Testskripte zu schreiben
Speziell für das API-Testing gibt es zwei gängige Ansätze, die zu unterschiedlichen Teams passen.
Der Code-First-Ansatz schreibt Testskripte in einer Allzwecksprache. In Python bedeutet das ein Framework wie pytest plus eine HTTP-Bibliothek; in JavaScript, einen Test-Runner plus fetch. Sie schreiben die Anfrage, die Assertions und das Setup als tatsächlichen Code, und die Skripte leben in Ihrem Repository zusammen mit der Anwendung.
Dieser Ansatz bietet volle programmatische Kontrolle. Komplexe Logik, benutzerdefinierte Fixtures und ungewöhnliche Assertions sind alles nur Code. Die Kosten bestehen darin, dass jedes Skript Code ist, den Sie schreiben und warten müssen, das Team die Sprachkenntnisse benötigt und viel Boilerplate, Authentifizierungsbehandlung, Anfragenaufbau, Antwort-Parsing, über Skripte hinweg neu geschrieben wird. Er passt zu Ingenieurteams, die Tests mit dem Code versioniert haben möchten und sich wohl dabei fühlen, diese Wartung zu übernehmen.
Der visuelle Ansatz erstellt das Testskript in einem dedizierten API-Testtool. Sie definieren die Anfrage, fügen Assertions per Klick hinzu und verketten Anfragen zu Szenarien, ohne Skriptcode für die gängigen Fälle zu schreiben oder zu warten. Tools wie Apidog gehen diesen Weg.
Dieser Ansatz beseitigt den Boilerplate-Code und macht Skripte für jeden im Team lesbar, nicht nur für diejenigen, die die Sprache beherrschen. Für seltene Logiken, die der visuelle Builder nicht ausdrücken kann, müssen Sie jedoch weiterhin auf benutzerdefinierten Code zurückgreifen. Er passt zu gemischten Teams, QA-geleiteten Tests und jedem, der schnell eine Testsuite ohne ein angehängtes Skriptprojekt zum Laufen bringen möchte.
Keiner der Ansätze ist falsch. Die entscheidende Frage ist, wer die Skripte pflegt und ob sie im Anwendungs-Repository leben sollen. Für die meisten API-Tests ermöglicht der visuelle Ansatz eine schnellere und wartungsärmere Ausführung einer zuverlässigen Suite.
Schreiben eines automatisierten API-Testskripts in Apidog
Hier ist der vollständige Ablauf für die visuelle Erstellung eines langlebigen API-Testskripts.
Schritt 1: Anfrage definieren. Importieren Sie den Endpunkt aus einer OpenAPI-Datei in Apidog oder definieren Sie ihn direkt. Dies ist der Arrange-Schritt; die Anfrage enthält ihre Methode, ihren Pfad, ihre Header und ihren Body.
Schritt 2: Testdaten hinzufügen. Legen Sie die Eingabe-Payload für den Fall fest, den Sie testen. Um viele Eingaben mit einem Skript abzudecken, hängen Sie eine CSV- oder JSON-Datei an, sodass das Skript einmal pro Zeile ausgeführt wird; datengesteuertes Testen ersetzt ein Dutzend nahezu identischer Skripte durch eines.
Schritt 3: Bestätigungen schreiben. Dies ist der Kern. Fügen Sie visuelle Prüfungen hinzu: Der Status entspricht dem erwarteten Code, wichtige Body-Felder existieren und haben die richtigen Werte, die Antwort entspricht dem Schema, die Antwortzeit liegt innerhalb des Budgets. Bei negativen Fällen bestätigen Sie die Fehlerform, nicht nur den Fehlercode. Widerstehen Sie dem Drang, flüchtige Daten zu bestätigen.
Schritt 4: Anfragen zu einem Szenario verketten. Echte Workflows umfassen mehrere Aufrufe. Erstellen Sie ein Szenario, das sich anmeldet, eine Ressource erstellt, sie zurückliest und löscht, wobei Werte von einem Schritt zum nächsten übergeben werden. Jeder Schritt ist ein Skript; zusammen testen sie einen vollständigen Ablauf.
Schritt 5: Benutzerdefinierte Skriptlogik nur bei Bedarf hinzufügen. Für Prüfungen, die visuelle Assertions nicht ausdrücken können, bedingte Logik, berechnete Werte, vergleichen von Anfragen, fügen Sie einen JavaScript-Prä- oder Post-Prozessor hinzu. Halten Sie dies minimal; die meisten Skripte benötigen es nie.
Schritt 6: Ausführen und den Bericht lesen. Führen Sie das Szenario aus. Apidog führt jedes Skript aus, evaluiert jede Assertion und meldet die genaue fehlgeschlagene Prüfung mit erwarteten und tatsächlichen Werten nebeneinander.
Schritt 7: Den Lauf automatisieren. Verknüpfen Sie das Szenario mit CI/CD, damit es bei jedem Commit ausgeführt wird. Ein Testskript, das nur läuft, wenn sich jemand daran erinnert, ist nicht wirklich automatisiert. Laden Sie Apidog herunter, um Ihr erstes Szenario zu erstellen.
Testskripte gesund halten
Eine Testsuite ist ein lebendiges Gebilde. Skripte, die bei der Veröffentlichung perfekt waren, veralten mit der Änderung der API. Drei Praktiken halten eine Suite vertrauenswürdig.
Aktualisieren Sie Skripte zusammen mit der API, nicht danach. Wenn sich der Vertrag eines Endpunkts ändert, ändert sich das Skript im selben Commit. Ein Skript, das ein altes Schema bestätigt, schlägt aus dem falschen Grund fehl und untergräbt das Vertrauen in jedes andere Skript.
Behandeln Sie fehleranfällige Skripte als echte Fehler. Ein Skript, das die meiste Zeit erfolgreich ist, ist schlimmer als gar kein Skript, weil es dem Team beibringt, dass Rot nicht gleich Kaputt bedeutet. Finden Sie die Ursache, meist einen gemeinsamen Zustand oder eine Timing-Annahme, und beheben Sie sie.
Überprüfen Sie Skripte wie Produktionscode. Ein Skript mit schwachen Assertions, einer reinen 200er-Prüfung, sieht grün aus und fühlt sich sicher an, während es fast nichts testet. Ein zweiter Leser bemerkt das.
Häufig gestellte Fragen
Was ist der Unterschied zwischen einem Testfall und einem Testskript? Ein Testfall beschreibt die Absicht in menschlicher Sprache, die Eingabe, Aktion und das erwartete Ergebnis. Ein Testskript ist die ausführbare Version, die eine Maschine ausführt. Der Fall ist der Plan; das Skript ist die Implementierung.
Muss ich programmieren können, um automatisierte Testskripte zu schreiben? Nicht für API-Tests mit einem visuellen Tool. In Apidog erstellen Sie Anfragen, Assertions und Szenarien per Klick und schreiben Code nur für ungewöhnliche Logik. Code-First-Frameworks erfordern jedoch Sprachkenntnisse.
Warum brechen meine Testskripte immer wieder ab? Die üblichen Ursachen sind das Bestätigen von flüchtigen Daten, Skripte, die voneinander abhängig sind, und das Nicht-Aktualisieren von Skripten, wenn sich die API ändert. Isolieren Sie Testdaten, halten Sie Skripte unabhängig und aktualisieren Sie sie zusammen mit dem Vertrag.
Wie viele Assertions sollte ein Testskript haben? Genug, um das Ergebnis wirklich zu überprüfen, typischerweise Status, wichtige Body-Felder, Schema und Timing. Eine einzelne Statuscode-Assertion ist zu wenig; sie ist erfolgreich, obwohl die Antwort falsch ist.
Sollten Testskripte im Anwendungs-Repository liegen? Bei einem Code-First-Ansatz normalerweise ja, damit Tests mit dem Code versioniert werden. Bei einem visuellen Tool leben Skripte auf der Testplattform und synchronisieren stattdessen mit der API-Definition. Beides funktioniert; Konsistenz ist wichtiger als die Wahl.
Wie schreibe ich Testskripte, bevor die API erstellt wird? Schreiben Sie sie gegen das API-Design. Wenn Sie eine OpenAPI-Spezifikation haben, können Sie daraus Anfragen und Assertions definieren und diese dann gegen einen Mock-Server ausführen, bis der tatsächliche Endpunkt existiert. Die Skripte sind bereit, sobald die Implementierung landet.
Was ist der Unterschied zwischen einem Testskript und einer Testsuite? Ein Testskript führt eine Prüfung aus. Eine Testsuite ist eine Sammlung von Skripten, die zusammen ausgeführt werden, oft eine ganze API oder Funktion abdecken. Suiten halten eine wachsende Menge von Skripten organisiert und ermöglichen es Ihnen, eine breite Abdeckung mit einem Befehl auszuführen.
Wie lang sollte ein automatisiertes Testskript sein? So kurz wie möglich, während es immer noch die vier Teile erfüllt: Arrange (Vorbereiten), Act (Ausführen), Assert (Bestätigen), Clean up (Bereinigen). Wenn ein Skript lang ist, testet es normalerweise mehr als eine Sache und sollte aufgeteilt werden. Ein Verhalten pro Skript macht Fehler leichter diagnostizierbar.