Eine API kann jeden funktionalen Test bestehen und dennoch in der Produktion scheitern. Sie liefert die richtigen Daten, mit dem richtigen Statuscode, gegen das richtige Schema, und dann bricht sie zusammen, sobald tausend Benutzer gleichzeitig darauf zugreifen. Funktionale Tests sagen Ihnen, dass die API korrekt ist. Performance-Tests sagen Ihnen, dass sie korrekt und schnell genug ist, um echten Datenverkehr zu überstehen.
Dieser Leitfaden erklärt, was API-Performance-Tests sind, welche Testarten wichtig sind, welche Metriken zu beachten sind und wie man einen Performance-Test Schritt für Schritt in Apidog durchführt.
Was API-Performance-Tests sind
API-Performance-Tests messen, wie sich eine API unter Last verhält: wie schnell sie reagiert, wie viele Anfragen sie verarbeiten kann und ab welchem Punkt sie sich verschlechtert oder zusammenbricht. Es geht nicht darum, ob die Antwort korrekt ist; das ist funktionales Testen. Es geht darum, ob die Antwort schnell und zuverlässig ankommt, wenn das System unter Druck steht.
Das Ziel ist es, die Grenzen zu finden, bevor Ihre Benutzer es tun. Jede API hat eine Obergrenze, einen Punkt, an dem die Antwortzeiten ansteigen, Fehler auftreten oder der Dienst nicht mehr reagiert. Performance-Tests lokalisieren diese Obergrenze in einer kontrollierten Umgebung, damit Sie sie erhöhen, die Kapazität entsprechend planen oder zumindest wissen, dass sie existiert.
APIs sind ein gutes Ziel für Performance-Tests, da sie deterministisch und schnell aufrufbar sind. Es gibt keinen Browser zum Rendern, keine UI, auf die man warten muss. Sie senden eine Anfrage, Sie messen die Antwort. Das macht API-Performance-Tests kostengünstiger und stabiler als vollständige End-to-End-Lasttests.
Die Arten von Performance-Tests
„Performance-Testing“ ist ein Überbegriff. Darunter fallen mehrere unterschiedliche Testarten, von denen jede eine andere Frage beantwortet.
Lasttests wenden den tatsächlich erwarteten Datenverkehr an, Ihr normales und Spitzen-Anfragevolumen, und bestätigen, dass die API diesen innerhalb akzeptabler Antwortzeiten verarbeitet. Dies ist der grundlegende Test, den die meisten Teams zuerst durchführen.
Stresstests überschreiten den erwarteten Datenverkehr und erhöhen die Last, bis die API sich verschlechtert oder ausfällt. Ziel ist es, den Bruchpunkt zu finden und zu sehen, wie sie bricht. Verlangsamt sie sich elegant, oder gibt sie Fehler zurück und verliert Daten?
Spike-Tests wenden einen plötzlichen, starken Anstieg des Datenverkehrs an, wie ihn ein Flash-Sale oder ein viraler Moment erzeugt, und prüfen, ob die API ihn absorbiert oder zusammenbricht. Ein System, das eine gleichmäßige Last verarbeitet, kann bei einem Spike dennoch versagen.
Dauertests, auch Endurance-Tests genannt, halten eine moderate Last über einen langen Zeitraum, Stunden oder Tage, um schleichende Probleme aufzudecken: Speicherlecks, Erschöpfung von Verbindungspools, das Füllen einer Festplatte durch Protokolldateien. Diese zeigen sich niemals in einem fünfminütigen Lasttest.
Smoke-Tests sind die leichte Vorprüfung: eine geringe Last, um zu bestätigen, dass die API und das Test-Setup funktionieren, bevor Sie sich auf einen langen, teuren Testlauf einlassen.
Die meisten Teams benötigen mindestens Last-, Stress- und Dauertests. Spike-Tests sind wichtig, wenn Ihr Datenverkehr stoßweise auftritt.
Die wichtigen Metriken
Ein Performance-Test erzeugt Zahlen. Diese sollten Sie lesen.
Antwortzeit ist die Zeit, die die API benötigt, um eine Anfrage zu empfangen, zu verarbeiten und zurückzugeben. Betrachten Sie Perzentile, nicht nur den Durchschnitt. Der Durchschnitt kann gesund aussehen, während das 95. und 99. Perzentil, die langsamsten 5 % und 1 % der Anfragen, inakzeptabel sind. Echte Benutzer spüren die Ausläufer.
Durchsatz ist die Anzahl der Anfragen, die die API pro Sekunde abschließt. Er sagt Ihnen die tatsächliche Kapazität des Systems, unabhängig davon, wie viele Benutzer verbunden sind.
Gleichzeitige Benutzer oder virtuelle Benutzer ist die Anzahl der simultanen Aufrufer, die der Test simuliert. Die Kapazität wird oft als die maximale Gleichzeitigkeit ausgedrückt, die die API aufrechterhält, bevor die Antwortzeiten Ihr Budget überschreiten.
Fehlerrate ist der Prozentsatz der Anfragen, die unter Last fehlschlagen. Eine API, die schnell bleibt, aber bei hoher Gleichzeitigkeit 500er-Fehler zurückgibt, hat den Test dennoch nicht bestanden.
Ressourcennutzung, CPU und Speicher auf dem Server, verrät Ihnen, warum die Performance nachlässt. Wenn die Antwortzeiten steigen, während die CPU bei 100 % liegt, sind Sie rechengebunden; wenn die CPU untätig ist, aber die Latenz steigt, liegt der Engpass woanders, oft bei einer Datenbank oder einem nachgeschalteten Aufruf.
Ein guter Performance-Bericht verknüpft diese Punkte: bei dieser Gleichzeitigkeit erreichte der Durchsatz seinen Höhepunkt, die Antwortzeit des 95. Perzentils war dies, und die Fehlerrate war das.
Wie man einen API-Performance-Test in Apidog durchführt
Apidog enthält Lasttests, die in denselben Arbeitsbereich integriert sind, in dem Sie Ihre APIs entwerfen und funktional testen, sodass Sie kein separates Tool benötigen, um loszulegen.
Schritt 1: Wählen Sie den zu testenden Endpunkt oder das Szenario aus. Wählen Sie einen einzelnen kritischen Endpunkt oder ein mehrstufiges Testszenario, das einen realen Benutzerfluss widerspiegelt, z. B. Anmeldung gefolgt von einem Datenabruf. Das Testen eines realistischen Flows liefert ehrlichere Zahlen als das isolierte Belasten eines einzelnen Endpunkts.
Schritt 2: Bestätigen Sie zunächst die funktionale Korrektheit. Führen Sie die Anfrage mit ihren Assertions einmal aus. Es hat keinen Sinn, einen Endpunkt einem Lasttest zu unterziehen, der falsche Daten zurückgibt; beheben Sie die Korrektheit, bevor Sie die Geschwindigkeit messen.
Schritt 3: Konfigurieren Sie die Last. Legen Sie die Anzahl der virtuellen Benutzer und die Testdauer fest. Apidog ermöglicht es Ihnen, die Last schrittweise zu erhöhen, indem es Benutzer simuliert, die im Laufe der Zeit beitreten, anstatt alle auf einmal, was ein realistischeres Bild erzeugt und hilft, den Grad der Gleichzeitigkeit zu bestimmen, bei dem die Performance umschlägt.
Schritt 4: Führen Sie den Test aus. Apidog führt die Last aus und meldet live: Antwortzeiten, Durchsatz, Fehlerrate und wie sich jede Metrik mit steigender Gleichzeitigkeit ändert. Achten Sie auf den Wendepunkt, an dem die Antwortzeit schneller ansteigt als die Last.
Schritt 5: Lesen Sie die Ergebnisse und finden Sie den Engpass. Wenn die Antwortzeit des 95. Perzentils bei 300 gleichzeitigen Benutzern Ihr Budget überschreitet, ist das Ihre aktuelle Obergrenze. Vergleichen Sie dies mit der Server-CPU und dem Speicher, um die Ursache zu verstehen. Führen Sie den Test nach einer Korrektur erneut aus, um zu bestätigen, dass sich die Obergrenze verschoben hat.
Schritt 6: Für größere Anforderungen nach JMeter exportieren. Wenn Sie eine verteilte Lastgenerierung jenseits einer einzelnen Maschine benötigen, kann Apidog das Szenario nach JMeter exportieren, sodass Sie dieselbe Testdefinition beibehalten, während Sie die Lastquelle skalieren.
Laden Sie Apidog herunter, um Ihren ersten Lasttest gegen einen Endpunkt auszuführen, den Sie bereits besitzen.
Ein echtes Performance-Ergebnis lesen
Zahlen ohne Interpretation sind Rauschen. Nehmen wir einen konkreten Lauf: Sie testen GET /products mit virtuellen Benutzern, die über fünf Minuten von 0 auf 500 ansteigen.
Für die ersten 200 Benutzer bleibt die Antwortzeit des 95. Perzentils stabil bei etwa 180 ms, und der Durchsatz steigt im Gleichschritt mit der Last. Dies ist die gesunde Zone; die API kommt mit. Bei etwa 280 Benutzern beginnt die 95.-Perzentil-Zeit anzusteigen, 240 ms, dann 400 ms, dann 900 ms, während der Durchsatz stagniert statt zu steigen. Diese Stagnation ist das Signal: Die API hat ihre Obergrenze erreicht. Das Hinzufügen weiterer Benutzer führt nun zu langsameren Antworten, nicht zu mehr erledigter Arbeit. Nach 420 Benutzern steigt die Fehlerrate auf über 1 %, da Anfragen anfangen, ein Timeout zu erfahren.
Das Urteil ist konkret. Diese API bedient bequem etwa 250 gleichzeitige Benutzer innerhalb eines Budgets von 200 ms. Ihre praktische Obergrenze liegt bei etwa 280, und sie beginnt um 420 herum zu versagen. Wenn Sie Spitzenverkehr von 200 gleichzeitigen Benutzern erwarten, haben Sie Spielraum. Wenn Sie 350 erwarten, haben Sie ein Problem, das vor dem Start behoben werden muss, nicht danach.
Das ist es, was ein Performance-Test liefert: nicht „bestanden“ oder „nicht bestanden“, sondern eine klare Karte, wo die API komfortabel ist, wo sie an ihre Grenzen stößt und wo sie bricht.
Häufige API-Performance-Engpässe
Wenn ein Test eine Obergrenze aufzeigt, ist die Ursache meist einer der bekannten Übeltäter.
Langsame Datenbankabfragen sind am häufigsten. Eine nicht-indizierte Spalte, ein N+1-Abfragemuster oder eine fehlende Abfragebegrenzung macht einen schnellen Endpunkt langsam, sobald das Datenvolumen oder die Gleichzeitigkeit steigt. Wenn die Latenz steigt, während die Server-CPU niedrig bleibt, verdächtigen Sie zuerst die Datenbank.
Blockierende externe Aufrufe ziehen einen Endpunkt auf die Geschwindigkeit seiner langsamsten Abhängigkeit herunter. Eine API, die synchron einen Zahlungsanbieter oder einen Drittanbieterdienst aufruft, erbt die Latenz und Ausfälle dieses Dienstes.
Erschöpfung des Verbindungspools tritt unter anhaltender Last auf: Die API läuft aus Datenbankverbindungen oder HTTP-Clients heraus, und Anfragen stehen Schlange. Dies ist ein klassisches Ergebnis eines Dauertests.
Ineffiziente Serialisierung großer Antwort-Payloads verbraucht CPU-Ressourcen. Das Zurückgeben von mehr Daten, als der Client benötigt, macht jede Antwort langsamer in der Erstellung und langsamer in der Übertragung.
Ein Performance-Test zeigt auf, wo die Obergrenze liegt; in Kombination mit serverseitigen Metriken sagt er Ihnen, warum.
Performance-Tests in Ihren Prozess integrieren
Ein Performance-Test, der einmalig vor einem großen Launch durchgeführt wird, ist nützlich. Ein Performance-Test, der regelmäßig läuft, ist weitaus wertvoller, da die Performance schleichend nachlassen kann. Eine neue Datenbankabfrage, ein zusätzlicher nachgeschalteter Aufruf oder eine nicht-indizierte Spalte kann jeweils Latenz hinzufügen, die kein funktionaler Test bemerkt.
Legen Sie ein Budget für Antwortzeiten und Fehlerraten für Ihre kritischen Endpunkte fest und behandeln Sie eine Überschreitung als Fehler, genauso wie Sie eine fehlerhafte Assertion behandeln würden. Führen Sie einen leichteren Lasttest als Teil von CI/CD durch, damit eine Regression bereits beim Pull Request auffällt, und reservieren Sie intensive Stress- und Dauertests für geplante Pre-Release-Tests.
Halten Sie Performance-Tests neben funktionalen Tests. Wenn die beiden zusammen existieren, wird jede API-Änderung sowohl auf Korrektheit als auch auf Geschwindigkeit geprüft, und „es funktioniert“ und „es funktioniert schnell genug“ sind keine getrennten, leicht vergessenen Fragen mehr.
Häufig gestellte Fragen
Was ist der Unterschied zwischen Lasttests und Stresstests? Lasttests wenden den erwarteten Datenverkehr an und bestätigen, dass die API diesen verarbeitet. Stresstests überschreiten dies, um den Bruchpunkt zu finden. Lasttests überprüfen den normalen Betrieb; Stresstests kartieren den Fehlermodus.
Sollte ich Durchschnitts- oder Perzentil-Antwortzeiten betrachten? Perzentile. Der Durchschnitt verbirgt die langsamen Ausläufer. Das 95. und 99. Perzentil zeigen, was Ihre am wenigsten glücklichen Benutzer tatsächlich erleben, und das ist es, was Beschwerden hervorruft.
Kann ich eine API testen, bevor das Backend fertig ist? Sie können den Vertrag und das Design testen, aber aussagekräftige Latenzwerte erfordern eine echte Infrastruktur. Verwenden Sie einen Mock-Server für frühe funktionale Arbeiten und führen Sie Lasttests gegen die echte Implementierung durch.
Wie oft sollten Performance-Tests durchgeführt werden? Führen Sie bei jeder Änderung an kritischen Endpunkten einen leichten Lasttest in CI durch und vor jeder größeren Veröffentlichung vollständige Stress- und Dauertests. Die Performance verschlechtert sich schleichend, daher sind regelmäßige Überprüfungen besser als ein großer Testlauf vor dem Launch.