Eines der Probleme, auf die Softwareanbieter mit mehreren Produkten häufig stoßen, ist die Verdoppelung der Kompetenzen von Ingenieuren - Entwicklern, Testern und Infrastrukturadministratoren - in fast jedem Team. Dies gilt auch für teure Ingenieure - Experten auf dem Gebiet der Lastprüfung.Anstatt sich ihrer direkten Verantwortung zu widmen und ihre einzigartige Erfahrung zu nutzen, um den Lasttestprozess aufzubauen, eine Methodik, optimale Metriken auszuwählen und Selbsttests gemäß Lastprofilen zu schreiben, müssen Ingenieure häufig eine Testinfrastruktur von Grund auf neu bereitstellen, Lasttools konfigurieren und sie einbetten Konfigurieren Sie in CI-Systemen die Überwachung und Veröffentlichung von Berichten.In einem anderen Artikel finden Sie Lösungen für einige organisatorische Probleme beim Testen, die wir bei Positive Technologies verwenden . Und hier werde ich über die Möglichkeit sprechen, Lasttests in eine gemeinsame CI-Pipeline zu integrieren, wobei das Konzept des "Lasttests als Service" verwendet wird. Sie erfahren, wie und welche Docker-Images von Lastquellen in der CI-Pipeline verwendet werden können. So verbinden Sie Lastquellen mithilfe einer Baugruppenvorlage mit Ihrem CI-Projekt; Wie eine Demo-Pipe aussieht, um Auslastungstests durchzuführen und Ergebnisse zu veröffentlichen. Der Artikel kann für Software-Testingenieure und Automatisierungsingenieure bei CI nützlich sein, die über die Architektur ihres Lastsystems nachgedacht haben.Essenz des Konzepts
Das Konzept des Lasttests als Service impliziert die Fähigkeit, Apache JMeter, Yandex.Tank-Ladetools und eigene Frameworks in ein beliebiges kontinuierliches Integrationssystem zu integrieren. Eine Demo wird für GitLab CI sein, aber die Prinzipien sind allen CI-Systemen gemeinsam.Load Testing as a Service ist ein zentraler Dienst zur Durchführung von 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 realisiert - durch Hinzufügen und Parametrieren der üblichen gitlab-ci.yml-Vorlage im GitLab CI-Projekt.Der Vorteil des Ansatzes besteht darin, dass die gesamte CI-Infrastruktur, Lastagenten, Docker-Images von Lastquellen, Testpipelines und die Veröffentlichung von Berichten von der zentralen Automatisierungsabteilung (DevOps-Ingenieure) unterstützt werden und Lasttestingenieure ihre Bemühungen auf die Testentwicklung konzentrieren können und Analyse ihrer Ergebnisse, ohne sich mit Infrastrukturproblemen zu befassen.Zur Vereinfachung der Beschreibung wird davon ausgegangen, dass die Zieltestanwendung oder der Zielserver bereits im Voraus bereitgestellt und konfiguriert wurde (hierfür können automatisierte Skripts in Python, SaltStack, Ansible usw. verwendet werden). Dann gliedert sich das gesamte Konzept des Stresstests als Dienstleistung in drei Phasen: Vorbereitung, Prüfung, Veröffentlichung von Berichten . Weitere Details zum Diagramm (alle Bilder sind anklickbar):
Bei der Durchführung von Stresstests versuchen wir, die Standards und Methoden von ISTQB einzuhalten. Wir verwenden die entsprechende Terminologie und die empfohlenen Metriken. Ich werde eine kurze Liste grundlegender Konzepte und Definitionen beim Lasttest geben.Der Lade-Agent (Lade-Agent) - die virtuelle Maschine, auf der die Anwendung gestartet wird - die Quelle des Ladevorgangs (Apache JMeter, Yandex.Tank oder selbstgeschriebenes Lademodul).Der Testzweck (Ziel) ist ein Server oder eine Anwendung, die auf dem Server installiert ist und der Last ausgesetzt wird.Ein Testfall besteht aus einer Reihe parametrisierter Schritte: Benutzeraktionen und erwartete Reaktionen auf diese Aktionen mit festen Netzwerkanforderungen und -antworten in Abhängigkeit von den angegebenen Parametern.Profil oder Lastplan (Profil) - In der ISTQB-Methodik (Abschnitt 4.2.4, S. 43) bestimmen Lastprofile die für einen bestimmten Test kritischen Metriken und Optionen zum Ändern der Lastparameter während des Tests. Sie können Beispiele für Profile in der Abbildung sehen. Test ist ein Skript mit einem vordefinierten Parametersatz. Testplan - Testsuite und Lastprofil. Testran (Testlauf) - eine Iteration des Startens eines Tests mit einem vollständig ausgeführten Ladeszenario und einem empfangenen Bericht. Netzwerkanforderung (Anforderung) - Eine HTTP-Anforderung, die vom Agenten an das Ziel gesendet wird. Netzwerkantwort (Antwort) - Eine HTTP-Antwort, die vom Ziel an den Agenten gesendet wird.
Der HTTP-Antwortstatus ist ein Standardantwortcode vom Anwendungsserver.Transaktion (Transaktion) - ein vollständiger Zyklus von "Anfrage - Antwort". Eine Transaktion wird vom Beginn des Sendens einer Anfrage (Anfrage) bis zum Abschluss des Empfangs einer Antwort (Antwort) gezählt.Transaktionsstatus (Transaktionsstatus) - Konnte der Zyklus "Anfrage-Antwort" erfolgreich abgeschlossen werden? Wenn in dieser Schleife ein Fehler aufgetreten ist, wird die gesamte Transaktion als nicht erfolgreich angesehen.Antwortzeit (Latenz) - Zeit vom Ende des Sendens einer Anfrage (Anfrage) bis zum Beginn des Empfangs einer Antwort (Antwort).Lademetriken (Metriken) - Die Eigenschaften des geladenen Dienstes und des Lademittels, die während des Lasttestprozesses definiert wurden.Grundlegende Metriken zur Messung von Lastparametern
Einige der häufigsten und empfohlenen Metriken in der ISTQB- Methodik (S. 36, 52) sind in der folgenden Tabelle aufgeführt. Ähnliche Metriken für den Agenten und das Ziel werden in derselben Zeile angezeigt.Das grundlegende Schema des Lasttests ist sehr einfach und besteht aus drei Hauptphasen, die ich bereits erwähnt habe: Vorbereiten - Testen - Bericht , dh Vorbereiten von Testzielen und Festlegen von Parametern für Lastquellen, anschließendes Durchführen von Lasttests und schließlich Generieren und Veröffentlichen eines Berichts über das Testen. Anmerkungen zum Schema:
- QA.Tester - Stresstest-Experte,
- Ziel ist die Zielanwendung, für die Sie das Verhalten unter Last kennen müssen.
Klassifikator von Entitäten, Stufen und Schritten im Diagramm
CI-
Kommen wir zum praktischen Teil. Ich möchte zeigen, wie wir bei einigen Projekten bei Positive Technologies das Konzept des Lasttests als Service implementiert haben.Zunächst haben wir mithilfe unserer DevOps-Ingenieure einen dedizierten Agentenpool in GitLab CI erstellt, um Auslastungstests auszuführen. Um sie in Vorlagen nicht mit anderen zu verwechseln, z. B. Assembly-Pools, haben wir diesen Agenten Tags hinzugefügt : tags : load. Sie können auch andere eindeutige Tags verwenden. Sie werden bei der Registrierung von GitLab CI Runners festgelegt.Wie finde ich die benötigte Leistung per Hardware heraus? Die Eigenschaften von Lade-Agenten - eine ausreichende Menge an vCPU, RAM und Festplatte - können auf der Grundlage berechnet werden, dass Docker, Python (für Yandex.Tank), GitLab CI-Agent und Java (für Apache JMeter) auf dem Agenten ausgeführt werden müssen. Für Java unter JMeter wird außerdem empfohlen, mindestens 512 MB RAM und als Obergrenze 80% des verfügbaren Speichers zu verwenden .Aufgrund unserer Erfahrung empfehlen wir daher, mindestens 4 vCPU, 4 GB RAM und 60 GB SSD für Load Agents zu verwenden. Die Bandbreite der Netzwerkkarte wird basierend auf den Anforderungen des Lastprofils bestimmt.Wir verwenden hauptsächlich zwei Ladequellen - Docker-Images Apache JMeter und Yandex.Tank.Yandex.Tank- Dies ist das Open Source-Tool von Yandex für Stresstests. Die modulare Architektur basiert auf dem leistungsstarken asynchronen hitbasierten HTTP-Anforderungsgenerator Phantom. Der Tank verfügt über eine integrierte Überwachung der Ressourcen des getesteten Servers mithilfe des SSH-Protokolls, kann den Test unter den angegebenen Bedingungen automatisch stoppen, die Ergebnisse sowohl an die Konsole ausgeben als auch in Form von Diagrammen. Sie können Ihre Module daran anschließen, um die Funktionalität zu erweitern. Übrigens haben wir Tank verwendet, als es noch kein Mainstream war. Im Artikel „ Yandex.Tank und Automatisierung von Lasttests “ können Sie die Geschichte lesen, wie wir 2013 damit Lasttests für PT Appllication Firewall durchgeführt haben - eines der Produkte unseres Unternehmens.Apache JMeterIst ein Open Source-Tool zur Durchführung von Apache-Stresstests. Es kann gleichermaßen gut zum Testen von statischen und dynamischen Webanwendungen verwendet werden. JMeter unterstützt eine Vielzahl von Protokollen und Interaktionsmöglichkeiten 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 Arbeit an der Befehlszeile eines kompatiblen Java-Betriebssystems (Linux, Windows, Mac OS X). Das Tool kann dynamisch einen HTML-Testbericht generieren.Zur Vereinfachung der Verwendung in unserem Unternehmen und zur Möglichkeit für Tester, die Umgebung zu ändern und hinzuzufügen, haben wir Docker-Images von Ladequellen auf GitLab CI erstellt und im internen Docker-Register auf Artifactory veröffentlicht . Auf diese Weise wird es schneller und einfacher, sie für Lasttests in Pipelines anzuschließen. Wie Sie Docker dazu bringen, die Registrierung über GitLab CI zu pushen - lesen Sie die Anweisungen .Die grundlegende Docker-Datei für Yandex.Tank haben wir diese genommen:Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]
Und für Apache JMeter dieses:Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]
Wie unser kontinuierliches Integrationssystem funktioniert, lesen Sie im Artikel „ Automatisierung von Entwicklungsprozessen: Wie wir DevOps-Ideen in positive Technologien umgesetzt haben “.Vorlage und Pipeline
Eine Beispielvorlage für die Durchführung von Lasttests ist im Demo-Lastprojekt verfügbar . Sie können die Anweisungen zur Verwendung der Vorlage in der Readme-Datei lesen. In der Vorlage selbst (der Datei .gitlab-ci.yml ) finden Sie Hinweise dazu, wofür dieser oder jener Schritt verantwortlich ist.Die Vorlage ist sehr einfach und zeigt die drei oben in der Abbildung beschriebenen Phasen der Lastprüfung: Erstellung, Prüfung und Veröffentlichung von Berichten. Verantwortlich dafür ist das Stage-Verzeichnis : Vorbereitung, Test und Bericht .- Prepare . , - docker registry: Test. .
- Test , . : Yandex.Tank, Apache JMeter, . job-. :
: CI- . , bash-. , — QA-. . ./tests.
- Report , Test, , GitLab Pages . GitLab Pages , ./public index.html. GitLab Pages .
, :
:
In einem Demo-Beispiel sieht eine Pipeline mit Lasttests und zwei Lastquellen (Sie können unnötige deaktivieren) folgendermaßen aus: Apache JMeter kann einen HTML-Bericht selbst generieren, sodass es rentabler ist, ihn mit regulären Tools in GitLab Pages zu speichern. So sieht der Apache JMeter-Bericht aus: In der Demo für Yandex.Tank wird im Abschnitt für GitLab-Seiten nur ein gefälschter Textbericht angezeigt . 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 ./tests/example-yandextank-test.yml ). So sieht der Bericht von Tank in Grafana aus:
Zusammenfassung
In dem Artikel habe ich über das Konzept des "Lasttests als Dienst" (Lasttest als Dienst) gesprochen. Die Hauptidee besteht darin, die Infrastruktur vorkonfigurierter Pools von Lastagenten, Docker-Images von Lastquellen, Berichtssystemen und einer Pipeline zu verwenden, die sie in GitLab CI auf der Grundlage einer einfachen .gitlab-ci.yml-Vorlage vereint (Beispiel als Referenz ). All dies wird von einem kleinen Team von Automatisierungsingenieuren unterstützt und auf Anfrage von Produktteams repliziert. Ich hoffe, dies hilft Ihnen bei der Vorbereitung und Implementierung eines ähnlichen Programms in Ihrem Unternehmen. Vielen Dank für Ihre Aufmerksamkeit!PS Ich möchte meinen Kollegen Sergey Kurbanov und Nikolay Yusev für die technische Unterstützung bei der Umsetzung des Konzepts der Lastprüfung als Dienstleistung in unserem Unternehmen ganz herzlich danken.Autor :Timur Gilmullin - Stellvertreter. Leiter Technologie- und Entwicklungsprozesse (DevOps), Positive Technologien