Олон төрлийн програм хангамжийн үйлдвэрлэгчдэд ихэвчлэн тулгардаг бэрхшээлүүдийн нэг бол бараг бүх баг дээр ажилладаг инженерүүд болох хөгжүүлэгчид, тестерүүд, дэд бүтцийн администраторуудын ур чадварын давхардал юм. Энэ нь үнэтэй инженерүүд - ачааллын туршилтын чиглэлээр мэргэшсэн мэргэжилтнүүдэд мөн хамаарна.
Шууд үүргээ гүйцэтгэж, өвөрмөц туршлагаа ашиглан ачааллын туршилт хийх процессыг бий болгох, аргачлал, оновчтой хэмжигдэхүүнийг сонгох, ачааллын профайлын дагуу автомат тест бичихийн оронд инженерүүд ихэвчлэн туршилтын дэд бүтцийг эхнээс нь байрлуулж, ачааллын хэрэгслийг тохируулах, тэдгээрийг суулгах шаардлагатай болдог. өөрсдөө CI системд хяналт тавьж, тайланг нийтлэх.
Positive Technologies-д бидний ашигладаг туршилтын явцад та зохион байгуулалтын зарим асуудлын шийдлийг олох боломжтой . Мөн энэ хэсэгт би ачааллын туршилтыг "үйлчилгээ болгон ачааллын туршилт" (үйлчилгээ болгон ачааллын туршилт) гэсэн ойлголтыг ашиглан нийтлэг CI дамжуулах хоолойд нэгтгэх боломжийн талаар ярих болно. Та CI дамжуулах хоолойд ачааллын эх үүсвэрийн докерын зургийг хэрхэн, ямар ашиглаж болохыг сурах болно; бүтээх загвар ашиглан ачааллын эх үүсвэрийг CI төсөлдөө хэрхэн холбох; Ачааллын туршилтыг явуулж, үр дүнг нийтлэхэд демо дамжуулах хоолой ямар харагддаг. Энэхүү нийтлэл нь ачааллын системийн архитектурын талаар бодож байгаа CI дахь програм хангамжийн туршилтын инженерүүд болон автоматжуулалтын инженерүүдэд хэрэгтэй байж магадгүй юм.
Үзэл баримтлалын мөн чанар
Ачааллын туршилтын тухай ойлголт нь ачааллын хэрэгсэл Apache JMeter, Yandex.Tank болон өөрийн хүрээг дурын тасралтгүй интеграцийн системд нэгтгэх чадварыг илэрхийлдэг. Демо нь GitLab CI-д зориулагдсан боловч зарчмууд нь бүх CI системд нийтлэг байдаг.
Ачааллын тест нь ачааллын туршилтын төвлөрсөн үйлчилгээ юм. Ачааллын туршилтыг тусгай агентын санд явуулдаг бөгөөд үр дүнг GitLab Pages, Influx DB болон Grafana эсвэл туршилтын тайлангийн системд (TestRail, ReportPortal гэх мэт) автоматаар нийтэлдэг. GitLab CI төсөлд ердийн gitlab-ci.yml загварыг нэмж, параметржүүлэх замаар автоматжуулалт ба масштабыг аль болох энгийн байдлаар хэрэгжүүлдэг.
Энэхүү аргын давуу тал нь CI-ийн бүх дэд бүтэц, ачааллын агентууд, ачааллын эх үүсвэрийн докерийн зургууд, туршилтын дамжуулах хоолой, нийтлэх тайлангуудыг төвлөрсөн автоматжуулалтын хэлтэс (DevOps инженерүүд) хариуцдаг бол ачааллын туршилтын инженерүүд туршилтыг боловсруулахад хүчин чармайлтаа төвлөрүүлж чаддагт оршино. дэд бүтцийн асуудлыг шийдвэрлэхгүйгээр тэдгээрийн үр дүнд дүн шинжилгээ хийх.
Тайлбарыг хялбарчлахын тулд бид зорилтот програм эсвэл туршилтын серверийг аль хэдийн байрлуулж, тохируулсан гэж үзэх болно (үүнд Python, SaltStack, Ansible гэх мэт автоматжуулсан скриптүүдийг ашиглаж болно). Дараа нь үйлчилгээний ачааллын туршилтын тухай ойлголт нь гурван үе шатанд багтдаг. тайлан бэлтгэх, турших, нийтлэх. Диаграмын талаарх дэлгэрэнгүй мэдээллийг (бүх зургийг дарж болно):
Ачааллын туршилтын үндсэн ойлголт, тодорхойлолтууд
Ачааллын туршилт хийхдээ бид дагаж мөрдөхийг хичээдэг , тохирох нэр томьёо болон санал болгож буй хэмжүүрүүдийг ашиглах. Би ачааллын туршилтын үндсэн ойлголт, тодорхойлолтуудын товч жагсаалтыг өгөх болно.
Агентийг ачаалах - програмыг ажиллуулах виртуал машин - ачааллын эх үүсвэр (Apache JMeter, Yandex.Tank эсвэл өөрөө бичсэн ачааллын модуль).
Туршилтын зорилго (зорилтот) - сервер дээр суулгасан сервер эсвэл програм ачаалагдах болно.
Туршилтын хувилбар (туршилтын тохиолдол) - параметржүүлсэн алхмуудын багц: заасан параметрээс хамааран тогтмол сүлжээний хүсэлт, хариулт бүхий хэрэглэгчийн үйлдэл ба эдгээр үйлдэлд хүлээгдэж буй хариу үйлдэл.
Профайл эсвэл ачааллын төлөвлөгөө (профайл) - үед (Хэсэг 4.2.4, х. 43) ачааллын профайл нь тодорхой туршилтанд чухал ач холбогдолтой хэмжүүрүүд болон туршилтын явцад ачааллын параметрүүдийг өөрчлөх сонголтуудыг тодорхойлдог. Та зураг дээрх профайлын жишээг харж болно.
Туршилт - урьдчилан тодорхойлсон параметрийн багц бүхий скрипт.
Туршилтын төлөвлөгөө (туршилтын төлөвлөгөө) - туршилтын багц ба ачааллын профайл.
Тестран (туршилт) - бүрэн гүйцэтгэсэн ачааллын хувилбар болон хүлээн авсан тайлантай нэг туршилтыг ажиллуулах нэг давталт.
Сүлжээний хүсэлт (хүсэлт) — Агентаас зорилтот руу илгээсэн HTTP хүсэлт.
Сүлжээний хариу (хариу) — Зорилтотоос агент руу илгээсэн HTTP хариу.
HTTP хариултын код (HTTP хариултын төлөв) - програмын серверийн стандарт хариултын код.
Гүйлгээ нь хүсэлт-хариултын бүрэн мөчлөг юм. Гүйлгээг хүсэлт (хүсэлт) илгээж эхэлснээс хойш хариу (хариу) хүлээн авах хүртэл тооцно.
Гүйлгээний төлөв - хүсэлт-хариултын мөчлөгийг амжилттай дуусгах боломжтой эсэх. Хэрэв энэ мөчлөгт ямар нэгэн алдаа гарсан бол бүх гүйлгээ амжилтгүй болсон гэж үзнэ.
Хариу өгөх хугацаа (хоцролт) - хүсэлт (хүсэлт) илгээж дууссанаас хариу (хариулт) хүлээн авах хүртэлх хугацаа.
Хэмжилтийг ачаалах - ачаалагдсан үйлчилгээний шинж чанар, ачааллын туршилтын явцад тодорхойлсон ачааллын агент.
Ачааллын параметрүүдийг хэмжих үндсэн хэмжүүрүүд
Арга зүйд хамгийн түгээмэл хэрэглэгддэг, санал болгож буй зарим нь (х. 36, 52) хэмжүүрүүдийг доорх хүснэгтэд үзүүлэв. Агент болон зорилтот хүмүүсийн ижил төстэй хэмжүүрүүдийг нэг мөрөнд жагсаав.
Ачаалагчийн хэмжүүр
Ачааллын дор туршиж буй зорилтот систем эсвэл програмын хэмжүүрүүд
Тоо vCPU болон санах ой RAM,
диск - ачааны агентын "төмрийн" шинж чанар
CPU-ийн, Санах ой, Дискний хэрэглээ - CPU, санах ой, диск ачаалах динамик
туршилтын явцад. Ихэвчлэн хувиар хэмждэг
боломжтой хамгийн их утгууд
сүлжээний нэвтрүүлэх чадвар (ачааллын агент дээр) - нэвтрүүлэх чадвар
сервер дээрх сүлжээний интерфейс,
ачааллын агент суурилуулсан газар.
Ихэвчлэн секундэд байтаар хэмжигддэг (bps)
сүлжээний нэвтрүүлэх чадвар(зорилтот дээр) - сүлжээний интерфейсийн зурвасын өргөн
зорилтот сервер дээр. Ихэвчлэн секундэд байтаар хэмжигддэг (bps)
Виртуал хэрэглэгчид- виртуал хэрэглэгчдийн тоо,
ачааллын хувилбаруудыг хэрэгжүүлэх ба
хэрэглэгчийн бодит үйлдлийг дуурайлган хийх
Виртуал хэрэглэгчийн статус, Дамжсан/Бүтэлгүй/Нийт — амжилттай болон
виртуал хэрэглэгчдийн амжилтгүй статусууд
ачааллын хувилбарууд, түүнчлэн тэдгээрийн нийт тоо.
Ерөнхийдөө бүх хэрэглэгчид дуусгах боломжтой гэж найдаж байна
ачааллын профайл дээр заасан таны бүх даалгаврууд.
Аливаа алдаа нь жинхэнэ хэрэглэгч үүнийг хийх боломжгүй болно гэсэн үг юм
системтэй ажиллахдаа асуудлаа шийдээрэй
Секундэд хийх хүсэлт (минут)- секундэд (эсвэл минут) сүлжээний хүсэлтийн тоо.
Ачааллын агентын чухал шинж чанар нь хичнээн хүсэлтийг үүсгэж чадах явдал юм.
Үнэн хэрэгтээ энэ нь виртуал хэрэглэгчдийн програм руу нэвтрэх дуураймал юм
Секундэд хариулах тоо (минут)
- секундэд (эсвэл минут) сүлжээний хариу өгөх тоо.
Зорилтот үйлчилгээний чухал шинж чанар: хэр их
ашиглан асуулгад хариулт үүсгэх, илгээх
ачих агент
HTTP хариултын төлөв- өөр өөр хариу кодын тоо
ачааллын агент хүлээн авсан програмын серверээс.
Жишээлбэл, 200 OK гэдэг нь амжилттай дуудлага,
болон 404 - нөөц олдсонгүй
Лавлагаа (хариу өгөх хугацаа) - төгсгөлөөс хойшхи хугацаа
хариу (хариу) хүлээн авч эхлэхээс өмнө хүсэлт (хүсэлт) илгээх.
Ихэвчлэн миллисекундээр хэмжигддэг (мс)
Гүйлгээнд хариу өгөх хугацаа- нэг бүтэн гүйлгээ хийх хугацаа,
хүсэлт-хариултын мөчлөгийг дуусгах.
Энэ нь хүсэлт (хүсэлт) илгээж эхэлснээс хойшхи хугацаа юм.
хариу (хариу) хүлээн авах хүртэл.
Гүйлгээний хугацааг секундээр (эсвэл минутаар) хэмжиж болно.
хэд хэдэн аргаар: хамгийн бага хэмжээг авч үзэх,
хамгийн их, дундаж, жишээлбэл, 90 дахь хувь.
Хамгийн бага ба хамгийн их уншилтууд нь туйлын их байдаг
системийн гүйцэтгэлийн байдал.
Ерэн хувь нь хамгийн түгээмэл хэрэглэгддэг,
Энэ нь хэрэглэгчдийн ихэнх нь харуулж байна,
системийн гүйцэтгэлийн босгон дээр тав тухтай ажиллах
Секунд дахь гүйлгээ (минут) - бүрэн тоо
секундэд гүйлгээ (минут),
өөрөөр хэлбэл, хэр их өргөдөл хүлээн авах боломжтой байсан ба
хүсэлтийг боловсруулж, хариу өгөх.
Үнэн хэрэгтээ энэ бол системийн нэвтрүүлэх чадвар юм
Гүйлгээний төлөв , Давсан / Амжилтгүй / Нийт - тоо
амжилттай, амжилтгүй, нийт гүйлгээний тоо.
Жинхэнэ хэрэглэгчдийн хувьд амжилтгүй болсон
гүйлгээ нь үнэндээ гэсэн үг юм
ачаалалтай системтэй ажиллах чадваргүй байх
Ачааллын туршилтын бүдүүвч диаграм
Ачааллын туршилтын тухай ойлголт нь маш энгийн бөгөөд миний өмнө дурдсан гурван үндсэн үе шатаас бүрддэг. Бэлтгэх - Туршилт - Тайлан, өөрөөр хэлбэл, туршилтын зорилгыг бэлтгэх, ачааллын эх үүсвэрийн параметрүүдийг тохируулах, дараа нь ачааллын туршилтыг гүйцэтгэх, эцэст нь туршилтын тайланг гаргаж, нийтлэх.
Схемийн тэмдэглэл:
- QA.Tester нь ачааллын туршилтын мэргэжилтэн юм.
- Зорилтот нь ачааллын үед түүний үйлдлийг мэдэхийг хүсч буй зорилтот програм юм.
Диаграм дахь объект, үе шат, үе шатуудын ангилагч
Үе шат ба үе шатууд
Юу болоод байна
Орцонд юу байна
Гаралт нь юу вэ
Бэлтгэх: туршилтанд бэлтгэх үе шат
LoadParameters
Тохиргоо ба эхлүүлэх
хэрэглэгч
ачааллын параметрүүд,
хэмжүүрийн сонголт ба
туршилтын төлөвлөгөө бэлтгэх
(профайл ачаалах)
Тусгай сонголтууд
ачааллын агентыг эхлүүлэх
Туршилтын төлөвлөгөө
Туршилтын зорилго
VM
Үүлэн байршуулалт
бүхий виртуал машин
шаардлагатай шинж чанарууд
Ачаалагчийн VM тохиргоо
Автоматжуулалтын скриптүүд
VM үүсгэх
VM-г тохируулсан
үүл
Өргөн
OS-ийн тохиргоо ба бэлтгэл
зориулсан орчин
ачааны агентын ажил
Хүрээлэн буй орчны тохиргоо
ачааллын төлөөлөгч
Автоматжуулалтын скриптүүд
орчны тохиргоо
Бэлтгэсэн орчин:
үйлдлийн систем, үйлчилгээ, програмууд,
ажилд шаардлагатай
ачааллын төлөөлөгч
LoadAgents
Суурилуулалт, тохируулга, параметрийн тохиргоо
ачих агент.
Эсвэл докерын зургийг татаж авах
урьдчилан тохируулсан ачааллын эх үүсвэр
Эх сурвалжийн докерын зургийг ачаалах
(YAT, JM эсвэл өөрөө бичсэн хүрээ)
Тохиргоо
ачааллын төлөөлөгч
Тохируулж, бэлэн боллоо
ажлын ачааллын төлөөлөгч рүү
Туршилт: ачааллын туршилтыг гүйцэтгэх үе шат. Эх сурвалжууд нь GitLab CI-д зориулсан тусгай агентын санд байрлуулсан ачааллын агентууд юм
Load
Ачаалагчийг эхлүүлж байна
сонгосон туршилтын төлөвлөгөөтэй
болон ачааллын параметрүүд
Хэрэглэгчийн сонголтууд
эхлүүлэхийн тулд
ачааллын төлөөлөгч
Туршилтын төлөвлөгөө
Туршилтын зорилго
Гүйцэтгэлийн бүртгэлүүд
ачааллын туршилтууд
Системийн бүртгэлүүд
Зорилгын хэмжигдэхүүн ба ачааллын төлөөлөгчийн өөрчлөлтийн динамик
Агентуудыг ажиллуулах
Агентын гүйцэтгэл
олон тооны туршилтын скриптүүд
дагуу
ачааллын профайл
Агентийн харилцан үйлчлэлийг ачаалах
туршилтын зорилгоор
Туршилтын төлөвлөгөө
Туршилтын зорилго
бичиглэлээр
"Түүхий" гуалин цуглуулга
ачааллын туршилтын үед:
ачааллын төлөөлөгчийн үйл ажиллагааны бүртгэл,
туршилтын зорилтот төлөв
мөн агентийг ажиллуулж буй VM
Гүйцэтгэлийн бүртгэлүүд
ачааллын туршилтууд
Системийн бүртгэлүүд
Хэмжүүр
Туршилтын явцад "түүхий" хэмжигдэхүүнийг цуглуулах
Зорилгын хэмжүүрүүдийн өөрчлөлтийн динамик
болон ачааллын агент
Тайлан: туршилтын тайлан бэлтгэх үе шат
Генератор
Боловсруулалтыг цуглуулсан
ачаалах систем ба
хяналтын систем "түүхий"
хэмжигдэхүүн ба бүртгэл
тайланг бүрдүүлэх
хүн унших боломжтой хэлбэр
элементүүдээр боломжтой
шинжээчид
Гүйцэтгэлийн бүртгэлүүд
ачааллын туршилтууд
Системийн бүртгэлүүд
Хэмжилтийн өөрчлөлтийн динамик
зорилтот болон ачааллын агент
Боловсруулсан "түүхий" лог
тохиромжтой хэлбэрээр
гадаад санах ойд байршуулах
Статик ачааллын тайлан,
хүн унших боломжтой
нийтэл
Тайланг нийтлэх
ачааллын тухай
гадаад туршилт
үйлчилгээ
Боловсруулсан "түүхий"
тохиромжтой форматтай бүртгэлүүд
гадаад руу буулгах зориулалттай
хонгилууд
Гадаадад хадгалсан
хадгалах тайлангууд дээр
ачаалал, тохиромжтой
хүний шинжилгээнд зориулагдсан
CI загварт ачааллын эх үүсвэрүүдийг холбох
Практик хэсэг рүү шилжье. Би компаний зарим төсөл дээр яаж байгааг харуулахыг хүсч байна бид ачааллын туршилтын үзэл баримтлалыг үйлчилгээ болгон хэрэгжүүлсэн.
Нэгдүгээрт, бид DevOps-ийн инженерүүдийн тусламжтайгаар GitLab CI-д ачааллын туршилт явуулахын тулд тусгай агентуудын санг бий болгосон. Загвар дээр угсрах усан сан гэх мэт бусадтай андуурахгүйн тулд бид эдгээр агентуудад шошго нэмсэн. : ачаалал. Та бусад ойлгомжтой шошго ашиглаж болно. Тэд асуудаг GitLab CI гүйгчид.
Шаардлагатай хүчийг техник хангамжаар хэрхэн олох вэ? Ачааллын агентуудын шинж чанаруудыг - хангалттай тооны vCPU, RAM болон Disk - Docker, Python (Yandex.Tank-ийн хувьд), GitLab CI агент, Java (Apache JMeter-д зориулсан) агент дээр ажиллаж байх ёстойг үндэслэн тооцоолж болно. . JMeter-ийн дагуу Java-ийн хувьд хамгийн багадаа 512 МБ RAM ашиглахыг зөвлөж байна, дээд хязгаар болгон: .
Тиймээс, бидний туршлага дээр үндэслэн ачааллын агентуудад дор хаяж 4 vCPU, 4 ГБ RAM, 60 ГБ SSD ашиглахыг зөвлөж байна. Сүлжээний картын нэвтрүүлэх чадварыг ачааллын профайлын шаардлагад үндэслэн тодорхойлно.
Бид ихэвчлэн хоёр ачааллын эх үүсвэрийг ашигладаг - Apache JMeter болон Yandex.Tank докерын зургууд.
нь Yandex-ээс ачааллын туршилт хийх нээлттэй эхийн хэрэгсэл юм. Түүний модульчлагдсан архитектур нь Phantom-ийн өндөр гүйцэтгэлтэй асинхрон хитэд суурилсан HTTP хүсэлт үүсгэгч дээр суурилдаг. Танк нь SSH протоколоор дамжуулан туршиж буй серверийн нөөцийн хяналтыг суурилуулсан бөгөөд заасан нөхцөлд туршилтыг автоматаар зогсоож, үр дүнг консол болон график хэлбэрээр харуулах боломжтой, та модулиудаа холбох боломжтой. функцийг өргөжүүлэхийн тулд түүнд . Дашрамд хэлэхэд, бид танкийг хараахан дэлгэрээгүй байхад ашиглаж байсан. Нийтлэлд "» Та бид 2013 онд ачааллын туршилтыг хэрхэн хийсэн тухай түүхийг уншиж болно манай компанийн бүтээгдэхүүнүүдийн нэг юм.
нь Apache-ийн нээлттэй эхийн ачааллыг шалгах хэрэгсэл юм. Энэ нь статик болон динамик вэб програмуудыг туршихад адилхан ашиглагдаж болно. JMeter нь HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET гэх мэт), SOAP / REST вэб үйлчилгээ, FTP, TCP, LDAP, SMTP(S), POP3( гэх мэт олон тооны протокол, програмуудтай харилцах арга замыг дэмждэг. S) ) болон IMAP(S), JDBC-ээр дамжуулан мэдээллийн сан нь бүрхүүлийн командуудыг гүйцэтгэж, Java объектуудтай ажиллах боломжтой. JMeter нь туршилтын төлөвлөгөө үүсгэх, дибаг хийх, гүйцэтгэхэд зориулагдсан IDE-тэй. Мөн Java-д тохирох аливаа үйлдлийн систем (Linux, Windows, Mac OS X) дээр командын мөрийг ажиллуулах CLI байдаг. Энэхүү хэрэгсэл нь HTML тестийн тайланг динамикаар үүсгэж болно.
Манай компанийг ашиглахад хялбар болгох, шалгагчдыг хүрээлэн буй орчныг өөрчлөх, нэмэх чадварыг бий болгохын тулд бид GitLab CI дээр ачааллын эх үүсвэрийн докерын зургийг бүтээж, дотоод сүлжээнд нийтэлсэн. . Энэ нь ачааллын туршилтыг дамжуулах хоолойд холбоход илүү хурдан бөгөөд хялбар болгодог. GitLab CI-ээр дамжуулан docker push-ийг бүртгэл рүү хэрхэн яаж хийх вэ - үзнэ үү .
Бид Yandex.Tank-д зориулж энэ үндсэн докер файлыг авсан:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]Мөн Apache JMeter-ийн хувьд энэ нь:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Та манай тасралтгүй интеграцийн систем хэрхэн ажилладаг талаар нийтлэлээс уншиж болно.".
Загвар ба дамжуулах хоолой
Төсөлд ачааллын туршилт хийх загварын жишээг авах боломжтой . The Та загварыг ашиглах зааврыг уншиж болно. Загвар өөрөө (файл ) алхам бүрийг юу хариуцах тухай тэмдэглэл байдаг.
Загвар нь маш энгийн бөгөөд дээрх диаграммд тайлбарласан ачааллын туршилтын гурван үе шатыг харуулдаг: тайлан бэлтгэх, турших, нийтлэх. Үүний төлөө хариуцлага хүлээдэг : Бэлтгэх, турших, тайлагнах.
- Үе шат Туршилтын зорилтуудыг урьдчилан тохируулах эсвэл тэдгээрийн хүртээмжийг шалгахад ашиглах ёстой. Ачааллын эх үүсвэрийн орчныг тохируулах шаардлагагүй, тэдгээрийг докерын дүрс хэлбэрээр урьдчилан бүтээж, докерын бүртгэлд байршуулсан: Туршилтын шатанд хүссэн хувилбараа зааж өгөхөд л хангалттай. Гэхдээ та тэдгээрийг дахин бүтээж, өөрчилсөн зургуудаа хийж болно.
- Үе шат ачааллын эх үүсвэрийг тодорхойлох, туршилт явуулах, туршилтын олдворуудыг хадгалахад ашигладаг. Та ямар ч ачааллын эх үүсвэрийг сонгож болно: Yandex.Tank, Apache JMeter, өөрийн болон бүгдээрээ. Шаардлагагүй эх сурвалжийг идэвхгүй болгохын тулд зүгээр л коммент бичих эсвэл ажлыг устгана уу. Ачааллын эх үүсвэрийн орох цэгүүд:
- Yandex.Tank-ийн хөөргөх параметрүүдийг .,
- Apache JMeter эхлүүлэх параметрүүдийг файлд зааж өгсөн болно .
Тайлбар: Угсралтын тохиргооны загвар нь CI системтэй харилцан үйлчлэлийг тохируулахад хэрэглэгддэг бөгөөд үүнд туршилтын логикийг байрлуулах гэсэн үг биш юм. Туршилтын хувьд хяналтын bash скрипт байрладаг нэвтрэх цэгийг зааж өгсөн болно. Туршилт явуулах, тайлан гаргах, туршилтын скриптүүдийг өөрөө чанарын хяналтын инженерүүд хэрэгжүүлэх ёстой. Демо дээр ачааллын эх үүсвэрийн хувьд Yandex үндсэн хуудасны хүсэлтийг хамгийн энгийн тест болгон ашигладаг. Скриптүүд болон тестийн параметрүүд нь лавлахад байна .
- Тайзан дээр Туршилтын үе шатанд олж авсан туршилтын үр дүнг гадаад хадгалалт, жишээлбэл GitLab хуудас эсвэл тусгай тайлангийн системд хэрхэн нийтлэх талаар тайлбарлах хэрэгтэй. GitLab Pages нь ./public лавлах нь хоосон биш байх ёстой бөгөөд шалгалт дууссаны дараа дор хаяж index.html файл агуулсан байхыг шаарддаг. Та GitLab Pages үйлчилгээний нарийн ширийн зүйлийн талаар уншиж болно. .
Мэдээллийг хэрхэн экспортлох жишээ:
- JMeter-ээс ,
- Yandex.Tank-аас .
Нийтлэх тохиргооны заавар:
- HTML статик ,
- InfluxDB руу, дараа нь .
Демо жишээн дээр ачааллын туршилт, ачааллын хоёр эх үүсвэр бүхий дамжуулах хоолой (та шаардлагагүй эх үүсвэрийг идэвхгүй болгож болно) дараах байдалтай байна.
Apache JMeter нь HTML тайланг өөрөө үүсгэж чаддаг тул стандарт хэрэглүүрийг ашиглан GitLab хуудсанд хадгалах нь илүү ашигтай байдаг. Apache JMeter тайлан дараах байдалтай байна.
Yandex.Tank-ийн демо жишээн дээр та зөвхөн харах болно GitLab хуудасны хэсэгт. Туршилтын явцад танк нь үр дүнг InfluxDB мэдээллийн санд хадгалах боломжтой бөгөөд тэндээс тэдгээрийг жишээ нь Графана дээр харуулах боломжтой (тохиргоог файлд хийсэн болно) ). Графана дахь Танкийн тайлан ингэж харагдаж байна.
Хураангуй
Нийтлэлд би "үйлчилгээний ачааллын тест" (үйлчилгээний ачааллын тест) гэсэн ойлголтын талаар ярьсан. Гол санаа нь ачааллын агентуудын урьдчилан тохируулсан сангуудын дэд бүтэц, ачааллын эх үүсвэрийн докерийн зураг, тайлагнах систем, энгийн .gitlab-ci.yml загвар дээр суурилсан GitLab CI-д нэгтгэсэн дамжуулах шугамыг ашиглах явдал юм (жишээ нь ). Энэ бүхнийг автоматжуулалтын инженерүүдийн жижиг баг дэмжиж, бүтээгдэхүүний багуудын хүсэлтээр хуулбарладаг. Энэ нь танай компанид ижил төстэй схемийг бэлтгэх, хэрэгжүүлэхэд тусална гэж найдаж байна. Анхаарал тавьсанд баярлалаа!
Жич: Ачааллын туршилтыг манай компанид үйлчилгээ болгон хэрэгжүүлэхэд техникийн туслалцаа үзүүлсэн хамтран ажиллагсад Сергей Курбанов, Николай Юсев нартаа маш их баярлалаа гэж хэлмээр байна.
зохиогч: - Орлогч Positive Technologies-ийн Технологи ба хөгжлийн үйл явц (DevOps) хэлтсийн дарга
Эх сурвалж: www.habr.com