Lastprüfung mit Heuschrecke. Teil 3

Letzter Artikel zum Locust Stresstest-Tool. Heute werde ich die Beobachtungen teilen, die sich dabei angesammelt haben. Wie immer ist das Video beigefügt.

Teil 1 - Testen mit Locust
Teil 2 - Erweiterte Szenarien

Login

Beim Schreiben meiner ersten Tests mit Locust sah ich mich mit der Notwendigkeit konfrontiert, mich bei einer Ressource anzumelden und ein Autorisierungstoken zu erhalten, das ich später für Lasttests verwenden würde. Dann stellte sich sofort die Frage, wie dies zu tun ist, da das Tool geschärft ist, um alle Anforderungen an eine Ressource zu senden, die wir beim Starten des Tests in der Konsole angeben. Es gibt verschiedene Lösungen für das Problem:

• Deaktivieren der Autorisierung für die getestete Ressource - falls möglich
• Generieren Sie im Voraus ein Token und fügen Sie es vor dem Start in den Testcode ein - die schwächste Option, die bei jedem Start Handarbeit erfordert, in einigen seltenen Fällen jedoch das Recht hat, zu existieren
• Senden Sie eine Anfrage über die Anforderungsbibliothek und erhalten Sie ein Token aus der Antwort. Gut, die Syntax ist dieselbe

Ich habe die dritte Option gewählt. Im Folgenden schlage ich ein überarbeitetes Beispiel aus dem ersten Artikel mit verschiedenen Möglichkeiten vor, ein Token zu erhalten. Google.com fungiert als Autorisierungsserver und so weiter
Da es kein Token gibt, erhalte ich die einfachsten Werte

from locust import HttpLocust, TaskSet, task import requests class UserBehavior(TaskSet): def on_start(self): response = requests.post("http://mysite.sample.com/login", {"username": "ellen_key", "password": "education"}) # get "token" from response header self.client.headers.update({'Authorization': response.headers.get('Date')}) # get "token" from response cookies self.client.cookies.set('Authorization', response.cookies.get('NID')) # get "token" from response body self.client.headers.update({'Authorization': str(response.content.decode().find('google'))}) 

Wie Sie dem Beispiel entnehmen können, sendet der Benutzer vor Arbeitsbeginn eine Anfrage an einen Drittanbieter-Server und verarbeitet die Antwort, indem er die Daten in Header oder Cookies einfügt.

Überschriften

Bei der Arbeit mit Anforderungsheadern sind mehrere wichtige Nuancen zu berücksichtigen.
Für jede Anforderung können Sie Ihre eigenen Header wie folgt angeben

 self.client.post(url='/posts', data='hello world', headers={'hello': 'world'}) 

Wenn das obige Beispiel ausgeführt wird, wird der Hallo-Header zu den vorhandenen Headern der Client-Sitzung hinzugefügt, jedoch nur in dieser Anforderung nicht in allen folgenden. Um den Titel dauerhaft zu machen, können Sie ihn der Sitzung hinzufügen:

 self.client.headers.update({'aaa': 'bbb'}) 

Eine weitere interessante Beobachtung - wenn wir in der Anfrage den Header angeben, der sich bereits in der Sitzung befindet - wird dieser überschrieben, jedoch nur bei dieser Anfrage. Sie können also keine Angst haben, versehentlich etwas Wichtiges abzuwischen.

Es gibt jedoch Ausnahmen. Wenn wir ein mehrteiliges Formular senden müssen, generiert die Anforderung automatisch einen Content-Type- Header, der das Formulardaten-Trennzeichen angibt. Wenn wir erzwingen, dass der Header mithilfe des Header- Arguments neu geschrieben wird, schlägt die Anforderung fehl, da das Formular nicht korrekt verarbeitet werden kann.

Es ist auch erwähnenswert, dass alle Header notwendigerweise Zeichenfolgen sind. Wenn Sie versuchen, eine Nummer anzugeben, z. B. {'aaa': 123} , wird die Anforderung nicht gesendet und der Code löst eine InvalidHeader- Ausnahme aus

Verteiltes Testen

Für verteilte Tests bietet locust mehrere CLI-Argumente: --master und --slave , um Rollen klar zu definieren. In diesem Fall simuliert die Maschine mit Master nicht die Last, sondern sammelt nur Statistiken und koordiniert die Arbeit. Versuchen wir, unseren Testserver und mehrere Sitzungen im verteilten Modus auszuführen, indem wir die folgenden Befehle in verschiedenen Konsolen ausführen:

 json-server --watch sample_server/db.json locust -f locust_files\locust_file.py --master --host=http://localhost:3000 locust -f locust_files\locust_file.py --slave --master-host=localhost locust -f locust_files\locust_file.py --slave --master-host=localhost 

Wenn Sie locust im Browser öffnen ( localhost: 8089 ), können Sie feststellen, dass in der oberen rechten Ecke die Anzahl der Maschinen angegeben ist, die die Last tragen

Testen ohne Benutzeroberfläche

Wenn alle Tests geschrieben und debuggt sind, wäre es schön, sie in automatische Regressionstests einzubeziehen und die Ergebnisse nur regelmäßig zu überprüfen. Mit dem folgenden Befehl können Sie den Locust-Test ohne Benutzeroberfläche ausführen:

 locust -f locust_files\locust_file.py --host=http://localhost:3000 --no-web -c 10 -r 2 --run-time 1m --csv=test_result 

wo

• --no-web - Ein Argument, mit dem Sie Tests ohne Benutzeroberfläche ausführen können
• -c 10 - maximale Anzahl von Benutzern
• -r 2 - Benutzerwachstum pro Sekunde
• - Laufzeit 1 m - Testausführungszeit (1 Minute)
• --csv = test_result - Nach Abschluss des Tests werden im aktuellen Ordner 2 CSV-Dateien mit Ergebnissen erstellt, deren Namen mit test_result beginnen

Abschließende Fakten, Beobachtungen und Schlussfolgerungen

Verteiltes Testen kann mit Regressionstests kombiniert werden. Um sicherzustellen, dass alle Knoten für die Last gestartet werden, können Sie das Argument --expect-Slaves = 2 auf dem Master hinzufügen. In diesem Fall wird der Test nur gestartet, wenn mindestens 2 Knoten gestartet werden.

Ich bin einige Male auf eine Situation gestoßen - die getestete Ressource funktioniert nur unter HTTPS, während das Zertifikat vom Kunden generiert wird und das Betriebssystem es als verdächtig markiert. Damit die Tests erfolgreich funktionieren, können Sie allen Abfragen, die die Sicherheitsüberprüfung ignorieren, ein Argument hinzufügen, z. B.:

 self.client.get("/posts", verify=False) 

Da ich nicht immer sicher sein kann, in welcher Umgebung die Tests ausgeführt werden, gebe ich immer dieses Argument an.

Das ist alles was ich teilen wollte. Für mich selbst habe ich ein einfaches und praktisches Tool mit hervorragenden Testfunktionen und Variabilität beim Erstellen von Anforderungen und Verarbeiten von Serverantworten entdeckt. Vielen Dank für das Lesen bis zum Ende.