Eines der Probleme, mit denen Multi-Produkt-Softwareanbieter oft konfrontiert sind, ist die Duplizierung der Kompetenzen von Ingenieuren â Entwicklern, Testern und Infrastrukturadministratoren â in fast jedem Team. Dies betrifft auch teure Ingenieure â Spezialisten im Bereich Lasttests.
Anstatt sich um ihre direkten Aufgaben zu kĂŒmmern und ihre einzigartigen Erfahrungen fĂŒr die Gestaltung des Lasttestprozesses zu nutzen, die Methodik auszuwĂ€hlen, optimale Metrik-Werte festzulegen und automatische Tests gemÀà den Lastprofilen zu schreiben, mĂŒssen Ingenieure oft aus dem Nichts Testinfrastrukturen aufbauen, Lasttesttools konfigurieren, sie selbst in CI-Systeme integrieren und die Ăberwachung sowie die Veröffentlichung von Berichten einrichten.
Lösungen fĂŒr einige organisatorische Probleme im Testbereich, die wir bei Positive Technologies anwenden, finden Sie in . In diesem Artikel werde ich ĂŒber die Möglichkeit sprechen, Lasttests in eine allgemeine CI-Pipeline zu integrieren, indem das Konzept "Lasttest als Dienst" (Load Testing as a Service) genutzt wird. Sie werden erfahren, wie und welche Docker-Images von Lastquellen in der CI-Pipeline verwendet werden können; wie Lastquellen in Ihr CI-Projekt mit Hilfe einer Baumaske eingebunden werden können; wie eine Demopipeline fĂŒr den Start von Lasttests und die Veröffentlichung von Ergebnissen aussieht. Der Artikel könnte fĂŒr Softwaretestingenieure und Automatisierungsingenieure in CI nĂŒtzlich sein, die ĂŒber die Architektur ihres Lastsystems nachgedacht haben.
Der Kern des Konzepts
Das Konzept "Load Testing as a Service" sieht die Möglichkeit vor, die Lasttestwerkzeuge Apache JMeter, Yandex.Tank und eigene Frameworks in beliebige Continuous-Integration-Systeme zu integrieren. Das Beispiel wird fĂŒr GitLab CI sein, aber die GrundsĂ€tze sind fĂŒr alle CI-Systeme allgemein gehalten.
Load Testing as a Service ist ein zentralisierter Dienst fĂŒr die DurchfĂŒhrung von Lasttests. Lasttests werden in speziellen Agenten-Pools gestartet, die Veröffentlichung der Ergebnisse erfolgt automatisch in GitLab Pages, Influx DB und Grafana oder in Testberichterstattungssystemen (TestRail, ReportPortal usw.). Automatisierung und Skalierung werden so einfach wie möglich umgesetzt â durch das HinzufĂŒgen und Parametrieren einer regulĂ€ren Vorlage gitlab-ci.yml im GitLab CI-Projekt.
Der Vorteil des Ansatzes besteht darin, dass die gesamte CI-Infrastruktur, die Lastagenten, die Docker-Images der Lastquellen, die Testpipeline und die Veröffentlichung von Berichten â durch die KrĂ€fte der zentralisierten Automatisierungsabteilung (DevOps-Ingenieuren) unterstĂŒtzt werden, wĂ€hrend die Lasttestingenieure ihre BemĂŒhungen auf die Entwicklung von Tests und die Analyse ihrer Ergebnisse konzentrieren können, ohne sich mit infrastrukturellen Fragen zu befassen.
Zur Vereinfachung der Beschreibung gehen wir davon aus, dass die Zielanwendung oder der Server bereits im Voraus bereitgestellt und konfiguriert wurde (dazu können automatisierte Skripte in Python, SaltStack, Ansible usw. verwendet werden). Dann lÀsst sich das gesamte Konzept des Lasttestens als Dienst in drei Phasen zusammenfassen: Vorbereitung, Test, Veröffentlichung von Berichten. Weitere Details sind im Diagramm zu finden (alle Bilder sind klickbar):
Wesentliche Begriffe und Definitionen im Lasttesten
Bei der DurchfĂŒhrung von Lasttests versuchen wir, uns an zu orientieren, die entsprechende Terminologie und empfohlene Metriken zu verwenden. Ich werde eine kurze Liste der grundlegenden Begriffe und Definitionen im Lasttesten geben.
Lastagent (load agent) â eine virtuelle Maschine, auf der die Anwendung â die Lastquelle (Apache JMeter, Yandex.Tank oder ein selbst geschriebener Lastmodul) ausgefĂŒhrt wird.
Ziel des Tests (target) â der Server oder die Anwendung, die auf dem Server installiert ist und der Last ausgesetzt wird.
Test-Szenario (test case) â eine Reihe von parametrisierten Schritten: Benutzeraktionen und die erwarteten Reaktionen auf diese Aktionen, mit festgelegten Netzwerkrequests und -antworten, je nach vorgegebenen Parametern.
Lastprofil oder Lastplan (profile) â bei (Abschnitt 4.2.4, Seite 43) Lastprofile definieren kritische Metriken fĂŒr den spezifischen Test und die Varianten der Anpassung der Lastparameter wĂ€hrend des Tests. Beispiele fĂŒr Profile finden Sie in der Abbildung.
Test (test) â ein Szenario mit einer vordefinierten Reihe von Parametern.
Testplan (test-plan) â eine Reihe von Tests und ein Lastprofil.
TestausfĂŒhrung (testrun) â eine Iteration der DurchfĂŒhrung eines Tests mit einem vollstĂ€ndig durchgefĂŒhrten Lastszenario und einem erhaltenen Bericht.
Netzwerkrequest (request) â HTTP-Request, der vom Agenten an das Ziel gesendet wird.
Netzwerkantwort (response) â HTTP-Antwort, die vom Ziel an den Agenten gesendet wird.
HTTP-Statuscode (HTTP responses status) â standardmĂ€Ăiger Antwortcode vom Anwendungsserver.
Transaktion (transaction) â der vollstĂ€ndige Zyklus "Anfrage â Antwort". Eine Transaktion wird von dem Moment an betrachtet, in dem die Anfrage (request) gesendet wird, bis die Antwort (response) empfangen wird.
Status der Transaktion (transactions status) â ob der Zyklus "Anfrage â Antwort" erfolgreich abgeschlossen werden konnte. Wenn in diesem Zyklus ein Fehler aufgetreten ist, wird die gesamte Transaktion als nicht erfolgreich betrachtet.
Antwortzeit (latency) â die Zeit vom Ende der AnfrageĂŒbermittlung (request) bis zum Beginn des Antwortempfangs (response).
Lastmetriken (metrics) â Eigenschaften des belasteten Dienstes und des Lastagentes, die im Rahmen von Lasttests definiert werden.
Hauptmetriken zur Messung der Lastparameter
Einige der am hĂ€ufigsten verwendeten und in der Methodologie empfohlenen (S. 36, 52) Metriken sind in der folgenden Tabelle aufgefĂŒhrt. Ăhnliche Metriken fĂŒr Agenten und Ziele sind in einer Zeile aufgefĂŒhrt.
Metriken fĂŒr den Lastagenten
Metriken des Zielsystems oder der unter Last getesteten Anwendung
Die Anzahl  vCPU und Speicher RAM,
Festplatte â "Hardware"-Eigenschaften des Lastagenten
CPU, Speicher-, Festplattennutzung â Dynamik der Auslastung von CPU, Speicher und Festplatte
wÀhrend des Tests. Normally wird der Prozentsatz von
den maximal verfĂŒgbaren Werten gemessen.
Netzwerkdurchsatz (am Lastagenten) â die Bandbreite
des Netzwerkinterfaces auf dem Server,
auf dem der Lastagent installiert ist.
Normalerweise wird in Bytes pro Sekunde (bps) gemessen.
Netzwerkdurchsatz(am Ziel) â die Bandbreite des Netzwerkinterfaces
auf dem Zielserver. Normalerweise wird in Bytes pro Sekunde (bps) gemessen.
Virtuelle Benutzerâ die Anzahl der virtuellen Benutzer,
die Lastszenarien umsetzen und
reale Benutzeraktionen simulieren.
Status der virtuellen Benutzer, Bestanden/Nicht bestanden/Gesamt â die Anzahl der erfolgreichen und
nicht erfolgreichen Status der Arbeit virtueller Benutzer
fĂŒr Lastszenarien sowie deren Gesamtanzahl.
Normalerweise wird erwartet, dass alle Benutzer
alle ihre Aufgaben gemÀà dem Lastprofil erfolgreich durchfĂŒhren konnten.
Jeder Fehler wĂŒrde bedeuten, dass auch der echte Benutzer seine Aufgabe
bei der Arbeit mit dem System nicht lösen kann.
Anfragen pro Sekunde (Minute)â die Anzahl der Netzwerkfragen pro Sekunde (oder Minute).
Eine wichtige Eigenschaft des Lastagenten: wie viele Anfragen er generieren kann.
TatsÀchlich ist dies eine Nachahmung der Ansprache an die Anwendung durch virtuelle Benutzer
Antworten pro Sekunde (Minute)
â die Anzahl der Netzwerkantworten pro Sekunde (oder Minute).
Eine wichtige Kennzahl des Zielservices: wie viele es gelungen ist
zu generieren und Antworten auf Anfragen zu senden mit
Lastagent
HTTP-Antwortstatusâ die Anzahl der verschiedenen Antwortcodes
vom Anwendungsserver, die vom Lastagenten erhalten wurden.
Zum Beispiel bedeutet 200 OK, dass die Ansprache erfolgreich war,
wÀhrend 404 bedeutet, dass die Ressource nicht gefunden wurde
Latenz (Antwortzeit) â die Zeit vom Abschluss
des Sendens der Anfrage (request) bis zum Beginn des Empfangs der Antwort (response).
Normalerweise wird in Millisekunden (ms) gemessen
Transaktionsantwortzeitâ die Zeit fĂŒr eine vollstĂ€ndige Transaktion,
das Ende des Zyklus «Anfrage â Antwort».
Diese Zeit reicht von Beginn des Sendens der Anfrage (request)
bis zum Abschluss des Empfangs der Antwort (response).
Die Transaktionszeit kann auf verschiedene Weise in Sekunden (oder Minuten) gemessen werden:
man zÀhlt das Minimum,
Maximum, Mittelwert und zum Beispiel den 90. Perzentil.
Minimale und maximale Werte sind die Extrempunkte
der Systemleistung.
Der neunzige Perzentil wird am hÀufigsten verwendet,
da er die Mehrheit der Benutzer zeigt,
die angenehm auf der Leistungsgrenze des Systems arbeiten
Transaktionen pro Sekunde (Minute) â die Anzahl der vollstĂ€ndigen
Transaktionen pro Sekunde (Minute),
d.h. wie viele Anfragen die Anwendung annehmen und
verarbeiten und Antworten ausgeben konnte.
TatsÀchlich ist dies die Durchsatzrate des Systems
Transaktionsstatus , Passed / Failed / Total â die Anzahl
erfolgreicher, nicht erfolgreicher und die Gesamtzahl der Transaktionen.
FĂŒr reale Benutzer wĂŒrde eine nicht erfolgreiche
Transaktion praktisch bedeuten,
dass die Arbeit mit dem System unter Last unmöglich ist.
Prinzipielle Skizze des Lasttests
Die prinzipielle Skizze des Lasttests ist sehr einfach und besteht aus drei Hauptphasen, die ich bereits erwĂ€hnt habe: Vorbereitung â Test â Bericht, also die Vorbereitung der Testziele und das Setzen von Parametern fĂŒr die Lastquellen, dann die DurchfĂŒhrung von Lasttests und schlieĂlich die Erstellung und Veröffentlichung des Testberichts.
Anmerkungen zur Skizze:
- QA.Tester â Experte fĂŒr Lasttests,
- Ziel â die Zielanwendung, fĂŒr die das Verhalten unter Last ermittelt werden muss.
Klassifizierung von EntitÀten, Phasen und Schritten in der Skizze
Phasen und Schritte
Was passiert
Was am Eingang
Was am Ausgang
Prepare: Vorbereitungsphase fĂŒr die Tests
LoadParameters
Aufgabe und Initialisierung
vom Benutzer
Belastungsparameter,
Auswahl der Metriken und
Vorbereitung des Testplans
(Lastprofil)
Benutzerdefinierte Parameter fĂŒr
die Initialisierung des Lastagenten
Testplan
Ziel des Tests
VM
Bereitstellung einer virtuellen Maschine in der Cloud mit
den erforderlichen Eigenschaften
VM-Parameter fĂŒr den Lastagenten
Automatisierungsskripte zur
Erstellung von VMs
Konfigurierte VM in
Env
der Cloud
Konfiguration des Betriebssystems und Vorbereitung
der Umgebung fĂŒr
den Betrieb des Lastagenten
Umgebungsparameter fĂŒr
den Lastagenten
Umgebungsanpassungen
Erstellung von VMs
Vorbereitete Umgebung:
Betriebssystem, Dienste und Anwendungen,
die fĂŒr den Betrieb erforderlich sind
LoadAgents
Umgebungsanpassungen
Installation, Konfiguration und Parametrisierung
des Lastagenten.
Oder Herunterladen des Docker-Images mit
vorgefertigter Lastquelle
Docker-Image der Lastquelle
(JMeter, JM oder selbstgeschriebenes Framework)
Einstellungen
Konfigurierten und einsatzbereiten Lastagenten
Umgebungsanpassungen
Test: Phase der AusfĂŒhrung von Lasttests. Die Quellen sind Lastagenten, die in dedizierten Agentenpools fĂŒr GitLab CI bereitgestellt werden.
Load
Starten des Lastagenten
mit dem ausgewÀhlten Testplan
und belastungsspezifischen Parametern
Benutzerdefinierte Parameter
fĂŒr die Initialisierung
Protokolle der AusfĂŒhrung
von Lasttests
Umgebungsanpassungen
Testplan
Ziel des Tests
Systemprotokolle
Dynamik der VerÀnderung der Zielmetriken und des Lastagenten
RunAgents
AusfĂŒhrung von Test-Szenarien durch den
Lastagent entsprechend dem
Lastprofil
Interaktion des Lastagenten
mit dem Testziel
Logs
Sammlung von "rohen" Logs
im Verlauf der Lasttests:
Testplan
Ziel des Tests
Aufzeichnungen ĂŒber die Aktionen des Lastagenten,
Zustand des Testziels
und der VM, auf der der Agent lÀuft
Metrics
Sammlung von "rohen" Metriken wÀhrend des Tests
Dynamik der VerÀnderung der Zielmetriken
Systemprotokolle
Dynamik der VerÀnderung der Zielmetriken und des Lastagenten
RunAgents
und des Lastagenten
Report: Phase der Erstellung des Testberichts
Generator
Verarbeitung der gesammelten
rohen Metriken und Protokollen
Erstellung des Berichts in
menschenlesbarem Format,
möglichst mit Elementen
der Analyse
Dynamik der VerÀnderung der Metriken
des Ziels und des Lastagenten
Verarbeitete "grobe" Logs
in einem format, das fĂŒr
Export in externe Speicher geeignet ist
Systemprotokolle
Dynamik der VerÀnderung der Zielmetriken und des Lastagenten
RunAgents
Statischer Bericht ĂŒber die Last,
geeignet fĂŒr die menschliche Analyse
Publish
Veröffentlichung des Berichts
ĂŒber die Lasttests in einem externen
Dienst
fĂŒr die Analyse durch Menschen geeignet
Veröffentlichen
Veröffentlichung des Berichts
ĂŒber
Lasttests in einem externen
Dienst
Verarbeitete âRohdatenâ
Logs in einem geeigneten Format
fĂŒr den Export in externe
Speicher
In externem
Speichersystem gespeicherte Berichte ĂŒber
belastung, geeignet
fĂŒr die Analyse durch Menschen
Anschluss von Lastquellen im CI-Template
Lass uns zum praktischen Teil ĂŒbergehen. Ich möchte zeigen, wie wir in einigen Projekten bei das Konzept des Lasttests als Service umgesetzt haben.
ZunĂ€chst haben unsere DevOps-Ingenieure in GitLab CI einen dedizierten Pool von Agenten fĂŒr die DurchfĂŒhrung von Lasttests erstellt. Um sie in den Templates nicht mit anderen, wie z.B. Build-Pools, zu verwechseln, haben wir den Agenten Tags hinzugefĂŒgt, : load. Es können auch andere verstĂ€ndliche Tags verwendet werden. Diese werden der GitLab CI Runner festgelegt.
Wie bestimmt man die benötigte Hardware-Leistung? Die Spezifikationen der Lastagenten â ausreichende Anzahl an vCPU, RAM und Speicher â können unter BerĂŒcksichtigung der Tatsache berechnet werden, dass auf dem Agenten Docker, Python (fĂŒr Yandex.Tank), der GitLab CI-Agent und Java (fĂŒr Apache JMeter) ausgefĂŒhrt werden mĂŒssen. FĂŒr Java unter JMeter wird zudem empfohlen, mindestens 512 MB RAM und als obere Grenze .
zu verwenden. Basierend auf unserer Erfahrung empfehlen wir fĂŒr Lastagenten mindestens: 4 vCPU, 4 GB RAM, 60 GB SSD. Die Bandbreite der Netzwerkkarte wird basierend auf den Anforderungen des Lastprofils bestimmt.
Wir verwenden hauptsĂ€chlich zwei Lastquellen â Docker-Images von Apache JMeter und Yandex.Tank.
ist ein Open-Source-Tool von Yandex fĂŒr Lasttests. Die modulare Architektur basiert auf einem leistungsstarken asynchronen hit-basierten HTTP-Anfragesender namens Phantom. Der Tank verfĂŒgt ĂŒber integrierte RessourcenĂŒberwachung des getesteten Servers ĂŒber das SSH-Protokoll, kann Tests unter bestimmten Bedingungen automatisch stoppen, kann Ergebnisse sowohl in die Konsole als auch grafisch anzeigen und ermöglicht das HinzufĂŒgen eigener Module zur Erweiterung der FunktionalitĂ€t. Ăbrigens haben wir den Tank verwendet, als dies noch nicht Mainstream war. In dem Artikel âkann man die Geschichte lesen, wie wir 2013 mit seiner Hilfe Lasttests durchgefĂŒhrt haben fĂŒr eines der Produkte unseres Unternehmens.
â dies ist ein Open-Source-Tool zur DurchfĂŒhrung von Lasttests des Unternehmens Apache. Es kann sowohl fĂŒr das Testen von statischen als auch von dynamischen Webanwendungen gleichermaĂen gut verwendet werden. JMeter unterstĂŒtzt eine riesige Anzahl von Protokollen und Interaktionsmethoden 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, kann Shell-Kommandos 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 in der Kommandozeile jeder mit Java kompatiblen Betriebssystem (Linux, Windows, Mac OS X). Das Tool kann dynamisch einen HTML-Bericht ĂŒber die Tests generieren.
Um die Nutzung innerhalb unseres Unternehmens zu erleichtern und den Testern die Möglichkeit zu geben, selbst Umgebungen zu Ă€ndern und hinzuzufĂŒgen, haben wir Docker-Image-Builds der Lastquellen in GitLab CI erstellt und in das interne veröffentlicht. So wird es schneller und einfacher, sie in Pipelines fĂŒr Lasttests zu integrieren. Wie man docker push in die Registry ĂŒber GitLab CI macht â siehe in .
Die Basis-Docker-Datei fĂŒr Yandex.Tank haben wir diese hier genommen:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]Und fĂŒr Apache JMeter diese:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Wie unser Continuous Integration-System aufgebaut ist, können Sie in dem Artikel lesen â».
Vorlage und Pipeline
Ein Beispiel fĂŒr eine Vorlage zur DurchfĂŒhrung von Lasttests ist im Projekt . In zu finden, wo die Anleitung zur Nutzung der Vorlage beschrieben ist. In der Vorlage selbst (Datei ) finden Sie Anmerkungen dazu, welche Schritte fĂŒr was verantwortlich sind.
Die Vorlage ist sehr einfach und zeigt die drei Phasen des Lasttests, die oben im Diagramm beschrieben sind: Vorbereitung, Test und Berichtserstellung. DafĂŒr sind verantwortlich : Prepare, Test und Report.
- Die Phase sollte zur anfĂ€nglichen Konfiguration der Testziele oder zur ĂberprĂŒfung ihrer Erreichbarkeit verwendet werden. Die Umgebung fĂŒr die Lastquellen muss nicht konfiguriert werden, sie sind bereits als Docker-Images erstellt und im Docker-Registry abgelegt: es genĂŒgt, die benötigte Version in der Testphase anzugeben. Man kann sie jedoch auch neu zusammenstellen und eigene modifizierte Images erstellen.
- Die Phase wird verwendet, um die Lastquelle anzugeben, Tests zu starten und Testartefakte zu speichern. Sie können jede Lastquelle auswĂ€hlen: Yandex.Tank, Apache JMeter, Ihre eigene oder alle zusammen. Um unnötige Quellen zu deaktivieren, genĂŒgt es, die Job-Quelle auszukommentieren oder zu löschen. Eintrittspunkte fĂŒr Lastquellen:
- Die Startparameter von Yandex.Tank werden in der Datei angegeben.,
- Die Startparameter von Apache JMeter werden in der Datei angegeben .
Hinweis: Die Vorlage der Build-Konfiguration wird verwendet, um die Interaktion mit dem CI-System einzurichten und soll keine Logik der Tests enthalten. FĂŒr die Tests wird der Eintrittspunkt angegeben, an dem sich das Steuerungs-Bash-Skript befindet. Die Art und Weise, wie Tests gestartet, Berichte erstellt und die Test-Szenarien selbst umgesetzt werden â das sollen QA-Ingenieure realisieren. Im Demobeispiel wird fĂŒr beide Lastquellen als einfachster Test eine Anfrage an die Hauptseite von Yandex verwendet. Die Szenarien und Testparameter befinden sich im Verzeichnis .
- In der Phase mĂŒssen die Methoden zur Veröffentlichung der im Teststadium erhaltenen Testergebnisse in externe Speicherorte beschrieben werden, zum Beispiel in GitLab Pages oder spezielle Berichtssysteme. FĂŒr GitLab Pages ist es erforderlich, dass das Verzeichnis ./public nach Abschluss der Tests nicht leer ist und mindestens die Datei index.html enthĂ€lt. Ăber die Feinheiten des Dienstes GitLab Pages können Sie lesen .
Beispiele, wie man Daten exportiert:
- von JMeter nach ,
- von Yandex.Tank nach .
Anweisungen zur Einrichtung der Veröffentlichung:
- HTML-Statischer Inhalt nach ,
- in InfluxDB und dann nach .
Im Demobeispiel sieht die Pipeline mit Lasttests und zwei Lastquellen (eine kann deaktiviert werden) so aus:
Apache JMeter kann selbst HTML-Berichte erstellen, daher ist es vorteilhafter, diese mit den Standardmitteln in GitLab Pages zu speichern. So sieht der Bericht von Apache JMeter aus:
Im Demobeispiel fĂŒr Yandex.Tank sehen Sie nur im Bereich fĂŒr GitLab Pages. WĂ€hrend des Tests kann Tank Ergebnisse in die InfluxDB speichern, und von dort können diese beispielsweise in Grafana angezeigt werden (die Einrichtung erfolgt in der Datei ). So sieht der Bericht von Tank in Grafana aus:
Zusammenfassung
In dem Artikel habe ich das Konzept des "Load Testing as a Service" (Lasttest als Dienst) erlĂ€utert. Die Hauptidee besteht darin, die Infrastruktur von vorgefertigten Pools von Lastagenten, Docker-Images fĂŒr Lastquellen, Berichtssystemen und dem sie verbindenden Pipeline in GitLab CI basierend auf einer einfachen Vorlage .gitlab-ci.yml zu nutzen (Beispiel. ). All dies wird von einem kleinen Team von Automatisierungsingenieuren unterstĂŒtzt und auf Anfrage der Produktteams reproduziert. Ich hoffe, dass dies Ihnen bei der Vorbereitung und Umsetzung eines Ă€hnlichen Schemas in Ihrem Unternehmen hilft. Vielen Dank fĂŒr Ihre Aufmerksamkeit!
P. S. Ich möchte meinen Kollegen, Sergej Kurbanow und Nikolai Jussew, fĂŒr die technische UnterstĂŒtzung bei der Umsetzung des Konzepts "Load Testing as a Service" in unserem Unternehmen herzlich danken.
Autor: â stellvertretender Leiter der Abteilung fĂŒr Technologien und Entwicklungsprozesse (DevOps) bei Positive Technologies
Quelle: habr.com
