Ko'p mahsulotli dasturiy ta'minot sotuvchilari tez-tez duch keladigan muammolardan biri deyarli har bir jamoada muhandislar - ishlab chiquvchilar, testerlar va infratuzilma ma'murlari vakolatlarining takrorlanishidir. Bu, shuningdek, qimmat muhandislar uchun ham amal qiladi - yuk sinovlari sohasidagi mutaxassislar.
To'g'ridan-to'g'ri vazifalarini bajarish va yukni sinovdan o'tkazish jarayonini yaratish, metodologiyani, optimal o'lchovlarni tanlash va yuk profillariga muvofiq avtotestlarni yozish uchun noyob tajribasidan foydalanish o'rniga, muhandislar ko'pincha sinov infratuzilmasini noldan o'rnatishlari, yuklash vositalarini sozlashlari va ularni o'rnatishlari kerak. o'zlarini CI tizimlarida monitoring qilish va hisobotlarni nashr etishni o'rnatish.
Positive Technologies-da biz foydalanadigan testlarda siz ba'zi tashkiliy muammolarga yechim topishingiz mumkin . Va bu erda men "xizmat sifatida yukni sinovdan o'tkazish" (xizmat sifatida yuk sinovi) tushunchasidan foydalangan holda yuk sinovlarini umumiy CI quvuriga integratsiya qilish imkoniyati haqida gapiraman. CI quvurida yuk manbalarining qanday va qaysi docker tasvirlaridan foydalanish mumkinligini bilib olasiz; qurish shablonidan foydalanib, yuk manbalarini CI loyihangizga qanday ulash mumkin; yuk testlarini o'tkazish va natijalarni nashr qilish uchun demo quvur liniyasi qanday ko'rinishga ega. Maqola o'z yuk tizimining arxitekturasi haqida o'ylayotgan CIda dasturiy ta'minotni sinovdan o'tkazuvchi muhandislar va avtomatlashtirish muhandislari uchun foydali bo'lishi mumkin.
Kontseptsiyaning mohiyati
Xizmat sifatida yukni tekshirish kontseptsiyasi yuklash vositalarini Apache JMeter, Yandex.Tank va o'zingizning ramkalaringizni o'zboshimchalik bilan uzluksiz integratsiya tizimiga birlashtirish qobiliyatini nazarda tutadi. Namoyish GitLab CI uchun bo'ladi, lekin printsiplar barcha CI tizimlari uchun umumiydir.
Xizmat sifatida yukni sinovdan o'tkazish yukni tekshirish uchun markazlashtirilgan xizmatdir. Yuklash testlari maxsus agent hovuzlarida o'tkaziladi, natijalar avtomatik ravishda GitLab Pages, Influx DB va Grafana da yoki test hisobotlari tizimlarida (TestRail, ReportPortal va boshqalar) chop etiladi. Avtomatlashtirish va masshtablash imkon qadar sodda tarzda amalga oshiriladi - GitLab CI loyihasida odatiy gitlab-ci.yml shablonini qo'shish va parametrlash orqali.
Ushbu yondashuvning afzalligi shundaki, butun CI infratuzilmasi, yuk agentlari, yuk manbalarining docker tasvirlari, sinov quvurlari va hisobotlarni nashr qilish markazlashtirilgan avtomatlashtirish bo'limi (DevOps muhandislari) tomonidan ta'minlanadi, yukni sinash bo'yicha muhandislar esa o'z kuchlarini sinovni ishlab chiqishga qaratishlari mumkin. va infratuzilma masalalari bilan shug'ullanmasdan, ularning natijalarini tahlil qilish.
Ta'rifning soddaligi uchun biz sinovdan o'tayotgan maqsadli dastur yoki server oldindan o'rnatilgan va sozlangan deb taxmin qilamiz (buning uchun Python, SaltStack, Ansible va boshqalardagi avtomatlashtirilgan skriptlardan foydalanish mumkin). Keyin xizmat sifatida yukni sinab ko'rishning butun kontseptsiyasi uch bosqichga to'g'ri keladi: hisobotlarni tayyorlash, sinovdan o'tkazish, nashr etish. Diagramma bo'yicha batafsil ma'lumot (barcha rasmlarni bosish mumkin):
Yukni tekshirishda asosiy tushunchalar va ta'riflar
Yuk sinovlarini o'tkazishda biz rioya qilishga harakat qilamiz , tegishli terminologiya va tavsiya etilgan ko'rsatkichlardan foydalaning. Men yukni sinovdan o'tkazishda asosiy tushunchalar va ta'riflarning qisqacha ro'yxatini beraman.
Yuklash agenti - dastur ishga tushiriladigan virtual mashina - yuk manbai (Apache JMeter, Yandex.Tank yoki o'z-o'zidan yozilgan yuk moduli).
Sinov maqsadi (maqsad) - server yoki yuklanishi mumkin bo'lgan serverda o'rnatilgan dastur.
Sinov stsenariysi (sinov ishi) - parametrlashtirilgan qadamlar to'plami: belgilangan parametrlarga qarab, sobit tarmoq so'rovlari va javoblari bilan foydalanuvchi harakatlari va ushbu harakatlarga kutilgan reaktsiyalar.
Profil yoki yuk rejasi (profil) - In (4.2.4-bo'lim, 43-bet) yuk rejimlari muayyan sinov uchun muhim bo'lgan ko'rsatkichlarni va sinov paytida yuk parametrlarini o'zgartirish variantlarini belgilaydi. Rasmda profillarning namunalarini ko'rishingiz mumkin.
Sinov β oldindan belgilangan parametrlar toβplamiga ega skript.
Test rejasi (test rejasi) - testlar to'plami va yuk profili.
Testran (sinov) - to'liq bajarilgan yuk stsenariysi va olingan hisobot bilan bitta testni bajarishning bir iteratsiyasi.
Tarmoq so'rovi (so'rov) β Agentdan nishonga yuborilgan HTTP so'rovi.
Tarmoq javobi (javob) β Maqsaddan agentga yuborilgan HTTP javobi.
HTTP javob kodi (HTTP javoblar holati) - dastur serveridan standart javob kodi.
Tranzaktsiya so'rov-javobning to'liq aylanishidir. Bitim so'rov (so'rov) yuborilgan paytdan boshlab javob (javob) olish tugaguniga qadar hisoblanadi.
Tranzaksiya holati - so'rov-javob aylanishini muvaffaqiyatli yakunlash mumkinmi. Agar ushbu tsiklda biron bir xato bo'lsa, unda butun tranzaksiya muvaffaqiyatsiz deb hisoblanadi.
Javob vaqti (kechikish) - so'rov (so'rov) jo'natilgandan to javob (javob) olish boshlanishigacha bo'lgan vaqt.
Ko'rsatkichlarni yuklash β yuklangan xizmat va yukni sinash jarayonida aniqlangan yuk agentining xususiyatlari.
Yuk ko'rsatkichlarini o'lchash uchun asosiy ko'rsatkichlar
Metodologiyada eng ko'p ishlatiladigan va tavsiya etilganlardan ba'zilari (36, 52-bet) ko'rsatkichlar quyidagi jadvalda ko'rsatilgan. Agent va maqsad uchun o'xshash ko'rsatkichlar bir qatorda keltirilgan.
Yuklash agenti uchun ko'rsatkichlar
Maqsadli tizim yoki dasturning yuk ostida sinovdan o'tkazilayotgan ko'rsatkichlari
soni vCPU va xotira Ram,
disk - yuk agentining "temir" xususiyatlari
Markaziy protsessor, Xotira, diskdan foydalanish - protsessor, xotira va diskni yuklash dinamikasi
sinov jarayonida. Odatda foiz sifatida o'lchanadi
maksimal mavjud qiymatlar
tarmoq o'tkazuvchanligi (yuk agentida) - o'tkazish qobiliyati
serverdagi tarmoq interfeysi,
yuk agenti o'rnatilgan joyda.
Odatda soniyada baytlarda o'lchanadi (bps)
tarmoq o'tkazuvchanligi(maqsadda) - tarmoq interfeysi tarmoqli kengligi
maqsadli serverda. Odatda soniyada baytlarda o'lchanadi (bps)
Virtual foydalanuvchilar- virtual foydalanuvchilar soni,
yuk stsenariylarini amalga oshirish va
haqiqiy foydalanuvchi harakatlarini taqlid qilish
Virtual foydalanuvchilar holati, O'tdi/Muvaffaqiyatsiz/Jami - muvaffaqiyatlilar soni va
virtual foydalanuvchilarning muvaffaqiyatsiz holatlari
yuk stsenariylari uchun, shuningdek, ularning umumiy soni.
Umuman olganda, barcha foydalanuvchilar bajarishga muvaffaq bo'lishlari kutilmoqda
yuk profilida ko'rsatilgan barcha vazifalaringiz.
Har qanday xato haqiqiy foydalanuvchi qila olmasligini anglatadi
tizim bilan ishlashda muammoingizni hal qiling
Bir soniyada so'rovlar (daqiqa)- soniyada (yoki daqiqada) tarmoq so'rovlari soni.
Yuklash agentining muhim xususiyati uning qancha so'rovlarni yaratishi mumkinligidir.
Aslida, bu virtual foydalanuvchilar tomonidan ilovaga kirishga taqlid qilishdir
soniyada javoblar (daqiqa)
- soniyada (yoki daqiqada) tarmoq javoblari soni.
Maqsadli xizmatning muhim xarakteristikasi: qancha
bilan so'rovlarga javoblar yaratish va yuborish
yuklash agenti
HTTP javob holatiβ turli javob kodlari soni
yuk agenti tomonidan qabul qilingan dastur serveridan.
Masalan, 200 OK muvaffaqiyatli qo'ng'iroqni anglatadi,
va 404 - resurs topilmadi
Kechikish (javob vaqti) - oxiridan boshlab vaqt
javob (javob) olishni boshlashdan oldin so'rov (so'rov) yuborish.
Odatda millisekundlarda (ms) o'lchanadi
Tranzaksiyaga javob berish vaqti- bitta to'liq tranzaksiya vaqti,
so'rov-javob siklini yakunlash.
Bu so'rov (so'rov) yuborilishi boshlangan vaqt.
javob (javob) olish tugaguniga qadar.
Tranzaksiya vaqtini soniyalarda (yoki daqiqalarda) o'lchash mumkin
bir necha usulda: minimalni ko'rib chiqing,
maksimal, o'rtacha va, masalan, 90 foiz.
Minimal va maksimal o'qishlar ekstremaldir
tizimning ishlash holati.
To'qsoninchi foiz eng ko'p qo'llaniladi,
foydalanuvchilarning ko'pchiligini ko'rsatganidek,
tizimning ishlashi ostonasida qulay ishlash
Bir soniyadagi tranzaksiyalar (daqiqa) - to'liq soni
soniyada operatsiyalar (daqiqa),
ya'ni, ariza qancha qabul qila oldi va
so'rovlarni ko'rib chiqish va javob berish.
Aslida, bu tizimning o'tkazuvchanligi
Tranzaksiya holati , O'tdi / Muvaffaqiyatsiz / Jami - raqam
muvaffaqiyatli, muvaffaqiyatsiz va tranzaktsiyalarning umumiy soni.
Haqiqiy foydalanuvchilar uchun muvaffaqiyatsiz
tranzaktsiya aslida anglatadi
yuk ostida tizim bilan ishlashning mumkin emasligi
Yukni sinovdan o'tkazish sxematik diagrammasi
Yukni sinovdan o'tkazish tushunchasi juda oddiy va men allaqachon aytib o'tgan uchta asosiy bosqichdan iborat: Tayyorlash-test-hisobot, ya'ni test maqsadlarini tayyorlash va yuk manbalari uchun parametrlarni o'rnatish, keyin yuk testlarini bajarish va oxirida test hisobotini yaratish va nashr etish.
Sxematik eslatmalar:
- QA.Tester yuklarni sinovdan o'tkazish bo'yicha mutaxassis,
- Maqsad - bu yuk ostida uning harakatini bilmoqchi bo'lgan maqsadli dastur.
Ob'ektlar tasniflagichi, diagrammadagi bosqichlar va bosqichlar
Bosqichlar va bosqichlar
Nima bo'lyapti
Kirishda nima bor
Chiqish nima
Tayyorlang: sinovga tayyorgarlik bosqichi
LoadParameters
Sozlash va ishga tushirish
foydalanuvchi
yuk parametrlari,
ko'rsatkichlarni tanlash va
test rejasini tayyorlash
(yuklash profili)
uchun moslashtirilgan variantlar
yuk agentini ishga tushirish
Sinov rejasi
Sinov maqsadi
VM
Bulutli tarqatish
bilan virtual mashina
talab qilinadigan xususiyatlar
Yuklash agenti uchun VM sozlamalari
Avtomatlashtirish uchun skriptlar
VM yaratish
VM sozlangan
bulut
Yuborish
OTni sozlash va tayyorlash
uchun muhit
yuk agenti ishi
Atrof-muhit sozlamalari
yuk agenti
Avtomatlashtirish uchun skriptlar
muhit sozlamalari
Tayyorlangan muhit:
OS, xizmatlar va ilovalar,
ish uchun zarur
yuk agenti
LoadAgents
O'rnatish, sozlash va parametrlashtirish
yuklash agenti.
Yoki docker tasvirini yuklab olish
oldindan tuzilgan yuk manbai
Docker manba tasvirini yuklang
(YAT, JM yoki o'z-o'zidan yozilgan ramka)
Sozlamalar
yuk agenti
Sozlang va tayyor
ish yuki agentiga
Sinov: yuk sinovlarini bajarish bosqichi. Manbalar GitLab CI uchun maxsus agent hovuzlarida joylashtirilgan yuk agentlaridir
yuk
Yuklash agentini ishga tushirish
tanlangan test rejasi bilan
va yuklash parametrlari
Foydalanuvchi parametrlari
ishga tushirish uchun
yuk agenti
Sinov rejasi
Sinov maqsadi
Amalga oshirish jurnallari
yuk sinovlari
Tizim jurnallari
Maqsad ko'rsatkichlari va yuk agentidagi o'zgarishlar dinamikasi
Agentlarni ishga tushirish
Agent ijrosi
ko'plab test skriptlari
ga ko'ra
yuk profili
Agentning o'zaro ta'sirini yuklash
sinov maqsadida
Sinov rejasi
Sinov maqsadi
Qaydlar
"Xom" jurnallar to'plami
yuk sinovi paytida:
yuk agenti faoliyati yozuvlari,
sinov maqsadi holati
va agentni boshqaradigan VM
Amalga oshirish jurnallari
yuk sinovlari
Tizim jurnallari
Metrikalar
Sinov paytida "xom" ko'rsatkichlarni yig'ish
Maqsad ko'rsatkichlarining o'zgarishlar dinamikasi
va yuk agenti
Hisobot: test hisobotini tayyorlash bosqichi
Jenerator
Qayta ishlash yig'ildi
yuklash tizimi va
"xom" monitoring tizimi
ko'rsatkichlar va jurnallar
Hisobotni shakllantirish
inson o'qiy oladigan shakl
elementlar bilan mumkin
tahlilchilar
Amalga oshirish jurnallari
yuk sinovlari
Tizim jurnallari
Ko'rsatkichlardagi o'zgarishlar dinamikasi
maqsad va yuk agenti
Qayta ishlangan "xom" jurnallar
uchun mos formatda
tashqi xotiraga yuklaydi
Statik yuk hisoboti,
inson tomonidan o'qilishi mumkin
Nashr qiling
Hisobotni nashr etish
yuk haqida
tashqi test
xizmat
Qayta ishlangan "xom"
tegishli formatda jurnallar
tashqi yuklarni tushirish uchun
omborlar
Tashqi tomondan saqlangan
saqlash hisobotlari yoqilgan
yuk, mos
inson tahlili uchun
CI shablonidagi yuk manbalarini ulash
Keling, amaliy qismga o'tamiz. Men kompaniyadagi ba'zi loyihalarda qandayligini ko'rsatmoqchiman biz xizmat sifatida yuk sinovi kontseptsiyasini amalga oshirdik.
Birinchidan, DevOps muhandislarimiz yordamida biz yuk sinovlarini oβtkazish uchun GitLab CI da maxsus agentlar pulini yaratdik. Shablonlarda ularni boshqalar bilan, masalan, yig'ish hovuzlari bilan aralashtirib yubormaslik uchun biz ushbu agentlarga teglar qo'shdik, : yuk. Boshqa tushunarli teglardan foydalanishingiz mumkin. β deb soβrashadi GitLab CI yuguruvchilari.
Uskuna orqali kerakli quvvatni qanday aniqlash mumkin? Yuklash agentlarining xarakteristikalari - etarli miqdordagi vCPU, RAM va Disk - Docker, Python (Yandex.Tank uchun), GitLab CI agenti, Java (Apache JMeter uchun) agentda ishlashi kerakligiga asoslanib hisoblanishi mumkin. . JMeter ostida Java uchun kamida 512 MB operativ xotiradan foydalanish tavsiya etiladi va yuqori chegara sifatida: .
Shunday qilib, tajribamizga asoslanib, yuk agentlari uchun kamida 4 vCPU, 4 GB RAM, 60 GB SSD foydalanishni tavsiya etamiz. Tarmoq kartasining o'tkazuvchanligi yuk profilining talablari asosida aniqlanadi.
Biz asosan ikkita yuklash manbasidan foydalanamiz - Apache JMeter va Yandex.Tank docker tasvirlari.
yukni tekshirish uchun Yandex-dan ochiq manbali vositadir. Uning modulli arxitekturasi Phantomning yuqori unumli asinxron hitga asoslangan HTTP so'rov generatoriga asoslangan. Tankda SSH protokoli orqali sinovdan o'tayotgan server resurslarining o'rnatilgan monitoringi mavjud, belgilangan sharoitlarda sinovni avtomatik ravishda to'xtatishi, natijalarni konsolda ham, grafiklar ko'rinishida ham ko'rsatishi mumkin, siz modullaringizni ulashingiz mumkin. funksionallikni kengaytirish uchun unga. Aytgancha, biz tankdan hali asosiy oqim bo'lmaganida foydalanganmiz. Maqolada "Β» siz 2013 yilda u bilan yuk sinovini qanday o'tkazganimiz haqidagi hikoyani o'qishingiz mumkin kompaniyamiz mahsulotlaridan biridir.
bu Apache'dan ochiq manba yuk sinov vositasidir. U statik va dinamik veb-ilovalarni sinab ko'rish uchun teng darajada yaxshi ishlatilishi mumkin. JMeter juda ko'p sonli protokollar va ilovalar bilan ishlash usullarini qo'llab-quvvatlaydi: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET va boshqalar), SOAP / REST veb-xizmatlari, FTP, TCP, LDAP, SMTP(S), POP3( S) ) va IMAP(S), JDBC orqali ma'lumotlar bazalari qobiq buyruqlarini bajarishi va Java ob'ektlari bilan ishlashi mumkin. JMeterda test rejalarini yaratish, disk raskadrovka qilish va bajarish uchun IDE mavjud. Java-ga mos keluvchi har qanday operatsion tizimda (Linux, Windows, Mac OS X) buyruq qatori ishlashi uchun CLI ham mavjud. Asbob dinamik ravishda HTML test hisobotini yaratishi mumkin.
Kompaniyamizda foydalanish qulayligi uchun, sinovchilarning o'zlari muhitni o'zgartirishi va qo'shishi uchun biz GitLab CI-da yuk manbalarining docker tasvirlarini ishlab chiqdik va ichki nashrga e'lon qildik. . Bu ularni yuk sinovlari uchun quvurlarga ulashni tezroq va osonlashtiradi. GitLab CI orqali registrga docker push-ni qanday qilish kerak - qarang .
Biz Yandex.Tank uchun ushbu asosiy docker faylini oldik:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]Va Apache JMeter uchun bu:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Bizning uzluksiz integratsiya tizimimiz qanday ishlashini maqolada o'qishingiz mumkin "".
Shablon va quvur liniyasi
Loyihada yuk sinovlarini o'tkazish uchun shablon namunasi mavjud . The Shablonni ishlatish bo'yicha ko'rsatmalarni o'qishingiz mumkin. Shablonning o'zida (fayl ) har bir qadam nima uchun mas'ul ekanligi haqida eslatmalar mavjud.
Shablon juda oddiy va yuqoridagi diagrammada tasvirlangan yukni tekshirishning uch bosqichini ko'rsatadi: hisobotlarni tayyorlash, sinovdan o'tkazish va nashr etish. Buning uchun javobgar : Tayyorlang, sinab ko'ring va hisobot bering.
- Stage test maqsadlarini oldindan sozlash yoki ularning mavjudligini tekshirish uchun ishlatilishi kerak. Yuklash manbalari uchun muhitni sozlash shart emas, ular docker tasvirlari sifatida oldindan tuzilgan va docker registriga joylashtirilgan: Test bosqichida kerakli versiyani ko'rsatish kifoya. Lekin siz ularni qayta tiklashingiz va o'zingizning o'zgartirilgan tasvirlaringizni yaratishingiz mumkin.
- Stage yuk manbasini belgilash, testlarni o'tkazish va sinov artefaktlarini saqlash uchun ishlatiladi. Siz har qanday yuk manbasini tanlashingiz mumkin: Yandex.Tank, Apache JMeter, o'zingiz yoki barchasi birgalikda. Keraksiz manbalarni o'chirish uchun ishni sharhlang yoki o'chiring. Yuklash manbalari uchun kirish nuqtalari:
- Yandex.Tank uchun ishga tushirish parametrlari .,
- Apache JMeter ishga tushirish parametrlari faylda ko'rsatilgan .
Eslatma: Yig'ish konfiguratsiyasi shabloni CI tizimi bilan o'zaro aloqani o'rnatish uchun ishlatiladi va unda test mantig'ini joylashtirishni nazarda tutmaydi. Sinovlar uchun boshqaruv bosh skripti joylashgan kirish nuqtasi ko'rsatilgan. Sinovlarni o'tkazish, hisobotlarni yaratish va test skriptlarining o'zlari QA muhandislari tomonidan amalga oshirilishi kerak. Namoyishda ikkala yuklash manbalari uchun Yandex asosiy sahifa so'rovi eng oddiy sinov sifatida ishlatiladi. Skriptlar va test parametrlari katalogda .
- Sahnada Sinov bosqichida olingan test natijalarini tashqi xotiralarga, masalan, GitLab Pages yoki maxsus hisobot tizimlariga qanday chop etishni tasvirlab berishingiz kerak. GitLab Pages ./public katalogi bo'sh bo'lmasligini va sinovlar tugagandan so'ng kamida index.html faylini o'z ichiga olishini talab qiladi. GitLab Pages xizmatining nuanslari haqida o'qishingiz mumkin. .
Ma'lumotlarni eksport qilishga misollar:
- JMeter dan ,
- Yandex.Tankdan .
Joylashtirish bo'yicha ko'rsatmalar:
- HTML statikasi ,
- InfluxDB ga va keyin .
Namoyish misolida yuk sinovlari va ikkita yuk manbalari bo'lgan quvur liniyasi (keraksizni o'chirib qo'yishingiz mumkin) quyidagicha ko'rinadi:
Apache JMeter HTML hisobotini o'zi yaratishi mumkin, shuning uchun uni standart vositalar yordamida GitLab sahifalarida saqlash foydaliroq. Apache JMeter hisoboti quyidagicha ko'rinadi:
Yandex.Tank uchun demo misolida siz faqat ko'rasiz GitLab sahifalari bo'limida. Sinov paytida Tank natijalarni InfluxDB ma'lumotlar bazasiga saqlashi mumkin va u erdan ular, masalan, Grafana-da ko'rsatilishi mumkin (konfiguratsiya faylda amalga oshiriladi) ). Tank hisoboti Grafanada shunday ko'rinadi:
Xulosa
Maqolada men "xizmat sifatida yuk testi" (xizmat sifatida yuk testi) tushunchasi haqida gapirdim. Asosiy g'oya avvaldan tuzilgan yuk agentlari hovuzlari infratuzilmasidan, yuk manbalarining docker tasvirlaridan, hisobot tizimlaridan va ularni oddiy .gitlab-ci.yml shabloniga asoslangan GitLab CI da birlashtirgan quvur liniyasidan foydalanishdir (misol ). Bularning barchasi avtomatlashtirish muhandislarining kichik jamoasi tomonidan qo'llab-quvvatlanadi va mahsulot guruhlari talabiga binoan takrorlanadi. Umid qilamanki, bu sizning kompaniyangizda shunga o'xshash sxemani tayyorlash va amalga oshirishda sizga yordam beradi. E'tiboringiz uchun tashakkur!
PS. Men hamkasblarim Sergey Qurbonov va Nikolay Yusevga kompaniyamizda xizmat sifatida yuk sinovi kontseptsiyasini amalga oshirishda texnik yordam ko'rsatganlari uchun katta rahmat aytmoqchiman.
muallif: - Deputat Positive Technologies kompaniyasining Texnologiya va rivojlanish jarayonlari (DevOps) rahbari
Manba: www.habr.com