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
për analizën nga njeriu
Lidhja e burimeve të ngarkesës në modelin CI
Të kalojmë në pjesën praktike. Dua të tregoj se si në disa projekte në kompaninë 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
