Ihre Anwendung funktioniert perfekt mit zehn Benutzern. Was passiert am Verkaufstag mit zehntausend? Lasttests vs. Stresstests beschreibt zwei verschiedene Möglichkeiten, dies zu beantworten, und ihre Verwechslung führt zu Tests, die nicht das beweisen, was Sie von ihnen erwarten.

In diesem Leitfaden wird erläutert, was die einzelnen Tests anzeigen, welche Testtypen sie haben und wie die Ergebnisse zu lesen sind. Wir haben die kleine Perzentilberechnung unten auf Python 3.13 mit simulierten Zahlen durchgeführt. Die k6-Skripte sind anschauliche Beispiele, die wir nicht ausgeführt haben, und die Benutzerzahlen und Ziele sind erfunden, also ersetzen Sie sie durch Ihre eigenen. Führen Sie diese Tests nur auf Systemen durch, die Sie besitzen oder zu deren Testen Sie berechtigt sind, da starker Datenverkehr wie ein Angriff aussehen und echte Ausfälle verursachen kann.

Die kurze Antwort

Bei einem Auslastungstest wird gefragt: Können wir den erwarteten Datenverkehr bewältigen und dabei unsere Ziele erreichen? Ein Stresstest fragt: Wie viel können wir aushalten, bevor wir scheitern, wie scheitern wir und wie schnell erholen wir uns?

Denken Sie an eine Brücke. Ein Belastungstest fährt die erwartete Anzahl an LKWs hinüber und bestätigt, dass alles in Ordnung ist. Bei einem Stresstest wird immer wieder Gewicht hinzugefügt, um herauszufinden, wann die Grenze erreicht ist und ob zuerst eine Warnung ausgegeben wird. Glücklicherweise ist es billiger, Software zu zerstören als eine Brücke.

Belastungstest und Stresstest nebeneinander

Was ist ein Lasttest?

Lasttests simulieren den erwarteten realistischen Datenverkehr und messen, wie sich das System verhält. Es braucht ein Ziel zum Testen, zum Beispiel: „Bei 500 gleichzeitigen Benutzern werden 95 % der Checkout-Anfragen innerhalb von 800 ms abgeschlossen, mit weniger als 1 % Fehler.“

So könnte das als K6-Skript aussehen. k6-Tests sind in JavaScript geschrieben und thresholds verwandeln Ihre Ziele in ein bestandenes oder nicht bestandenes Ergebnis:

import http from "k6/http";
import { sleep } from "k6";

export const options = {
  stages: [
    { duration: "5m", target: 500 },   // ramp up
    { duration: "20m", target: 500 },  // hold at expected peak
    { duration: "2m", target: 0 },     // ramp down
  ],
  thresholds: {
    http_req_duration: ["p(95)<800"],
    http_req_failed: ["rate<0.01"],
  },
};

export default function () {
  http.get("https://staging.example.com/products");
  sleep(1);   // think time, as real users pause
}

Die sleep ist wichtig. Ohne Bedenkzeit hämmert jeder virtuelle Benutzer kontinuierlich auf den Server ein und erzeugt weitaus mehr Datenverkehr als die gleiche Anzahl realer Personen.

Was ist Stresstest?

Stresstests gehen bewusst über das erwartete Maß hinaus. Du versuchst nicht zu bestehen. Sie möchten Antworten auf Fragen wie:

• Ab welchem Niveau beginnt die Leistung einzubrechen?
• Welche Komponente fällt zuerst aus: die Datenbank, die Anwendungsserver oder ein Drittanbieteraufruf?
• Schlägt es ordnungsgemäß mit eindeutigen Fehlern fehl oder stürzt es ab und verliert Daten?
• Erholt es sich von selbst, wenn der Datenverkehr nachlässt?

export const options = {
  stages: [
    { duration: "5m", target: 500 },    // expected peak
    { duration: "5m", target: 1000 },   // beyond it
    { duration: "5m", target: 2000 },   // further
    { duration: "5m", target: 4000 },   // likely to break
    { duration: "10m", target: 0 },     // recovery: does it come back?
  ],
};

Diese letzte Genesungsphase wird häufig vergessen und ist möglicherweise die wertvollste. Ein System, das Fehler gut bewältigt, sich aber ohne einen manuellen Neustart nie erholt, bedeutet immer noch einen Ausfall, den jemand mitten in der Nacht beheben muss. Im Idealfall sollte ein System unter extremer Last auf kontrollierte Weise Arbeit abwerfen und eindeutige 503 Antworten zurückgeben, anstatt eine Zeitüberschreitung zu verursachen.

Spike, Soak und andere Arten

Last- und Stresstests gehören zu einer größeren Familie von Leistungstests:

Einweichtests erkennen Probleme, die bei kurzen Tests nie sichtbar werden. Ein kleiner Speicherverlust kann zwanzig Minuten lang harmlos aussehen und den Dienst erst nach zwei Tagen zum Erliegen bringen. Spike-Tests eignen sich für Veranstaltungen wie Flash-Sales, bei denen der Traffic nicht allmählich ansteigt.

Kennzahlen, die wichtig sind

Warum Durchschnittswerte irreführend sind

Durchschnittswerte verbergen die langsamen Anfragen, über die sich echte Menschen beschweren. Um dies zu zeigen, haben wir 100 simulierte Antwortzeiten generiert, von denen 95 schnell (80 bis 200 ms) und 5 sehr langsam (2,5 bis 4 Sekunden) waren, und dann die allgemeinen Statistiken berechnet:

import math, random, statistics

random.seed(3)
times = [random.randint(80, 200) for _ in range(95)] \
      + [random.randint(2500, 4000) for _ in range(5)]

def pct(values, p):
    values = sorted(values)
    return values[math.ceil(p / 100 * len(values)) - 1]

print("avg", round(statistics.mean(times)), "p50", pct(times, 50),
      "p95", pct(times, 95), "p99", pct(times, 99), "max", max(times))

# avg 302 p50 150 p95 199 p99 3740 max 3896

Schauen Sie sich diese Zahlen genau an. Der Durchschnitt von 302 ms beschreibt niemanden. Typische Anfragen dauerten etwa 150 ms, während die langsamen über 3 Sekunden dauerten. Sogar p95 sieht bei 199 ms gesund aus, und nur p99 offenbart das Problem. Eine Zahl wie p95 bedeutet, dass 95 % der Anfragen so schnell oder schneller waren.

Und ein Prozent der Anfragen ist keine Seltenheit. Wenn eine Seite 50 Anfragen stellt, wirkt sich ein langsamer p99 auf einen großen Teil der Seitenaufrufe aus. Legen Sie Ziele für die Perzentile fest, die für Sie wichtig sind, und betrachten Sie mehrere zusammen.

Werkzeuge

Jedes davon kann sowohl Last- als auch Stresstests durchführen. Wählen Sie diejenige aus, die zu den Fähigkeiten Ihres Teams passt, anstatt einer Funktionsliste hinterherzujagen. Informationen zur Verwendung in Ihrer Pipeline finden Sie unter Was ist CI/CD.

So planen Sie einen Test

1. Setzen Sie sich Ziele. Verwenden Sie echte Analysen, um Ihren Spitzenverkehr zu ermitteln und Ziele zu definieren.
2. Wählen Sie Reisen. Modellieren Sie realistisches Benutzerverhalten, wie z. B. Stöbern, Suchen und Bezahlen, in realistischen Proportionen. Ein bloßer Aufruf der Startseite beweist wenig.
3. Verwenden Sie eine realistische Umgebung. Ein winziger Staging-Server kann die Produktion nicht vorhersagen. Beachten Sie etwaige Unterschiede.
4. Bereiten Sie Daten vor. Verwenden Sie realistische Volumina, da eine Abfrage, die für 100 Zeilen schnell ist, möglicherweise 10 Millionen durchforstet.
5. Warnen Sie die Leute. Informieren Sie Ihr Betriebsteam und alle Dritten und testen Sie einen Zahlungsanbieter nicht versehentlich. Gegebenenfalls externe Dienste simulieren.
6. Fangen Sie klein an. Führen Sie zunächst einen kleinen Rauchtest durch, um zu bestätigen, dass Ihr Skript funktioniert.
7. Überwachen Sie alles. Ohne Servermetriken werden Sie sehen, dass es langsamer wurde, aber nicht, warum.
8. Wiederholen. Führen Sie es nach jedem Fix erneut aus und behalten Sie eine Basislinie zum Vergleich bei.

Lesen der Ergebnisse

Datenbanken sind ein häufiger Engpass. Wenn also Abfragen das Problem sind, lesen Sie unseren Leitfaden zur SQL-Abfrageoptimierung. Diese letzte Zeile der Tabelle ist eine wichtige Falle: Überprüfen Sie immer auch den Zustand der Maschine, die die Last erzeugt.

Häufige Fehler

• Verwirrung von Benutzern mit Anfragen. Machen Sie sich klar, ob ein Ziel gleichzeitige Benutzer oder Anfragen pro Sekunde bedeutet.
• Denkzeit weglassen. Dies erhöht den Datenverkehr und führt zu irreführenden Ergebnissen.
• Testen zu spät. Eine Woche vor dem Start bleibt keine Zeit, Architekturprobleme zu beheben.
• Verwendung eines einzigen Endpunkts. Echter Datenverkehr mischt Lese-, Schreib- und Suchvorgänge.
• Caching verbirgt alles. Identische wiederholte Anfragen testen möglicherweise nur Ihren Cache, also variieren Sie die Daten.
• Einmal testen. Die Leistung ändert sich mit jeder Veröffentlichung, also führen Sie regelmäßig Tests durch.

Fazit

Führen Sie Lasttests durch, um sicherzustellen, dass Sie den erwarteten Datenverkehr bewältigen können, und führen Sie Stresstests durch, um zu erfahren, was passiert, wenn Sie dies nicht können. Fangen Sie klein an: Wählen Sie Ihre wichtigste User Journey, legen Sie ein klares Ziel fest und führen Sie einen kurzen Test mit Staging und aktivierter Überwachung durch. Bei diesem ersten Durchlauf lernen Sie normalerweise etwas, und Sie können darauf aufbauen.

Häufige Fragen

Lerne weiter