API-Testmethoden danach geordnet, was nur sie finden
Smoke
Findet: Das Deployment ist kaputt.
Kosten: Minuten. Immer ausführen. Nichts sonst sagt es Ihnen so schnell.
Funktional
Findet: falsches Verhalten an einem einzelnen Endpunkt, auch bei fehlerhaften Eingaben.
Kosten: moderat. Die Grundlage, die alles andere voraussetzt.
Integration
Findet: Abläufe, die scheitern, obwohl jeder einzelne Schritt besteht.
Kosten: höher, wegen des Zustands. Höchster Ertrag bei Fehlern, die Nutzer zu sehen bekommen.
Regression ist keine eigene Methode, sondern ein Rhythmus: bei jeder Änderung das auszuführen, was Sie ohnehin schon haben. Contract findet auseinanderdriftende Datenformate zwischen unabhängig deployten Services. Last findet Kapazitätsgrenzen. Fuzz findet Abstürze bei fehlerhaft aufgebauten Eingaben. Sicherheitsverhalten findet Fehler in der Autorisierung und ist deutlich günstiger als sein Ruf.
Die Methode, die falsch eingeordnet wird
Regressionstests werden als Methode aufgeführt und dann als Aktivität eingeplant, meist vor Releases. Genau das ist der Fehler. Regression ist das, was Ihre vorhandenen Tests tun, wenn sie laufen, und ihr Wert hängt fast vollständig davon ab, wie oft das geschieht. Eine Regressions-Suite, die monatlich läuft, ist eine Suite, die Probleme einen Monat zu spät findet.
Auswählen, ohne alles zu machen
Smoke plus funktionale Tests an kritischen Endpunkten. Die günstigste nützliche Abdeckung, die es gibt.
Integration entlang echter Nutzerabläufe. Dort stecken die Fehler, auf die Ihre Nutzer tatsächlich stoßen.
Prüfungen der Autorisierung. Günstig – und die am häufigsten ausgenutzte Schwachstelle in echten APIs.
Contract, nur wenn Services unabhängig deployt werden.
Last und Fuzz, wenn das Risiko es rechtfertigt. Beide sind berechtigt – und beide sind die falsche erste Investition.
Black Box gegen White Box
Eine Unterscheidung, die bei der Arbeit mit APIs weniger zählt als früher. Über die öffentliche Schnittstelle zu testen ist die richtige Voreinstellung, denn genau die nutzen Ihre Clients. White-Box-Wissen hilft bei der Auswahl, was Sie testen, nicht dabei, wie Sie es testen.
Wo die Pyramide bei APIs in die Irre führt
Die Testpyramide wurde für eine Welt aus Units und Benutzeroberflächen gezeichnet, und wer sie direkt auf die Arbeit mit APIs überträgt, macht einen verbreiteten Fehler.
Die Pyramide sagt: oben wenige langsame Tests. Bei APIs ist die teure Ebene nicht offensichtlich: Ein API-Test ist deutlich günstiger als ein Browser-Test und deutlich teurer als ein Unit-Test, und er findet Dinge, die keiner von beiden findet. Teams, die API-Tests der schmalen Spitze der Pyramide zuordnen, haben am Ende zu wenige davon; Teams, die sie der breiten Basis zuordnen, haben am Ende eine langsame Suite voller trivialer Assertions.
Ein besseres Denkmodell für Services ist die Frage, welche Ebene eine bestimmte Frage überhaupt beantworten kann. Ob eine Berechnung stimmt, gehört in einen Unit-Test. Ob der Endpunkt sie korrekt anwendet, gehört in einen API-Test. Ob Nutzer überhaupt dorthin gelangen, gehört über beide. Die Verhältnisse ergeben sich dann aus Ihrem Produkt statt aus einem Diagramm.
Was alle Methoden im Unterbau brauchen
Vier Dinge entscheiden, 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.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
Das Dashboard bietet dasselbe für alle, die keine lokale Installation möchten, und der vollständige Befehlsumfang steht im CLI-Repository.
Zwei Wege, und die Wahl hängt im Kern daran, wer die Pipeline verantwortet. Die GitHub App aus dem Dashboard anzubinden erfordert keinerlei Änderung an Ihrem Repository, denn sie reagiert auf das Deployment, das Ihr Build ohnehin erzeugt. Ein Schritt mit GitHub Actions bringt die Prüfung ins Repository, wo sie wie der Rest des Builds reviewt wird.
Welche Methoden TestSprite abdeckt
Funktional und Integration, dazu der verhaltensbezogene Teil der Sicherheit und Regression als Rhythmus statt als Aktivität. Generierte Pläne umfassen die Kategorien Funktion, Schema, Autorisierung, Fehlerbehandlung und Grenzwerte und lassen sich in natürlicher Sprache verfeinern.
Auto-Authentication hält Sessions über einen Lauf hinweg aktiv, Dynamic Variables tragen Werte zwischen Aufrufen weiter, Dependency Chains leiten die Ausführungsreihenfolge daraus ab, was jeder Testfall benötigt und erzeugt, und Auto-Cleanup entfernt genau das, was der Lauf angelegt hat. Erst dadurch kann Regression tatsächlich kontinuierlich laufen, statt vor Releases eingeplant zu werden – und das ist der mit Abstand größte Faktor dafür, ob eine Methode überhaupt Nutzen bringt.
Contract, Last und Fuzzing bleiben eigene Instrumente. Der Gewinn: Die drei ertragreichsten Methoden konkurrieren nicht länger mit der Feature-Arbeit um die Zeit fürs Schreiben von Tests, sodass die Abdeckung vorhanden ist statt geplant.
Welche Methode findet die meisten Fehler?
In den meisten Produkten die Integration, denn Fehler, die Nutzer zu sehen bekommen, entstehen meist zwischen Aufrufen und nicht innerhalb eines einzelnen.
Lohnt sich für Smoke-Tests eine eigene Suite?
Ja. Eine Zwei-Minuten-Prüfung, die bei jedem Deployment läuft, hat eine andere Aufgabe als eine Suite von zwanzig Minuten; vermischt man beides, läuft keine von beiden zum richtigen Zeitpunkt.
Brauchen wir Fuzz-Tests?
Wenn fehlerhaft aufgebaute Eingaben an Ihrem Service echte Folgen haben, ja. Bei den meisten internen APIs stehen sie in der Priorität hinter Autorisierungsprüfungen und Integrationsabdeckung.
Was ist mit explorativem API-Testing?
Wirklich wertvoll und nicht automatisierbar. Machen Sie es, wenn eine API neu ist oder sich stark verändert hat, und halten Sie anschließend fest, was Sie gefunden haben.
Wie ordnet sich das in die Testpyramide ein?
Nur lose. Die Pyramide wurde für Unit und UI gezeichnet. Bei APIs ist die nützliche Achse, was eine Prüfung als Einzige findet, und nicht, zu welcher Ebene sie gehört.
Wählen Sie danach aus, was jede Methode als Einzige findet.
API-Testmethoden ordnen Sie besser nach Kosten gegen einzigartigen Ertrag, statt sie auswendig zu lernen. Zuerst Smoke und funktionale Tests, Integration für die echten Fehler, Autorisierungsprüfungen, weil sie günstig sind, und Last zuletzt.