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 â pothuajse nĂ« çdo ekip. Kjo vlen edhe pĂ«r inxhinierĂ«t e shtrenjtĂ« â specialistĂ«t nĂ« fushĂ«n e testimit tĂ« ngarkesĂ«s.
Në vend që të merren me detyrat e tyre të drejtpërdrejta dhe të përdorin eksperiencën e tyre unike për të ndërtuar procesin e testimit të ngarkesës, për të zgjedhur metodologjinë, vlerat optimale të metrikave dhe për të shkruar teste të automatizuara në përputhje me profilin e ngarkesës, inxhinierët shpesh duhet të krijojnë nga e para infrastrukturën testuese, të konfiguroni mjetet e ngarkesës, t'i integrojnë ato në sistemet CI, të vendosin monitorimin dhe publikimin e raportimeve.
Zgjidhjet për disa probleme organizative në testim, që ne i zbatojmë 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ë konvejerin e përgjithshëm CI duke përdorur konceptin e "testimit të ngarkesës si shërbim". Do të mësoni se cilat figura docker të burimeve të ngarkesës mund të përdoren në konvejerin CI; si të lidhen burimet e ngarkesës në projektin tuaj CI me një shabllon ndërtimi; si duket një pipeline demo për të ekzekutuar testet e ngarkesës dhe për të publikuar rezultatet. Artikulli mund të jetë i dobishëm për inxhinierët e testimit të softuerit dhe inxhinierët automatizues në CI, që po mendojnë për arkitekturën e sistemit të tyre të ngarkesës.
Thelbi i konceptit
Koncepti i testimit të ngarkesës si shërbim supozon mundësinë e integrimit të mjeteve të ngarkesës Apache JMeter, Yandex.Tank dhe kornizave tona të brendshme në çdo sistem të vazhdueshëm integrimi. Shembulli demon do të jetë për GitLab CI, por parimet e paraqitura janë të përgjithshme për të gjithë sistemet CI.
Testimi i ngarkesĂ«s si shĂ«rbim Ă«shtĂ« njĂ« shĂ«rbim qendrorizuar pĂ«r zhvillimin e testeve tĂ« ngarkesĂ«s. Testet e ngarkesĂ«s ekzekutohen nĂ« grupe tĂ« veçanta tĂ« agjentĂ«ve, publikimi i rezultateve ndodh automatikisht nĂ« GitLab Pages, Influx DB dhe Grafana ose nĂ« sistemet e raportimit tĂ« testit (TestRail, ReportPortal, etj.). Automatizimi dhe shkallĂ«zimi realizohen maksimalisht thjesht â pĂ«rmes shtimit dhe parametrizimit nĂ« projektin GitLab CI tĂ« njĂ« shablloni tĂ« zakonshĂ«m gitlab-ci.yml.
Avantazhi i qasjes qĂ«ndron nĂ« faktin 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 ekipi i centralizuar i automatizimit (in XhinierĂ«t DevOps), ndĂ«rsa inxhinierĂ«t e testimit tĂ« ngarkesĂ«s mund tĂ« pĂ«rqendrohen nĂ« zhvillimin e testeve dhe analizimin e rezultateve tĂ« tyre, pa u shqetĂ«suar pĂ«r çështjet infrastrukturore.
Për thjeshtësinë e përshkrimit, le të supozojmë se aplikacioni ose serveri i testuar tashmë është vendosur dhe konfigurimi i tij është bërë paraprakisht (për të mund të përdoren skenarë të automatizuar në Python, SaltStack, Ansible etj.). Kështu, e gjithë koncepti i testimit të ngarkesës si një shërbim përfshin tre faza: përgatitja, testimi, publikimi i raporteve. Më shumë në diagram (të gjitha imazhet janë të klikueshme):
Koncepte dhe definita kryesore në testimin e ngarkesës
Kur bëjmë prova ngarkesash, ne mundohemi të respektojmë , përdorim terminologjinë përkatëse dhe metrikat e rekomanduara. Ja një listë e shkurtër e koncepteve dhe definita kryesore në testimin e ngarkesës.
Agjenti i ngarkesĂ«s (load agent) â njĂ« makinĂ« virtuale, mbi tĂ« cilĂ«n do tĂ« ekzekutohet aplikacioni â burimi i ngarkesĂ«s (Apache JMeter, Yandex.Tank ose moduli i ngarkesĂ«s i shkruar nga vetĂ«).
QĂ«llimi i testimit (target) â serveri ose aplikacioni, i instaluar nĂ« server, i cili do tĂ« nĂ«nshtruar ngarkesĂ«s.
Skenari i testit (test case) â njĂ« grup hapash tĂ« parametrizuar: veprime tĂ« pĂ«rdoruesve dhe reagimet e pritura ndaj kĂ«tyre veprimeve, me kĂ«rkesat dhe pĂ«rgjigjet e ngurtĂ«suara nĂ« rrjet, nĂ« varĂ«si tĂ« parametrave tĂ« caktuar.
Profili ose plani i ngarkesĂ«s (profile) â nĂ« (p. 4.2.4, fq. 43) profili i ngarkesĂ«s pĂ«rcakton metrikat kritike pĂ«r testin specifik dhe variantet e ndryshimit tĂ« parametrave tĂ« ngarkesĂ«s gjatĂ« testit. Shembujt e profileve mund t'i shihni nĂ« figurĂ«.
Testi (test) â njĂ« skenar me njĂ« grup parametresh tĂ« caktuar mĂ« parĂ«.
Plani i testit (test-plan) â njĂ« grup testesh dhe njĂ« profil ngarkese.
Testimi (testrun) â njĂ« iteracion i njĂ« testi tĂ« vetĂ«m me njĂ« skenar tĂ« ngarkesĂ«s tĂ« plotĂ« dhe raporte tĂ« marrĂ«.
KĂ«rkesa nĂ« rrjet (request) â kĂ«rkesa HTTP, e dĂ«rguar nga agjenti nĂ« qĂ«llim.
PĂ«rgjigja nĂ« rrjet (response) â HTTP pĂ«rgjigja 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 fillon me dĂ«rgimin e kĂ«rkesĂ«s (request) dhe pĂ«rfundon me marrjen e pĂ«rgjigjes (response).
Statusi i transaksionit (transactions status) â nĂ«se cikli 'kĂ«rkesĂ« â pĂ«rgjigje' Ă«shtĂ« pĂ«rfunduar me sukses. NĂ«se kishte ndonjĂ« gabim nĂ« kĂ«tĂ« cikĂ«l, i gjithĂ« transaksioni konsiderohet si i dĂ«shtuar.
Koha e pĂ«rgjigjes (latency) â koha nga pĂ«rfundimi i dĂ«rgimit tĂ« kĂ«rkesĂ«s (request) deri nĂ« fillimin e marrjes sĂ« pĂ«rgjigjes (response).
Metrikat e ngarkesĂ«s (metrics) â karakteristikat e shĂ«rbimit tĂ« ngarkuar dhe agjentit tĂ« ngarkesĂ«s tĂ« pĂ«rcaktuara gjatĂ« testimit tĂ« ngarkesĂ«s.
Metrikat kryesore për matjen e parametrave të ngarkesës
Disa nga metrikat më të zakonshme dhe të rekomanduara në metodologji (fq. 36, 52) metrike janë listuar në tabelën më poshtë. Metrikat e ngjashme për agjentin dhe objektin janë treguar në një rresht.
Metrikat për agjentin e ngarkesës
Metrikat e sistemit ose aplikacionit të targetuar, të testuara nën ngarkesë
Numri  vCPU dhe memories RAM,
Disk â karakteristikat 'harduer' tĂ« agjentit tĂ« ngarkesĂ«s
CPU, PĂ«rkujtimi, PĂ«rdorimi i Diskut â dinamika e ngarkesĂ«s sĂ« procesorit, memories dhe diskut
gjatë testimit. Zakonisht matet në përqindje të
vlerave maksimale të disponueshme
Kapaciteti i rrjetit (nĂ« agjentin e ngarkesĂ«s) â kapaciteti i
ndërfaqes rrjetësore në serverin
ku është instaluar agjenti i ngarkesës.
Zakonisht matet në bytes për sekondë (bps)
Kapaciteti i rrjetit(nĂ« objekt) â kapaciteti i ndĂ«rfaqes rrjetĂ«sore
në serverin e targetuar. Zakonisht matet në bytes për sekondë (bps)
PĂ«rdoruesit virtualĂ«â numri i pĂ«rdoruesve virtualĂ«,
të cilët realizojnë skenarët e ngarkesës dhe
imitohen veprimet reale të përdoruesve
Statusi i pĂ«rdoruesve virtualĂ«, Kaloi/DĂ«shtoi/Total â 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ë jenë në gjendje të kryejnë
të gjitha detyrat e tyre, siç janë specifikuar në profilin e ngarkesës.
Ădo gabim do tĂ« thotĂ« se asnjĂ« pĂ«rdorues real nuk do tĂ« mund
të zgjidhë detyrën e tij kur punon me sistemin
KĂ«rkesat pĂ«r sekondĂ« (minutĂ«)â numri i kĂ«rkesave rrjetĂ«sore nĂ« sekondĂ« (ose minutĂ«).
Një karakteristikë e rëndësishme e agjentit të ngarkesës: sa mund të gjenerojë kërkesa.
Kjo është, në të vërtetë, një imitim i interaksionit me aplikacionin nga përdorues virtualë.
Përgjigjet për sekondë (minutë)
â numri i pĂ«rgjigjeve rrjetore nĂ« sekondĂ« (ose nĂ« minutĂ«).
Një karakteristikë e rëndësishme e shërbimit të synuar: sa është arritur
të gjenerohen dhe dërgohen përgjigje ndaj kërkesave nga
agjenti i ngarkesës.
Statusi i pĂ«rgjigjeve HTTPâ numri i kodĂ«ve tĂ« ndryshĂ«m tĂ« pĂ«rgjigjes
nga serveri i aplikacionit, të marrë nga agjenti i ngarkesës.
Për shembull, 200 OK do të thotë një kërkesë të suksesshme,
ndërsa 404 nënkupton se burimi nuk u gjet.
Latenca (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).
Në përgjithësi 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: llogaritet minimalja,
maksimalja, mesatarja dhe, për shembull, percentili 90.
Shifrat minimale dhe maksimale përfaqësojnë skajet
e performancës së sistemit.
Percentili i nëntëdhjetë përdoret më shpesh,
sepse tregon shumicën e përdoruesve,
që punojnë komfortshëm në pragun e performancës së sistemit.
Transaksionet pĂ«r sekondĂ« (minutĂ«) â numri i transaksioneve tĂ« plota
në sekondë (minutë),
domethënë sa kërkesa aplikacioni mundi të pranojë dhe
të përpunojë dhe të japë përgjigje.
Kjo është, në fakt, kapaciteti i sistemit.
Statusi i transaksioneve , Kaloi / DĂ«shtoi / Totali â numri
i transaksioneve të suksesshme, të dështuar dhe të përgjithshme.
Për përdoruesit real, një transaksion i dështuar
do të thotë realisht
pamundësia për të punuar me sistemin nën ngarkesë.
Skema themelore e testimit të ngarkesës
Skema themelore e 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 â Test â Raport, domethĂ«nĂ« pĂ«rgatitja e qĂ«llimeve tĂ« testimit dhe caktimi i 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 rreth skemës:
- QA.Tester â ekspert nĂ« testimin e ngarkesĂ«s,
- Target â aplikacioni i synuar, pĂ«r tĂ« cilin duhet tĂ« kuptohet sjellja e tij nĂ«n ngarkesĂ«.
Klassifikatori i entiteteve, etapave dhe hapave në skemë
Etapat dhe hapat
ĂfarĂ« po ndodh
ĂfarĂ« ka nĂ« hyrje
ĂfarĂ« ka nĂ« dalje
Prepare: faza e përgatitjes për testimin
LoadParameters
Caktimi dhe inicializimi
nga përdoruesi
parametrat e ngarkesës,
zgjedhja e metrikave dhe
përgatitja e planit të testit
(profili i ngarkesës)
Parametrat e personalizuar për
inicializimin e agentit të ngarkesës
Plani i testit
QĂ«llimi i testimit
VM
Zhvillimi në cloud
të makinës virtuale me
karakteristikat e kërkuara
Parametrat e VM për agentin e ngarkesës
Skenarët e automatizimit për
krijimin e VM
VM e konfiguruar në
cloud
Env
Konfigurimi i OS dhe përgatitja
e ambientit për
punën e agentit të ngarkesës
Parametrat e ambientit për
agjentin e ngarkesës
Skenarët e automatizimit për
konfigurimet e ambientit
Ambient i përgatitur:
OS, shërbimet dhe aplikacionet,
të nevojshme për funksionimin
agjentin e ngarkesës
LoadAgents
Instalimi, konfigurimi dhe parametrizimi
i agentit të ngarkesës.
Ose shkarkimi i imazhit docker me
burimin e ngarkesës të parakonfiguruar
Imazhi docker i burimit të ngarkesës
(YT, JM ose një framework të shkruar vetë)
Parametrat e konfigurimit
agjentin e ngarkesës
Agjenti i ngarkesës i konfiguruar dhe i gatshëm
për punë
Test: faza e ekzekutimit të testeve të ngarkesës. Burimet janë agjentët e ngarkesës, të zhvilluar në grupe të dedikuara të agjentëve për GitLab CI
Ngarko
Nisja e agjentit të ngarkesës
me planin e testit të përzgjedhur
dhe parametrat e ngarkesës
Parametrat e personalizuar
për inicializimin
agjentin e ngarkesës
Plani i testit
QĂ«llimi i testimit
Diengjërit e ekzekutimit
të testeve të ngarkesës
Gazetat sistemore
Dinamika e ndryshimit të metrikave të qëllimit dhe agjentit të ngarkesës
RunAgents
Ekzekutimi nga agjenti
i ngarkesës i skenarëve të testeve
përputhshëm me
profilin e ngarkesës
Ndërveprimi i agjentit të ngarkesës
me qëllimin e testimit
Plani i testit
QĂ«llimi i testimit
Logs
Grumbullimi i âlogĂ«veâ tĂ« papĂ«rpunuara
në procesin e testimit të ngarkesës:
shënimet mbi veprimet e agjentit të ngarkesës,
gjendja e qëllimit të testimit
dhe VM, në të cilën është nisur agjenti
Diengjërit e ekzekutimit
të testeve të ngarkesës
Gazetat sistemore
Metrics
Grumbullimi i metrikave âtĂ« papĂ«rpunuaraâ gjatĂ« testimit
Dinamika e ndryshimit të metrikave të qëllimit
dhe agjentit të ngarkesës
Raport: faza e përgatitjes së raportit për testimin
Generator
Shpërndarja e të dhënave të mbledhura
nga sistemi i ngarkesës dhe
sistemi mbikĂ«qyrĂ«s âtĂ« papĂ«rpunuaraâ
metrikave dhe logëve
Formimi i raportit në
një format të lexueshëm nga njeriu,
ndoshta me elemente
analizë
Diengjërit e ekzekutimit
të testeve të ngarkesës
Gazetat sistemore
Dinamika e ndryshimit të metrikave
të qëllimit dhe agjentit të ngarkesës
LogĂ«t e pĂ«rpunuara âtĂ« papĂ«rpunuaraâ
në format, të përshtatshëm për
eksportin në magazina të jashtme
Raporti statik mbi ngarkesën,
i përshtatshëm për analizë nga njeriu
Publiko
Publikimi i raportit
për testimin e ngarkesës në
të jashtme
shërbimit
Të procesuar "të papërpunuar"
logjet në formatin e përshtatshëm
për eksport në depo të jashtme
deponi
Raportet e ruajtura në depo të jashtme për
ngarkesën, të përshtatshme
për analizë nga njeriu
K lidhja e burimeve të ngarkesës në template CI
Të kalojmë në pjesën praktike. Dua të tregoj se si në disa projekte në kompaninë
Positive Technologies Fillimisht, me ndihmën e inxhinierëve tanë DevOps, krijuam në GitLab CI një grup të dedikuar të agjentëve për të drejtuar testet e ngarkesës. Që të mos i ngatërrojmë në template me të tjerët, siç janë grupet e ndërtimit, ne shtuam etiketa në këta agjentë,
etiketat në regjistrim Si ta kuptojmë fuqinë e nevojshme për "çelikan"? Karakteristikat e agjentëve të ngarkesës - numri i mjaftueshëm i vCPU, RAM dhe Disk - mund të llogariten duke pasur parasysh se në agjent duhet të jenë të nisura 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 kufi të sipërm,
80% e memories së disponueshme .
Ne zakonisht përdorim dy burime ngarkese - imazhet docker të Apache JMeter dhe Yandex.Tank.
Yandex.Tank
Yandex.Tank dhe automatizimi i testimit të ngarkesësPT Appllication Firewall Apache JMeter
â Ă«shtĂ« njĂ« mjet open-source pĂ«r kryerjen e testimeve tĂ« ngarkesĂ«s, i zhvilluar nga kompania Apache. Ai mund tĂ« pĂ«rdoret po aq mirĂ« pĂ«r testimin e aplikacioneve tĂ« uebit statike ashtu si dhe pĂ«r ato dinamike. JMeter mbĂ«shtet njĂ« numĂ«r tĂ« madh protokollesh dhe mĂ«nyrash ndĂ«rveprimi 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, mund tĂ« ekzekutojĂ« komandat shell dhe tĂ« punojĂ« me objekte Java. JMeter ka njĂ« IDE pĂ«r krijimin, debugimin dhe ekzekutimin e planeve tĂ« testimit. Po ashtu ka njĂ« CLI pĂ«r tĂ« punuar nĂ« linjĂ«n e komandĂ«s nĂ« çdo sistem operativ tĂ« pĂ«rputhshĂ«m me Java (Linux, Windows, Mac OS X). Ky mjet Ă«shtĂ« nĂ« gjendje tĂ« gjenerojĂ« dinamikisht njĂ« raport HTML mbi testimin.
Për lehtësi përdorimi brenda kompanisë sonë, për t'iu dhënë mundësi testuesve të ndryshojnë dhe shtojnë ambientin, ne kemi bërë ndërtimet e imazheve Docker për burimet e ngarkesës në GitLab CI me publikim në . Kështu bëhet më shpejt dhe më lehtë për t'i lidhur në pipeline për testet e ngarkesës. Si të bëni docker push në regjistrin përmes GitLab CI - shihni në .
Dockerfile bazë për Yandex.Tank ne e morëm këtë:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]Dhe për Apache JMeter këtë:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Si funksionon sistemi ynë i integrimit të vazhdueshëm, mund të lexoni në artikullin "».
Shabllon dhe pipeline
Një shembull shablloni për kryerjen e testeve të ngarkesës është i disponueshëm në projektin . Në mund të lexoni udhëzimet për përdorimin e shabllonit. Në vetë shabllonin (skedari ) ka vërejtje mbi atë që përfaqëson çdo hap.
Shablloni është shumë i thjeshtë dhe demonstrojnë tre faza të testimit të ngarkesës, të përshkruara më lart në diagram: përgatitja, testimi dhe publikimi i raporteve. Këto përfaqësohen nga : Prepare, Test dhe Report.
- Faza duhet të përdoret për konfigurimin paraprak të objektivave të testimit ose për të kontrolluar disponueshmërinë e tyre. Ambienti për burimet e ngarkesës nuk ka nevojë të konfigurohet, ato janë më parë ndërtuar si imazhe Docker dhe janë ngarkuar në regjistrinë docker: mjafton të specifikoni versionin e nevojshëm në fazën Test. Por mund të rindezësh ato dhe të bësh imazhe të modifikuara të tua.
- Faza përdoret për të treguar burimin e ngarkesës, për të filluar testet dhe për të ruajtur artefaktet e testimit. Mund të zgjidhet çdo burim ngarkese: Yandex.Tank, Apache JMeter, i tuaj ose të gjitha së bashku. Për të çaktivizuar burimet e panevojshme, mjafton të komenton ose të fshin punën. Pikat e hyrjes për burimet e ngarkesës:
- parameteret e nisjes Yandex.Tank përcaktohen në skedarin.,
- parameteret e nisjes Apache JMeter përcaktohen në skedarin .
Shënim: modelimi i konfigurimit të ndërtimit përdoret për të rregulluar ndërveprimin me sistemin CI dhe nuk supozon të vendosë logjikën e testeve. Për testet, përcaktohet pika e hyrjes ku ndodhet skripti menaxhues bash. Mënyra se si kruhen testet, formimi i raporteve dhe vetë skenarët e testimit - duhet të realizohen nga inxhinierët QA. Në shembullin e demonstrimit për të dy burimet e ngarkesës, si një test më të thjesht e përdorin kërkesën për faqen kryesore të Yandex. Skenarët dhe parametrat e testeve ndodhen në katalogun .
- Në fazën duhet të përshkruajë mënyrat e publikimit të rezultateve të testimit, 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 papërmbushur dhe të përmbajë të paktën skedarin index.html. Për detajet e funksionimit të shërbimit 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-statika në ,
- në InfluxDB dhe më pas në .
Në shembullin e demonstrimit, pipeline me testet e ngarkesës dhe dy burime ngarkese (mund të çaktivizoni të panevojshmin) duket kështu:
Apache JMeter e ka mundësinë për të formuar vetë raportin HTML, prandaj është më e leverdishme që të ruhen në GitLab Pages me mjetet standarde. Ja si duket raporti i Apache JMeter:
Në shembullin e demonstrimit 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 nga aty ato mund të shfaqen, për shembull, në Grafana (konfigurimi bëhet në skedarin ). Ja si duket raporti i Tankës në Grafana:
CV
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 është përdorimi i infrastrukturës së grupeve të parakonfiguruara të agjentëve të ngarkesës, imazheve Docker të burimeve të ngarkesës, sistemeve të raportimit dhe një pipeline të bashkuar në GitLab CI mbi një template të thjeshtë .gitlab-ci.yml (shembull ). E gjithë kjo mbështetet nga një ekip i vogël inxhinierësh-automatizuesish dhe mund të riprodhohet sipas kërkesës së ekipeve produktore. Shpresoj se kjo do t'ju ndihmojë në përgatitjen dhe realizimin e një skeme të ngjashme në kompaninë tuaj. Faleminderit për vëmendjen!
P. S. Dua t'u them falënderime të mëdha kolegëve të mi, Sergey Kurbanov dhe Nikolay Yusev, për ndihmën teknike në realizimin e konceptit të testimit të ngarkesës si shërbim në kompaninë tonë.
Autori: â zĂ«vendĂ«sdrejtor i departamentit tĂ« teknologjive dhe proceseve tĂ« zhvillimit (DevOps) nĂ« Positive Technologies
Burimi: habr.com
