So führen Sie einen neuen Lasttest durch

Einen neuen Lasttest mit LoadFocus durchführen

Es ist ganz einfach, einen neuen Lasttest für eine Website oder einen API-Endpunkt über die Benutzeroberfläche auf der Seite für neuen Lasttest zu erstellen.

Oben auf der Seite steht der Testname, darunter folgen drei nummerierte Schritte: Was möchten Sie testen?, Wie viel Last? und Von wo?. Darunter finden Sie unter Weitere Optionen die optionalen Einstellungen, und die Leiste unten enthält die Schaltfläche Test ausführen.

Schritte zur Konfiguration eines neuen Lasttests

Testname

Wir generieren automatisch einen Testnamen für Ihren Test unter Verwendung des aktuellen Datums und der Uhrzeit. Er steht oben auf der Seite hinter Neuer Test:. Um ihn zu ändern, klicken Sie auf den Namen (oder auf den Stift daneben) und geben Ihren eigenen ein. Wie der Hinweis daneben sagt, können Sie ihn jederzeit umbenennen. Sobald Sie in Schritt 1 eine URL eingeben und der Name noch der automatische ist, wird der Hostname der Website vorangestellt. Buchstaben, Ziffern und Punkte bleiben erhalten; jedes andere Zeichen im Namen wird zu einem Unterstrich.

1. Was möchten Sie testen?

Im ersten nummerierten Schritt, Was möchten Sie testen?, legen Sie den URL-Endpunkt (Website, API-URI, mobile App-URL) für die Tests fest.

Standardmäßig setzen wir die Anfragemethode auf GET (dies ist die Anfrage, die beim Laden einer Website in einem Browser gestellt wird). Wählen Sie über die Liste Methode eine andere aus, wenn Ihr Testszenario es verlangt: GET, POST, PUT, PATCH, DELETE, OPTIONS oder HEAD.

Mit der Schaltfläche Weitere Anfrage hinzufügen können Sie eine oder mehrere Anfragen zu Ihren Lasttests hinzufügen. Alle virtuellen Benutzer werden die Endpunkte nacheinander aufrufen. Wenn Sie die Anfragen neu anordnen möchten, können Sie sie einfach per Drag and Drop über das Pfeilsymbol rechts verschieben.

Header, Body und Cookies

Klicken Sie unter jeder URL auf Header, Body, Cookies…, um Query Params, Headers, Browser Compatible Headers, Cookies, POST Body, Basic Auth und Extract Variable anzuzeigen. Solange die Optionen zugeklappt sind, zeigt die Schaltfläche, wie viele davon gesetzt sind, zum Beispiel "Header, Body, Cookies… (2)". Zu Headers siehe Header und Header-Vorlagen, zu Cookies Verwendung von Cookies.

Sie können mehrere Query-Parameter zu Ihrer URL hinzufügen, indem Sie Schlüssel/Wert-Paare mit Query Params hinzufügen. URL-Feld und Liste bleiben synchron, die Bearbeitung des einen aktualisiert also das andere. Mehr unter Query-Parameter.

Dies führt zu einer URL: https://www.example.com?key1=value1&key2=value2

2. Wie viel Last?

Der zweite Schritt, Wie viel Last?, beginnt mit vier Voreinstellungen: Kurzer Check (wenige Benutzer, um zu prüfen, ob alles läuft), Typisch (Ihr alltäglicher Traffic), Spitzenlast (Ihre Spitzenzeiten, um die Grenze zu finden) und Benutzerdefiniert (eigene Werte). Jede Voreinstellung zeigt die Benutzer und die Gesamtzeit, die sie einstellt, passend zu den Limits Ihres Tarifs. Ein Klick darauf füllt die Schieberegler darunter aus; wenn Sie selbst einen Schieberegler ändern, wird die passende Voreinstellung oder Benutzerdefiniert ausgewählt.

Mit den Schiebereglern legen Sie die Anzahl der Virtuellen Benutzer, die Dauer und die Hochlaufzeit fest, die den Test auf die gewünschte Last bringt. Öffnen Sie Feinabstimmung für die Hochlauf-Schritte und für Nach Iterationen statt nach Zeit ausführen: Damit wird aus dem Schieberegler Dauer (s) ein Schieberegler Iterationen, und der Test läuft eine feste Anzahl von Iterationen statt einer festen Zeit. Steht ein Schieberegler am Limit Ihres Tarifs, öffnet ein Link "Mehr benötigt?" die Preisseite. Prüfen Sie visuell mit dem Diagramm, wie Ihr Lasttest ablaufen wird, indem Sie die Hochlaufzeit, die Schritte und die Dauer des Lasttests betrachten. Der Satz unter dem Diagramm fasst es zusammen, zum Beispiel auf wie viele Benutzer hochgefahren wird und wie lange der ganze Lauf dauert.

Ein Feld Verzögerung (ms) gibt es auf dieser Seite nicht: Neue Tests werden mit der Standardverzögerung von 100 ms gespeichert (siehe Was ist Verzögerung). In der Testphase und im Free-Plan enden die Schieberegler bei niedrigeren Limits, die am Ende dieser Seite stehen.

3. Von wo?

Wählen Sie im dritten Schritt, Von wo?, den geografischen Standort, von dem aus die virtuellen Benutzer Anfragen an Ihre Website/API senden. In bezahlten Plänen ist die Liste nach Regionen gruppiert: Amerika, Europa, Asien-Pazifik sowie Naher Osten und Afrika. Im Free-Plan kann nur der erste Standort ausgewählt werden; die übrigen sind unter "In bezahlten Plänen" aufgeführt. Siehe die Liste der Lasttest-Standorte und die IP-Adressen für das Whitelisting.

Weitere Optionen

Unter Weitere Optionen können Sie diese optionalen Zeilen aufklappen. Jede Zeile zeigt neben ihrem Namen einen kurzen Status, zum Beispiel An oder Aus:

• Autorisierung (gilt für jede Anfrage): Setzen Sie Autorisierungstyp auf OAuth 2.0, wenn die API ein Token braucht (siehe OAuth 2.0-Autorisierung). Standard ist Keine Authentifizierung.
• Erfolgs- und Fehlerkriterien: Grenzwerte, an denen jeder Lauf gemessen wird (siehe Pass/Fail-Schwellenwerte).
• Nach Zeitplan ausführen: ein wiederkehrender Zeitplan (siehe Geplante Lasttests).
• Seitengeschwindigkeit unter Last: misst Core Web Vitals in einem Cloud-Browser, während der Test läuft; erfordert einen kostenpflichtigen Page-Speed-Monitoring-Tarif.
• Ergebnisse an Datadog, New Relic… senden: sendet die Ergebnisse an die Integrationen, die Sie eingerichtet haben.

Alle sind optional.

Den Test ausführen

Klicken Sie auf Test ausführen, um den Lauf zu starten, oder auf Entwurf speichern, um die Konfiguration zu behalten, ohne ihn auszuführen. Vor dem Start bestätigen Sie den Lauf im Dialog Diesen Test starten?. Wenn der Lauf beendet ist, öffnet sich die Ergebnisseite mit der Kapazitätsanzeige über den Diagrammen, falls der Test hochgefahren wurde.

Um einen gespeicherten Test stattdessen aus einer CI/CD-Pipeline zu starten, siehe Lasttest-API.

Limits während der 7-tägigen Testphase

Ein kostenpflichtiger Plan beginnt mit einer 7-tägigen kostenlosen Testphase. Während dieser Testphase läuft jeder Lasttest unabhängig vom gewählten Plan mit reduzierten Limits: 50 virtuelle Benutzer, 5-minütige Tests und 3 Testläufe pro Tag. Deshalb endet der Schieberegler für die Virtuellen Benutzer bei 50, solange Sie sich in der Testphase befinden. Auch eine Starter-Testphase ist auf 50 virtuelle Benutzer begrenzt, behält aber die 20-minütigen Tests von Starter. Die vollen Limits Ihres Plans (zum Beispiel 1.500 virtuelle Benutzer bei Basic) greifen automatisch, sobald die Testphase endet. Um sie früher freizuschalten, nutzen Sie Testphase überspringen und jetzt freischalten im Hinweis unter dem Schieberegler oder Testphase überspringen und jetzt bezahlen im Limits-Dialog; die Abrechnung beginnt sofort.

Die 3 Testläufe pro Tag gelten zusammen für Cloud-, JMeter- und k6-Tests. In einer Testphase ohne Karte zählen auch Läufe mit, die Sie in den letzten 24 Stunden im Free-Plan gestartet haben. Fügen Sie eine Karte hinzu, dann erhalten Sie sofort 3 weitere Läufe: Läufe vor dem Hinzufügen der Karte zählen nicht mehr. Das geht einmal pro Testphase, und Ihr Plan beginnt mit dem Ende der Testphase, sofern Sie nicht vorher kündigen. Wenn Sie das Tageslimit erreichen, bietet der Limits-Dialog dafür Karte hinzufügen: 3 weitere Läufe heute an.

Limits im Free-Plan

Im Free-Plan können Sie in beliebigen 24 Stunden 3 Testläufe starten, gezählt über Cloud-, JMeter- und k6-Tests zusammen. Der Free-Plan hat außerdem eine Obergrenze von 10 Läufen pro Jahr je Testart: Cloud-, JMeter- und k6-Tests zählen getrennt. Ein Lauf, den LoadFocus nicht starten konnte, zählt nicht.

Kostenlose Konten teilen sich außerdem ein Kontingent pro Website: Alle kostenlosen Konten zusammen erhalten 3 Tests pro Tag und 10 pro Jahr für dieselbe Website. Das geteilte Kontingent greift erst, wenn ein anderes Konto diese Website im selben Zeitraum getestet hat. Eine Website, die nur Ihr Konto testet, wird also nie abgelehnt. Ist das Kontingent aufgebraucht, nennt der Dialog Kostenlose Tests für diese Website aufgebraucht, ab wann Sie die Website wieder kostenlos testen können. Ihre anderen Websites sind nicht betroffen, und bezahlte Tarife haben kein geteiltes Kontingent.

• Öffentliche Testdienste wie test.k6.io, quickpizza.grafana.com, httpbin.org, jsonplaceholder.typicode.com und petstore.swagger.io verbrauchen kein Kontingent.
• Bei JMeter- und k6-Tests werden die Websites aus den URLs in Ihrem Skript gelesen. Eine Website, die erst während des Tests feststeht, wird nicht gezählt.
• Cloud-Tests, die ihre Website über eine Variable festlegen, teilen sich ein Kontingent für alle so festgelegten Websites.