Çox məhsullu proqram təminatı təchizatçılarının tez-tez qarşılaşdıqları problemlərdən biri demək olar ki, hər bir komandada mühəndislərin - tərtibatçıların, testerlərin və infrastruktur administratorlarının səlahiyyətlərinin təkrarlanmasıdır. Bu, həm də bahalı mühəndislərə - yük testi sahəsində mütəxəssislərə aiddir.
Mühəndislər öz birbaşa vəzifələrini yerinə yetirmək və yük sınaq prosesi qurmaq, metodologiya, optimal ölçülər seçmək və yük profillərinə uyğun avtotestlər yazmaq üçün unikal təcrübələrindən istifadə etmək əvəzinə, tez-tez sınaq infrastrukturunu sıfırdan yerləşdirməli, yükləmə alətlərini konfiqurasiya etməli və onları daxil etməli olurlar. özlərini CI sistemlərində, monitorinqi və hesabatların dərcini qururlar.
Positive Technologies-də istifadə etdiyimiz testlərdə bəzi təşkilati problemlərin həllini tapa bilərsiniz . Və bu məqalədə mən "bir xidmət kimi yük testi" (bir xidmət kimi yük testi) anlayışından istifadə edərək yük testlərini ümumi CI boru kəmərinə inteqrasiya etmək imkanından danışacağam. Siz CI boru kəmərində yükləmə mənbələrinin necə və hansı docker şəkillərinin istifadə oluna biləcəyini öyrənəcəksiniz; quraşdırma şablonundan istifadə edərək yükləmə mənbələrini CI layihənizə necə qoşmaq olar; demo boru kəmərinin yük testlərini həyata keçirmək və nəticələri dərc etmək üçün necə göründüyü. Məqalə, yük sisteminin arxitekturasını düşünən CI-də proqram təminatı testi mühəndisləri və avtomatlaşdırma mühəndisləri üçün faydalı ola bilər.
Konsepsiyanın mahiyyəti
Bir xidmət kimi yük testi konsepsiyası yük alətləri Apache JMeter, Yandex.Tank və öz çərçivələrinizi ixtiyari davamlı inteqrasiya sisteminə inteqrasiya etmək qabiliyyətini nəzərdə tutur. Demo GitLab CI üçün olacaq, lakin prinsiplər bütün CI sistemləri üçün ümumidir.
Xidmət kimi yük sınağı yük sınağı üçün mərkəzləşdirilmiş xidmətdir. Yük testləri xüsusi agent hovuzlarında aparılır, nəticələr avtomatik olaraq GitLab Səhifələrində, Influx DB və Grafana-da və ya test hesabat sistemlərində (TestRail, ReportPortal və s.) dərc olunur. Avtomatlaşdırma və miqyaslama mümkün qədər sadə şəkildə həyata keçirilir - GitLab CI layihəsində adi gitlab-ci.yml şablonunu əlavə etmək və parametrləşdirməklə.
Bu yanaşmanın üstünlüyü ondan ibarətdir ki, bütün CI infrastrukturu, yük agentləri, yük mənbələrinin docker şəkilləri, sınaq boru kəmərləri və hesabat nəşri mərkəzləşdirilmiş avtomatlaşdırma şöbəsi (DevOps mühəndisləri) tərəfindən saxlanılır və yük testi mühəndisləri səylərini testlərin hazırlanmasına və infrastruktur məsələləri ilə məşğul olmadan onların nəticələrinin təhlili.
Təsvirin sadəliyi üçün biz güman edəcəyik ki, sınaqdan keçirilən hədəf proqram və ya server əvvəlcədən yerləşdirilib və konfiqurasiya edilib (bunun üçün Python, SaltStack, Ansible və s. avtomatlaşdırılmış skriptlərdən istifadə etmək olar). Sonra bir xidmət kimi yük testinin bütün konsepsiyası üç mərhələyə uyğundur: hesabatların hazırlanması, sınaqdan keçirilməsi, nəşri. Diaqram haqqında daha ətraflı məlumat (bütün şəkillər tıklanabilir):
Yük testində əsas anlayışlar və təriflər
Yük testlərini apararkən, riayət etməyə çalışırıq , müvafiq terminologiyadan və tövsiyə olunan ölçülərdən istifadə edin. Yük testində əsas anlayışların və təriflərin qısa siyahısını verəcəyəm.
Yük agenti - proqramın işə salınacağı virtual maşın - yükləmə mənbəyi (Apache JMeter, Yandex.Tank və ya öz-özünə yazılmış yük modulu).
Test məqsədi (hədəf) - yüklənməyə məruz qalacaq serverdə quraşdırılmış server və ya proqram.
Test ssenarisi (test işi) - parametrləşdirilmiş addımlar toplusu: müəyyən edilmiş parametrlərdən asılı olaraq sabit şəbəkə sorğuları və cavabları ilə istifadəçi hərəkətləri və bu hərəkətlərə gözlənilən reaksiyalar.
Profil və ya yükləmə planı (profil) - in (Bölmə 4.2.4, s. 43) yük profilləri müəyyən test üçün kritik olan ölçüləri və sınaq zamanı yük parametrlərinin dəyişdirilməsi variantlarını müəyyən edir. Şəkildə profil nümunələrinə baxa bilərsiniz.
Test — əvvəlcədən müəyyən edilmiş parametrlər dəsti olan skript.
Test planı (test planı) - bir sıra testlər və yük profili.
Testran (sınaq) - tam icra edilmiş yükləmə ssenarisi və alınan hesabat ilə bir testin icrasının bir iterasiyası.
Şəbəkə sorğusu (sorğu) — Agentdən hədəfə göndərilən HTTP sorğusu.
Şəbəkə cavabı (cavab) — Hədəfdən agentə göndərilən HTTP cavabı.
HTTP cavab kodu (HTTP cavab statusu) - proqram serverindən standart cavab kodu.
Əməliyyat tam sorğu-cavab dövrüdür. Əməliyyat sorğunun (sorğunun) göndərilməsinin başlanmasından cavabın (cavabın) alınmasının başa çatmasına qədər sayılır.
Əməliyyat statusu - sorğu-cavab dövrünü uğurla başa çatdırmaq mümkün olub-olmaması. Bu dövrədə hər hansı bir səhv olarsa, bütün əməliyyat uğursuz sayılır.
Cavab müddəti (gecikmə) - sorğunun (sorğunun) göndərilməsinin başa çatmasından cavabın (cavabın) alınmasına qədər olan vaxt.
Metrikləri yükləyin — yüklənmiş xidmətin və yükün yoxlanılması prosesində müəyyən edilmiş yük agentinin xüsusiyyətləri.
Yük parametrlərinin ölçülməsi üçün əsas ölçülər
Metodologiyada ən çox istifadə edilən və tövsiyə olunanlardan bəziləri (səh. 36, 52) göstəricilər aşağıdakı cədvəldə göstərilmişdir. Agent və hədəf üçün oxşar göstəricilər eyni sətirdə verilmişdir.
Yük agenti üçün ölçülər
Yük altında sınaqdan keçirilən hədəf sistem və ya tətbiqin göstəriciləri
Nömrə vCPU və yaddaş RAM,
Disk - yük agentinin "dəmir" xüsusiyyətləri
CPU, Yaddaş, Disk istifadəsi - CPU, yaddaş və disk yüklənməsinin dinamikası
sınaq prosesində. Adətən faizlə ölçülür
maksimum mövcud dəyərlər
şəbəkə ötürmə qabiliyyəti (yük agentində) - ötürmə qabiliyyəti
serverdə şəbəkə interfeysi,
yük agentinin quraşdırıldığı yer.
Adətən saniyədə baytla ölçülür (bps)
şəbəkə ötürmə qabiliyyəti(hədəf üzrə) - şəbəkə interfeysinin bant genişliyi
hədəf serverdə. Adətən saniyədə baytla ölçülür (bps)
Virtual istifadəçilər- virtual istifadəçilərin sayı,
yük ssenarilərinin həyata keçirilməsi və
real istifadəçi hərəkətlərini təqlid etmək
Virtual istifadəçilər statusu, Keçildi/Uğursuz/Cəmi — uğurluların sayı və
virtual istifadəçilərin uğursuz statusları
yük ssenariləri, eləcə də onların ümumi sayı üçün.
Ümumiyyətlə bütün istifadəçilərin tamamlaya bildiyi gözlənilir
yük profilində göstərilən bütün tapşırıqlarınız.
Hər hansı bir səhv real istifadəçinin edə bilməyəcəyi anlamına gələcək
sistemlə işləyərkən probleminizi həll edin
Saniyədə sorğular (dəqiqə)- saniyədə (və ya dəqiqədə) şəbəkə sorğularının sayı.
Yük agentinin mühüm xüsusiyyəti onun nə qədər sorğu yarada bilməsidir.
Əslində, bu, virtual istifadəçilər tərəfindən tətbiqə girişin imitasiyasıdır
Saniyədə cavablar (dəqiqə)
- saniyədə (və ya dəqiqədə) şəbəkə cavablarının sayı.
Hədəf xidmətinin mühüm xarakteristikası: nə qədər
ilə sorğulara cavablar yaradın və göndərin
yükləmə agenti
HTTP cavab statusu— müxtəlif cavab kodlarının sayı
yükləmə agenti tərəfindən qəbul edilən proqram serverindən.
Məsələn, 200 OK uğurlu zəng deməkdir,
və 404 - resursun tapılmaması
gizlilik (cavab vaxtı) - sondan vaxt
cavab (cavab) almağa başlamazdan əvvəl sorğu (sorğu) göndərilməsi.
Adətən millisaniyələrlə (ms) ölçülür
Əməliyyatın cavab müddəti- bir tam əməliyyatın vaxtı,
sorğu-cavab dövrünün tamamlanması.
Bu, sorğunun (sorğunun) göndərilməsinin başlandığı vaxtdır
cavabın (cavabın) alınması başa çatana qədər.
Əməliyyat müddəti saniyələrlə (və ya dəqiqələrlə) ölçülə bilər
bir neçə yolla: minimumu nəzərdən keçirin,
maksimum, orta və məsələn, 90-cı faiz.
Minimum və maksimum oxunuşlar həddindən artıqdır
sistemin performans vəziyyəti.
Doxsanıncı faiz ən çox istifadə ediləndir,
istifadəçilərin əksəriyyətini göstərdiyi kimi,
sistem performansının astanasında rahat işləmək
Saniyədə əməliyyatlar (dəqiqə) - tam sayı
saniyədə əməliyyatlar (dəqiqə),
yəni ərizə nə qədər qəbul edə bildi və
sorğuları emal edir və cavablar verir.
Əslində bu sistemin ötürmə qabiliyyətidir
Əməliyyat statusu , Keçdi / Uğursuz / Ümumi - sayı
uğurlu, uğursuz və əməliyyatların ümumi sayı.
Uğursuz real istifadəçilər üçün
əməliyyat əslində demək olacaq
yük altında sistemlə işləyə bilməməsi
Yük Sınaqının Sxematik Diaqramı
Yük testi konsepsiyası çox sadədir və artıq qeyd etdiyim üç əsas mərhələdən ibarətdir: Hazırla-Sınaq-Hesabat, yəni test məqsədlərini hazırlamaq və yükləmə mənbələri üçün parametrləri təyin etmək, sonra yük testlərini yerinə yetirmək və sonunda sınaq hesabatını yaratmaq və dərc etmək.
Sxematik qeydlər:
- QA.Tester yük testi üzrə mütəxəssisdir,
- Hədəf yük altında davranışını bilmək istədiyiniz hədəf proqramdır.
Diaqramda obyektlərin, mərhələlərin və addımların təsnifatı
Mərhələlər və addımlar
Nə baş verir
Girişdə nə var
Çıxış nədir
Hazırlayın: sınaq üçün hazırlıq mərhələsi
LoadParameters
Quraşdırma və işə salma
istifadəçi
yük parametrləri,
ölçülərin seçimi və
sınaq planının hazırlanması
(yük profili)
üçün fərdi seçimlər
yük agentinin işə salınması
Test planı
Testin məqsədi
VM
Bulud yerləşdirilməsi
ilə virtual maşın
tələb olunan xüsusiyyətlər
Yük agenti üçün VM parametrləri
Üçün avtomatlaşdırma skriptləri
VM yaradılması
VM konfiqurasiya edilmişdir
bulud
Sv
ƏS-nin qurulması və hazırlanması
üçün mühit
yük agenti işi
Üçün ətraf mühit parametrləri
yük agenti
Üçün avtomatlaşdırma skriptləri
mühit parametrləri
Hazırlanmış mühit:
ƏS, xidmətlər və tətbiqlər,
iş üçün lazımdır
yük agenti
LoadAgents
Quraşdırma, konfiqurasiya və parametrləşdirmə
yükləmə agenti.
Və ya docker şəklini yükləyin
əvvəlcədən konfiqurasiya edilmiş yük mənbəyi
Mənbə docker şəklini yükləyin
(YAT, JM və ya öz-özünə yazılmış çərçivə)
Parametrlər
yük agenti
Quraşdırın və hazırdır
iş yükü agentinə
Test: yük testlərinin icra mərhələsi. Mənbələr GitLab CI üçün xüsusi agent hovuzlarında yerləşdirilən yük agentləridir
Yük
Yükləmə agentinin işə salınması
seçilmiş sınaq planı ilə
və yükləmə parametrləri
İstifadəçi Seçimləri
başlatma üçün
yük agenti
Test planı
Testin məqsədi
İcra qeydləri
yük testləri
Sistem qeydləri
Məqsəd ölçülərindəki dəyişikliklərin dinamikası və yük agenti
Agentləri işə salın
Agentin icrası
çoxlu test skriptləri
uyğun olaraq
yük profili
Agentin qarşılıqlı əlaqəsini yükləyin
sınaq məqsədi ilə
Test planı
Testin məqsədi
Qeydlər
"Xam" logların toplanması
yük testi zamanı:
yük agenti fəaliyyət qeydləri,
test hədəfinin vəziyyəti
və agenti idarə edən VM
İcra qeydləri
yük testləri
Sistem qeydləri
Metrik
Test zamanı "xam" ölçülərin toplanması
Məqsəd ölçülərində dəyişikliklərin dinamikası
və yük agenti
Hesabat: sınaq hesabatının hazırlanması mərhələsi
Generator
Emal toplandı
yükləmə sistemi və
monitorinq sistemi "xam"
ölçülər və qeydlər
Hesabatın formalaşdırılması
insanın oxuna biləcəyi forma
elementləri ilə mümkündür
analitiklər
İcra qeydləri
yük testləri
Sistem qeydləri
Metriklərdəki dəyişikliklərin dinamikası
hədəf və yük agenti
İşlənmiş "xam" loglar
uyğun formatda
xarici yaddaşa yükləmələr
Statik yük hesabatı,
insan tərəfindən oxuna bilən
Dərc etmək
Hesabatın dərci
yük haqqında
xarici test
xidmət
İşlənmiş "xam"
uyğun formatda qeydlər
xaricə boşaltmaq üçün
depolar
Xarici olaraq saxlandı
saxlama hesabatları
yük, uyğun
insan analizi üçün
CI Şablonunda Yük Mənbələrinin Birləşdirilməsi
Gəlin praktik hissəyə keçək. Mən şirkətdəki bəzi layihələrdə necə olduğunu göstərmək istəyirəm biz bir xidmət olaraq yük testi konsepsiyasını tətbiq etdik.
Birincisi, DevOps mühəndislərimizin köməyi ilə yük testlərini həyata keçirmək üçün GitLab CI-də xüsusi agentlər hovuzu yaratdıq. Şablonlarda onları başqaları ilə, məsələn, montaj hovuzları ilə qarışdırmamaq üçün bu agentlərə etiketlər əlavə etdik, : yük. Siz hər hansı digər başa düşülən etiketlərdən istifadə edə bilərsiniz. Soruşurlar GitLab CI Runners.
Tələb olunan gücü avadanlıqla necə tapmaq olar? Yük agentlərinin xüsusiyyətləri - kifayət qədər sayda vCPU, RAM və Disk - agentdə Docker, Python (Yandex.Tank üçün), GitLab CI agenti, Java (Apache JMeter üçün) işləməli olduğuna əsaslanaraq hesablana bilər. . JMeter altında Java üçün minimum 512 MB RAM və yuxarı hədd kimi istifadə etmək tövsiyə olunur. .
Beləliklə, təcrübəmizə əsaslanaraq, yük agentləri üçün ən azı 4 vCPU, 4 GB RAM, 60 GB SSD istifadə etməyi tövsiyə edirik. Şəbəkə kartının ötürmə qabiliyyəti yük profilinin tələblərinə əsasən müəyyən edilir.
Biz əsasən iki yükləmə mənbəyindən istifadə edirik - Apache JMeter və Yandex.Tank docker şəkilləri.
yük testi üçün Yandex-dən açıq mənbə alətidir. Onun modul arxitekturası Phantom-un yüksək performanslı asinxron hit-əsaslı HTTP sorğu generatoruna əsaslanır. Tank SSH protokolu vasitəsilə sınaqdan keçirilən serverin resurslarının daxili monitorinqinə malikdir, müəyyən edilmiş şərtlərdə testi avtomatik dayandıra bilər, nəticələri həm konsolda, həm də qrafiklər şəklində göstərə bilər, modullarınızı birləşdirə bilərsiniz. funksionallığı genişləndirmək üçün ona. Yeri gəlmişkən, biz Tankdan hələ əsas olmayan dövrlərdə istifadə etdik. Məqalədə "» 2013-cü ildə onunla yük testini necə həyata keçirdiyimizin hekayəsini oxuya bilərsiniz şirkətimizin məhsullarından biridir.
Apache-dən açıq mənbə yük testi vasitəsidir. Həm statik, həm də dinamik veb proqramlarını sınamaq üçün eyni dərəcədə yaxşı istifadə edilə bilər. JMeter çox sayda protokolları və tətbiqlərlə qarşılıqlı əlaqə yollarını dəstəkləyir: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET və s.), SOAP / REST Veb Xidmətləri, FTP, TCP, LDAP, SMTP(S), POP3( S) ) və IMAP(S), JDBC vasitəsilə verilənlər bazaları qabıq əmrlərini yerinə yetirə və Java obyektləri ilə işləyə bilər. JMeter test planlarının yaradılması, sazlanması və icrası üçün IDE-yə malikdir. İstənilən Java uyğun əməliyyat sistemində (Linux, Windows, Mac OS X) komanda xətti ilə işləmək üçün CLI də mövcuddur. Alət dinamik olaraq HTML test hesabatını yarada bilər.
Şirkətimizdə istifadənin asanlığı, test edənlərin özlərinin ətraf mühiti dəyişdirmək və əlavə etmək qabiliyyəti üçün GitLab CI-də yükləmə mənbələrinin docker şəkillərini daxili nəşrdə dərc etdik. . Bu, yük sınaqları üçün onları boru kəmərlərində birləşdirməyi daha sürətli və asanlaşdırır. GitLab CI vasitəsilə reyestrə docker push-u necə etmək olar - baxın .
Yandex.Tank üçün bu əsas docker faylını götürdük:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]Və Apache JMeter üçün bu:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Davamlı inteqrasiya sistemimizin necə işlədiyini məqalədə oxuya bilərsiniz ".
Şablon və boru kəməri
Layihədə yük testlərinin aparılması üçün şablon nümunəsi mövcuddur . Ilə Şablonu istifadə etmək üçün təlimatları oxuya bilərsiniz. Şablonun özündə (fayl ) hər bir addımın nədən məsul olduğu barədə qeydlər var.
Şablon çox sadədir və yuxarıdakı diaqramda təsvir edilən yük testinin üç mərhələsini nümayiş etdirir: hesabatların hazırlanması, sınaqdan keçirilməsi və dərc edilməsi. Bunun üçün cavabdehdir : Hazırlayın, sınaqdan keçirin və hesabat verin.
- Mərhələ test hədəflərini əvvəlcədən konfiqurasiya etmək və ya onların mövcudluğunu yoxlamaq üçün istifadə edilməlidir. Yük mənbələri üçün mühitin konfiqurasiya edilməsinə ehtiyac yoxdur, onlar docker şəkilləri kimi əvvəlcədən qurulur və docker reyestrində yerləşdirilir: sadəcə Test mərhələsində istədiyiniz versiyanı göstərin. Lakin siz onları yenidən qura və öz dəyişdirilmiş şəkillərinizi yarada bilərsiniz.
- Mərhələ yük mənbəyini müəyyən etmək, testləri həyata keçirmək və sınaq artefaktlarını saxlamaq üçün istifadə olunur. İstənilən yükləmə mənbəyini seçə bilərsiniz: Yandex.Tank, Apache JMeter, özünüz və ya hamısı birlikdə. Lazımsız mənbələri deaktiv etmək üçün sadəcə şərh bildirin və ya işi silin. Yük mənbələri üçün giriş nöqtələri:
- Yandex.Tank üçün işəsalma parametrləri .,
- Apache JMeter başlanğıc parametrləri faylda göstərilmişdir .
Qeyd: Montaj konfiqurasiya şablonu CI sistemi ilə qarşılıqlı əlaqə qurmaq üçün istifadə olunur və orada test məntiqinin yerləşdirilməsini nəzərdə tutmur. Testlər üçün nəzarət bash skriptinin yerləşdiyi giriş nöqtəsi müəyyən edilir. Testlərin aparılması, hesabatların yaradılması və sınaq skriptlərinin özləri QA mühəndisləri tərəfindən həyata keçirilməlidir. Demoda, hər iki yükləmə mənbəyi üçün Yandex əsas səhifə sorğusu ən sadə test kimi istifadə olunur. Skriptlər və test parametrləri kataloqdadır .
- Səhnədə Test mərhələsində əldə edilmiş test nəticələrini xarici yaddaşlarda, məsələn, GitLab Səhifələrində və ya xüsusi hesabat sistemlərində necə dərc edəcəyinizi təsvir etməlisiniz. GitLab Səhifələri ./public qovluğunun boş olmamasını və sınaqlar bitdikdən sonra ən azı index.html faylını ehtiva etməsini tələb edir. GitLab Pages xidmətinin nüansları haqqında oxuya bilərsiniz. .
Məlumatların ixracına dair nümunələr:
- JMeter-dən ,
- Yandex.Tank-dan .
Quraşdırma təlimatlarının göndərilməsi:
- HTML statikası ,
- InfluxDB-yə və sonra .
Demo nümunəsində, yük testləri və iki yükləmə mənbəyi olan boru kəməri (lazımsız olanı söndürə bilərsiniz) belə görünür:
Apache JMeter HTML hesabatını özü yarada bilər, ona görə də standart alətlərdən istifadə edərək onu GitLab Səhifələrində saxlamaq daha sərfəlidir. Apache JMeter hesabatı belə görünür:
Yandex.Tank üçün demo nümunəsində yalnız görəcəksiniz GitLab Səhifələri bölməsində. Test zamanı Tank nəticələri InfluxDB verilənlər bazasında saxlaya bilər və oradan, məsələn, Grafana-da göstərilə bilər (konfiqurasiya faylda aparılır) ). Tankın hesabatı Grafanada belə görünür:
Xülasə
Məqalədə mən "servis olaraq yük testi" (servis olaraq yük testi) anlayışı haqqında danışdım. Əsas ideya əvvəlcədən konfiqurasiya edilmiş yük agentləri hovuzlarının infrastrukturundan, yük mənbələrinin docker şəkillərindən, hesabat sistemlərindən və onları sadə .gitlab-ci.yml şablonuna (nümunə) əsaslanan GitLab CI-də birləşdirən boru kəmərindən istifadə etməkdir. ). Bütün bunlar avtomatlaşdırma mühəndislərindən ibarət kiçik bir komanda tərəfindən dəstəklənir və məhsul qruplarının tələbi ilə təkrarlanır. Ümid edirəm ki, bu, şirkətinizdə oxşar sxemin hazırlanmasında və həyata keçirilməsində sizə kömək edəcək. Diqqətiniz üçün təşəkkürlər!
P.S. Mən həmkarlarım Sergey Kurbanov və Nikolay Yusevə şirkətimizdə bir xidmət kimi yüklərin sınaqdan keçirilməsi konsepsiyasının həyata keçirilməsində texniki yardıma görə böyük təşəkkür etmək istəyirəm.
Müəllif: - Müavin Positive Technologies-də Texnologiya və İnkişaf Proseslərinin (DevOps) rəhbəri
Mənbə: www.habr.com