Die fünf Tätigkeiten im API-Testing
Funktional. Tut ein einzelner Endpunkt das Richtige, auch bei fehlerhaften Eingaben? Fangen Sie hier an. Alles andere baut darauf auf.
Integration. Liefern Abläufe das richtige Ergebnis? Hier stecken die meisten Fehler, die Nutzer tatsächlich zu sehen bekommen.
Contract. Sind sich zwei Services über die Struktur einig? Wertvoll bei unabhängigen Deployments, blind für Korrektheit.
Die beiden anderen sind Last, die die Frage nach der Kapazität beantwortet und einen eigenen Generator braucht, und Sicherheitsverhalten, das größtenteils aus Autorisierungsprüfungen besteht und neben die funktionale Abdeckung gehört statt in eine vierteljährliche Übung.
Die Reihenfolge, die sich lohnt
Funktional, auf den Endpunkten, die zählen. Inklusive der Negativfälle. Alles andere baut darauf auf.
Integration, auf Ihren tatsächlichen Nutzerabläufen. Drei bis fünf Schritte pro Ablauf, nicht zwölf.
Autorisierungsprüfungen überall. Günstig – und Autorisierung auf Objektebene ist die am häufigsten ausgenutzte API-Schwachstelle.
Contract-Tests, wenn Services unabhängig deployt werden. Können Sie überspringen, wenn Sie alles gemeinsam ausliefern.
Last, vor Releases. Zuletzt, denn ein Lasttest auf einem fehlerhaften Endpunkt misst nur, wie schnell Sie falsch liegen können.
Die vier Probleme – unabhängig vom gewählten Werkzeug
Vier Dinge entscheiden darüber, ob eine API-Suite ihr erstes Jahr übersteht: Sessions, die ablaufen, Werte, die erst zur Laufzeit existieren, Aufrufe, die voneinander abhängen, und Datensätze, die niemand aufräumt. TestSprite deckt das mit Auto-Authentication, Dynamic Variables, Dependency Chains und Auto-Cleanup ab, beschrieben in der Dokumentation zum API-Testing.
Jedes Team begegnet ihnen in derselben Reihenfolge, und die meisten werden davon überrascht. Sie von Anfang an einzuplanen, ist der Unterschied zwischen einer Suite, die Bestand hat, und einer, die irgendwann stillgelegt wird.
Die Assertion, auf die es am meisten ankommt
Prüfen Sie den Body der Antwort, nicht nur den Status. Eine 200 mit einer leeren Liste, wo ein Datensatz stehen sollte, ist ein Fehler, den eine reine Statusprüfung als bestanden durchwinkt. Diese eine Gewohnheit findet mehr echte Defekte als jede andere einzelne Änderung.
Die ersten zehn Testfälle, konkret
Wenn die Suite noch leer ist, ist die Entscheidung, wo man anfängt, der schwerste Teil – und eine allgemeine Antwort kostet eine Woche. Hier ist eine Liste, die für die meisten Produkte funktioniert.
Drei für das zentrale Objekt, um das es in Ihrem Produkt geht: anlegen, wieder abrufen und die Felder prüfen, löschen und bestätigen, dass es weg ist. Zwei für die Autorisierung: derselbe Abruf ohne Zugangsdaten und mit den Zugangsdaten eines zweiten Nutzers. Zwei für die Eingabe: ein Pflichtfeld fehlt, und ein Wert liegt außerhalb des gültigen Bereichs. Zwei für den Ablauf, bei dem Ihnen vor einem Release mulmig wird – was auch immer das bei Ihnen ist. Einer für den Endpunkt, der letztes Mal kaputtgegangen ist.
Zehn Fälle, ein Vormittag Arbeit – und sie decken die Muster ab, aus denen die meisten Incidents entstehen. Was danach dazukommt, sollte sich daran orientieren, was tatsächlich schiefgeht, und nicht an einer Abdeckungsquote, denn der zweite Weg führt zu Suites, die groß sind und am Wesentlichen vorbeigehen.
Wo Sie heute anfangen
Richten Sie ein Projekt auf Ihren Service, lassen Sie die Discovery erfassen, was es gibt, und lesen Sie den generierten Plan, bevor Sie irgendetwas ausführen. Der Plan sagt Ihnen mehr über Ihre API als die ersten Ergebnisse, und er ist die Stelle, an der Ihr Produktwissen einfließt.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
Wenn Sie lieber nichts installieren möchten, erledigt das Dashboard dasselbe. Alles Weitere, was die Kommandozeile kann, steht im CLI-Repository.
Die GitHub App ist ein Webhook, den Sie im TestSprite-Dashboard einrichten. Er lauscht auf das Deployment-Event, das Ihre Pipeline ohnehin schon erzeugt – an Ihrem Repository ändert sich also nichts.
GitHub Actions legt den Schritt in Ihren eigenen Workflow, konfiguriert vom Terminal aus.
Wo TestSprite unter den fünf Tätigkeiten ansetzt
Funktional, Integration und die verhaltensbezogene Hälfte der Sicherheit. TestSprite testet den laufenden Service, erzeugt Pläne aus einem Discovery-Durchlauf plus Ihrer Spezifikation und deckt die Negativfälle ab, die handgeschriebene Suites auslassen.
Auto-Authentication hält Sessions über einen ganzen Lauf hinweg am Leben, Dynamic Variables reichen Werte zwischen Aufrufen weiter, Dependency Chains leiten die Ausführungsreihenfolge daraus ab, was jeder Fall braucht und erzeugt, und Auto-Cleanup entfernt genau das, was der Lauf angelegt hat. Diese vier entscheiden in jedem Werkzeug darüber, ob eine Suite ihr erstes Jahr übersteht, und dass es sie als Produktfunktion gibt, ist der Unterschied zwischen dem Erweitern einer Suite und ihrer Pflege.
Contract-Tests und Lasttests bleiben eigene Instrumente, und TestSprite läuft neben beiden. Was Sie bekommen, ist die Ebene, auf der die meisten für Nutzer sichtbaren Defekte liegen – abgedeckt ohne eigenes Framework und ausgeführt bei jedem Pull Request.
Wie viel Abdeckung brauchen wir?
Decken Sie die Abläufe ab, bei denen es Ihnen peinlich wäre, sie kaputtzumachen, plus jeden Endpunkt, der Geld oder Berechtigungen berührt. Erweitern Sie ausgehend von Incidents, nicht in Richtung einer Prozentzahl.
Sollten wir gegen die Produktivumgebung testen?
Gegen eine repräsentative Umgebung. Datensätze in der Produktion anzulegen und zu löschen, nur damit eine Testsuite zufrieden ist, bringt eigene Risiken mit sich.
Brauchen wir eine Spezifikation?
Sie hilft, ist aber nicht zwingend. Ein Discovery-Durchlauf über den laufenden Service plus ein Anforderungsdokument reichen für einen brauchbaren Plan.
Was ist mit Mocking?
Mocken Sie Drittanbieter, die Sie nicht kontrollieren. Den eigenen Service zu mocken heißt, den Mock zu testen.
Wie oft sollte die Suite laufen?
Bei jedem Pull Request für Funktionales und Integration, nach Zeitplan für Last. Eine Suite, die wöchentlich läuft, findet Probleme eine Woche zu spät.
Fünf Tätigkeiten, eine Reihenfolge.
API-Testing heißt funktional, Integration, Contract, Last und Sicherheitsverhalten. Machen Sie funktional und Integration zuerst, ergänzen Sie überall Autorisierungsprüfungen und planen Sie Sessions, erfasste Werte, Reihenfolge und Aufräumen von Anfang an ein.