Pass/Fail-Kriterien für Lasttests: so legen Sie sie fest

Pass/Fail-Kriterien für Lasttests sind die wenigen Grenzwerte, die ein Lauf einhalten muss, um als bestanden zu gelten: ein Latenz-Perzentil für die Anfragen, auf die Nutzer warten, eine Fehlerrate und eine Mindestrate an Anfragen, jeweils bei einer festgelegten Last. Leiten Sie die Grenzwerte aus einem Service Level Objective (SLO) ab, legen Sie Regressionsgrenzen aus früheren Läufen innerhalb davon fest und lassen Sie den Exit-Code des Tools den Lauf nur an diesen harten Grenzwerten scheitern. Alles andere ist eine Warnung, die ein Mensch liest.

Die Angaben zu den Tools wurden am 9. Oktober 2026 in der Dokumentation des jeweiligen Projekts geprüft, und jeder gezeigte Grenzwert ist ein Beispiel.

Wann besteht ein Lasttest, und wann scheitert er?

Ein Lauf besteht, wenn jeder harte Grenzwert bei der geplanten Last hält, und scheitert, sobald einer verfehlt wird. Ungültig ist er, wenn der Test selbst seine Aufgabe nicht erfüllt hat, ganz gleich, was die Zahlen sagen.

Ein ausgelasteter Lastgenerator, eine Last, die ihr Ziel nie erreicht hat, oder ein fehlerhaftes Skript liefern Zahlen über den Testaufbau. LoadFocus zeigt zum Beispiel eine Warnung zur Sättigung des Lastgenerators, wenn eine Engine in der Spitze 80 % CPU oder mehr erreicht hat. Die Exit-Codes von k6 trennen die Fälle für die CI: 99 steht für verfehlte Schwellenwerte, 107 für eine Exception im Skript (geprüft am 9. Oktober 2026).

Wie wird aus einem SLO ein Kriterium für den Lasttest?

Formulieren Sie jedes SLO, das unter Last brechen kann, meist Latenz und Verfügbarkeit, als Grenzwert für das, was der Test misst, und machen Sie ihn strenger als das SLO, damit ein Bestehen Luft lässt.

Googles SRE-Buch definiert ein SLO als Zielwert oder Wertebereich für ein Service-Level, gemessen durch einen Indikator (SLI), mit Beispielen wie: 99 % der Get-Aufrufe sind in unter 100 ms fertig. Es verlangt, dass ein SLO angibt, wie es gemessen wird und wann es gilt, und empfiehlt eine Sicherheitsreserve: ein internes Ziel, das strenger ist als das, was Nutzer zugesagt bekommen.

Bei einem Lasttest bedeutet „wann es gilt“ die Last und den Anfragemix. Aus „95 % der Checkout-Aufrufe unter 500 ms“ könnte zum Beispiel „p95 des Checkouts unter 400 ms bei 300 Anfragen pro Sekunde über 15 Minuten“ werden. Gibt es noch kein SLO, vereinbaren Sie ein vorläufiges mit dem Product Owner.

Welche Metriken sollten die Kriterien abdecken?

Latenz für die Anfragen, auf die Nutzer warten, eine Fehlerrate, die erreichte Anfragerate und, meist als Warnung, die Ressourcen der Server.

• Latenz pro Anfragetyp. Ein globales Perzentil mischt einen schnellen Health Check mit einer langsamen Suche. In k6 erzeugen getaggte Anfragen Sub-Metriken mit eigenen Grenzwerten; in Gatling zielt details() auf eine einzelne Anfrage oder Gruppe. Ein Test, der seine eigene Last gebremst hat, meldet geschönte Perzentile (Coordinated Omission).
• Fehler, weit gefasst. Eine schnelle 200 mit Fehlerseite bleibt ein Fehler, prüfen Sie also den Inhalt. Eine fehlgeschlagene JMeter-Response Assertion markiert ihr Sample als nicht erfolgreich; k6-Checks wirken nur über einen Schwellenwert auf den Exit-Code.
• Eine Untergrenze für die Anfragerate. Im geschlossenen Lastmodell erhält ein langsames System weniger Anfragen, sodass ein Lauf seine Latenzgrenzen bei einem Bruchteil der geplanten Last einhalten kann (offenes vs geschlossenes Lastmodell).
• Ressourcen der Server. CPU, Speicher und Pool-Auslastung kommen aus Ihrem Monitoring. Behandeln Sie sie als Warnungen, solange kein Kapazitätsplan eine harte Obergrenze setzt.

Wie wählt man die Zahlen?

Die Obergrenze kommt aus dem SLO, die Regressionsgrenze aus früheren Läufen desselben Tests. Das SLO sagt, was Nutzer hinnehmen; frühere Läufe zeigen, was dieser Build normalerweise leistet.

Das SRE-Buch warnt davor, ein SLO aus der aktuellen Performance abzuleiten. Eine Regressionsgrenze soll Veränderungen bemerken, also ist die aktuelle Performance genau ihr Ausgangspunkt. Lassen Sie den unveränderten Build mehrmals mit derselben Umgebung und Last laufen, notieren Sie, wie weit jede Metrik schwankt, und setzen Sie die Grenze mit etwas Reserve über den schlechtesten Lauf, aber unter die aus dem SLO abgeleitete Obergrenze, wo es eine gibt.

Schwanken Läufe desselben Builds stärker als die Regression, die Sie erkennen wollen, ist der Test zu verrauscht, um Builds zu blockieren: Verlängern Sie zuerst die stabile Phase oder isolieren Sie die Umgebung. Erfassen Sie nach jeder bewussten Änderung neue Referenzläufe.

Welche Kriterien sollten den Build scheitern lassen, und welche nur warnen?

Lassen Sie den Build an Grenzwerten scheitern, die aus einem SLO stammen oder Korrektheit prüfen. Warnen Sie bei Tail-Perzentilen, Ressourcenverbrauch und langsamen Drifts, die eine Einschätzung brauchen; ein Gate, das an Rauschen scheitert, wird bald abgeschaltet.

Das ensure-Plugin von Artillery hat eine Warnstufe: Eine Bedingung mit strict: false ist optional, ein Verfehlen lässt den Exit-Code also unberührt (geprüft am 9. Oktober 2026). In k6 lässt ein Check ohne Schwellenwert den Lauf nie scheitern. In anderen Tools gehören Warnungen nicht in die Assertions.

config:
  plugins:
    ensure:
      thresholds:
        - "http.response_time.p95": 400
      conditions:
        - expression: "http.response_time.p99 < 1200"
          strict: false

Wann sollte ein Lasttest vorzeitig abbrechen?

Wenn Weitermachen nur schaden oder nichts mehr beweisen kann: Fehler weit über der Grenze, ein System, das schon ausgefallen ist, oder ein Generator, der nicht mehr mithält. Geben Sie der Regel eine Schonfrist, damit Rauschen beim Start sie nicht auslöst.

Setzen Sie Abbruchregeln lockerer an als die Grenzen fürs Bestehen: Sie schützen eine gemeinsam genutzte Umgebung. abortOnFail stoppt einen k6-Test, sobald ein Schwellenwert verfehlt ist, nach einem optionalen delayAbortEval. Die Doku von Locust zu Erweiterungen zeigt ein Greenlet im Hintergrund, das den Lauf beendet, sobald die Fehlerquote eine Schwelle überschreitet. crashLoadGeneratorIf stoppt in Gatling den Generator mit einem Fehlercode, wenn eine Bedingung in der Session eines virtuellen Benutzers zutrifft. Eine JMeter-Thread Group kann den Test bei einem Sampler-Fehler stoppen, was zu einer Korrektheitsprüfung passt (alles geprüft am 9. Oktober 2026).

Wie setzt jedes Tool die Kriterien um?

k6 und Artillery machen aus einem verfehlten harten Grenzwert einen Exit-Code ungleich null, Locust tut das bei jeder fehlgeschlagenen Anfrage oder bei selbst programmierten Grenzwerten, und die Assertions von Gatling lassen den Build scheitern. JMeter überlässt das Urteil einem Schritt nach dem Lauf.

k6: Die Schwellenwerte stehen in den Optionen des Skripts. Dieses Beispiel scheitert am p95 der mit name: checkout getaggten Anfragen oder an 0,5 % Fehlern und bricht nach einer Minute ab, wenn die Fehler 5 % übersteigen:

export const options = {
  thresholds: {
    "http_req_duration{name:checkout}": ["p(95)<400"],
    http_req_failed: [
      "rate<0.005",
      { threshold: "rate<0.05", abortOnFail: true,
        delayAbortEval: "1m" },
    ],
  },
};

Gatling: Die Assertions verbinden einen Geltungsbereich (global, forAll, details), eine Statistik wie ein Perzentil oder requestsPerSec und eine Bedingung. Sie werden nach dem Lauf ausgewertet, und eine fehlgeschlagene Assertion lässt die Simulation scheitern.

Locust beendet sich mit Exit-Code 1, wenn mindestens eine Anfrage fehlgeschlagen ist, und --exit-code-on-error ändert diesen Code. Für eine Quote oder ein Perzentil setzen Sie environment.process_exit_code in einem quitting-Listener; laut Quellcode von Locust hat dieser Wert Vorrang.

JMeter bewertet mit Assertions einzelne Samples, und seine Kommandozeilenoptionen kennen keinen Grenzwert für den ganzen Lauf. Die CI entscheidet: mit einem kurzen Skript über die Ergebnisdatei, wie in unserem Leitfaden zu GitHub Actions, oder mit dem jmeter-maven-plugin eines Drittanbieters, dessen results-Goal den Build bei jedem fehlgeschlagenen Sample scheitern lässt, sofern errorRateThresholdInPercent keine Rate vorgibt (geprüft am 9. Oktober 2026).

LoadFocus bewertet Läufe anhand von Pass/Fail-Schwellenwerten, die am Test gespeichert sind: maximale p95- und p99-Antwortzeit, maximale Fehlerrate und minimale Anfragerate, jeweils optional. Jeder Lauf erhält ein PASS- oder FAIL-Badge mit Ist- und Zielwerten, und eine API gibt das Urteil an eine Pipeline weiter. LoadFocus führt k6-Szenarien mit Ankunftsrate mit einer festen Zahl von Benutzern aus; dort prüft eine Untergrenze für die Rate also, was diese Benutzer erreicht haben.

FAQ

Sollte die durchschnittliche Antwortzeit ein Pass/Fail-Kriterium sein? Selten. Das SRE-Buch bevorzugt Perzentile: Ein Durchschnitt verdeckt die langsamen Ausreißer am Ende der Verteilung und kann flach bleiben, während die langsamsten Anfragen deutlich langsamer werden.

Wie viele Pass/Fail-Kriterien sollte ein Lasttest haben? Eine Handvoll harter Grenzwerte, dazu Warnungen. Das SRE-Buch rät zu so wenigen SLOs wie möglich und sagt: Wenn man mit einem SLO nie eine Diskussion über Prioritäten gewinnen kann, lohnt es sich wahrscheinlich nicht. Legen Sie an jeden Grenzwert eines Lasttests denselben Maßstab an.

Kann ein Lasttest mit einigen fehlgeschlagenen Anfragen bestehen? Ja, wenn die Fehlerrate unter ihrer Grenze bleibt. Prüfen Sie die Voreinstellung Ihres Tools: Locust lässt den Lauf bei jeder fehlgeschlagenen Anfrage scheitern.

Weiterlesen

• Lasttests in GitHub Actions: ein praktischer Leitfaden
• Coordinated Omission: was es ist und wie man es vermeidet
• Lasttest durchführen: eine Schritt-für-Schritt-Anleitung
• Apdex-Score: was er bedeutet und wie man ihn berechnet
• SLO vs. SLA: der Unterschied, SLIs und Fehlerbudgets

Die technischen Aussagen in diesem Artikel wurden nicht unabhängig geprüft.