Die drei Fragen im API-Performance-Testing
| Kapazität | Wie viel gleichzeitiger Traffic, bevor sich die Latenz verschlechtert. Braucht einen Lastgenerator. Vor Releases und nach Architekturänderungen ausführen. |
| Regression | Hat dieser Pull Request einen Aufruf langsamer gemacht als zuvor. Braucht eine Baseline und einen Vergleich, keine hohe Parallelität. |
| Korrektheit | Stimmt die Antwort, auch bei sperrigen Eingaben. Braucht Assertions auf Response-Bodies. Die günstigste der drei – und die, die am häufigsten ausgelassen wird. |
Warum sich die Regression zuerst zu automatisieren lohnt
Kapazitätstests sind teuer in der Durchführung und ändern sich zwischen Releases selten. Performance-Regression ist das Gegenteil: Sie schleicht sich nach und nach ein, Pull Request für Pull Request, und wenn ein Kapazitätstest sie endlich auffängt, haben Sie sechs Monate angesammelte Änderungen vor sich – und keine Ahnung, welche davon es war.
Ein einfacher Zeitvergleich pro Aufruf gegen eine Baseline, bei jeder Änderung ausgeführt, erkennt die zehnmal langsamere Query an dem Tag, an dem sie im Code landet. Das ist mehr wert als ein vierteljährlicher Kapazitätsbericht.
Korrektheit als Untergrenze
Keine einzige Zeitmessung bedeutet etwas, wenn die Antworten falsch sind. Ein Endpunkt, der ein leeres Array zurückgibt, ist extrem schnell. Das klingt offensichtlich – und genau so geht ein Dienst mit einem kaputten Filter und hervorragenden Latenzdiagrammen in Produktion.
Die Reihenfolge lautet also: Korrektheit, dann Regression, dann Kapazität. Die meisten Teams gehen umgekehrt vor, weil Kapazitätstests am ehesten nach Performance-Arbeit aussehen.
Was generierte Abdeckung beiträgt
API-Testpläne enthalten Grenzfälle und stressähnliche Fälle, die jene Eingabekombinationen sichtbar machen, die einen Endpunkt aus strukturellen statt aus Lastgründen langsam machen. Eine Query, die bei großer Seitengröße immer langsamer wird, taucht hier lange auf, bevor ein Kapazitätstest sie findet.
Das ist kein Lasttest und auch kein Ersatz dafür. Es ist die günstige Schicht darunter.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
Wenn Sie lieber nichts installieren möchten: Das Dashboard kann dasselbe. Alles Weitere, was die Kommandozeile beherrscht, steht im CLI-Repository.
Session, State, Reihenfolge und Cleanup behandelt die API-Testing-Dokumentation.
Wo die Regression meistens steckt
Wird ein Endpunkt zwischen zwei Releases langsamer, hat das fast immer eine von drei Ursachen, und wer sie kennt, verkürzt die Suche erheblich.
Eine Query, die ihren Index verloren oder eine Bedingung dazubekommen hat, die der Index nicht abdeckt. Das ist mit Abstand der häufigste Fall, und er erzeugt eine Änderung, die im Diff unsichtbar bleibt, weil das SQL in Ordnung aussieht.
Ein Aufruf, der früher ein Roundtrip war und jetzt mehrere braucht, meist weil eine Hilfsfunktion angefangen hat, verwandte Datensätze einzeln in einer Schleife zu laden. Der Code liest sich besser als vorher – und genau deshalb kommt er durch das Review.
Etwas ist gewachsen. Eine Antwort enthält eine Sammlung, die früher fünf Einträge hatte und jetzt fünfhundert, weil das Produkt erfolgreich war. Nichts ist kaputtgegangen, und der Endpunkt ist jetzt für alle langsam.
Taktung
Zwei Wege, und die Wahl hängt im Kern davon ab, wem die Pipeline gehört. Die GitHub App aus dem Dashboard anzubinden, erfordert keinerlei Änderung an Ihrem Repository, weil sie auf das Deployment reagiert, das Ihr Build ohnehin bereits erzeugt. Ein Schritt mit GitHub Actions bringt die Prüfung ins Repository, wo sie wie der Rest des Builds im Review landet.
Was TestSprite von den dreien abdeckt
Das dritte: Korrektheit – und die Grenzfälle, die strukturelle Langsamkeit sichtbar machen. Eine Query, die bei großer Seitengröße langsamer wird, zeigt sich als fehlschlagender oder langsamer Grenzfall, lange bevor ein Kapazitätstest sie erreicht, und zu einem Bruchteil der Kosten.
Die Abdeckung entsteht aus API Discovery plus Ihrer Spezifikation, wobei die Pläne die Kategorien Funktion, Schema, Autorisierung, Fehlerbehandlung und Grenzfälle umfassen. Auto-Authentication hält Sessions über einen ganzen Lauf hinweg am Leben, Dynamic Variables transportieren Werte zwischen Aufrufen, Dependency Chains leiten die Ausführungsreihenfolge daraus ab, was jeder Fall benötigt und erzeugt, und Auto-Cleanup entfernt genau das, was der Lauf angelegt hat.
Sie bekommen damit die Schicht, die den meisten Performance-Programmen fehlt: etwas, das bei jedem Pull Request läuft und bemerkt, wenn ein Endpunkt leere Ergebnisse liefert – also genau den Fehler, den ein Durchsatzdiagramm als hervorragend meldet.
Misst TestSprite die Latenz?
TestSprite prüft Korrektheit, nicht Kapazität. Zeitmessung und Durchsatz unter anhaltender Parallellast brauchen ein dediziertes Performance-Werkzeug.
Was ist eine sinnvolle Baseline?
Ihre eigenen früheren Werte in derselben Umgebung. Absolute Zielwerte, die von anderen Produkten übernommen sind, sagen sehr wenig aus.
Sollten Performance-Tests einen Merge blockieren?
Bei einer großen Regression auf einem kritischen Pfad: ja. Bei kleinen Schwankungen: nein – sonst verbringen Sie Ihre Zeit damit, Schwellenwerte zu justieren, statt auszuliefern.
Warum schwanken unsere Werte so stark?
Meist liegt es an einer geteilten Umgebung, einem kalten Cache oder unterschiedlichen Datenmengen. Bringen Sie das unter Kontrolle, bevor Sie einem Vergleich trauen.
Kann ein einziges Werkzeug alle drei abdecken?
Manche behaupten es. In der Praxis braucht die Kapazitätsfrage einen Lastgenerator und die Korrektheitsfrage Assertions auf Response-Bodies – und beides in einem Lauf gut zu machen, ist seltener, als das Marketing vermuten lässt.
Korrektheit, dann Regression, dann Kapazität.
API-Performance-Testing besteht aus drei Fragen mit drei Antworten. Die Regression lohnt es sich bei jeder Änderung zu automatisieren, die Korrektheit ist das Fundament unter allem, und die Kapazität ist die teure Frage, mit der die meisten Teams anfangen.