Eines der Probleme, mit denen Anbieter von Mehrproduktsoftware häufig konfrontiert sind, ist die Duplizierung der Kompetenzen von Ingenieuren – Entwicklern, Testern und Infrastrukturadministratoren – in fast jedem Team. Dies gilt auch für teure Ingenieure – Spezialisten auf dem Gebiet der Belastungsprüfung.
Anstatt ihre direkten Aufgaben zu erfüllen und ihre einzigartige Erfahrung zu nutzen, um einen Lasttestprozess aufzubauen, eine Methodik und optimale Metriken auszuwählen und Autotests entsprechend den Lastprofilen zu schreiben, müssen Ingenieure oft die Testinfrastruktur von Grund auf bereitstellen, Lasttools konfigurieren und sie einbetten sich in CI-Systemen einbinden, Monitoring und Veröffentlichung von Berichten einrichten.
Lösungen für einige organisatorische Probleme finden Sie in den Tests, die wir bei Positive Technologies in verwenden . Und in diesem Fall werde ich über die Möglichkeit sprechen, Lasttests mithilfe des Konzepts „Lasttests als Dienst“ (Lasttests als Dienst) in eine gemeinsame CI-Pipeline zu integrieren. Sie erfahren, wie und welche Docker-Images von Lastquellen in der CI-Pipeline verwendet werden können; wie Sie Lastquellen mithilfe einer Build-Vorlage mit Ihrem CI-Projekt verbinden; wie die Demo-Pipeline zum Ausführen von Lasttests und zum Veröffentlichen der Ergebnisse aussieht. Der Artikel kann für Softwaretestingenieure und Automatisierungsingenieure in CI nützlich sein, die über die Architektur ihres Lastsystems nachdenken.
Die Essenz des Konzepts
Das Konzept des Lasttests als Dienst impliziert die Möglichkeit, die Ladetools Apache JMeter, Yandex.Tank und Ihre eigenen Frameworks in ein beliebiges kontinuierliches Integrationssystem zu integrieren. Die Demo gilt für GitLab CI, die Prinzipien gelten jedoch für alle CI-Systeme.
Load Testing as a Service ist ein zentralisierter Dienst für Lasttests. Lasttests werden in dedizierten Agentenpools ausgeführt, die Ergebnisse werden automatisch in GitLab Pages, Influx DB und Grafana oder in Testberichtssystemen (TestRail, ReportPortal usw.) veröffentlicht. Automatisierung und Skalierung werden so einfach wie möglich umgesetzt – durch Hinzufügen und Parametrisieren der üblichen Vorlage gitlab-ci.yml im GitLab CI-Projekt.
Der Vorteil dieses Ansatzes besteht darin, dass die gesamte CI-Infrastruktur, Lastagenten, Docker-Images von Lastquellen, Testpipelines und Veröffentlichungsberichte von einer zentralen Automatisierungsabteilung (DevOps-Ingenieure) verwaltet werden, während Lasttestingenieure ihre Bemühungen auf die Testentwicklung konzentrieren können und Analyse ihrer Ergebnisse, ohne sich mit Infrastrukturproblemen zu befassen.
Zur Vereinfachung der Beschreibung gehen wir davon aus, dass die zu testende Zielanwendung oder der zu testende Server bereits vorab bereitgestellt und konfiguriert wurde (hierfür können automatisierte Skripte in Python, SaltStack, Ansible usw. verwendet werden). Dann gliedert sich das gesamte Konzept des Lasttests als Service in drei Phasen: Erstellung, Prüfung, Veröffentlichung von Berichten. Weitere Details zum Diagramm (alle Bilder sind anklickbar):
Grundlegende Konzepte und Definitionen im Lasttest
Bei der Durchführung von Belastungstests versuchen wir diese einzuhalten , verwenden Sie die entsprechende Terminologie und die empfohlenen Metriken. Ich werde eine kurze Liste der wichtigsten Konzepte und Definitionen beim Lasttest geben.
Agent laden - eine virtuelle Maschine, auf der die Anwendung gestartet wird - die Ladequelle (Apache JMeter, Yandex.Tank oder ein selbst geschriebenes Lademodul).
Testziel (target) - Server oder auf dem Server installierte Anwendung, die einer Belastung ausgesetzt ist.
Testszenario (Testfall) - eine Reihe parametrisierter Schritte: Benutzeraktionen und erwartete Reaktionen auf diese Aktionen, mit festen Netzwerkanforderungen und -antworten, abhängig von den angegebenen Parametern.
Profil bzw. Ladeplan (Profil) - in (Abschnitt 4.2.4, S. 43) Lastprofile definieren Metriken, die für einen bestimmten Test kritisch sind, und Optionen zum Ändern von Lastparametern während des Tests. Beispiele für Profile sehen Sie in der Abbildung.
Prüfen – ein Skript mit einem vorgegebenen Parametersatz.
Testplan (test-plan) - eine Reihe von Tests und ein Lastprofil.
Testran (Testlauf) - eine Iteration der Ausführung eines Tests mit einem vollständig ausgeführten Lastszenario und dem empfangenen Bericht.
Netzwerkanfrage (Anfrage) – Eine HTTP-Anfrage, die von einem Agenten an ein Ziel gesendet wird.
Netzwerkantwort (Antwort) – Eine HTTP-Antwort, die vom Ziel an den Agenten gesendet wird.
HTTP-Antwortcode (HTTP-Antwortstatus) – Standardantwortcode vom Anwendungsserver.
Eine Transaktion ist ein vollständiger Anfrage-Antwort-Zyklus. Eine Transaktion wird vom Beginn des Sendens einer Anfrage (Request) bis zum Abschluss des Empfangs einer Antwort (Response) gezählt.
Transaktionsstatus - ob der Anfrage-Antwort-Zyklus erfolgreich abgeschlossen werden konnte. Wenn in diesem Zyklus ein Fehler aufgetreten ist, gilt die gesamte Transaktion als fehlgeschlagen.
Reaktionszeit (Latenz) - die Zeit vom Ende des Sendens einer Anfrage (Request) bis zum Beginn des Empfangs einer Antwort (Response).
Metriken laden — die im Rahmen des Lasttests ermittelten Eigenschaften des geladenen Dienstes und des Lastagenten.
Grundlegende Metriken zur Messung von Lastparametern
Einige der in der Methodik am häufigsten verwendeten und empfohlenen Methoden (S. 36, 52) Die Kennzahlen sind in der folgenden Tabelle aufgeführt. Ähnliche Metriken für Agent und Ziel werden in derselben Zeile aufgeführt.
Metriken für den Ladeagenten
Metriken des Zielsystems oder der Zielanwendung, das unter Last getestet wird
Anzahl vCPU und Erinnerung RAM,
Festplatten - „Eisen“-Eigenschaften des Lademittels
CPU, Speicher, Festplattennutzung - Dynamik der CPU-, Speicher- und Festplattenbelastung
im Testprozess. Wird normalerweise als Prozentsatz von gemessen
maximal verfügbare Werte
Netzwerkdurchsatz (beim Laden des Agenten) – Durchsatz
Netzwerkschnittstelle auf dem Server,
wo der Ladeagent installiert ist.
Wird normalerweise in Bytes pro Sekunde (bps) gemessen.
Netzwerkdurchsatz(am Ziel) – Bandbreite der Netzwerkschnittstelle
auf dem Zielserver. Wird normalerweise in Bytes pro Sekunde (bps) gemessen.
Virtuelle Benutzer- die Anzahl der virtuellen Benutzer,
Umsetzung von Lastszenarien und
Nachahmung echter Benutzeraktionen
Status virtueller Benutzer, Bestanden/Fehlgeschlagen/Gesamt – Anzahl erfolgreicher und
erfolglose Status virtueller Benutzer
für Lastszenarien sowie deren Gesamtzahl.
Es wird allgemein erwartet, dass alle Benutzer die Prüfung abschließen konnten
alle Ihre im Lastprofil spezifizierten Aufgaben.
Jeder Fehler bedeutet, dass ein echter Benutzer dies nicht tun kann
Lösen Sie Ihr Problem bei der Arbeit mit dem System
Anfragen pro Sekunde (Minute)– die Anzahl der Netzwerkanfragen pro Sekunde (oder Minute).
Ein wichtiges Merkmal eines Ladeagenten ist die Anzahl der Anfragen, die er generieren kann.
Tatsächlich handelt es sich hierbei um eine Nachahmung des Zugriffs virtueller Benutzer auf die Anwendung
Antworten pro Sekunde (Minute)
- die Anzahl der Netzwerkantworten pro Sekunde (oder Minute).
Ein wichtiges Merkmal der Zielleistung: wie viel
Generieren und senden Sie Antworten auf Anfragen mit
Lademittel
HTTP-Antwortstatus— Anzahl verschiedener Antwortcodes
vom Anwendungsserver, der vom Ladeagenten empfangen wurde.
Beispielsweise bedeutet 200 OK einen erfolgreichen Anruf.
und 404 – dass die Ressource nicht gefunden wurde
Latency (Reaktionszeit) – Zeit ab dem Ende
Senden einer Anfrage (Request), bevor mit dem Empfang einer Antwort (Response) begonnen wird.
Wird normalerweise in Millisekunden (ms) gemessen.
Reaktionszeit der Transaktion— Zeitpunkt einer vollständigen Transaktion,
Abschluss des Anfrage-Antwort-Zyklus.
Dies ist die Zeit ab dem Beginn des Sendens der Anfrage (Anfrage).
bis zum Abschluss des Erhalts einer Antwort (Antwort).
Die Transaktionszeit kann in Sekunden (oder Minuten) gemessen werden.
auf verschiedene Weise: Betrachten Sie das Minimum,
Maximum, Durchschnitt und beispielsweise das 90. Perzentil.
Die minimalen und maximalen Messwerte sind extrem
Systemleistungsstatus.
Das neunzigste Perzentil wird am häufigsten verwendet.
wie es den meisten Benutzern zeigt,
komfortables Arbeiten an der Grenze der Systemleistung
Transaktionen pro Sekunde (Minute) - die Anzahl der abgeschlossenen
Transaktionen pro Sekunde (Minute),
das heißt, wie viel der Antrag annehmen konnte und
Bearbeitung von Anfragen und Ausgabe von Antworten.
Tatsächlich ist dies der Durchsatz des Systems
Transaktionsstatus , Bestanden / Nicht bestanden / Gesamtzahl
erfolgreiche, erfolglose und die Gesamtzahl der Transaktionen.
Für echte Benutzer erfolglos
die Transaktion wird tatsächlich bedeuten
Unfähigkeit, mit dem System unter Last zu arbeiten
Schematische Darstellung des Lasttests
Das Konzept des Lasttests ist sehr einfach und besteht aus drei Hauptphasen, die ich bereits erwähnt habe: Testbericht erstellenDas heißt, Testziele vorbereiten und Parameter für Lastquellen festlegen, dann Lasttests durchführen und am Ende einen Testbericht erstellen und veröffentlichen.
Schematische Hinweise:
- QA.Tester ist Experte für Lasttests,
- Ziel ist die Zielanwendung, deren Verhalten unter Last Sie wissen möchten.
Klassifizierer von Entitäten, Phasen und Schritten im Diagramm
Stufen und Schritte
Was ist los
Was ist am Eingang?
Was ist die Ausgabe?
Vorbereiten: Vorbereitungsphase für den Test
LoadParameters
Einstellung und Initialisierung
Benutzer
Lastparameter,
Auswahl der Metriken und
Vorbereitung des Testplans
(Lastprofil)
Benutzerdefinierte Optionen für
Initialisierung des Ladeagenten
Versuchsplan
Zweck der Prüfung
VM
Cloud-Bereitstellung
virtuelle Maschine mit
erforderliche Eigenschaften
VM-Einstellungen für den Ladeagenten
Automatisierungsskripte für
VM-Erstellung
VM konfiguriert in
eine Wolke
Unserer Partner
Einrichtung und Vorbereitung des Betriebssystems
Umgebung für
Load-Agent-Arbeit
Umgebungseinstellungen für
Ladeagent
Automatisierungsskripte für
Umgebungseinstellungen
Vorbereitete Umgebung:
Betriebssystem, Dienste und Anwendungen,
für die Arbeit notwendig
Ladeagent
LoadAgents
Installation, Konfiguration und Parametrierung
Lademittel.
Oder laden Sie ein Docker-Image herunter von
vorkonfigurierte Ladequelle
Laden Sie das Quell-Docker-Image
(YAT, JM oder selbstgeschriebenes Framework)
Einstellungsoptionen
Ladeagent
Aufstellen und fertig
zum Arbeitslastagenten
Test: Ausführungsphase von Lasttests. Quellen sind Ladeagenten, die in dedizierten Agentenpools für GitLab CI bereitgestellt werden
Laden Sie
Starten des Ladeagenten
mit ausgewähltem Testplan
und Ladeparameter
Benutzeroptionen
zur Initialisierung
Ladeagent
Versuchsplan
Zweck der Prüfung
Ausführungsprotokolle
Belastungstests
Systemprotokolle
Dynamik von Änderungen der Zielmetriken und des Lastagenten
Führen Sie Agenten aus
Agentenausführung
jede Menge Testskripte
gemäß
Lastprofil
Load Agent-Interaktion
zum Zweck des Testens
Versuchsplan
Zweck der Prüfung
Logs
Sammlung „roher“ Protokolle
während des Belastungstests:
Aktivitätsdatensätze des Agenten laden,
Zustand des Testziels
und die VM, auf der der Agent ausgeführt wird
Ausführungsprotokolle
Belastungstests
Systemprotokolle
Metrik
Sammeln „roher“ Metriken während des Testens
Dynamik von Änderungen der Zielmetriken
und Ladeagent
Bericht: Vorbereitungsphase des Testberichts
Stromerzeuger
Verarbeitung erhoben
Ladesystem und
Überwachungssystem „roh“
Metriken und Protokolle
Erstellung eines Berichts in
menschenlesbare Form
mit Elementen möglich
Analysten
Ausführungsprotokolle
Belastungstests
Systemprotokolle
Dynamik von Änderungen in Metriken
Ziel und Ladeagent
Verarbeitete „rohe“ Protokolle
in einem geeigneten Format für
Uploads auf externen Speicher
Statischer Belastungsbericht,
für Menschen lesbar
Veröffentlichen
Veröffentlichung des Berichts
über Ladung
Prüfung im externen
Service
„Roh“ verarbeitet
Protokolle in einem geeigneten Format
zum Entladen nach außen
Repositorys
In extern gespeichert
Speicherberichte über
Belastung, geeignet
für die menschliche Analyse
Anschließen von Lastquellen in der CI-Vorlage
Kommen wir zum praktischen Teil. Ich möchte zeigen, wie es bei einigen Projekten im Unternehmen geht Wir haben das Konzept des Lasttests als Service implementiert.
Zunächst haben wir mit Hilfe unserer DevOps-Ingenieure einen dedizierten Pool von Agenten in GitLab CI erstellt, um Lasttests durchzuführen. Um sie in Vorlagen nicht mit anderen, wie z. B. Assembly-Pools, zu verwechseln, haben wir diesen Agenten Tags hinzugefügt. : Belastung. Sie können beliebige andere verständliche Tags verwenden. Sie Fragen GitLab CI-Läufer.
Wie finde ich die benötigte Leistung per Hardware heraus? Die Eigenschaften von Ladeagenten – eine ausreichende Anzahl an vCPU, RAM und Festplatte – können basierend auf der Tatsache berechnet werden, dass Docker, Python (für Yandex.Tank), GitLab CI-Agent, Java (für Apache JMeter) auf dem Agenten ausgeführt werden sollten . Für Java unter JMeter wird außerdem empfohlen, mindestens 512 MB RAM zu verwenden und als Obergrenze .
Aufgrund unserer Erfahrung empfehlen wir daher die Verwendung von mindestens 4 vCPUs, 4 GB RAM und 60 GB SSD für Ladeagenten. Der Durchsatz der Netzwerkkarte wird anhand der Anforderungen des Lastprofils ermittelt.
Wir verwenden hauptsächlich zwei Ladequellen – Apache JMeter und Yandex.Tank Docker-Images.
ist ein Open-Source-Tool von Yandex für Lasttests. Seine modulare Architektur basiert auf dem leistungsstarken asynchronen, auf Treffern basierenden HTTP-Anfragegenerator von Phantom. Der Tank verfügt über eine integrierte Überwachung der Ressourcen des zu testenden Servers über das SSH-Protokoll, kann den Test unter bestimmten Bedingungen automatisch stoppen, kann die Ergebnisse sowohl in der Konsole als auch in Form von Diagrammen anzeigen, Sie können Ihre Module verbinden dazu, um die Funktionalität zu erweitern. Übrigens haben wir den Tank genutzt, als er noch nicht zum Mainstream gehörte. Im Artikel "» Hier können Sie die Geschichte lesen, wie wir damit im Jahr 2013 Lasttests durchgeführt haben ist eines der Produkte unseres Unternehmens.
ist ein Open-Source-Lasttest-Tool von Apache. Es kann gleichermaßen zum Testen statischer und dynamischer Webanwendungen verwendet werden. JMeter unterstützt eine Vielzahl von Protokollen und Möglichkeiten zur Interaktion mit Anwendungen: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET usw.), SOAP/REST-Webservices, FTP, TCP, LDAP, SMTP(S), POP3( S) ) und IMAP(S), Datenbanken über JDBC, können Shell-Befehle ausführen und mit Java-Objekten arbeiten. JMeter verfügt über eine IDE zum Erstellen, Debuggen und Ausführen von Testplänen. Es gibt auch eine CLI für die Befehlszeilenbedienung auf jedem Java-kompatiblen Betriebssystem (Linux, Windows, Mac OS X). Das Tool kann dynamisch einen HTML-Testbericht generieren.
Um die Verwendung in unserem Unternehmen zu vereinfachen und den Testern die Möglichkeit zu geben, die Umgebung selbst zu ändern und hinzuzufügen, haben wir Builds von Docker-Images von Ladequellen auf GitLab CI mit Veröffentlichung intern erstellt . Dies macht es schneller und einfacher, sie für Lasttests in Pipelines zu verbinden. So führen Sie Docker-Push in die Registrierung über GitLab CI durch – siehe .
Wir haben diese grundlegende Docker-Datei für Yandex.Tank genommen:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]Und für Apache JMeter dieses hier:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Wie unser Continuous-Integration-System funktioniert, können Sie im Artikel „".
Vorlage und Pipeline
Ein Beispiel für eine Vorlage zur Durchführung von Belastungstests ist im Projekt verfügbar . In Sie können die Anweisungen zur Verwendung der Vorlage lesen. In der Vorlage selbst (Datei ) gibt es Hinweise dazu, wofür jeder Schritt verantwortlich ist.
Die Vorlage ist sehr einfach und demonstriert die drei im obigen Diagramm beschriebenen Phasen des Lasttests: Vorbereiten, Testen und Veröffentlichen von Berichten. Verantwortlich dafür : Vorbereiten, testen und berichten.
- Bühne soll dazu dienen, Testziele vorzukonfigurieren oder deren Verfügbarkeit zu prüfen. Die Umgebung für Ladequellen muss nicht konfiguriert werden, sie werden als Docker-Images vorgefertigt und in der Docker-Registrierung veröffentlicht: Geben Sie einfach die gewünschte Version in der Testphase an. Sie können sie jedoch neu erstellen und Ihre eigenen modifizierten Bilder erstellen.
- Bühne Wird verwendet, um die Ladequelle anzugeben, Tests auszuführen und Testartefakte zu speichern. Sie können eine beliebige Ladequelle auswählen: Yandex.Tank, Apache JMeter, Ihre eigene oder alle zusammen. Um unnötige Quellen zu deaktivieren, kommentieren Sie den Job einfach aus oder löschen ihn. Einstiegspunkte für Lastquellen:
- Die Startparameter für Yandex.Tank werden im angegeben.,
- Die Startparameter für Apache JMeter sind in der Datei angegeben .
Hinweis: Die Assembly-Konfigurationsvorlage wird zum Einrichten der Interaktion mit dem CI-System verwendet und impliziert nicht die Platzierung der Testlogik darin. Für Tests wird der Einstiegspunkt angegeben, an dem sich das Kontroll-Bash-Skript befindet. Die Methode zum Ausführen von Tests, zum Erstellen von Berichten und die Testskripte selbst müssen von QA-Ingenieuren implementiert werden. In der Demo wird für beide Ladequellen die Yandex-Hauptseitenanforderung als einfachster Test verwendet. Skripte und Testparameter befinden sich im Verzeichnis .
- Auf der Bühne Sie müssen beschreiben, wie die in der Testphase erhaltenen Testergebnisse in externen Speichern veröffentlicht werden, beispielsweise auf GitLab-Seiten oder speziellen Berichtssystemen. GitLab Pages erfordert, dass das Verzeichnis ./public nicht leer ist und nach Abschluss der Tests mindestens eine index.html-Datei enthält. Sie können mehr über die Nuancen des GitLab Pages-Dienstes erfahren. .
Beispiele für den Export von Daten:
- von JMeter zu ,
- von Yandex.Tank zu .
Anweisungen zum Posten-Setup:
- HTML-Statik in ,
- zu InfluxDB und dann zu .
Im Demobeispiel sieht die Pipeline mit Lasttests und zwei Lastquellen (Sie können die unnötige ausschalten) so aus:
Apache JMeter kann selbst einen HTML-Bericht generieren, daher ist es rentabler, ihn mit Standardtools in GitLab Pages zu speichern. So sieht der Apache JMeter-Bericht aus:
Im Demobeispiel für Yandex.Tank sehen Sie nur im Abschnitt für GitLab-Seiten. Während des Tests kann der Tank die Ergebnisse in der InfluxDB-Datenbank speichern und von dort aus beispielsweise in Grafana anzeigen (die Konfiguration erfolgt in der Datei). ). So sieht Tanks Bericht in Grafana aus:
Zusammenfassung
In dem Artikel habe ich über das Konzept des „Lasttests als Dienst“ (Lasttests als Dienst) gesprochen. Die Hauptidee besteht darin, die Infrastruktur aus vorkonfigurierten Pools von Ladeagenten, Docker-Images von Ladequellen, Berichtssystemen und einer Pipeline zu nutzen, die diese in GitLab CI basierend auf einer einfachen .gitlab-ci.yml-Vorlage (Beispiel) kombiniert ). All dies wird von einem kleinen Team von Automatisierungsingenieuren unterstützt und auf Wunsch der Produktteams repliziert. Ich hoffe, dass dies Ihnen bei der Vorbereitung und Umsetzung eines ähnlichen Programms in Ihrem Unternehmen helfen wird. Danke für die Aufmerksamkeit!
PS: Ich möchte mich ganz herzlich bei meinen Kollegen Sergey Kurbanov und Nikolai Yusev für die technische Unterstützung bei der Umsetzung des Konzepts des Lasttests als Dienstleistung in unserem Unternehmen bedanken.
Autor: - Stellvertreter Leiter Technologie- und Entwicklungsprozesse (DevOps) bei Positive Technologies
Source: habr.com