Një nga problemet me të cilat shpesh përballen shitësit e softuerëve me shumë produkte është dyfishimi i kompetencave të inxhinierëve - zhvilluesve, testuesve dhe administratorëve të infrastrukturës - në pothuajse çdo ekip. Kjo vlen edhe për inxhinierët e shtrenjtë - specialistë në fushën e testimit të ngarkesës.
Në vend që të kryejnë detyrat e tyre të drejtpërdrejta dhe të përdorin përvojën e tyre unike për të ndërtuar një proces testimi të ngarkesës, të zgjedhin një metodologji, metrikë optimale dhe të shkruajnë autoteste në përputhje me profilet e ngarkesës, inxhinierëve shpesh u duhet të vendosin infrastrukturën e testimit nga e para, të konfigurojnë mjetet e ngarkesës dhe t'i ngulitin ato. vetë në sistemet e KI, vendosin monitorimin dhe publikimin e raporteve.
Ju mund të gjeni zgjidhje për disa probleme organizative në testimin që ne përdorim në Positive Technologies in . Dhe në këtë, unë do të flas për mundësinë e integrimit të testeve të ngarkesës në një tubacion të përbashkët CI duke përdorur konceptin e "testimit të ngarkesës si shërbim" (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ë tubacionin CI; si të lidhni burimet e ngarkesës me projektin tuaj CI duke përdorur një shabllon ndërtimi; si duket tubacioni demo për ekzekutimin e testeve të ngarkesës dhe publikimin e rezultateve. Artikulli mund të jetë i dobishëm për inxhinierët e testimit të softuerit dhe inxhinierët e automatizimit në CI të cilët 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 nënkupton aftësinë për të integruar mjetet e ngarkesës Apache JMeter, Yandex.Tank dhe kornizat tuaja në një sistem arbitrar integrimi të vazhdueshëm. Demoja do të jetë për GitLab CI, por parimet janë të përbashkëta për të gjitha sistemet CI.
Testimi i ngarkesës si shërbim është një shërbim i centralizuar për testimin e ngarkesës. Testet e ngarkimit kryhen në grupe të dedikuara agjentësh, rezultatet publikohen automatikisht në GitLab Pages, Influx DB dhe Grafana ose në sistemet e raportimit të testeve (TestRail, ReportPortal, etj.). Automatizimi dhe shkallëzimi zbatohen sa më thjeshtë që të jetë e mundur - duke shtuar dhe parametrizuar shabllonin e zakonshëm gitlab-ci.yml në projektin GitLab CI.
Avantazhi i kësaj qasjeje është se e gjithë infrastruktura CI, agjentët e ngarkesës, imazhet e dokerit të burimeve të ngarkesës, tubacionet e testimit dhe raportet e publikimit mbahen nga një departament i centralizuar automatizimi (inxhinierët DevOps), ndërsa inxhinierët e testimit të ngarkesës mund të përqendrojnë përpjekjet e tyre në zhvillimin e testeve dhe analiza e rezultateve të tyre, pa u marrë me çështjet e infrastrukturës.
Për thjeshtësi të përshkrimit, do të supozojmë se aplikacioni i synuar ose serveri në provë tashmë është vendosur dhe konfiguruar paraprakisht (skriptet e automatizuara në Python, SaltStack, Ansible, etj. mund të përdoren për këtë). Pastaj i gjithë koncepti i testimit të ngarkesës si shërbim përshtatet në tre faza: përgatitja, testimi, publikimi i raporteve. Më shumë detaje mbi diagramin (të gjitha fotot mund të klikohen):
Konceptet dhe përkufizimet bazë në testimin e ngarkesës
Gjatë kryerjes së testeve të ngarkesës, ne përpiqemi t'i përmbahemi , përdorni terminologjinë e duhur dhe metrikat e rekomanduara. Unë do të jap një listë të shkurtër të koncepteve dhe përkufizimeve kryesore në testimin e ngarkesës.
Agjent ngarkues - një makinë virtuale në të cilën do të nisë aplikacioni - burimi i ngarkesës (Apache JMeter, Yandex.Tank ose një modul ngarkese i shkruar vetë).
Qëllimi i testit (objektivi) - serveri ose aplikacioni i instaluar në server që do t'i nënshtrohet ngarkimit.
Skenari i testimit (rasti i provës) - një grup hapash të parametrizuar: veprimet e përdoruesit dhe reagimet e pritshme ndaj këtyre veprimeve, me kërkesat dhe përgjigjet fikse të rrjetit, në varësi të parametrave të specifikuar.
Profili ose plani i ngarkimit (profili) - në (Seksioni 4.2.4, fq. 43) profilet e ngarkesës përcaktojnë metrikat që janë kritike për një test të veçantë dhe opsionet për ndryshimin e parametrave të ngarkesës gjatë testit. Ju mund të shihni shembuj të profileve në figurë.
Test — një skript me një grup të paracaktuar parametrash.
Plani i testimit (plani i testit) - një grup testesh dhe një profil ngarkese.
Testran (testun) - një përsëritje e ekzekutimit të një testi me një skenar ngarkese të ekzekutuar plotësisht dhe raportin e marrë.
Kërkesë për rrjet (kërkesë) — Një kërkesë HTTP e dërguar nga një agjent te një objektiv.
Përgjigja e rrjetit (përgjigje) — Një përgjigje HTTP e dërguar nga objektivi te agjenti.
Kodi i përgjigjes HTTP (statusi i përgjigjeve HTTP) - kodi standard i përgjigjes nga serveri i aplikacionit.
Një transaksion është një cikël i plotë kërkesë-përgjigje. Një transaksion llogaritet nga fillimi i dërgimit të një kërkese (kërkese) deri në përfundimin e marrjes së një përgjigje (përgjigje).
Statusi i transaksionit - nëse ishte e mundur të përfundonte me sukses ciklin kërkesë-përgjigje. Nëse ka pasur ndonjë gabim në këtë cikël, atëherë i gjithë transaksioni konsiderohet i pasuksesshëm.
Koha e përgjigjes (latente) - koha nga përfundimi i dërgimit të një kërkese (kërkese) deri në fillimin e marrjes së një përgjigje (përgjigje).
Metrikat e ngarkesës — karakteristikat e shërbimit të ngarkuar dhe agjenti i ngarkesës të përcaktuara në procesin e testimit të ngarkesës.
Metrikat bazë për matjen e parametrave të ngarkesës
Disa nga më të përdorurat dhe të rekomanduara në metodologji (fq. 36, 52) matjet janë paraqitur në tabelën e mëposhtme. Metrika të ngjashme për agjentin dhe objektivin renditen në të njëjtën linjë.
Metrikë për agjentin e ngarkesës
Metrikat e sistemit ose aplikacionit të synuar që testohen nën ngarkesë
Numër vCPU dhe kujtesa RAM,
Disk - karakteristikat "hekuri" të agjentit të ngarkesës
CPU, Memoria, përdorimi i diskut - dinamika e procesorit, ngarkimit të memories dhe diskut
në procesin e testimit. Zakonisht matet si përqindje e
vlerat maksimale të disponueshme
qarkullimi i rrjetit (në agjentin e ngarkesës) - xhiros
ndërfaqja e rrjetit në server,
ku është instaluar agjenti i ngarkesës.
Zakonisht matet në bajt për sekondë (bps)
qarkullimi i rrjetit(në objektiv) - gjerësia e brezit të ndërfaqes së rrjetit
në serverin e synuar. Zakonisht matet në bajt për sekondë (bps)
Përdoruesit virtualë- numri i përdoruesve virtualë,
zbatimin e skenarëve të ngarkesës dhe
imitimi i veprimeve reale të përdoruesit
Statusi i përdoruesve virtualë, Kaluar/Dështuar/Total — numri i të suksesshëm dhe
statuset e pasuksesshme të përdoruesve virtualë
për skenarët e ngarkesës, si dhe numrin total të tyre.
Në përgjithësi pritet që të gjithë përdoruesit ishin në gjendje të plotësonin
të gjitha detyrat tuaja të specifikuara në profilin e ngarkesës.
Çdo gabim do të thotë që një përdorues i vërtetë nuk do të jetë në gjendje
zgjidhni problemin tuaj kur punoni me sistemin
Kërkesat për sekondë (minutë)- numri i kërkesave të rrjetit për sekondë (ose minutë).
Një karakteristikë e rëndësishme e një agjenti ngarkues është se sa kërkesa mund të gjenerojë.
Në fakt, ky është një imitim i aksesit në aplikacion nga përdoruesit virtualë
Përgjigjet për sekondë (minutë)
- numri i përgjigjeve të rrjetit për sekondë (ose minutë).
Një karakteristikë e rëndësishme e shërbimit të synuar: sa
gjenerojnë dhe dërgojnë përgjigje ndaj pyetjeve me
agjent ngarkues
Statusi i përgjigjes HTTP— numri i kodeve të ndryshme të përgjigjes
nga serveri i aplikacionit i marrë nga agjenti i ngarkesës.
Për shembull, 200 OK do të thotë një telefonatë e suksesshme,
dhe 404 - se burimi nuk u gjet
gjendje latente (koha e përgjigjes) - koha nga fundi
dërgimi i një kërkese (kërkese) përpara se të fillojë të marrë një përgjigje (përgjigje).
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 (kërkesës)
deri në përfundimin e marrjes së përgjigjes (përgjigjes).
Koha e transaksionit mund të matet në sekonda (ose minuta)
në disa mënyra: merrni parasysh minimumin,
maksimale, mesatare dhe, për shembull, përqindja e 90-të.
Leximet minimale dhe maksimale janë ekstreme
statusi i performancës së sistemit.
Përqindja e nëntëdhjetë është më e përdorura,
siç tregon shumica e përdoruesve,
duke funksionuar me lehtësi në pragun e performancës së sistemit
Transaksionet për sekondë (minutë) - numri i plotë
transaksione për sekondë (minutë),
pra sa ka mundur të pranojë aplikacioni dhe
përpunojnë kërkesat dhe nxjerrin përgjigje.
Në fakt, ky është xhiroja e sistemit
Statusi i transaksionit , Kaluar / Dështuar / Total - numër
të suksesshme, të pasuksesshme dhe numrin total të transaksioneve.
Për përdoruesit e vërtetë të pasuksesshme
transaksioni në të vërtetë do të thotë
pamundësia për të punuar me sistemin nën ngarkesë
Diagrami skematik i testimit të ngarkesës
Koncepti i testimit të ngarkesës është shumë i thjeshtë dhe përbëhet nga tre faza kryesore, të cilat i kam përmendur tashmë: Përgatit-Test-Raport, pra përgatitja e qëllimeve të testimit dhe vendosja e parametrave për burimet e ngarkesës, më pas ekzekutimi i testeve të ngarkesës dhe, në fund, gjenerimi dhe publikimi i një raporti testimi.
Shënime skematike:
- QA.Tester është një ekspert në testimin e ngarkesës,
- Target është aplikacioni i synuar për të cilin dëshironi të dini sjelljen e tij nën ngarkesë.
Klasifikuesi i entiteteve, fazave dhe hapave në diagram
Fazat dhe hapat
Cfare po ndodh
Çfarë ka në hyrje
Cili është prodhimi
Përgatitja: faza përgatitore për testim
Parametrat e ngarkimit
Vendosja dhe inicializimi
përdorues
parametrat e ngarkesës,
zgjedhja e metrikës dhe
përgatitja e planit të testit
(ngarko profilin)
Opsionet e personalizuara për
Inicializimi i agjentit të ngarkesës
Plani i testimit
Qëllimi i testimit
VM
Vendosja e resë
makinë virtuale me
karakteristikat e kërkuara
Cilësimet e VM për agjentin e ngarkesës
Skriptet e automatizimit për
Krijimi i VM
VM i konfiguruar në
re
Dërgo
Vendosja dhe përgatitja e OS
mjedis për
puna e agjentit të ngarkesës
Cilësimet e mjedisit për
agjent ngarkese
Skriptet e automatizimit për
cilësimet e mjedisit
Ambienti i përgatitur:
OS, shërbimet dhe aplikacionet,
të nevojshme për punë
agjent ngarkese
LoadAgents
Instalimi, konfigurimi dhe parametrizimi
agjent ngarkues.
Ose shkarkimi i një imazhi doker nga
burimi i ngarkesës i parakonfiguruar
Ngarko imazhin e dokerit të burimit
(YAT, JM ose kornizë e shkruar vetë)
Cilësimet
agjent ngarkese
Vendosur dhe gati
për agjentin e ngarkesës së punës
Testi: faza e ekzekutimit të testeve të ngarkesës. Burimet janë agjentë ngarkesash të vendosura në grupe të dedikuara agjentësh për GitLab CI
Ngarkesë
Nisja e agjentit të ngarkesës
me planin e përzgjedhur të testimit
dhe parametrat e ngarkesës
Opsionet e përdoruesit
për inicializimin
agjent ngarkese
Plani i testimit
Qëllimi i testimit
Regjistrat e ekzekutimit
testet e ngarkesës
Regjistrat e sistemit
Dinamika e ndryshimeve në metrikën e qëllimit dhe agjentin e ngarkesës
Drejtoni Agjentët
Ekzekutimi i agjentit
shumë skripta testimi
në përputhje me
ngarkoni profilin
Ndërveprimi i agjentit të ngarkesës
me qëllim të testimit
Plani i testimit
Qëllimi i testimit
Shkrime
Mbledhja e trungjeve "të papërpunuara".
gjatë testimit të ngarkesës:
ngarkoni të dhënat e aktivitetit të agjentit,
gjendja e objektivit të provës
dhe VM që drejton agjentin
Regjistrat e ekzekutimit
testet e ngarkesës
Regjistrat e sistemit
Certifikatë lindjeje
Mbledhja e metrikave "të papërpunuara" gjatë testimit
Dinamika e ndryshimeve në metrikat e qëllimit
dhe agjent ngarkese
Raporti: faza e përgatitjes së raportit të testit
Gjenerator
Përpunimi i mbledhur
sistemi i ngarkimit dhe
sistemi i monitorimit "i papërpunuar"
metrikë dhe regjistra
Formimi i një raporti në
formë e lexueshme nga njeriu
e mundur me elemente
analistët
Regjistrat e ekzekutimit
testet e ngarkesës
Regjistrat e sistemit
Dinamika e ndryshimeve në metrikë
objektivi dhe agjenti i ngarkesës
Shkrime "të papërpunuara" të përpunuara
në një format të përshtatshëm për
ngarkimet në hapësirën ruajtëse të jashtme
Raporti i ngarkesës statike,
i lexueshëm nga njeriu
Publikoj
Publikimi i raportit
në lidhje me ngarkesën
testimi në të jashtme
shërbim
Të përpunuara "të papërpunuara"
regjistrat në një format të përshtatshëm
për shkarkim në të jashtme
qemeret
Ruajtur në të jashtme
raportet e ruajtjes në
ngarkesë, e përshtatshme
për analiza njerëzore
Lidhja e burimeve të ngarkesës në shabllonin CI
Le të kalojmë në pjesën praktike. Unë dua të tregoj se si në disa projekte në kompani ne kemi zbatuar konceptin e testimit të ngarkesës si shërbim.
Së pari, me ndihmën e inxhinierëve tanë DevOps, ne krijuam një grup të dedikuar agjentësh në GitLab CI për të kryer testet e ngarkesës. Për të mos i ngatërruar ato në shabllone me të tjera, të tilla si pishinat e montimit, ne u shtuam etiketa këtyre agjentëve, : ngarkesë. Mund të përdorni çdo etiketë tjetër të kuptueshme. Ata pyesin GitLab CI Runners.
Si të zbuloni fuqinë e kërkuar nga hardueri? Karakteristikat e agjentëve të ngarkesës - një numër i mjaftueshëm vCPU, RAM dhe Disk - mund të llogariten bazuar në faktin se Docker, Python (për Yandex.Tank), agjenti GitLab CI, Java (për Apache JMeter) duhet të funksionojnë në agjent . Për Java nën JMeter, rekomandohet gjithashtu përdorimi i një minimumi prej 512 MB RAM dhe, si kufi i sipërm, .
Kështu, bazuar në përvojën tonë, ne rekomandojmë përdorimin e të paktën 4 vCPU, 4 GB RAM, 60 GB SSD për agjentët e ngarkesës. Shpejtësia e kartës së rrjetit përcaktohet në bazë të kërkesave të profilit të ngarkesës.
Ne përdorim kryesisht dy burime ngarkimi - imazhet e dokerit të Apache JMeter dhe Yandex.Tank.
është një mjet me burim të hapur nga Yandex për testimin e ngarkesës. Arkitektura e saj modulare bazohet në gjeneratorin e kërkesave HTTP asinkron me performancë të lartë të Phantom-it të bazuar në hit. Rezervuari ka një monitorim të integruar të burimeve të serverit në provë përmes protokollit SSH, mund të ndalojë automatikisht testin në kushte të specifikuara, mund të shfaqë rezultatet si në tastierë ashtu edhe në formën e grafikëve, mund të lidhni modulet tuaja për të zgjeruar funksionalitetin. Nga rruga, ne përdorëm Tank-in kur nuk ishte ende i zakonshëm. Në artikullin "» ju mund të lexoni historinë se si kemi kryer testimin e ngarkesës me të në 2013 është një nga produktet e kompanisë sonë.
është një mjet testimi i ngarkesës me burim të hapur nga Apache. 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 për të bashkëvepruar me aplikacionet: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, etj.), Shërbimet e internetit SOAP / REST, FTP, TCP, LDAP, SMTP(S), POP3( S) ) dhe IMAP(S), bazat e të dhënave nëpërmjet JDBC, mund të ekzekutojnë komanda të guaskës dhe të punojnë me objekte Java. JMeter ka një IDE për krijimin, korrigjimin dhe ekzekutimin e planeve të testimit. Ekziston gjithashtu një CLI për funksionimin e linjës së komandës në çdo sistem operativ të pajtueshëm me Java (Linux, Windows, Mac OS X). Mjeti mund të gjenerojë në mënyrë dinamike një raport testimi HTML.
Për lehtësinë e përdorimit brenda kompanisë sonë, për aftësinë e vetë testuesve për të ndryshuar dhe shtuar mjedisin, ne bëmë ndërtime të imazheve docker të burimeve të ngarkesës në GitLab CI me publikim në të brendshme . Kjo e bën më të shpejtë dhe më të lehtë lidhjen e tyre në tubacione për provat e ngarkesës. Si të bëni shtytje docker në regjistër përmes GitLab CI - shihni .
Ne morëm këtë skedar bazë docker për Yandex.Tank:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]Dhe për Apache JMeter kjo:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Ju mund të lexoni se si funksionon sistemi ynë i integrimit të vazhdueshëm në artikull "'.
Modeli dhe tubacioni
Një shembull i një modeli për kryerjen e testeve të ngarkesës është i disponueshëm në projekt . Në Ju mund të lexoni udhëzimet për përdorimin e shabllonit. Në vetë shabllonin (skedar ) ka shënime se për çfarë është përgjegjës secili hap.
Modeli është shumë i thjeshtë dhe demonstron tre fazat e testimit të ngarkesës të përshkruara në diagramin e mësipërm: përgatitjen, testimin dhe publikimin e raporteve. Përgjegjës për këtë : Përgatitni, testoni dhe raportoni.
- Fazë duhet të përdoret për të konfiguruar paraprakisht objektivat e testimit ose për të kontrolluar disponueshmërinë e tyre. Mjedisi për burimet e ngarkesës nuk ka nevojë të konfigurohet, ato janë ndërtuar paraprakisht si imazhe doker dhe postohen në regjistrin e dokerit: thjesht specifikoni versionin e dëshiruar në fazën e Testit. Por ju mund t'i rindërtoni ato dhe të bëni imazhet tuaja të modifikuara.
- Fazë përdoret për të specifikuar burimin e ngarkesës, ekzekutimin e testeve dhe ruajtjen e objekteve të provës. Ju mund të zgjidhni çdo burim ngarkese: Yandex.Tank, Apache JMeter, tuajin ose të gjithë së bashku. Për të çaktivizuar burimet e panevojshme, thjesht komentoni ose fshini punën. Pikat e hyrjes për burimet e ngarkesës:
- Parametrat e nisjes për Yandex.Tank janë specifikuar në .,
- Parametrat e nisjes së Apache JMeter janë të specifikuara në skedar .
Shënim: Shablloni i konfigurimit të montimit përdoret për të vendosur ndërveprimin me sistemin CI dhe nuk nënkupton vendosjen e logjikës së testimit në të. Për testet, specifikohet pika e hyrjes, ku ndodhet skripti i kontrollit bash. Metoda e ekzekutimit të testeve, gjenerimi i raporteve dhe vetë skriptet e testimit duhet të zbatohen nga inxhinierët e QA. Në demonstrim, për të dy burimet e ngarkesës, kërkesa e faqes kryesore Yandex përdoret si testi më i thjeshtë. Skriptet dhe parametrat e testimit janë në direktori .
- Në skenë ju duhet të përshkruani se si të publikoni rezultatet e testit të marra në fazën e Testit në memoriet e jashtme, për shembull, në Faqet GitLab ose në sisteme të veçanta raportimi. Faqet GitLab kërkon që drejtoria ./public të mos jetë bosh dhe të përmbajë të paktën një skedar index.html pasi të kenë përfunduar testet. Mund të lexoni për nuancat e shërbimit GitLab Pages. .
Shembuj se si të eksportoni të dhëna:
- nga JMeter në ,
- nga Yandex.Tank në .
Udhëzimet e konfigurimit të postimit:
- Statika HTML në ,
- në InfluxDB dhe më pas në .
Në shembullin demonstrues, tubacioni me testet e ngarkesës dhe dy burime ngarkese (mund ta çaktivizoni atë të panevojshëm) duket kështu:
Apache JMeter mund të gjenerojë një raport HTML vetë, kështu që është më fitimprurëse ta ruani atë në GitLab Pages duke përdorur mjete standarde. Kështu duket raporti Apache JMeter:
Në shembullin demonstrues për Yandex.Tank, do të shihni vetëm në seksionin për Faqet GitLab. Gjatë testimit, Tank mund t'i ruajë rezultatet në bazën e të dhënave InfluxDB dhe prej andej ato mund të shfaqen, për shembull, në Grafana (konfigurimi bëhet në skedar ). Ja si duket raporti i Tank në Grafana:
Përmbledhje
Në artikull, unë fola për konceptin e "testimit të ngarkesës si shërbim" (testimi i ngarkesës si shërbim). Ideja kryesore është të përdoret infrastruktura e grupeve të para-konfiguruara të agjentëve të ngarkesës, imazhet e dokerit të burimeve të ngarkesës, sistemet e raportimit dhe një tubacion që i kombinon ato në GitLab CI bazuar në një shabllon të thjeshtë .gitlab-ci.yml (shembull ). E gjithë kjo mbështetet nga një ekip i vogël inxhinierësh automatizimi dhe riprodhohet me kërkesë të ekipeve të produktit. Shpresoj se kjo do t'ju ndihmojë në përgatitjen dhe zbatimin e një skeme të ngjashme në kompaninë tuaj. Faleminderit per vemendjen!
PS Dua të them një falënderim të madh për kolegët e mi, Sergey Kurbanov dhe Nikolai Yusev, për ndihmën teknike me zbatimin e konceptit të testimit të ngarkesës si shërbim në kompaninë tonë.
Autor: - Zv Shef i Teknologjive dhe Proceseve të Zhvillimit (DevOps) në Positive Technologies
Burimi: www.habr.com