Një nga problemet me të cilat shpesh përballen ofruesit e softuerëve me shumë produkte është dyfishimi i kompetencave të inxhinierëve — zhvilluesve, testuesve dhe administratorëve të infrastrukturës — në praktikat e bëra. Kjo ndikon edhe në inxhinierët e shtrenjtë — specialistët në fushën e testimit të ngarkesave.
Në vend që të merret me detyrat e tyre kryesore dhe të përdorin eksperiencën e tyre unike për të ndërtuar procesin e testimit të ngarkesave, për të zgjedhur metodologjinë, vlerat optimale të matjeve dhe për të shkruar teste automatike përkatëse me profilin e ngarkesës, inxhinierët shpesh janë të detyruar të krijojnë nga e para infrastrukturën e testit, të konfigurojnë mjetet e ngarkesës, t'i integrojnë ato në sistemet CI, të vendosin monitorimin dhe publikimin e raporteve.
Zgjidhjet e disa problemeve organizative në testim, të cilat ne aplikojmë në Positive Technologies, mund t’i gjeni në . Në këtë artikull do të flas për mundësinë e integrimit të testeve të ngarkesës në të gjithë CI-pipeline me ndihmën e konceptit "testimi i ngarkesës si shërbim". Do të mësoni se si dhe cilat imazhe Docker të burimeve të ngarkesës mund të përdoren në CI-pipeline; si të lidhni burimet e ngarkesës në projektin tuaj CI me ndihmën e një shablloni ndërtimi; si duket një demo pipeline për ekzekutimin e testeve të ngarkesës dhe publikimin e rezultateve. Artikulli mund të jetë i dobishëm për inxhinierët e testeve të softuerit dhe inxhinierët e automatizimit në CI, të cilët kanë menduar për arkitekturën e sistemit të tyre të ngarkesës.
Thelbi i konceptit
Koncepti i testimit të ngarkesës si shërbim nënkupton mundësinë për të integruar mjetet e ngarkesës Apache JMeter, Yandex.Tank dhe kornizat tona të vetme në çdo sistem kontinues integrimi. Shembulli i demonstrohet për GitLab CI, por parimet e paraqitura janë të përgjithshme për të gjitha sistemet CI.
Testimi i ngarkesës si shërbim — është një shërbim i centralizuar për zhvillimin e testimeve të ngarkesës. Testet e ngarkesës ekzekutohen në grupe të dedikuara agjentësh, publikimi i rezultateve ndodh automatikisht në GitLab Pages, Influx DB dhe Grafana ose në sistemet e raportimit të testimeve (TestRail, ReportPortal etj.). Automatizimi dhe shkallëzimi realizohet sa më thjeshtë — duke shtuar dhe parametrizuar brenda projektit GitLab CI një model standard gitlab-ci.yml.
Avantazhi i këtij qasje është se e gjithë infrastruktura CI, agjentët e ngarkesës, imazhet Docker të burimeve të ngarkesës, pipeline-t e testimit dhe publikimi i raporteve — mbahen nga një departament i centralizuar të automatizimit ( inxhinierë DevOps), ndërsa inxhinierët e testimit të ngarkesës mund të përqendrojnë përpjekjet e tyre në zhvillimin e testeve dhe analizimin e rezultateve të tyre, pa u shqetësuar për çështjet infrastrukturore.
Për thjeshtësi në përshkrim, le të supozojmë që aplikacioni ose serveri i testuar është tashmë i instaluar dhe i konfiguruar paraprakisht (për këtë mund të përdoren skenarët automatizuar në Python, SaltStack, Ansible etj.). Kështu, e gjithë koncepti i testimit të ngarkesës si shërbim përmbushet në tre faza: përgatitja, testimi, publikimi i raporteve. Më shumë detaje në diagram (të gjitha imazhet janë klikueshme):
Koncepte dhe definita kryesore në testimin e ngarkesës
Gjatë zhvillimit të provave të ngarkesës, ne përpiqemi të respektojmë , përdorim terminologjinë dhe metrikat e rekomanduara. Do t'ju paraqes një përmbledhje të shkurtër të koncepteve dhe definicioneve kryesore në testimin e ngarkesës.
Agjenti i ngarkesës (load agent) — një makinë virtuale, në të cilën do të ekzekutohet aplikacioni — burimi i ngarkesës (Apache JMeter, Yandex.Tank ose një modul të ngarkesës të shkruar nga vetë).
Qëllimi i testimit (target) — serveri ose aplikacioni, i instaluar në server, që do të përballet me ngarkesë.
Skenari i testit (test case) — një grup parametrizuar hapash: veprimet e përdoruesve dhe reagimet e pritura ndaj këtyre veprimeve, me kërkesa dhe përgjigje të fiksuara të rrjetit, në varësi të parametrave të caktuar.
Profili ose plani i ngarkesës (profile) — në (p. 4.2.4, fq. 43) profilat e ngarkesës përcaktojnë metrikat kritikë për testin specifik dhe variantet e ndryshimit të parametrave të ngarkesës gjatë testit. Shembujt e profilave mund t'i shihni në figurë.
Testi (test) — një skenar me një grup të përcaktuar paraprakisht të parametrave.
Plani i testit (test-plan) — një grup testesh dhe një profil ngarkese.
Testimi (testrun) — një iteracion i ekzekutimit të një testi me skenarin e ngarkesës të plotë dhe raportin e marrë.
Kërkesa rrjeti (request) — një kërkesë HTTP, e dërguar nga agjenti te objekti.
Përgjigjja rrjeti (response) — një përgjigje HTTP, e dërguar nga objekti te agjenti.
Kodi i përgjigjes HTTP (HTTP responses status) — kodi standard i përgjigjes nga serveri i aplikacioneve.
Transaksioni (transaction) — cikli i plotë "kërkesë — përgjigje". Transaksioni konsiderohet nga fillimi i dërgimit të kërkesës (request) deri në përfundimin e marrjes së përgjigjes (response).
Statusi i transaksionit (transactions status) — a u arritur me sukses përfundimi i ciklit «kërkesë – përgjigje». Nëse në këtë cikël është ndodhur ndonjë gabim, atëherë të gjitha transaksionet konsiderohen të dështuar.
Kohë përgjigjeje (latency) — koha nga përfundimi i dërgimit të kërkesës (request) deri në fillimin e marrjes së përgjigjes (response).
Metrit e ngarkesës (metrics) — karakteristikat që përcaktohen gjatë testimit të ngarkesës për shërbimin në ngarkesë dhe agjentin e ngarkesës.
Metrit kryesore për matjen e parametrave të ngarkesës
Disa nga metrit më të zakonshme dhe të rekomanduara në metodologji (f. 36, 52) metrit janë paraqitur në tabelën më poshtë. Metrit e ngjashme për agjentin dhe objektin janë shënuar në një rresht.
Metrit për agjentin e ngarkesës
Metrit e sistemit ose aplikacionit të synuar, të testuar nën ngarkesë
Numri vCPU dhe memorjes RAM,
Disk — karakteristikat 'harduerike' të agjentit të ngarkesës
CPU, Përdorimi i memories, Disku — dinamika e ngarkesës së procesorit, memories dhe diskut
gjatë procesit të testimit. Zakonisht matet në përqindje nga
vlerat maksimale të disponueshme.
Kapaciteti i rrjetit (në agjentin e ngarkesës) — kapaciteti i rrjetit
në ndërfaqen e rrjetit në serverin,
ku është instaluar agjenti i ngarkesës.
Zakonisht matet në byte për sekondë (bps)
Kapaciteti i rrjetit(në objektiv) — kapaciteti i ndërfaqes rrjetore
në serverin e synuar. Zakonisht matet në byte për sekondë (bps)
Përdorues virtualë— numri i përdoruesve virtualë,
që realizojnë skenarë ngarkese dhe
imiton veprime reale të përdoruesve
Statusi i përdoruesve virtualë, Kaloi/Dështoi/Totali — numri i statusëve të suksesshëm dhe
të dështuar të punës së përdoruesve virtualë
për skenarët e ngarkesës, si dhe numri i tyre total.
Zakonisht pritet që të gjithë përdoruesit të kenë përfunduar
të gjitha detyrat e tyre të caktuara në profilin e ngarkesës.
Çdo gabim do të thotë se asnjë përdorues real nuk do të jetë në gjendje
të zgjidhë detyrën e tij gjatë punës me sistemin.
Kërkesa për sekondë (minutë)— numri i kërkesave rrjetore për sekondë (ose minutë).
Një karakteristikë e rëndësishme e agentit të ngarkesës: sa kërkesa mund të gjenerojë.
Në thelb, është një simuluar i qasjes në aplikacion nga përdorues virtualë.
Përgjigjet për sekondë (minutë)
— numri i përgjigjeve rrjetore për sekondë (ose minutë).
Një karakteristikë e rëndësishme e shërbimit të synuar: sa arriti
të gjenerojë dhe të dërgojë përgjigje për kërkesat nga
agjenti i ngarkesës.
Statusi i përgjigjeve HTTP— numri i kodeve të ndryshme të përgjigjeve
nga nga serveri aplikacionit, të marra nga agjenti i ngarkesës.
Për shembull, 200 OK do të thotë se kërkesa ishte e suksesshme,
ndërsa 404 do të thotë se burimi nuk u gjet.
Gabimi (koha e përgjigjes) - koha nga përfundimi
i dërgimit të kërkesës (request) deri në fillimin e pranimit të përgjigjes (response).
Zakonisht matet në milisekonda (ms).
Koha e përgjigjes së transaksionit- koha e një transaksioni të plotë,
përfundimi i ciklit "kërkesë - përgjigje".
Kjo është koha nga fillimi i dërgimit të kërkesës (request)
deri në përfundimin e pranimit të përgjigjes (response).
Koha e transaksionit mund të matet në sekonda (ose minuta)
në disa mënyra: llogariten minimale,
maksimale, mesatare dhe, për shembull, percentili i 90-të.
Leximet minimale dhe maksimale janë gjendjet ekstreme
e performancës së sistemit.
Percentili i nëntëdhjetë përdoret më shpesh,
sepse tregon shumicën e përdoruesve,
duke punuar rehat në pragun e performancës së sistemit.
Transaksionet për sekondë (minutë) - numri i plotë
i transaksioneve në sekondë (në minutë),
domethënë sa kërkesa arriti aplikacioni dhe
i përpunoi ato dhe dha përgjigje.
Në fakt, kjo është kapaciteti i sistemit.
Statusi i transaksioneve , Kaloi / Dështoi / Totali - numri
transaksione të suksesshme, të pasuksesshme dhe numri total i transaksioneve.
Për përdoruesit e vërtetë, një transaksion i pasuksesshëm
do të nënkuptonte
pamundësinë për të punuar me sistemin nën ngarkesë
Sh shemën parimore të testimit të ngarkesës
Sh shemën parimore të testimit të ngarkesës është shumë e thjeshtë dhe përbëhet nga tre etapa kryesore, për të cilat kam përmendur tashmë: Përgatit — Testo — Raporto, domethënë përgatitja e objektivave të testimit dhe vendosja e parametrave për burimet e ngarkesës, pastaj kryerja e testeve të ngarkesës dhe, në fund, formimi dhe publikimi i raportit të testimit.
Shënime për skemën:
- QA.Tester — ekspert në testimin e ngarkesës,
- Target — aplikacioni i synuar, për të cilin është e nevojshme të kuptohet sjellja e tij nën ngarkesë.
Klasifikuesi i entiteteve, fazave dhe hapave në skemë
Etapat dhe hapat
Çfarë ndodh
Çfarë është në hyrje
Çfarë është në dalje
Prepare: faza e përgatitjes për testimin
LoadParameters
Vendosja dhe inicializimi
përdoruesit
e parametrave të ngarkesës,
zgjedhja e metrikave dhe
përgatitja e planit të testimit
(profili i ngarkesës)
Parametrat e përdoruesit për
inizializimin e agjentit të ngarkesës
Plani i testimit
Qëllimi i testimit
VM
Shkëputja në cloud
virtual machines with
required characteristics
VM parameters for the load agent
Automation scripts for
creating VMs
Configured VM in
re
Env
OS setup and preparation
environment for
the load agent operation
Environment parameters for
load agent
Automation scripts for
environment settings
Prepared environment:
OS, services, and applications,
necessary for operation
load agent
LoadAgents
Installation, configuration, and parameterization
of the load agent.
Or downloading a Docker image with
a pre-configured load source
Docker image of the load source
(JMeter, JM, or custom framework)
Configuration parameters
load agent
Configured and ready
to operate load agent
Test: execution stage of load tests. The sources are load agents deployed in dedicated agent pools for GitLab CI
Ngarko
Start the load agent
with the selected test plan
and load parameters
User parameters
for initialization
load agent
Plani i testimit
Qëllimi i testimit
Execution logs
of load tests
System logs
Dynamics of metrics changes of the target and load agent
RunAgents
Execution by the agent
of load test scenarios
përputhje me
load profile
Interaction of the load agent
me qëllim testimi
Plani i testimit
Qëllimi i testimit
Log-et
Grumbullimi i logeve "të papërpunuara"
në procesin e testimit të ngarkesës:
regjistrimet e veprimeve të agjentit të ngarkesës,
gjendja e qëllimit të testimit
dhe VM-së, ku është aktivizuar agjenti
Execution logs
of load tests
System logs
Metrika
Grumbullimi i metrikave "të papërpunuara" gjatë testimit
Dinamika e ndryshimeve të metrikave të qëllimit
dhe agjentit të ngarkesës
Report: faza e përgatitjes së raportit të testimit
Generator
Trajtimi i të grumbulluarve
nga sistemi i ngarkesës dhe
sistemi i monitorimit "të papërpunuara"
metrikave dhe logeve
Formimi i raportit në
format të lexueshëm për njeriun,
ndoshta me elemente
analize
Execution logs
of load tests
System logs
Dinamika e ndryshimeve të metrikave
të qëllimit dhe agjentit të ngarkesës
Loget "të papërpunuara" të përpunuara
në një format të përshtatshëm për
eksportim në depo të jashtme
Raporti statik për ngarkesën,
i përshtatshëm për analizë nga njeriu
Publiko
Publikimi i raportit
për testimin e ngarkesës në shërbimin e jashtëm
Loget e përpunuara "të papërpunuara"
në një format të përshtatshëm
për eksportim në depo të jashtme
Raportet e ruajtura në depo të jashtme
për ngarkesën, të përshtatshme
për analizë nga njeriu
Lidhja e burimeve të ngarkesës në modelin CI
Të kalojmë në pjesën praktike. Dëshiroj të tregoj se si në disa projekte në kompaninë
Positive Technologies
для анализа человеком
Подключение источников нагрузки в CI-шаблоне
Перейдем к практической части. Я хочу показать, как на некоторых проектах в компании ne kemi realizuar konceptin e testimit të ngarkesës si një shërbim.
Fillimisht, me ndihmën e inxhinierëve tanë DevOps, krijuam në GitLab CI një grup të dedikuar agentësh për të ekzekutuar testet e ngarkesës. Për të shmangur ngatërrimin e tyre me grupe të tjera, siç janë ato të ndërtimit, shtuam etiketa në këta agjentë, : ngarkesë. Mund të përdoren çdo etiketa tjetër kuptimplotë. Ato caktohen të GitLab CI Runners.
Si të dini fuqinë e nevojshme të hardware-it? Karakteristikat e agjentëve të ngarkesës — numri i mjaftueshëm i vCPU, RAM dhe Disk — mund të llogariten duke marrë parasysh se në agjent duhet të jenë të ekzekutuar Docker, Python (për Yandex.Tank), agjenti GitLab CI, Java (për Apache JMeter). Për Java nën JMeter, gjithashtu rekomandohet të përdoren të paktën 512 MB RAM dhe, si një kufi i sipërm, .
Kështu, sipas përvojës tonë, ne rekomandojmë përdorimin e të paktën: 4 vCPU, 4 GB RAM, 60 GB SSD për agjentët e ngarkesës. Kapaciteti i kartelës së rrjetit përcaktohet në bazë të kërkesave të profilit të ngarkesës.
Ne kryesisht përdorim dy burime ngarkese — imazhet docker të Apache JMeter dhe Yandex.Tank.
— është një mjet open-source nga kompania Yandex për kryerjen e testimit të ngarkesës. Baza e arkitekturës së saj modulare është një gjenerator HTTP me performancë të lartë që punon në mënyrë asinkrone dhe bazohet në hit. Tanka ka monitorimin e burimeve të serverit të testuar përmes protokollit SSH, mund të ndalojë automatikisht testin në përputhje me kushte të caktuara, dhe ofron rezultatet si në konsolë dhe në formën e grafikëve, dhe është e mundur të lidhen modulet tuaja për të zgjeruar funksionalitetin. Për mendje, ne e kemi përdorur Tanka kur kjo ende nuk ishte një praktikë e zakonshme. Në artikullin "" mund të lexoni historinë se si në vitin 2013 ne realizuam testimin e ngarkesës me ndihmën e tij — një nga produktet e kompanisë sonë.
— është një mjet open-source për kryerjen e testeve të ngarkesës nga Apache. Ai mund të përdoret po aq mirë për testimin e aplikacioneve web statike dhe dinamike. JMeter mbështet një numër të madh protokollesh dhe mënyrash interaksioni me aplikacionet: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET etj.), SOAP / REST Webservices, FTP, TCP, LDAP, SMTP(S), POP3(S) dhe IMAP(S), bazat e të dhënave përmes JDBC, ka aftësi për të ekzekutuar komanda shell dhe për të punuar me objekte Java. JMeter ka një IDE për krijimin, arsyetimin dhe ekzekutimin e planeve të testeve. Gjithashtu ka një CLI për të punuar në komandën e linjës së çdo sistemi operativ të përputhshëm me Java (Linux, Windows, Mac OS X). Mjeti ka aftësinë për të gjeneruar dinamikisht një raport HTML mbi testimin.
Për lehtësinë e përdorimit brenda kompanisë sonë, për të mundësuar që testuesit të ndryshojnë dhe shtojnë vetë ambientet, ne kemi bërë ndërtimet e imazheve docker të burimeve të ngarkesës në GitLab CI me publikimin në . Kështu bëhet më shpejt dhe më lehtë t'i lidhen ato në pipeline për testet e ngarkesës. Si të bëni docker push në regjistrin përmes GitLab CI — shihni në .
Ne morëm këtë skedar bazik docker për Yandex.Tank:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]Por Apache JMeter, kyçni:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Si e funksionon sistemi ynë i integrimit të vazhdueshëm, mund ta lexoni në artikullin "».
Shabloni dhe pipeline
Një shembull shabloni për testimet e ngarkesës është i disponueshëm në projektin . Në mund të lexoni udhëzimet për përdorimin e shablonit. Në vetë shablonin (skedari ) ka shënime për atë që përfaqëson çdo hap.
Shabloni është shumë i thjeshtë dhe demonstron tre faza të testimeve të ngarkesës, të përshkruara më sipër në skemë: përgatitja, testimi dhe publikimi i raporteve. Kjo mbikëqyret nga : Prepare, Test dhe Report.
- Shkalla duhet të përdoret për konfigurimin paraprak të objektivave të testimit ose për të verifikuar disponueshmërinë e tyre. Mjedisi për burimet e ngarkesës nuk ka nevojë të konfigurohet, ato janë mbledhur përpara si imazhe docker dhe janë publikuar në regjistrin docker: mjafton të specifikoni versionin e nevojshëm në fazën e Test. Por mund t'i rindërtoni dhe të krijoni imazhe të modifikuara sipas dëshirës.
- Shkalla përdoret për të treguar burimin e ngarkesës, për të nisur teste dhe për të ruajtur artefaktet e testimit. Mund të zgjidhet çdo burim ngarkese: Yandex.Tank, Apache JMeter, i vetëështë ose të gjithë së bashku. Për të fikur burimet e padëshiruara mjafton të komentoni ose fshini job-in. Pikat e hyrjes për burimet e ngarkesës:
- parametrat e nisjes Yandex.Tank caktohen në skedarin.,
- parametrat e nisjes Apache JMeter caktohen në skedarin .
Shënim: modeli i konfigurimit të ndërtimit përdoret për të konfiguruar ndërveprimin me sistemin CI dhe nuk parashikon vendosjen e logjikës së testeve brenda tij. Për testet caktohet një pikë hyrjeje, ku ndodhet skripti i menaxhimit bash. Mënyra e nisjes së testeve, formimi i raporteve dhe vetë skenarët e testeve - duhet të realizohen nga inxhinierët QA. Në shembujt demo për të dy burimet e ngarkesës si një provë të thjeshtë përdoret kërkesa për faqen kryesore të Yandex. Skenarët dhe parametrat e testeve ndodhin në katalogun .
- Në fazën Duhet të përshkruani mënyrat e publikimit të rezultateve të testimeve të marra në fazën Test, në depo të jashtme, për shembull në GitLab Pages ose sisteme të veçanta raportimi. Për GitLab Pages, kërkohet që pas përfundimit të testeve katalogu ./public të jetë i pa bosh dhe të përmbajë të paktën skedarin index.html. Për detajet e punës me shërbimin GitLab Pages, mund të lexoni .
Shembuj, si të eksportoni të dhënat:
- nga JMeter në ,
- nga Yandex.Tank në .
Udhëzime për konfigurimin e publikimit:
- HTML-statike në ,
- InfluxDB dhe më pas në .
Në shembullin demo, pipeline me teste ngarkese dhe dy burime ngarkese (mund të çaktivizoni atë që nuk ju nevojitet) duket kështu:
Apache JMeter di të krijojë automatikisht raportin HTML, prandaj është më e dobishme ta ruani në GitLab Pages me mjete standarde. Kështu duket raporti i Apache JMeter:
Në shembullin demo për Yandex.Tank do të shihni vetëm në seksionin për GitLab Pages. Gjatë testimit, Tanka di të ruajë rezultatet në bazën InfluxDB, dhe aty mund të shfaqen, për shembull, në Grafana (konfigurimi bëhet në skedarin ). Kështu duket raporti i Tankës në Grafana:
Curriculum Vitae
Në këtë artikull, unë kam folur për konceptin e «testimit të ngarkesës si shërbim» (load testing as a service). Ideja kryesore qëndron në përdorimin e infrastrukturës së grupeve të paracaktuar të agenteve të ngarkesës, imazheve docker të burimeve të ngarkesës, sistemeve të raportimit dhe tubacionit që i bashkon ato në GitLab CI bazuar në një model të thjeshtë .gitlab-ci.yml (shembuj. ). Të gjitha këto mbështeten nga forcat e një ekipi të vogël inxhinierësh automatizues dhe janë bërë të disponueshëm me kërkesë për ekipet produktive. Shpresoj se kjo do t'ju ndihmojë në përgatitjen dhe zbatimin e një skeme të ngjashme në kompaninë tuaj. Faleminderit për vëmendjen!
P.S. Dëshiroj të falënderoj shumë kolegët e mi, Sergey Kurbanov dhe Nikolay Yusev, për ndihmën teknike në zbatimin e konceptit të load testing as a service në kompaninë tonë.
Autor: — zëvendës. drejtori i departamentit të teknologjive dhe proceseve të zhvillimit (DevOps) në kompaninë Positive Technologies
Burimi: habr.com
