Ee vun de Probleemer déi Multi-Produkt Software Ubidder dacks konfrontéieren ass d'Duplikatioun vun de Kompetenzen vun Ingenieuren - Entwéckler, Tester an Infrastrukturadministratoren - op bal all Team. Dëst gëllt och fir deier Ingenieuren - Spezialisten am Beräich vun der Laaschtestung.
Amplaz hir direkt Aufgaben ze maachen an hir eenzegaarteg Erfarung ze benotzen fir e Laaschttestprozess ze bauen, wielt eng Methodik, optimal Metriken an Autotester am Aklang mat Laaschtprofiler ze schreiwen, mussen d'Ingenieuren dacks Testinfrastruktur vun Null ofsetzen, Laaschtinstrumenter konfiguréieren an se embeden sech an CI Systemer, Iwwerwachung a Verëffentlechung vu Berichter opgeriicht.
Dir kënnt Léisunge fir e puer organisatoresch Probleemer am Test fannen, déi mir bei Positive Technologies benotzen . An an dësem wäert ech iwwer d'Méiglechkeet schwätzen, Laaschtester an enger gemeinsamer CI Pipeline z'integréieren mat dem Konzept vun "Laaschtestung als Service" (Laaschttest als Service). Dir léiert wéi a wéi eng Docker-Biller vu Lastquellen an der CI Pipeline benotzt kënne ginn; wéi Dir Luedequellen mat Ärem CI-Projet verbënnt mat enger Build-Schabloun; wéi d'Demo Pipeline ausgesäit fir Laaschtester auszeféieren an d'Resultater ze publizéieren. Den Artikel kann nëtzlech sinn fir Software Testen Ingenieuren an Automatisatiounsingenieuren am CI déi iwwer d'Architektur vun hirem Lastsystem denken.
D'Essenz vum Konzept
D'Konzept vun der Laaschttest als Service implizéiert d'Fäegkeet fir Laaschtinstrumenten Apache JMeter, Yandex.Tank an Ären eegene Kaderen an en arbiträr kontinuéierlechen Integratiounssystem z'integréieren. D'Demo wäert fir GitLab CI sinn, awer d'Prinzipien si gemeinsam fir all CI Systemer.
Last Testen als Service ass en zentraliséierte Service fir Last Testen. D'Laaschtester ginn an engagéierten Agent-Pools ausgeführt, d'Resultater ginn automatesch op GitLab Pages, Influx DB a Grafana oder an Testberichtsystemer (TestRail, ReportPortal, etc.) publizéiert. Automatisatioun a Skaléierung ginn esou einfach wéi méiglech ëmgesat - andeems Dir déi üblech gitlab-ci.yml Schabloun am GitLab CI Projet addéiert an parametreiert.
De Virdeel vun dëser Approche ass datt déi ganz CI Infrastruktur, Laaschtagenten, Docker-Biller vu Laaschtquellen, Testpipelines a Verëffentlechungsberichter vun enger zentraliséierter Automatisatiounsdepartement (DevOps Ingenieuren) ënnerhale ginn, wärend Laaschttestingenieure kënnen hir Efforten op Testentwécklung konzentréieren. an Analyse vun hire Resultater, ouni sech mat Infrastrukturproblemer ze beschäftegen.
Fir d'Einfachheet vun der Beschreiwung wäerte mir dovun ausgoen datt d'Zilapplikatioun oder de Server ënner Test schonn am Viraus ofgesat a konfiguréiert ass (automatiséiert Scripten am Python, SaltStack, Ansible, etc. kënne fir dëst benotzt ginn). Dann passt dat ganzt Konzept vum Lasttest als Service an dräi Etappen: Virbereedung, Testen, Verëffentlechung vu Berichter. Méi Detailer am Diagramm (all Biller sinn klickbar):
Basis Konzepter an Definitiounen am Laascht Testen
Wann Dir Laaschtester ausféiert, probéieren mir ze halen , benotzt déi entspriechend Terminologie a recommandéiert Metriken. Ech ginn eng kuerz Lëscht vun den Haaptkonzepter an Definitiounen am Laaschttest.
Luede Agent - eng virtuell Maschinn op där d'Applikatioun lancéiert gëtt - d'Laaschtquell (Apache JMeter, Yandex.Tank oder e selbstgeschriwwene Lastmodul).
Testziel (Zil) - Server oder Applikatioun op de Server installéiert, deen ze lueden wäert.
Testszenario (Testfall) - eng Rei vu parameteriséierte Schrëtt: Benotzeraktiounen an erwaart Reaktiounen op dës Aktiounen, mat fixen Netzwierkfuerderungen an Äntwerten, ofhängeg vun de spezifizéierte Parameteren.
Profil oder Ladeplang (Profil) - an (Sektioun 4.2.4, S. 43) Lastprofile definéieren Metriken déi kritesch sinn fir e bestëmmten Test an Optiounen fir d'Laaschtparameter während dem Test z'änneren. Dir kënnt Beispiller vu Profiler an der Figur gesinn.
Test - e Skript mat engem virbestëmmten Set vu Parameteren.
Testplang (Testplang) - eng Rei vun Tester an engem Laascht Profil.
Testran (Testrun) - eng Iteratioun vun engem Test mat engem voll ausgeführten Lastszenario an dem kritt Bericht.
Reseau Ufro (Ufro) - Eng HTTP-Ufro vun engem Agent op en Zil geschéckt.
Reseau Äntwert (Äntwert) - Eng HTTP Äntwert vum Zil un den Agent geschéckt.
HTTP Äntwert Code (HTTP Äntwerte Status) - Standard Äntwert Code vum Applikatioun Server.
Eng Transaktioun ass e komplette Ufro-Äntwert-Zyklus. Eng Transaktioun gëtt gezielt vum Ufank vun der Sendung vun enger Ufro (Ufro) bis zum Ofschloss vun der Empfang vun enger Äntwert (Äntwert).
Transaktioun Status - ob et méiglech war den Ufro-Äntwert-Zyklus erfollegräich ofzeschléissen. Wann et e Feeler an dësem Zyklus war, gëtt déi ganz Transaktioun als net erfollegräich ugesinn.
Äntwertzäit (latency) - d'Zäit vum Enn vun der Sendung vun enger Ufro (Ufro) bis zum Ufank vun der Empfang vun enger Äntwert (Äntwert).
Lueden Metriken - d'Charakteristiken vum geluedene Service an dem Laaschtagent bestëmmt am Laaschttest.
Basis Metriken fir d'Mooss vun Lastparameter
E puer vun de meescht benotzt a recommandéiert an der Methodik (S. 36, 52) d'Metriken sinn an der Tabell hei ënnen gewisen. Ähnlech Metriken fir Agent an Zil sinn op der selwechter Linn opgezielt.
Metriken fir de Last Agent
Metriken vum Zilsystem oder der Applikatioun déi ënner Laascht getest gëtt
Zuel vu vCPU an Erënnerung Ram,
Scheif - "Eisen" Charakteristiken vun der Laascht Agent
cpu, Erënnerung, Disk Benotzung - Dynamik vun der CPU, Erënnerung an Disk Lueden
am Prozess vun Tester. Normalerweis gemooss als Prozentsaz vun
maximal verfügbare Wäerter
Reseau Duerchgang (op Laascht Agent) - Duerchgang
Netzwierk Interface um Server,
wou d'Laascht Agent installéiert ass.
Normalerweis gemooss an Bytes pro Sekonn (bps)
Reseau Duerchgang(op Zil) - Netz Interface bandwidth
op der Zilserver. Normalerweis gemooss an Bytes pro Sekonn (bps)
Virtuell Benotzer- d'Zuel vun de virtuelle Benotzer,
Ëmsetzung Laascht Szenarie an
real Benotzeraktiounen imitéieren
Virtuell Benotzer Status, Passéiert / Ausgefall / Total - Zuel vun erfollegräich an
net erfollegräiche Statuse vu virtuelle Benotzer
fir Lastszenarien, souwéi hir Gesamtzuel.
Et gëtt allgemeng erwaart datt all Benotzer fäerdeg waren
all Är Aufgaben, déi am Laaschtprofil spezifizéiert sinn.
All Feeler bedeit datt e richtege Benotzer net fäeg ass
léisen Äre Problem wann Dir mam System schafft
Ufroen pro Sekonn (Minutt)- d'Zuel vun de Reseau Ufroen pro Sekonn (oder Minutt).
Eng wichteg Charakteristik vun engem Laaschtagent ass wéi vill Ufroe et generéiere kann.
Tatsächlech ass dëst eng Imitatioun vum Zougang zu der Applikatioun vu virtuelle Benotzer
Äntwerten pro Sekonn (Minutt)
- d'Zuel vun de Reseau Äntwerte pro Sekonn (oder Minutt).
Eng wichteg Charakteristiken vun der Zil- Service: wéi vill
generéiert a schéckt Äntwerten op Ufroen mat
Luede Agent
HTTP Äntwert Status- Zuel vu verschiddene Äntwert Coden
vum Applikatiounsserver, dee vum Lastagent kritt gëtt.
Zum Beispill, 200 OK heescht en erfollegräichen Uruff,
an 404 - datt d'Ressource net fonnt gouf
Latenz (Äntwert Zäit) - Zäit vum Enn
schéckt eng Ufro (Ufro) ier Dir ufänkt eng Äntwert ze kréien (Äntwert).
Normalerweis gemooss an Millisekonnen (ms)
Transaktioun Äntwert Zäit- Zäit vun enger voller Transaktioun,
Ofschloss vum Ufro-Äntwert-Zyklus.
Dëst ass d'Zäit vum Ufank vun der Sendung vun der Ufro (Ufro)
bis Ofschloss vun enger Äntwert (Äntwert) kréien.
Transaktiounszäit kann a Sekonnen (oder Minutten) gemooss ginn
op verschidde Manéieren: betruecht de Minimum,
maximal, Moyenne an, zum Beispill, der 90. percentile.
Minimum a maximal Liesungen sinn extrem
System Leeschtung Status.
Den nonzegsten Prozenttil ass am meeschte benotzt,
wéi et déi meescht vun de Benotzer weist,
bequem op der Schwell vun der Systemleistung funktionnéiert
Transaktiounen pro Sekonn (Minutt) - d'Zuel vun komplett
Transaktiounen pro Sekonn (Minutt),
dat ass, wéi vill der Applikatioun konnt akzeptéieren an
Prozess Ufroen an erausginn Äntwerten.
Tatsächlech ass dëst den Duerchgang vum System
Transaktioun Status , Passéiert / Ausgefall / Ganzen - Zuel
erfollegräich, Mëssgléckt an der Gesamtzuel vun Transaktiounen.
Fir richteg Benotzer Mëssgléckt
der Transaktioun wäert eigentlech mengen
Onméiglechkeet mam System ënner Laascht ze schaffen
Lueden Test Schematesch Diagramm
D'Konzept vum Lasttest ass ganz einfach a besteet aus dräi Haaptstadien, déi ech scho gesot hunn: Preparéieren-Test-Rapport, dat heescht Testziler virbereeden an Parameteren fir Belaaschtungsquellen setzen, dann Laaschtester ausféieren an um Enn en Testbericht generéieren a publizéieren.
Schematesch Notizen:
- QA.Tester ass en Expert am Laaschttest,
- Target ass d'Zilapplikatioun fir déi Dir säi Verhalen ënner Laascht wësse wëllt.
Klassifizéierer vun Entitéiten, Etappen a Schrëtt am Diagramm
Etappen a Schrëtt
Waat leeft
Wat ass an der Entrée
Wat ass d'Ausgab
Preparéieren: Virbereedungsstadium fir Testen
Lueden Parameteren
Astellung an Initialiséierung
Benotzer
Lueden Parameteren,
Choix vun Metriken an
Testplang Virbereedung
(Profil lued)
Benotzerdefinéiert Optiounen fir
charge Agent initialization
Test Plang
Zweck vum Test
VM
Cloud Détachement
virtuell Maschinn mat
néideg Charakteristiken
VM Astellunge fir Luede Agent
Automatisatioun Scripten fir
VM Kreatioun
VM konfiguréiert an
Wollek
Schécken
OS Setup a Virbereedung
Ëmwelt fir
Laascht Agent Aarbecht
Ëmwelt Astellunge fir
Luede Agent
Automatisatioun Scripten fir
Ëmwelt Astellunge
Preparéiert Ëmfeld:
OS, Servicer an Uwendungen,
néideg fir Aarbecht
Luede Agent
LoadAgents
Installatioun, Konfiguratioun an Parameteriséierung
Luede Agent.
Oder download engem Docker Bild vun
virkonfiguréiert Luede Quell
Lued Quell docker Bild
(YAT, JM oder selbstgeschriwwene Kader)
Astellungen
Luede Agent
Ariichten a prett
ze schaffen Laascht Agent
Test: Etapp vun Ausféierung vun Laascht Tester. Quelle si Laaschtagenten, déi an engagéierten Agentpools fir GitLab CI ofgesat ginn
Lueden
De Load Agent starten
mat ausgewielten Testplang
a Luede Parameteren
Benotzer Optiounen
fir Initialiséierung
Luede Agent
Test Plang
Zweck vum Test
Ausféierung Logbicher
Laascht Tester
System Logbicher
Dynamik vun Ännerungen an Zil Metriken a Last Agent
Run Agenten
Agent Ausféierung
vill Test Scripten
am Aklang mat
lued Profil
Luet Agent Interaktioun
fir den Zweck vum Test
Test Plang
Zweck vum Test
Logbicher
Sammlung vun "raw" Logbicher
während Laascht Testen:
Last Agent Aktivitéit records,
Zoustand vum Testziel
an de VM deen den Agent leeft
Ausféierung Logbicher
Laascht Tester
System Logbicher
Metric
Sammelen "raw" Metriken beim Testen
Dynamik vun Ännerungen an Zil Metriken
an Luede Agent
Rapport: Test Rapport Virbereedung Etapp
Generator
Veraarbechtung gesammelt
Luede System an
Iwwerwaachungssystem "raw"
Metriken a Logbicher
Formatioun vun engem Rapport am
Mënsch liesbar Form
méiglech mat Elementer
Analysten
Ausféierung Logbicher
Laascht Tester
System Logbicher
Dynamik vun Ännerungen an Metriken
Zil- a Last Agent
Veraarbechtte "raw" Logbicher
an engem Format gëeegent fir
Eroplueden op extern Späichere
Statesch Belaaschtungsbericht,
Mënsch liesbar
publizéieren
Verëffentlechung vum Rapport
iwwer Laascht
Testen an externen
Déngscht
Veraarbechtt "raw"
Logbicher an engem passenden Format
fir Ausluede fir extern
gewellten
Gespäichert an externen
Stockage Rapporten op
lueden, gëeegent
fir mënschlech Analyse
Luede Quellen an enger CI Schabloun verbannen
Loosst eis op de prakteschen Deel goen. Ech wëll weisen wéi op e puer Projeten an der Firma mir hunn d'Konzept vum Lasttest als Service ëmgesat.
Als éischt, mat der Hëllef vun eisen DevOps Ingenieuren, hu mir en dedizéierten Pool vun Agenten am GitLab CI erstallt fir Laaschtester auszeféieren. Fir se net an Templates mat aneren ze verwiesselen, sou wéi Versammlungspools, hu mir Tags un dës Agenten bäigefüügt, : lued. Dir kënnt all aner verständlech Tags benotzen. Si froen GitLab CI Runners.
Wéi fannt Dir déi néideg Kraaft duerch Hardware? D'Charakteristike vu Lastagenten - eng genuch Zuel vu vCPU, RAM an Disk - kënne berechent ginn op Basis vun der Tatsaach datt Docker, Python (fir Yandex.Tank), GitLab CI Agent, Java (fir Apache JMeter) um Agent lafen sollen . Fir Java ënner JMeter ass et och recommandéiert e Minimum vu 512 MB RAM ze benotzen an als iewescht Limit, .
Also, baséiert op eiser Erfahrung, recommandéiere mir op d'mannst 4 vCPUs, 4 GB RAM, 60 GB SSD fir Laaschtagenten ze benotzen. Den Duerchgang vun der Netzwierkkaart gëtt op Basis vun den Ufuerderunge vum Lastprofil bestëmmt.
Mir benotzen haaptsächlech zwou Luede Quellen - Apache JMeter an Yandex.Tank Docker Biller.
ass en Open Source Tool vu Yandex fir Laaschttesten. Seng modulär Architektur baséiert op Phantom's High-Performance asynchronen Hit-baséiert HTTP-Ufro Generator. Den Tank huet eng agebaute Iwwerwaachung vun de Ressourcen vum Server ënner Test iwwer de SSH Protokoll, kann den Test automatesch ënner spezifizéierte Konditioune stoppen, kann d'Resultater souwuel an der Konsole wéi och a Form vu Grafike weisen, Dir kënnt Är Moduler verbannen fir d'Funktionalitéit auszebauen. Iwwregens hu mir den Tank benotzt wann en nach net Mainstream war. Am Artikel "» Dir kënnt d'Geschicht liesen wéi mir Laaschttesten domat am Joer 2013 gemaach hunn ass ee vun de Produkter vun eiser Firma.
ass en Open Source Last Test Tool vun Apache. Et kann gläich gutt benotzt ginn fir béid statesch an dynamesch Webapplikatiounen ze testen. JMeter ënnerstëtzt eng grouss Zuel vu Protokoller a Weeër fir mat Uwendungen ze interagéieren: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, etc.), SOAP / REST Webservices, FTP, TCP, LDAP, SMTP(S), POP3( S)) an IMAP(S), Datenbanken iwwer JDBC, kënne Shellbefehle ausféieren a mat Java Objekter schaffen. JMeter huet eng IDE fir Testpläng ze kreéieren, ze Debuggen an auszeféieren. Et gëtt och e CLI fir Kommandozeiloperatioun op all Java-kompatibel Betribssystem (Linux, Windows, Mac OS X). Den Tool kann dynamesch en HTML Testbericht generéieren.
Fir d'Benotzungsfäegkeet bannent eiser Firma, fir d'Fäegkeet vun den Tester selwer d'Ëmfeld z'änneren an ze addéieren, hu mir Baute vun Docker-Biller vu Laaschtquellen op GitLab CI gemaach mat der Verëffentlechung op den internen . Dëst mécht et méi séier a méi einfach fir se a Pipelines fir Laaschtester ze verbannen. Wéi maachen ech Docker Push op Registry iwwer GitLab CI - kuckt .
Mir hunn dës Basis Docker Datei fir Yandex.Tank geholl:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]A fir Apache JMeter dësen:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Dir kënnt liesen wéi eise kontinuéierleche Integratiounssystem funktionnéiert am Artikel "".
Schabloun a Pipeline
E Beispill vun enger Schabloun fir Laaschtester auszeféieren ass am Projet verfügbar . d' Dir kënnt d'Instruktioune liesen fir d'Schabloun ze benotzen. An der Schabloun selwer (Datei ) ginn et Notizen iwwer wat all Schrëtt verantwortlech ass.
D'Schabloun ass ganz einfach a weist déi dräi Etappe vu Lasttesten, déi am Diagramm uewe beschriwwe sinn: virbereeden, testen a verëffentlechen Berichter. Verantwortlech dofir : Preparéieren, Test a Rapport.
- Bühn soll benotzt ginn fir Testziler virzestellen oder hir Disponibilitéit ze kontrolléieren. D'Ëmfeld fir Belaaschtungsquellen brauch net konfiguréiert ze ginn, si sinn als Docker-Biller virgebaut an am Docker-Registry gepost: gitt just déi gewënschte Versioun an der Teststadium. Awer Dir kënnt se nei opbauen an Är eege modifizéiert Biller maachen.
- Bühn benotzt fir d'Laaschtquell ze spezifizéieren, Tester auszeféieren an Testartefakte ze späicheren. Dir kënnt all Belaaschtungsquell wielen: Yandex.Tank, Apache JMeter, Ären eegenen oder all zesummen. Fir onnéideg Quellen auszeschalten, einfach kommentéieren oder d'Aarbecht läschen. Entrée Punkten fir Luede Quellen:
- Startparameter fir Yandex.Tank ginn an der .,
- Apache JMeter Startupparameter ginn an der Datei spezifizéiert .
Notiz: D'Versammlungskonfiguratiounsschabloun gëtt benotzt fir Interaktioun mam CI System opzestellen an implizéiert net d'Placement vun der Testlogik dran. Fir Tester gëtt den Entréespunkt spezifizéiert, wou de Kontrollbash-Skript läit. D'Method fir Tester ze lafen, Berichter ze generéieren an d'Testskripter selwer musse vu QA Ingenieuren ëmgesat ginn. An der Demo, fir béid Luedequellen, gëtt d'Yandex Haaptsäit Ufro als einfachsten Test benotzt. Scripten an Testparameter sinn am Verzeechnes .
- Op der Bühn Dir musst beschreiwen wéi Dir d'Testresultater, déi an der Teststadium kritt goufen, op extern Späichere verëffentlechen, zum Beispill op GitLab Säiten oder speziell Berichtungssystemer. GitLab Säiten erfuerdert datt den ./public Verzeechnes net eidel ass an op d'mannst eng index.html Datei enthält nodeems d'Tester fäerdeg sinn. Dir kënnt iwwer d'Nuancen vum GitLab Pages Service liesen. .
Beispiller vu wéi Dir Daten exportéiert:
- vum JMeter bis ,
- vun Yandex.Tank zu .
Opstellungsinstruktiounen posten:
- HTML Statik an ,
- op InfluxDB an dann op .
Am Demo Beispill gesäit d'Pipeline mat Laaschtester an zwee Belaaschtungsquellen (Dir kënnt déi onnéideg auszeschalten) esou aus:
Apache JMeter kann en HTML Bericht selwer generéieren, sou datt et méi rentabel ass et op GitLab Säiten ze späicheren mat Standard Tools. Dëst ass wéi den Apache JMeter Bericht ausgesäit:
Am Demo Beispill fir Yandex.Tank, wäert Dir nëmmen gesinn an der Rubrik fir GitLab Säiten. Wärend dem Test kann den Tank d'Resultater an d'InfluxDB-Datebank späicheren, a vun do aus kënnen se zum Beispill an Grafana ugewise ginn (Konfiguratioun gëtt an der Datei gemaach ). Esou gesäit de Rapport vum Tank zu Grafana aus:
Summary
Am Artikel hunn ech iwwer d'Konzept vun "Laaschttesten als Service" geschwat (Laaschttesten als Service). D'Haaptidee ass d'Infrastruktur vu vir-konfiguréierte Poole vu Lastagenten, Docker-Biller vu Lastquellen, Berichterstattungssystemer an eng Pipeline ze benotzen déi se am GitLab CI kombinéiert baséiert op enger einfacher .gitlab-ci.yml Schabloun (Beispill) ). All dëst gëtt vun engem klengen Team vun Automatisatiounsingenieuren ënnerstëtzt a replizéiert op Ufro vun Produktteams. Ech hoffen dat hëlleft Iech bei der Virbereedung an Ëmsetzung vun engem ähnleche Schema an Ärer Firma. Merci fir d'Opmierksamkeet!
PS Ech wëll meng Kollegen, Sergey Kurbanov an Nikolai Yusev, e grousse Merci soen, fir technesch Hëllef mat der Ëmsetzung vum Konzept vum Lasttest als Service an eiser Firma.
Auteur: - Deputéiert Head of Technology and Development Processes (DevOps) bei Positive Technologies
Source: will.com