Slodzes pārbaude kā CI pakalpojums izstrādātājiem

Slodzes pārbaude kā CI pakalpojums izstrādātājiem

Viena no problēmām, ar ko bieži saskaras vairāku produktu programmatÅ«ras pārdevēji, ir inženieru ā€” izstrādātāju, testētāju un infrastruktÅ«ras administratoru ā€” kompetenču dublÄ“Å”anās gandrÄ«z katrā komandā. Tas attiecas arÄ« uz dārgiem inženieriem - speciālistiem slodzes testÄ“Å”anas jomā.

Tā vietā, lai veiktu savus tieÅ”os pienākumus un izmantotu savu unikālo pieredzi, lai izveidotu slodzes testÄ“Å”anas procesu, izvēlētos metodiku, optimālus rādÄ«tājus un rakstÄ«tu automātiskos testus saskaņā ar slodzes profiliem, inženieriem bieži ir jāizvieto testa infrastruktÅ«ra no nulles, jākonfigurē slodzes rÄ«ki un tie jāiegulsta. KI sistēmās, izveido uzraudzÄ«bu un ziņojumu publicÄ“Å”anu.

JÅ«s varat atrast risinājumus dažām organizatoriskām problēmām testÄ“Å”anā, ko mēs izmantojam vietnē Positive Technologies cits raksts. Un Å”ajā es runāŔu par iespēju integrēt slodzes testus kopējā CI cauruļvadā, izmantojot jēdzienu ā€œslodzes pārbaude kā pakalpojumsā€ (slodzes pārbaude kā pakalpojums). JÅ«s uzzināsit, kā un kādus slodzes avotu docker attēlus var izmantot CI konveijerā; kā savienot slodzes avotus ar CI projektu, izmantojot bÅ«vÄ“Å”anas veidni; kā izskatās demonstrācijas konveijera slodzes testu izpildei un rezultātu publicÄ“Å”anai. Raksts var bÅ«t noderÄ«gs programmatÅ«ras testÄ“Å”anas inženieriem un automatizācijas inženieriem CI, kuri domā par savas slodzes sistēmas arhitektÅ«ru.

Koncepcijas būtība

Slodzes testÄ“Å”anas kā pakalpojuma jēdziens ietver spēju integrēt ielādes rÄ«kus Apache JMeter, Yandex.Tank un savus ietvarus patvaļīgā nepārtrauktas integrācijas sistēmā. Demonstrācija bÅ«s paredzēta GitLab CI, taču principi ir kopÄ«gi visām CI sistēmām.

Slodzes pārbaude kā pakalpojums ir centralizēts slodzes testÄ“Å”anas pakalpojums. Slodzes testi tiek palaisti speciālos aÄ£entu pÅ«los, rezultāti tiek automātiski publicēti GitLab Pages, Influx DB un Grafana vai testa atskaites sistēmās (TestRail, ReportPortal utt.). Automatizācija un mērogoÅ”ana tiek Ä«stenota pēc iespējas vienkārŔāk ā€“ pievienojot un parametrizējot GitLab CI projektā ierasto gitlab-ci.yml veidni.

Å Ä«s pieejas priekÅ”rocÄ«ba ir tāda, ka visu CI infrastruktÅ«ru, ielādes aÄ£entus, slodzes avotu doku attēlus, testÄ“Å”anas cauruļvadus un pārskatu publicÄ“Å”anu uztur centralizēta automatizācijas nodaļa (DevOps inženieri), savukārt slodzes testÄ“Å”anas inženieri var koncentrēt savus centienus uz testu izstrādi. un to rezultātu analÄ«ze, nerisinot infrastruktÅ«ras jautājumus.

Apraksta vienkārŔības labad mēs pieņemsim, ka testējamā mērÄ·a lietojumprogramma vai serveris jau ir iepriekÅ” izvietots un konfigurēts (Å”im nolÅ«kam var izmantot automatizētos skriptus programmās Python, SaltStack, Ansible utt.). Tad visa slodzes testÄ“Å”anas kā pakalpojuma koncepcija ietilpst trÄ«s posmos: atskaiÅ”u sagatavoÅ”ana, testÄ“Å”ana, publicÄ“Å”ana. SÄ«kāka informācija par diagrammu (visi attēli ir noklikŔķināmi):

Slodzes pārbaude kā CI pakalpojums izstrādātājiem

Slodzes testÄ“Å”anas pamatjēdzieni un definÄ«cijas

Veicot slodzes testus, mēs cenÅ”amies ievērot ISTQB standarti un metodika, izmantojiet atbilstoÅ”u terminoloÄ£iju un ieteicamos rādÄ«tājus. Es sniegÅ”u Ä«su galveno jēdzienu un definÄ«ciju sarakstu slodzes testÄ“Å”anā.

IekrauŔanas aģents - virtuālā maŔīna, kurā tiks palaists lietojumprogramma - slodzes avots (Apache JMeter, Yandex.Tank vai paŔrakstīts ielādes modulis).

Pārbaudes mērķis (mērķis) - serveris vai serverī instalēta lietojumprogramma, kas tiks ielādēta.

Testa scenārijs (pārbaudes gadÄ«jums) - parametrizētu darbÄ«bu kopums: lietotāja darbÄ«bas un paredzamās reakcijas uz Ŕīm darbÄ«bām ar fiksētiem tÄ«kla pieprasÄ«jumiem un atbildēm atkarÄ«bā no norādÄ«tajiem parametriem.

Profils vai slodzes plāns (profils) - plkst ISTQB metodoloÄ£ija (4.2.4. sadaļa, 43. lpp.) slodzes profili definē metriku, kas ir kritiska konkrētam testam, un iespējas testa laikā mainÄ«t slodzes parametrus. Attēlā varat redzēt profilu piemērus.

Slodzes pārbaude kā CI pakalpojums izstrādātājiem

Pārbaude ā€” skripts ar iepriekÅ” noteiktu parametru kopu.

Pārbaudes plāns (pārbaudes plāns) - testu komplekts un slodzes profils.

Testran (testrun) - viena iterācija viena testa izpildei ar pilnībā izpildītu slodzes scenāriju un saņemto atskaiti.

TÄ«kla pieprasÄ«jums (pieprasÄ«jums) ā€” HTTP pieprasÄ«jums, kas nosÅ«tÄ«ts no aÄ£enta uz mērÄ·i.

TÄ«kla atbilde (atbilde) ā€” HTTP atbilde, kas nosÅ«tÄ«ta no mērÄ·a aÄ£entam.
HTTP atbildes kods (HTTP atbildes statuss) - standarta atbildes kods no lietojumprogrammu servera.
DarÄ«jums ir pilns pieprasÄ«juma-atbildes cikls. DarÄ«jums tiek skaitÄ«ts no pieprasÄ«juma (pieprasÄ«juma) nosÅ«tÄ«Å”anas sākuma lÄ«dz atbildes (atbildes) saņemÅ”anas pabeigÅ”anai.

DarÄ«juma statuss - vai bija iespējams veiksmÄ«gi pabeigt pieprasÄ«juma-atbildes ciklu. Ja Å”ajā ciklā ir kāda kļūda, tad viss darÄ«jums tiek uzskatÄ«ts par neveiksmÄ«gu.

Reakcijas laiks (latents) - laiks no pieprasÄ«juma (pieprasÄ«juma) nosÅ«tÄ«Å”anas beigām lÄ«dz atbildes (atbildes) saņemÅ”anas sākumam.

Ielādēt metriku ā€” noslogotā pakalpojuma un slodzes aÄ£enta raksturlielumi, kas noteikti slodzes pārbaudes procesā.

Pamatmetrika slodzes parametru mērÄ«Å”anai

Daži no metodoloÄ£ijā visbiežāk izmantotajiem un ieteiktajiem ISTQB (36., 52. lpp.) rādÄ«tāji ir parādÄ«ti zemāk esoÅ”ajā tabulā. LÄ«dzÄ«gas metrikas aÄ£entam un mērÄ·im ir norādÄ«tas vienā rindā.

Slodzes aģenta metrika
Mērķa sistēmas vai lietojumprogrammas metrika, kas tiek testēta zem slodzes

Skaits  vCPU un atmiņa RAM,
Disks - slodzes aģenta "dzelzs" raksturlielumi
CPU, Atmiņa, diska lietojums - CPU, atmiņas un diska ielādes dinamika
testÄ“Å”anas procesā. Parasti mēra procentos no
maksimālās pieejamās vērtības

Tīkla caurlaidspēja (uz slodzes aģents) - caurlaidspēja
tīkla interfeiss serverī,
kur ir uzstādīts slodzes aģents.
Parasti mēra baitos sekundē (bps)
Tīkla caurlaidspēja(mērķī) - tīkla interfeisa joslas platums
mērķa serverī. Parasti mēra baitos sekundē (bps)

Virtuālie lietotāji- virtuālo lietotāju skaits,
ievieŔot slodzes scenārijus un
reālu lietotāja darbību atdarināŔana
Virtuālo lietotāju statuss, Nokārtots/Neizdevies/Kopā ā€” sekmÄ«go un
neveiksmīgi virtuālo lietotāju statusi
slodzes scenārijiem, kā arī to kopējo skaitu.

Parasti ir sagaidāms, ka visi lietotāji varēja pabeigt
visi jūsu uzdevumi, kas norādīti slodzes profilā.
Jebkura kļūda nozīmē, ka īsts lietotājs to nevarēs izdarīt
atrisiniet savu problēmu, strādājot ar sistēmu

Pieprasījumi sekundē (minūtē)- tīkla pieprasījumu skaits sekundē (vai minūtē).

Svarīgs ielādes aģenta raksturlielums ir tas, cik pieprasījumu tas var ģenerēt.
Faktiski Ŕī ir virtuālo lietotāju piekļuves lietojumprogrammai imitācija
Atbildes sekundē (minūtē)
- tīkla atbilžu skaits sekundē (vai minūtē).

SvarÄ«ga mērÄ·a pakalpojuma Ä«paŔība: cik daudz
ģenerēt un nosūtīt atbildes uz vaicājumiem ar
iekrauŔanas aģents

HTTP atbildes statussā€” dažādu atbildes kodu skaits
no lietojumprogrammu servera, ko saņēmis ielādes aģents.
Piemēram, 200 OK nozīmē veiksmīgu zvanu,
un 404 - ka resurss netika atrasts

Latentums (reakcijas laiks) - laiks no beigām
pieprasÄ«juma (pieprasÄ«juma) nosÅ«tÄ«Å”ana pirms atbildes (atbildes) saņemÅ”anas uzsākÅ”anas.
Parasti mēra milisekundēs (ms)

DarÄ«juma reakcijas laiksā€” viena pilna darÄ«juma veikÅ”anas laiks,
pieprasījuma-atbildes cikla pabeigŔana.
Šis ir laiks no pieprasījuma (pieprasījuma) nosūtīŔanas sākuma
lÄ«dz atbildes (atbildes) saņemÅ”anas pabeigÅ”anai.

Darījuma laiku var izmērīt sekundēs (vai minūtēs)
vairākos veidos: apsveriet minimumu,
maksimums, vidējais un, piemēram, 90. procentile.
Minimālais un maksimālais rādījums ir ārkārtējs
sistēmas veiktspējas statuss.
Visbiežāk izmantotā ir deviņdesmitā procentile,
kā tas liecina lielākajai daļai lietotāju,
ērti darboties pie sistēmas veiktspējas sliekŔņa

Darījumi sekundē (minūtē) - pabeigto skaits
darījumi sekundē (minūtē),
tas ir, cik daudz pieteikumu varēja pieņemt un
apstrādāt pieprasījumus un izdot atbildes.
Faktiski tā ir sistēmas caurlaidspēja

Darījuma statuss , Nokārtots / Neizdevās / Kopā - skaitlis
veiksmīgi, neveiksmīgi un kopējais darījumu skaits.

Reāliem lietotājiem neveiksmīgi
darījums patiesībā nozīmēs
nespēja strādāt ar sistēmu zem slodzes

Slodzes pārbaudes shematiskā diagramma

Slodzes testÄ“Å”anas koncepcija ir ļoti vienkārÅ”a un sastāv no trim galvenajiem posmiem, kurus es jau minēju: Sagatavot-pārbaudes-ziņojumu, tas ir, testa mērÄ·u sagatavoÅ”ana un parametru iestatÄ«Å”ana slodzes avotiem, pēc tam slodzes testu izpilde un beigās testa atskaites Ä£enerÄ“Å”ana un publicÄ“Å”ana.

Slodzes pārbaude kā CI pakalpojums izstrādātājiem

Shematiskas piezīmes:

  • QA.Tester ir eksperts slodzes testÄ“Å”anā,
  • MērÄ·is ir mērÄ·a lietojumprogramma, kuras darbÄ«bu slodzes laikā vēlaties uzzināt.

Entītiju, posmu un posmu klasifikators diagrammā

Posmi un soļi
Kas notiek
Kas atrodas pie ieejas
Kāda ir izvade

SagatavoÅ”anās: sagatavoÅ”anas posms testÄ“Å”anai

LoadParameters
IestatīŔana un inicializācija
lietotājs
slodzes parametri,
metriku izvēle un
pārbaudes plāna sagatavoŔana
(ielādēt profilu)
Pielāgotas opcijas
ielādes aģenta inicializācija
Pārbaudes plāns
Pārbaudes mērķis

VM
Mākoņa izvietoÅ”ana
virtuālā maŔīna ar
nepiecieŔamās īpaŔības
VM iestatījumi ielādes aģentam
Automatizācijas skripti
VM izveide
VM konfigurēts
mākonis

Sūtīt
OS iestatīŔana un sagatavoŔana
vide priekÅ”
kravas aģenta darbs
Vides iestatījumi priekŔ
kravas aģents
Automatizācijas skripti
vides iestatījumi
Sagatavota vide:
OS, pakalpojumi un lietojumprogrammas,
nepiecieŔams darbam
kravas aģents

LoadAgents
UzstādÄ«Å”ana, konfigurÄ“Å”ana un parametru noteikÅ”ana
iekrauŔanas aģents.
Vai lejupielādējot docker attēlu no
iepriekÅ” konfigurēts slodzes avots
Ielādēt avota doka attēlu
(YAT, JM vai paŔrakstīts ietvars)
Iestatījumi
kravas aģents
Uzstādīts un gatavs
strādāt slodzes aģentu

Tests: slodzes testu izpildes posms. Avoti ir ielādes aģenti, kas izvietoti GitLab CI specializētos aģentu pūlos

Slodze
IekrauŔanas aģenta palaiŔana
ar izvēlēto pārbaudes plānu
un slodzes parametri
Lietotāja opcijas
inicializācijai
kravas aģents
Pārbaudes plāns
Pārbaudes mērķis
Izpildes žurnāli
slodzes testi
Sistēmas žurnāli
Mērķa metrikas un slodzes aģenta izmaiņu dinamika

Palaist aģentus
AÄ£enta izpilde
daudz testa skriptu
saskaņā ar
slodzes profils
Ielādēt aģenta mijiedarbību
testēŔanas nolūkos
Pārbaudes plāns
Pārbaudes mērķis

Baļķi
"Neapstrādātu" baļķu kolekcija
slodzes pārbaudes laikā:
iekrauŔanas aģenta darbības ieraksti,
testa mērķa stāvoklis
un VM, kas vada aģentu

Izpildes žurnāli
slodzes testi
Sistēmas žurnāli

Metrika
"Neapstrādātas" metrikas vākÅ”ana testÄ“Å”anas laikā

Mērķu metrikas izmaiņu dinamika
un kravas aģents

Atskaite: testa ziņojuma sagatavoÅ”anas posms

Ä¢enerators
Apstrāde savākta
iekrauÅ”anas sistēma un
uzraudzības sistēma "neapstrādāta"
metrika un žurnāli
Atskaites noformēŔana in
cilvēkam lasāma forma
iespējams ar elementiem
analītiķi
Izpildes žurnāli
slodzes testi
Sistēmas žurnāli
Metrikas izmaiņu dinamika
mērķa un slodzes aģents
Apstrādāti "neapstrādāti" baļķi
piemērotā formātā
augÅ”upielādes ārējā atmiņā
Statiskās slodzes ziņojums,
cilvēkam lasāms

Publicēt
Ziņojuma publicÄ“Å”ana
par slodzi
ārējā pārbaude
apkalpoŔana
Apstrādāts "neapstrādāts"
žurnālus piemērotā formātā
izkrauŔanai uz āru
krātuves
Saglabāts ārējā
uzglabāŔanas atskaites par
slodze, piemērota
cilvēku analīzei

Slodzes avotu savienoÅ”ana CI veidnē

Pārejam uz praktisko daļu. Es vēlos parādÄ«t, kā daži projekti uzņēmumā PozitÄ«vās tehnoloÄ£ijas esam ieviesuÅ”i slodzes testÄ“Å”anas koncepciju kā pakalpojumu.

Pirmkārt, ar mÅ«su DevOps inženieru palÄ«dzÄ«bu mēs GitLab CI izveidojām Ä«paÅ”u aÄ£entu kopu, lai veiktu slodzes testus. Lai veidnēs tos nesajauktu ar citām veidnēm, piemēram, montāžas pÅ«liem, mēs pievienojām Å”iem aÄ£entiem atzÄ«mes, tagi: slodze. Varat izmantot citus saprotamus tagus. Viņi jautā reÄ£istrācijas laikā GitLab CI skrējēji.

Kā pēc aparatÅ«ras uzzināt nepiecieÅ”amo jaudu? Slodzes aÄ£entu raksturlielumus - pietiekamu vCPU, RAM un diska skaitu - var aprēķināt, pamatojoties uz to, ka aÄ£entā vajadzētu darboties Docker, Python (priekÅ” Yandex.Tank), GitLab CI aÄ£ents, Java (Apache JMeter). . Java, izmantojot JMeter, ir arÄ« ieteicams izmantot vismaz 512 MB RAM un kā augŔējo robežu 80% pieejamās atmiņas.

Tādējādi, pamatojoties uz mūsu pieredzi, mēs iesakām slodzes aģentiem izmantot vismaz 4 vCPU, 4 GB RAM, 60 GB SSD. Tīkla kartes caurlaidspēja tiek noteikta, pamatojoties uz slodzes profila prasībām.

Mēs galvenokārt izmantojam divus ielādes avotus - Apache JMeter un Yandex.Tank docker attēlus.

Yandex.Tank ir Yandex atvērtā koda rÄ«ks slodzes pārbaudei. Tās modulārā arhitektÅ«ra ir balstÄ«ta uz Phantom augstas veiktspējas asinhrono uz trāpÄ«jumu balstÄ«to HTTP pieprasÄ«jumu Ä£eneratoru. Tvertnē ir iebÅ«vēts pārbaudāmā servera resursu monitorings, izmantojot SSH protokolu, var automātiski apturēt testu noteiktos apstākļos, var parādÄ«t rezultātus gan konsolē, gan grafiku veidā, jÅ«s varat savienot savus moduļus lai paplaÅ”inātu funkcionalitāti. Starp citu, mēs izmantojām Tank, kad tas vēl nebija mainstream. Rakstā "Yandex.Tank un slodzes testÄ“Å”anas automatizācijaĀ» varat izlasÄ«t stāstu par to, kā ar to veicām slodzes testÄ“Å”anu 2013. gadā PT lietojumprogrammu ugunsmÅ«ris ir viens no mÅ«su uzņēmuma produktiem.

Apache JMeter ir Apache atvērtā koda slodzes testÄ“Å”anas rÄ«ks. To var vienlÄ«dz labi izmantot gan statisku, gan dinamisku tÄ«mekļa lietojumprogrammu testÄ“Å”anai. JMeter atbalsta milzÄ«gu skaitu protokolu un veidu, kā mijiedarboties ar lietojumprogrammām: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET utt.), SOAP / REST tÄ«mekļa pakalpojumi, FTP, TCP, LDAP, SMTP(S), POP3( S)) un IMAP(S), datu bāzes, izmantojot JDBC, var izpildÄ«t čaulas komandas un strādāt ar Java objektiem. JMeter ir IDE, lai izveidotu, atkļūdotu un izpildÄ«tu testa plānus. Ir arÄ« CLI komandrindas darbÄ«bai jebkurā ar Java saderÄ«gā operētājsistēmā (Linux, Windows, Mac OS X). Å is rÄ«ks var dinamiski Ä£enerēt HTML testa ziņojumu.

Lai atvieglotu lietoÅ”anu mÅ«su uzņēmumā, lai paÅ”i testētāji varētu mainÄ«t un pievienot vidi, mēs izveidojām GitLab CI ielādes avotu docker attēlu bÅ«ves ar publicÄ“Å”anu iekŔējā doku reÄ£istrs vietnē Artifactory. Tas ļauj ātrāk un vienkārŔāk savienot tos cauruļvados slodzes testiem. Kā veikt docker push uz reÄ£istru, izmantojot GitLab CI - skatiet instrukcijas.

Mēs paņēmām Å”o pamata doka failu Yandex.Tank:

Dockerfile 
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]

Un Apache JMeter Ŕis:

Dockerfile 
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]

Kā darbojas mūsu nepārtrauktās integrācijas sistēma, varat izlasīt rakstā "Izstrādes procesu automatizācija: kā mēs īstenojām DevOps idejas uzņēmumā Positive Technologies'.

Veidne un cauruļvads

Slodzes testu veikÅ”anas veidnes piemērs ir pieejams projektā demonstrācijas slodze. Uz readme fails Varat izlasÄ«t veidnes lietoÅ”anas instrukcijas. PaŔā veidnē (fails .gitlab-ci.yml) ir piezÄ«mes par to, par ko ir atbildÄ«gs katrs solis.

Veidne ir ļoti vienkārÅ”a, un tajā ir parādÄ«ti trÄ«s slodzes testÄ“Å”anas posmi, kas aprakstÄ«ti iepriekÅ” diagrammā: pārskatu sagatavoÅ”ana, testÄ“Å”ana un publicÄ“Å”ana. AtbildÄ«gs par to posmi: Sagatavojiet, pārbaudiet un ziņojiet.

  1. Posms Sagatavot jāizmanto, lai iepriekÅ” konfigurētu testa mērÄ·us vai pārbaudÄ«tu to pieejamÄ«bu. Slodzes avotu vide nav jākonfigurē, tie ir iepriekÅ” izveidoti kā docker attēli un ievietoti docker reÄ£istrā: vienkārÅ”i norādiet vēlamo versiju testa stadijā. Bet jÅ«s varat tos atjaunot un izveidot savus modificētos attēlus.
  2. Posms Pārbaude izmanto, lai norādÄ«tu ielādes avotu, palaistu testus un uzglabātu testa artefaktus. Varat izvēlēties jebkuru ielādes avotu: Yandex.Tank, Apache JMeter, savu vai visus kopā. Lai atspējotu nevajadzÄ«gos avotus, vienkārÅ”i komentējiet vai izdzēsiet darbu. Ieejas punkti slodzes avotiem:

    PiezÄ«me. Montāžas konfigurācijas veidne tiek izmantota, lai iestatÄ«tu mijiedarbÄ«bu ar CI sistēmu, un tā nenozÄ«mē testa loÄ£ikas ievietoÅ”anu tajā. Testiem tiek norādÄ«ts ieejas punkts, kurā atrodas vadÄ«bas bash skripts. Testu izpildes, atskaiÅ”u Ä£enerÄ“Å”anas un paÅ”u testa skriptu metode ir jāievieÅ” kvalitātes nodroÅ”ināŔanas inženieriem. Demonstrācijā abiem ielādes avotiem Yandex galvenās lapas pieprasÄ«jums tiek izmantots kā vienkārŔākais tests. Skripti un testa parametri atrodas direktorijā ./testi.

  3. Pie skatuves ziņojums jāapraksta, kā testa posmā iegÅ«tos testa rezultātus publicēt ārējās krātuvēs, piemēram, GitLab lapās vai Ä«paŔās atskaites sistēmās. GitLab Pages pieprasa, lai ./publiskais direktorijs nebÅ«tu tukÅ”s un pēc testu pabeigÅ”anas tajā ir jābÅ«t vismaz failam index.html. Par GitLab Pages pakalpojuma niansēm varat lasÄ«t. ŠæŠ¾ ссыŠ»ŠŗŠµ.

    Datu eksportÄ“Å”anas piemēri:

    PublicÄ“Å”anas iestatÄ«Å”anas norādÄ«jumi:

Demonstrācijas piemērā cauruļvads ar slodzes testiem un diviem slodzes avotiem (varat atspējot nevajadzÄ«go) izskatās Ŕādi:

Slodzes pārbaude kā CI pakalpojums izstrādātājiem

Apache JMeter pats var Ä£enerēt HTML atskaiti, tāpēc izdevÄ«gāk ir to saglabāt GitLab lapās, izmantojot standarta rÄ«kus. Apache JMeter pārskats izskatās Ŕādi:

Slodzes pārbaude kā CI pakalpojums izstrādātājiem

Yandex.Tank demonstrācijas piemērā jÅ«s redzēsit tikai viltus teksta ziņojums sadaļā GitLab lapas. TestÄ“Å”anas laikā Tank var saglabāt rezultātus InfluxDB datu bāzē, un no turienes tos var parādÄ«t, piemēram, Grafana (konfigurācija tiek veikta failā ./tests/example-yandextank-test.yml). Šādi izskatās Tanka ziņojums Grafana:

Slodzes pārbaude kā CI pakalpojums izstrādātājiem

Kopsavilkums

Rakstā es runāju par jēdzienu "slodzes pārbaude kā pakalpojums" (slodzes pārbaude kā pakalpojums). Galvenā ideja ir izmantot iepriekÅ” konfigurētu ielādes aÄ£entu kopu infrastruktÅ«ru, slodzes avotu docker attēlus, ziņoÅ”anas sistēmas un konveijeru, kas tos apvieno GitLab CI, pamatojoties uz vienkārÅ”u .gitlab-ci.yml veidni (piemērs ŠæŠ¾ ссыŠ»ŠŗŠµ). To visu atbalsta neliela automatizācijas inženieru komanda, un to atkārto pēc produktu komandu pieprasÄ«juma. Es ceru, ka tas palÄ«dzēs jums sagatavot un ieviest lÄ«dzÄ«gu shēmu jÅ«su uzņēmumā. Paldies par uzmanÄ«bu!

PS Gribu pateikt lielu paldies saviem kolēģiem Sergejam Kurbanovam un Nikolajam Jusevam par tehnisko palÄ«dzÄ«bu slodzes testÄ“Å”anas kā pakalpojuma koncepcijas ievieÅ”anā mÅ«su uzņēmumā.

Autors: Timurs Gilmullins - vietnieks Positive Technologies tehnoloģiju un attīstības procesu (DevOps) vadītājs

Avots: www.habr.com

Pievieno komentāru