Software, die funktioniert, ist nicht dasselbe wie Software, die unter Last funktioniert. Eine Funktion kann jeden Funktionstest bestehen, sauber ausgeliefert werden und dann beim ersten echten Traffic zusammenbrechen. Performancetests sind die Disziplin, die diese Lücke schließt: Sie messen, wie sich ein System verhält, wenn es ausgelastet ist, nicht nur, ob es korrekt ist, wenn es im Leerlauf ist.
Dieser Leitfaden erklärt, was Performancetests sind, die wichtigsten Typen, die Metriken, die ein Ergebnis definieren, und wie sie in einen modernen Testprozess passen.
Was Performancetests sind
Performancetests bewerten die Geschwindigkeit, Stabilität und Skalierbarkeit eines Systems unter einer definierten Arbeitslast. Es wird nicht gefragt „funktioniert diese Funktion?“, sondern „wie schnell ist sie, wie viel kann sie verkraften und was passiert, wenn sie genug hatte?“
Dieser Unterschied ist wichtig. Funktionstests und Performancetests beantworten unterschiedliche Fragen und finden unterschiedliche Fehler. Ein Login-Endpunkt kann jedes Mal den korrekten Token zurückgeben und dennoch unter Last vier Sekunden dafür benötigen. Funktionstests bestehen; Benutzer verlassen die Seite. Performancetests decken dieses zweite Problem auf.
Das Ergebnis von Performancetests ist kein einfaches Bestanden oder Nicht bestanden. Es ist ein Profil: Bei dieser Last reagiert das System so schnell, hält diesen Durchsatz aufrecht und fällt auf diese Weise aus, wenn es über diesen Punkt hinaus belastet wird. Dieses Profil ermöglicht es einem Team, Kapazitäten zu planen, realistische Service-Level festzulegen und Regressionen vor der Veröffentlichung abzufangen.
Die wichtigsten Arten von Performancetests
Performancetests sind eine Familie von Testtypen, die jeweils auf unterschiedliche Weise Last anwenden, um unterschiedliche Fragen zu beantworten.
Baseline-Tests führen das System unter normaler, erwarteter Last aus und protokollieren das Ergebnis. Diese Baseline ist die Referenz, mit der jeder spätere Test verglichen wird. Ohne sie können Sie nicht feststellen, ob ein Wert gut, schlecht oder einfach nur anders ist.
Lasttests simulieren den erwarteten Spitzenverkehr und bestätigen, dass das System standhält: Antwortzeiten bleiben innerhalb des Budgets, Fehler bleiben nahe Null. Sie validieren, dass das System einen normalen geschäftigen Tag übersteht.
Stresstests überschreiten absichtlich die Kapazität und erhöhen die Last, bis das System sich verschlechtert oder ausfällt. Ziel ist es, den Bruchpunkt zu finden und den Fehlermodus zu beobachten. Eine graduelle Verschlechterung, langsamer, aber immer noch funktionierend, ist akzeptabel; Datenverlust oder kaskadierende Fehler sind es nicht.
Spike-Tests wenden einen plötzlichen, starken Lastanstieg an und reduzieren ihn dann wieder. Sie modellieren Flash Sales, Nachrichtenereignisse und andere Spitzen. Ein System, das für stetigen Verkehr optimiert ist, kann bei einem Spike immer noch versagen, weil es nicht schnell genug skalieren kann.
Kapazitätstests finden die maximale Last, die das System bewältigen kann, während es seine Ziele noch erreicht. Die Antwort ist eine konkrete Zahl, die direkt für die Kapazitätsplanung und die Schwellenwerte für die automatische Skalierung verwendet wird.
Soak-Tests, auch Stabilitäts- oder Dauerlauftests genannt, halten eine moderate Last über einen längeren Zeitraum aufrecht, um langsame Fehler aufzudecken: Speicherlecks, Ressourcenerschöpfung, allmähliche Verlangsamung. Diese sind bei kurzen Läufen unsichtbar und treten erst über Stunden auf.
Die meisten Teams führen Baseline-, Last- und Soak-Tests standardmäßig durch und fügen Stress- und Spike-Tests für Systeme mit hohem oder unvorhersehbarem Datenverkehr hinzu.
Die Metriken, die ein Ergebnis definieren
Ein Performancetest ist nur so nützlich wie die Metriken, die Sie daraus ablesen.
Antwortzeit ist die Dauer von der Anfrage bis zur Antwort. Lesen Sie sie immer als Verteilung. Der Durchschnitt ist irreführend; ein gesunder Durchschnitt kann ein 99. Perzentil verbergen, das zehnmal schlechter ist. Der langsame Teil ist das, was echte Benutzer bemerken und bemängeln.
Durchsatz ist das Arbeitsvolumen, das pro Zeiteinheit abgeschlossen wird, oft Anfragen pro Sekunde. Er wird als Gesamtzahl der Anfragen geteilt durch die Testdauer berechnet und repräsentiert die wahre Kapazität des Systems.
Parallelität ist die Anzahl der gleichzeitigen Benutzer oder Verbindungen. Die Systemkapazität wird häufig als das Parallelitätsniveau angegeben, bei dem die Antwortzeit die akzeptable Schwelle überschreitet.
Fehlerrate ist der Prozentsatz der Anfragen, die unter Last fehlschlagen. Ein System, das schnell bleibt, aber bei hoher Parallelität Anfragen fehlschlagen lässt, hat nicht bestanden; Geschwindigkeit ohne Zuverlässigkeit ist keine Performance.
CPU- und Speicherauslastung erklären, *warum* sich die anderen Zahlen ändern. Wenn die Latenz steigt, während die CPU zu 100 % ausgelastet ist, ist das System rechengebunden. Wenn die Latenz steigt, während die CPU im Leerlauf ist, liegt der Engpass nachgelagert, normalerweise eine Datenbank, eine Sperre oder eine externe Abhängigkeit.
Ein vollständiges Ergebnis liest sich wie ein Satz: Bei dieser Parallelität erreichte der Durchsatz hier seinen Höhepunkt, die Antwortzeit im 95. Perzentil war dies, die Fehlerrate war das, und der Server war an diese Ressource gebunden.
Wo Performancetests im Prozess passen
Performancetests waren früher ein einziges Gate am Ende eines Projekts, das einmal vor dem Start von einem Spezialistenteam durchgeführt wurde. Dieses Modell versagt bei Systemen, die kontinuierlich ausgeliefert werden, da die Performance bei fast jeder Änderung zurückgeht. Eine neue Abfrage, eine hinzugefügte Integration, eine unindizierte Spalte, all dies fügt leise Latenz hinzu, die kein Funktionstest erkennt.
Das bessere Modell behandelt Performance wie Korrektheit: kontinuierlich überprüft, mit einem Budget. Definieren Sie ein Budget für Antwortzeit und Fehlerrate für kritische Pfade. Führen Sie einen leichten Lasttest in CI/CD durch, damit eine Regression den Build bei der Pull-Anfrage fehlschlägt. Reservieren Sie schwere Stress- und Soak-Läufe für geplante Pre-Release-Tests, wo ihre längere Laufzeit akzeptabel ist.
Für die meisten Systeme ist die API-Schicht der wertvollste Ort für Performancetests. APIs tragen die Kernlogik, sie sind schnell und deterministisch aufzurufen, und sie haben keine instabile Benutzeroberfläche, mit der man kämpfen muss. Das Testen von APIs unter Last liefert zuverlässige Zahlen zu geringen Kosten; API-Performancetests behandeln diesen fokussierten Ansatz im Detail. Wenn Performancetests neben funktionalen API-Tests durchgeführt werden, wird jede Änderung gleichzeitig auf Korrektheit und Geschwindigkeit geprüft.
Häufige Fehler bei Performancetests
Performancetests lassen sich leicht so durchführen, dass sie selbstbewusste, aber falsche Antworten liefern. Ein paar Fehler tauchen immer wieder auf.
Testen mit unrealistischer Infrastruktur. Ein Lasttest auf einem Entwickler-Laptop oder gegen eine Staging-Umgebung mit einem Bruchteil der Produktionsressourcen liefert Zahlen, die nichts bedeuten. Testen Sie auf Infrastruktur, die der Produktion so genau wie möglich entspricht, wie Sie es sich leisten können.
Ignorieren von Aufwärmeffekten. Viele Systeme sind in den ersten Sekunden eines Laufs langsam, während Caches gefüllt und Verbindungspools geöffnet werden. Das gemeinsame Messen des Kaltstarts und des stabilen Zustands führt zu einem irreführenden Durchschnitt. Verwerfen Sie das Aufwärmfenster oder berichten Sie es separat.
Lesen von Durchschnitten statt Perzentilen. Dieser Fehler ist es wert, wiederholt zu werden, weil er so häufig ist. Eine durchschnittliche Antwortzeit von 200 ms kann ein 99. Perzentil von drei Sekunden verbergen. Der Durchschnitt beschreibt eine Anfrage, die niemand tatsächlich stellt; die Perzentile beschreiben echte Benutzer.
Verwendung unrealistischer Daten. Wenn jede Anfrage mit derselben Benutzer-ID oder demselben Produkt getestet wird, bedeutet dies, dass die Datenbank alles aus dem Cache liefert. Echter Verkehr verteilt sich über den Datensatz und trifft auf kalte Zeilen und Cache-Fehler. Variieren Sie die Testdaten entsprechend.
Testen eines Endpunkts isoliert. Echte Benutzer durchlaufen Workflows: Anmelden, Browsen, Suchen, Kasse. Das Beschießen eines einzelnen Endpunkts übersieht die Konkurrenz, die auftritt, wenn mehrere Endpunkte um dieselbe Datenbank und denselben Verbindungspool konkurrieren. Testen Sie realistische mehrstufige Szenarien, nicht nur einzelne Aufrufe.
Den Test als einmalige Angelegenheit behandeln. Ein einzelner Performancetest vor der Veröffentlichung veraltet in dem Moment, in dem die nächste Funktion ausgeliefert wird. Die Performance verschlechtert sich kontinuierlich, daher muss der Test ebenfalls kontinuierlich laufen.
Diese sechs Fehler zu vermeiden, macht den größten Teil dessen aus, was einen Performancetest, der eine Entscheidung untermauert, von einem unterscheidet, der ein beruhigendes, aber bedeutungsloses grünes Häkchen produziert.
Performancetests mit Apidog durchführen
Apidog integriert Lasttests in denselben Arbeitsbereich, der für API-Design und Funktionstests verwendet wird, sodass Performance-Checks kein separates Tool oder eine separate Kopie der API-Definition erfordern.
Sie nehmen einen Endpunkt oder ein mehrstufiges Testszenario, bestätigen, dass es funktional bestanden ist, und führen es dann mit einer konfigurierten Anzahl virtueller Benutzer für eine festgelegte Dauer aus. Apidog erhöht die Last schrittweise und meldet live die Perzentile der Antwortzeit, den Durchsatz und die Fehlerrate, sodass Sie genau sehen können, bei welchem Parallelitätsniveau die Performance umschlägt. Für Lasten über eine einzelne Maschine hinaus exportiert das Szenario nach JMeter, während die gleiche Definition beibehalten wird.
Da dasselbe Testszenario sowohl für funktionale als auch für Performance-Läufe dient, pflegen Sie ein Artefakt anstelle von zwei. Laden Sie Apidog herunter, um einen Endpunkt zu profilieren, den Sie bereits haben.
Häufig gestellte Fragen
Was ist der Unterschied zwischen Performancetests und Funktionstests? Funktionstests prüfen, ob die Software korrekte Ergebnisse liefert. Performancetests prüfen, wie schnell und wie zuverlässig sie dies unter Last tut. Beides ist notwendig; keines ersetzt das andere.
Welchen Performancetest-Typ sollte ich zuerst ausführen? Baseline, dann Last. Die Baseline liefert Ihnen eine Referenz unter normalen Bedingungen; der Lasttest bestätigt, dass das System den erwarteten Spitzenverkehr übersteht. Von dort aus fügen Sie Stress-, Spike- und Soak-Tests hinzu.
Warum Perzentile anstelle der durchschnittlichen Antwortzeit verwenden? Der Durchschnitt wird zur Mitte gezogen und verbirgt den langsamen Teil. Das 95. und 99. Perzentil zeigen, was die am wenigsten glücklichen Anfragen erleben, und dieser Teil ist das, was Benutzer empfinden.
Können Performancetests automatisiert werden? Ja. Ein leichter Lasttest läuft gut in CI bei jeder Änderung, mit einem definierten Budget, das den Build bei Regression fehlschlagen lässt. Schwerere Stress- und Soak-Tests werden normalerweise geplant und nicht bei jedem Commit ausgeführt.
Wann im Entwicklungszyklus sollten Performancetests beginnen? Früher, als die meisten Teams denken. Sie können keine endgültigen Latenzzeiten ohne echte Infrastruktur erhalten, aber Sie können Budgets festlegen und die Testszenarien während des Designs schreiben. Das Ausführen eines grundlegenden Lasttests, sobald ein Endpunkt funktionsfähig ist, fängt Probleme ab, solange sie noch günstig zu beheben sind.
Wer ist für Performancetests verantwortlich? In modernen Teams wird dies geteilt. Entwickler führen leichte Lastprüfungen an ihren eigenen Änderungen durch; die QA besitzt die breiteren Testszenarien und Budgets; Operationen oder SRE liefern die produktionsähnliche Infrastruktur und die serverseitigen Metriken. Es als die Aufgabe eines Spezialisten zu behandeln, führt dazu, dass Performance-Probleme die Produktion erreichen.
Wie lange sollte ein Performancetest laufen? Lang genug, um das Aufwärmfenster zu passieren und einen stabilen Zustand zu erreichen, normalerweise mehrere Minuten für einen Lasttest. Soak-Tests laufen konzeptbedingt stunden- oder tagelang, da ihr einziger Zweck darin besteht, langsame Verschlechterungen aufzudecken, die bei kurzen Läufen übersehen werden.