Teil eins: Wofür API-Testing und -Entwicklung mit Postman wirklich gut ist
Eine Collection ist eine teilbare, ausführbare Sammlung von Requests. Damit eignet sie sich hervorragend für drei Aufgaben: eine unbekannte API zu erkunden, eine API mit Beispielen zu dokumentieren, die sich tatsächlich ausführen lassen, und jemandem einen Reproduktionsfall zu übergeben, den diese Person selbst ausführen kann. Diese drei Dinge lohnt es sich gut zu machen, und sie werden häufig unterschätzt.
Der Fehler der Teams liegt nicht darin, Collections zu verwenden. Er liegt in der Annahme, die Collection ließe sich ohne weitere Änderungen zur Regressions-Suite ausbauen.
Teil zwei: Die vier Probleme
Jede API-Suite stößt früher oder später auf dieselben vier, in jedem Tool. Sie vorher zu kennen, macht den Großteil des Könnens aus.
Sessions laufen ab
Tokens laufen mitten im Lauf ab, und die Fehlschläge sehen aus wie Produktfehler.
Holen Sie Zugangsdaten aus den einzelnen Requests heraus und legen Sie sie ins Environment.
Werte wandern zwischen Aufrufen
Ein Create liefert eine ID zurück, die der nächste Aufruf braucht.
Fangen Sie sie ab und schreiben Sie sie niemals fest, sonst funktioniert die Suite genau einmal.
Die Reihenfolge zählt
Abdeckung ist ein Graph, eine Collection ist eine Liste.
Ein einziger früher Fehlschlag zieht einen ganzen Bildschirm voll unzusammenhängendem Rot nach sich.
Das vierte ist das Aufräumen. Datensätze häufen sich an, Eindeutigkeitsconstraints schlagen an, und Assertions auf die Paginierung driften. Löschen nach Namensmuster ist sicher, bis sich zwei Läufe überschneiden.
Teil drei: Assertions, die sich lohnen
Prüfen Sie den Body, nicht nur den Status. Ein 200 mit einer leeren Liste, in der ein Datensatz stehen sollte, ist ein Fehler, den eine reine Statusprüfung als bestanden verbucht.
Prüfen Sie, dass Fehlerfälle korrekt fehlschlagen. Fordern Sie etwas an, das es nicht gibt, und prüfen Sie Statuscode und Fehlerstruktur. Dienste, die ein 200 mit einem Fehler im Body zurückgeben, sind häufig.
Prüfen Sie über Endpunkte hinweg. Wenn ein Datensatz auf einen anderen verweist, rufen Sie diesen ab. Die interessanten Fehler stecken zwischen zwei Aufrufen.
Teil vier: Wenn die Collection nicht mehr reicht
Das Signal: Ihre Pre-request-Skripte sind zu einem kleinen Framework geworden, das nur eine Person versteht. Ab diesem Punkt sind die vier Probleme Ihre Infrastruktur und nicht die Ihres Tools, und das ist der Moment, die Regressionsabdeckung dorthin zu verlagern, wo sie als Teil des Produkts behandelt werden. TestSprite deckt sie als Auto-Authentication, Dynamic Variables, Dependency Chains und Auto-Cleanup ab, beschrieben in der API-Testing-Dokumentation.
Behalten Sie die Collection. Zum Erkunden und Dokumentieren ist sie nach wie vor das Beste, was Sie haben.
Teil viereinhalb: Die Skripte, die niemand reviewt
Die Pre-request- und Test-Skripte in einer Collection verdienen einen Moment Aufmerksamkeit, denn dort stecken die interessanten Fehler, und sie werden so gut wie nie reviewt.
Es ist JavaScript, es läuft in einer bestimmten Reihenfolge, es verändert gemeinsam genutzte Umgebungsvariablen, und es liegt in einem JSON-Export, der sich nicht sinnvoll diffen lässt. Eine Änderung an einem Skript zum Token-Refresh kann vierzig Requests zerlegen, während der Pull Request eine einzige geänderte JSON-Zeile zeigt. Teams entdecken das beim ersten Mal, wenn zwei Personen in derselben Woche dieselbe Collection bearbeiten.
Wenn Ihre Skripte so weit sind, dass Ihnen dieser Absatz bekannt vorkommt, ist die Collection zu Software geworden. Software braucht Reviews, Versionskontrolle und eigene Tests, und das ist ein seltsamer Ort, wenn das Ziel ursprünglich war, etwas anderes zu testen.
Teil fünf: So läuft es ohne Sie
Verbinden Sie das Repository im Dashboard, dann starten die Läufe aus dem Deployment, das Sie ohnehin erzeugen, oder fügen Sie stattdessen einen Schritt in Ihren eigenen Workflow ein.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
Dieselbe Einrichtung gibt es im TestSprite-Dashboard, falls Sie lokal nichts installieren möchten. Der restliche Funktionsumfang der CLI steht im CLI-Repository.
Teil sechs: Was TestSprite mit den vier Problemen macht
Jedes der vier hat einen Namen und wird als Produktfunktion behandelt statt als Ihr Skripting. Auto-Authentication konfiguriert den Login-Flow einmal und holt vor jedem Lauf ein frisches Token. Dynamic Variables greifen einen Wert aus einer Response ab und setzen ihn in den nächsten Request ein. Dependency Chains leiten aus dem, was jeder Testfall benötigt und erzeugt, eine sichere Reihenfolge ab. Auto-Cleanup löscht genau die Datensätze, die ein Lauf angelegt hat.
Die Abdeckung beginnt mit API Discovery über den laufenden Dienst und die Spezifikation, die Ihnen vorliegt, und der generierte Plan enthält die Kategorien Autorisierung, Fehlerbehandlung und Grenzfälle, also genau die, die übersprungen werden.
Der Vorteil für alle, die das Thema über Collections gelernt haben: Sie behalten die Collection zum Erkunden und Dokumentieren, wofür sie am besten taugt, und die Regressions-Suite ist kein JavaScript-Bestand mehr, den eine einzige Person pflegt.
Gibt es ein offizielles kostenloses PDF?
Das entscheiden die Verlage, und es ändert sich. Diese Seite ist das Arbeitswissen und keine Kopie eines Buches.
Sollte ich zuerst Postman lernen?
Ja. Es ist der schnellste Weg zu einem zutreffenden mentalen Modell einer API, und dieses Verständnis lässt sich auf jedes andere Tool übertragen.
Muss ich das Skripting lernen?
So weit, dass Sie es lesen können. Sobald Sie viel davon schreiben, ist das das Signal, dass Ihnen die Collection als Regressions-Suite zu eng geworden ist.
In welcher Reihenfolge sollte ich das lernen?
Requests senden, dann Bodies prüfen, dann Authentifizierung handhaben, dann Aufrufe verketten, dann aufräumen. Bei den letzten beiden hören die meisten auf, und genau dort liegt der Wert.
Reicht Newman für CI?
Es führt Collections in CI problemlos aus. Die Frage ist, wer die Skripte darunter pflegt, nicht welcher Runner sie ausführt.
Lernen Sie die vier Probleme, nicht das Menü.
Bei API-Testing und -Entwicklung mit Postman geht es vor allem um Sessions, abgefangene Werte, Reihenfolge und Aufräumen. Collections eignen sich hervorragend zum Erkunden und Dokumentieren; sobald die Skripte darunter zu einem Framework werden, verlagern Sie die Regressionsabdeckung dorthin, wo sie dafür gebaut ist.