Salah sawijining masalah sing asring dialami vendor piranti lunak multi-produk yaiku duplikasi kompetensi insinyur - pangembang, penguji, lan administrator infrastruktur - ing meh kabeh tim. Iki uga ditrapake kanggo insinyur larang - spesialis ing bidang tes beban.
Tinimbang nindakake tugas langsung lan nggunakake pengalaman unik kanggo mbangun proses testing beban, milih metodologi, metrik optimal lan nulis autotests sesuai karo profil beban, insinyur asring kudu masang prasarana test saka ngeruk, ngatur piranti mbukak, lan embed. dhewe ing sistem CI, nyetel ngawasi lan publikasi laporan.
Sampeyan bisa nemokake solusi kanggo sawetara masalah organisasi ing testing sing digunakake ing Positive Technologies ing . Lan ing siji iki, aku bakal ngomong babagan kemungkinan nggabungake tes beban menyang pipa CI umum kanthi nggunakake konsep "ujian beban minangka layanan" (ujian beban minangka layanan). Sampeyan bakal sinau carane lan gambar docker sumber beban bisa digunakake ing pipa CI; carane nyambungake sumber mbukak kanggo proyek CI nggunakake Cithakan mbangun; apa pipeline demo katon kanggo mbukak tes mbukak lan nerbitaké asil. Artikel kasebut bisa uga migunani kanggo insinyur uji coba piranti lunak lan insinyur otomatisasi ing CI sing mikir babagan arsitektur sistem beban.
Inti saka konsep
Konsep tes beban minangka layanan nuduhake kemampuan kanggo nggabungake alat beban Apache JMeter, Yandex.Tank lan kerangka sampeyan dhewe menyang sistem integrasi terus-terusan sing sewenang-wenang. Demo bakal kanggo GitLab CI, nanging prinsip umum kanggo kabeh sistem CI.
Pengujian beban minangka layanan minangka layanan terpusat kanggo pengujian beban. Tes beban ditindakake ing blumbang agen khusus, asil diterbitake kanthi otomatis ing GitLab Pages, Influx DB lan Grafana utawa ing sistem pelaporan tes (TestRail, ReportPortal, lsp.). Otomatisasi lan skala dileksanakake kanthi gampang - kanthi nambah lan nyetel parameter cithakan gitlab-ci.yml biasa ing proyek GitLab CI.
Kauntungan saka pendekatan iki yaiku kabeh infrastruktur CI, agen muatan, gambar docker saka sumber beban, saluran pipa tes, lan laporan penerbitan dikelola dening departemen otomatisasi terpusat (insinyur DevOps), dene insinyur tes beban bisa fokus upaya ing pangembangan tes. lan analisis asile, tanpa ngatasi masalah infrastruktur.
Kanggo gamblang gambaran, kita bakal nganggep yen aplikasi target utawa server ing test wis disebarake lan diatur ing advance (skrip otomatis ing Python, SaltStack, Ansible, etc. bisa digunakake kanggo iki). Banjur kabeh konsep tes beban minangka layanan cocog dadi telung tahap: preparation, testing, publikasi saka laporan. Rincian liyane babagan diagram (kabeh gambar bisa diklik):
Konsep dhasar lan definisi ing testing beban
Nalika nindakake tes beban, kita nyoba manut , gunakake terminologi sing cocog lan metrik sing disaranake. Aku bakal menehi dhaptar singkat konsep lan definisi utama ing testing mbukak.
Agen muatan - mesin virtual ing ngendi aplikasi bakal diluncurake - sumber beban (Apache JMeter, Yandex.Tank utawa modul beban sing ditulis dhewe).
Tujuan tes (target) - server utawa aplikasi diinstal ing server sing bakal tundhuk mbukak.
Skenario tes (test case) - sakumpulan langkah paramèter: tumindak pangguna lan reaksi sing dikarepake kanggo tumindak kasebut, kanthi panjalukan lan respon jaringan tetep, gumantung saka paramèter sing ditemtokake.
Profil utawa rencana muatan (profil) - ing (Bagian 4.2.4, p. 43) mbukak profil nemtokake metrik sing kritis kanggo test tartamtu lan opsi kanggo ngganti paramèter mbukak sak test. Sampeyan bisa ndeleng conto profil ing tokoh.
Tes - skrip kanthi paramèter sing wis ditemtokake.
Rencana tes (test-plan) - set tes lan profil beban.
Testran (testrun) - siji pengulangan kanggo mbukak siji test karo skenario mbukak kebak kaleksanan lan laporan ditampa.
Panjaluk jaringan (panyuwunan) - Panjaluk HTTP sing dikirim saka agen menyang target.
Tanggapan jaringan (respon) - Tanggepan HTTP sing dikirim saka target menyang agen.
Kode respon HTTP (status respon HTTP) - kode respon standar saka server aplikasi.
Transaksi minangka siklus panjalukan-respon lengkap. Transaksi diitung saka wiwitan ngirim panjalukan (request) nganti rampung nampa respon (respon).
Status transaksi - apa iku bisa kanggo kasil ngrampungake siklus request-respon. Yen ana kesalahan ing siklus iki, kabeh transaksi dianggep ora kasil.
Wektu Respon (Latensi) - wektu saka pungkasan ngirim panjaluk (panjaluk) nganti wiwitan nampa wangsulan (respon).
Metrik muatan - karakteristik layanan sing dimuat lan agen beban sing ditemtokake ing proses tes beban.
Metrik dhasar kanggo ngukur paramèter beban
Sawetara sing paling umum digunakake lan dianjurake ing metodologi (kaca 36, 52) metrik kasebut ditampilake ing tabel ing ngisor iki. Metrik sing padha kanggo agen lan target didaftar ing baris sing padha.
Metrik kanggo agen beban
Metrik sistem target utawa aplikasi sing diuji ing beban
Jumlah vCPU lan memori Ram,
disk - karakteristik "wesi" saka agen beban
CPU, Memori, panggunaan disk - dinamika CPU, memori lan loading disk
ing proses testing. Biasane diukur minangka persentasi saka
nilai maksimum kasedhiya
throughput jaringan (ing agen beban) - throughput
antarmuka jaringan ing server,
ngendi agen mbukak diinstal.
Biasane diukur ing bita per detik (bps)
throughput jaringan(ing target) - bandwidth antarmuka jaringan
ing server target. Biasane diukur ing bita per detik (bps)
Pangguna virtual- jumlah pangguna virtual,
ngleksanakake skenario mbukak lan
niru tumindak pangguna nyata
Status pangguna virtual, Lulus / Gagal / Total — nomer sukses lan
status pangguna virtual sing ora sukses
kanggo skenario mbukak, uga nomer total.
Umume samesthine kabeh pangguna bisa ngrampungake
kabeh tugas sing ditemtokake ing profil muat.
Sembarang kesalahan tegese pangguna nyata ora bakal bisa
ngatasi masalah nalika nggarap sistem
Panjaluk saben detik (menit)- jumlah panjalukan jaringan per detik (utawa menit).
Karakteristik penting saka agen beban yaiku pirang-pirang panjaluk sing bisa diasilake.
Nyatane, iki minangka imitasi akses menyang aplikasi dening pangguna virtual
Tanggapan saben detik (menit)
- jumlah respon jaringan per detik (utawa menit).
Karakteristik penting saka layanan target: pinten
generate lan ngirim respon kanggo pitakon karo
agen loading
Status respon HTTP- nomer kode respon beda
saka server aplikasi sing ditampa dening agen beban.
Contone, 200 OK tegese telpon sukses,
lan 404 - sing sumber ora ketemu
Latency (wektu respon) - wektu saka mburi
ngirim panyuwunan (panyuwunan) sadurunge miwiti nampa wangsulan (respon).
Biasane diukur ing milliseconds (ms)
Wektu nanggepi transaksi- wektu siji transaksi lengkap,
rampung siklus request-respon.
Iki wektu wiwit ngirim panjalukan (panyuwunan)
nganti tuntas nampa wangsulan (respon).
Wektu transaksi bisa diukur ing detik (utawa menit)
ing sawetara cara: nimbang minimal,
maksimum, rata-rata lan, contone, persentil 90th.
Wacan minimal lan maksimal iku ekstrim
status kinerja sistem.
Persentil sangang puluh minangka sing paling umum digunakake,
minangka nuduhake umume pangguna,
mulyo operasi ing ambang kinerja sistem
Transaksi per detik (menit) - nomer lengkap
transaksi per detik (menit),
iku, carane akeh aplikasi bisa nampa lan
proses panjalukan lan masalah respon.
Nyatane, iki minangka throughput sistem
Status transaksi , Lulus / Gagal / Total - nomer
sukses, ora kasil lan jumlah total transaksi.
Kanggo pangguna nyata ora kasil
transaksi bakal bener tegese
kasekengan kanggo bisa karo sistem ing mbukak
Diagram Skema Pengujian Beban
Konsep tes beban gampang banget lan kalebu telung tahap utama, sing wis dakcritakake: Siapke-Test-Laporan, yaiku, nyiapake gol tes lan nyetel paramèter kanggo sumber muatan, banjur nglakokaké tes beban lan, ing pungkasan, ngasilake lan nerbitake laporan tes.
Cathetan Skema:
- QA. Tester minangka pakar ing pengujian beban,
- Target minangka aplikasi target sing sampeyan pengin ngerti prilaku ing beban.
Klasifikasi entitas, tahapan lan langkah-langkah ing diagram
Tahap lan langkah
Apa kedaden
Apa ing ngleboke
Apa output
Siapke: tahap persiapan kanggo tes
LoadParameters
Setelan lan initialization
pangguna
parameter beban,
pilihan saka metrik lan
persiapan rencana tes
(munggah profil)
opsi Custom kanggo
initialization agen mbukak
Rencana tes
Tujuan saka testing
VM
Penyebaran awan
mesin virtual karo
karakteristik sing dibutuhake
Setelan VM kanggo agen mbukak
Skrip otomatisasi kanggo
nggawe VM
VM dikonfigurasi ing
awan
Ngirim
Persiyapan lan persiapan OS
lingkungan kanggo
karya agen mbukak
Setelan lingkungan kanggo
agen mbukak
Skrip otomatisasi kanggo
setelan lingkungan
Lingkungan sing disiapake:
OS, layanan lan aplikasi,
perlu kanggo karya
agen mbukak
LoadAgents
Instalasi, konfigurasi lan parameterisasi
agen loading.
Utawa ngundhuh gambar docker saka
sumber beban sing wis dikonfigurasi
Muat gambar docker sumber
(YAT, JM utawa kerangka kerja sing ditulis dhewe)
Setelan
agen mbukak
Siapke lan siap
kanggo nggarap agen beban
Tes: tahap eksekusi tes beban. Sumber minangka agen beban sing ditugasake ing kolam agen khusus kanggo GitLab CI
load
Miwiti Agen Load
karo rencana tes sing dipilih
lan paramèter beban
Pilihan pangguna
kanggo initialization
agen mbukak
Rencana tes
Tujuan saka testing
Log eksekusi
tes mbukak
Log sistem
Dinamika owah-owahan ing metrik gol lan agen muatan
Run Agen
Eksekusi Agen
akeh skrip test
jumbuh karo
mbukak profil
Interaksi Agen Muatan
kanggo tujuan testing
Rencana tes
Tujuan saka testing
log
Koleksi log "mentah".
sajrone tes beban:
cathetan aktivitas agen muatan,
status target tes
lan VM mlaku agen
Log eksekusi
tes mbukak
Log sistem
Metrik
Nglumpukake metrik "mentah" sajrone tes
Dinamika owah-owahan ing metrik gol
lan agen mbukak
Laporan: tahap persiapan laporan tes
Generator
Processing diklumpukake
sistem loading lan
sistem monitoring "raw"
metrik lan log
Pembentukan laporan ing
wujud manungsa kang bisa diwaca
bisa karo unsur
analis
Log eksekusi
tes mbukak
Log sistem
Dinamika owah-owahan ing metrik
target lan agen beban
Diproses log "mentah".
ing format cocok kanggo
unggahan menyang panyimpenan eksternal
Laporan beban statis,
bisa diwaca manungsa
nerbitaké
Publikasi laporan
babagan beban
testing ing njaba
layanan
Diproses "mentah"
log ing format cocok
kanggo unloading menyang njaba
repositori
Disimpen ing njaba
laporan panyimpenan ing
muat, cocok
kanggo analisis manungsa
Nyambungake sumber beban ing cithakan CI
Ayo pindhah menyang bagean praktis. Aku pengin nuduhake carane ing sawetara proyèk ing perusahaan kita wis ngetrapake konsep pengujian beban minangka layanan.
Kaping pisanan, kanthi bantuan insinyur DevOps, kita nggawe klompok agen khusus ing GitLab CI kanggo nganakake tes beban. Supaya ora mbingungake wong-wong mau ing cithakan karo wong liya, kayata kumpulan perakitan, kita nambahake tag menyang agen kasebut, : muatan. Sampeyan bisa nggunakake tag liyane sing bisa dingerteni. Padha takon GitLab CI Runners.
Carane ngerteni daya sing dibutuhake dening hardware? Karakteristik agen beban - jumlah vCPU, RAM lan Disk sing cukup - bisa diitung adhedhasar kasunyatan manawa Docker, Python (kanggo Yandex.Tank), agen GitLab CI, Java (kanggo Apache JMeter) kudu mlaku ing agen kasebut. . Kanggo Jawa ing JMeter, dianjurake uga nggunakake minimal 512 MB RAM lan, minangka watesan ndhuwur, .
Dadi, adhedhasar pengalaman, disaranake nggunakake paling ora 4 vCPU, 4 GB RAM, 60 GB SSD kanggo agen muatan. Throughput kertu jaringan ditemtokake adhedhasar syarat profil beban.
Kita utamane nggunakake rong sumber beban - gambar Apache JMeter lan Yandex.Tank docker.
minangka alat open source saka Yandex kanggo testing load. Arsitèktur modular kasebut adhedhasar generator panyuwunan HTTP asynchronous hit-kinerja dhuwur Phantom. Tank kasebut duwe pemantauan sumber daya server sing diuji liwat protokol SSH, kanthi otomatis bisa mungkasi tes ing kahanan sing ditemtokake, bisa nampilake asil ing konsol lan ing bentuk grafik, sampeyan bisa nyambungake modul sampeyan. kanggo iku kanggo nggedhekake fungsi. Miturut cara, kita nggunakake Tank nalika durung mainstream. Ing artikel "»Sampeyan bisa maca crita babagan carane nindakake testing beban ing taun 2013 minangka salah sawijining produk perusahaan kita.
minangka alat testing mbukak sumber saka Apache. Bisa digunakake kanthi apik kanggo nguji aplikasi web statis lan dinamis. JMeter ndhukung pirang-pirang protokol lan cara kanggo sesambungan karo aplikasi: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, lsp.), SOAP / REST Webservices, FTP, TCP, LDAP, SMTP(S), POP3( S) ) lan IMAP(S), basis data liwat JDBC, bisa nglakokake perintah cangkang lan nggarap obyek Jawa. JMeter duwe IDE kanggo nggawe, debugging lan nglakokake rencana uji coba. Ana uga CLI kanggo operasi baris perintah ing sistem operasi sing kompatibel karo Java (Linux, Windows, Mac OS X). Alat kasebut bisa ngasilake laporan tes HTML kanthi dinamis.
Kanggo gampang digunakake ing perusahaan kita, kanggo kemampuan para penguji dhewe kanggo ngganti lan nambah lingkungan, kita nggawe gambar docker saka sumber beban ing GitLab CI kanthi publikasi menyang internal. . Iki nggawe luwih cepet lan luwih gampang kanggo nyambungake ing pipa kanggo tes beban. Kepiye carane docker push menyang pendaptaran liwat GitLab CI - ndeleng .
Kita njupuk file docker dhasar iki kanggo Yandex.Tank:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]Lan kanggo Apache JMeter iki:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Sampeyan bisa maca cara kerja sistem integrasi terus-terusan ing artikel "".
Cithakan lan pipa
Conto cithakan kanggo nganakake tes beban kasedhiya ing proyek kasebut . ing Sampeyan bisa maca pandhuan kanggo nggunakake cithakan. Ing cithakan dhewe (file ) ana cathetan babagan tanggung jawab saben langkah.
Cithakan kasebut prasaja banget lan nduduhake telung tahap pengujian beban sing diterangake ing diagram ing ndhuwur: nyiapake, nguji, lan nerbitake laporan. Tanggung jawab iki : Siapke, Test lan Laporan.
- Stage kudu digunakake kanggo preconfigure target test utawa mriksa kasedhiyan. Lingkungan kanggo sumber beban ora perlu dikonfigurasi, lagi wis dibangun minangka gambar docker lan dikirim ing pendaptaran docker: mung nemtokake versi sing dikarepake ing tahap Test. Nanging sampeyan bisa mbangun maneh lan nggawe gambar sing diowahi dhewe.
- Stage digunakake kanggo nemtokake sumber beban, mbukak tes, lan nyimpen artefak tes. Sampeyan bisa milih sumber beban apa wae: Yandex.Tank, Apache JMeter, dhewe, utawa kabeh bebarengan. Kanggo mateni sumber sing ora perlu, mung menehi komentar utawa mbusak proyek kasebut. Titik entri kanggo sumber muatan:
- Parameter peluncuran kanggo Yandex.Tank ditemtokake ing .,
- Parameter wiwitan Apache JMeter ditemtokake ing file kasebut .
Wigati: Cithakan konfigurasi Déwan digunakake kanggo nyiyapake interaksi karo sistem CI lan ora ateges panggonan seko logika test ing. Kanggo tes, titik entri ditemtokake, ing ngendi skrip bash kontrol dumunung. Cara nglakokake tes, ngasilake laporan, lan skrip tes dhewe kudu ditindakake dening insinyur QA. Ing demo, kanggo loro sumber mbukak, panjalukan kaca utama Yandex digunakake minangka tes paling gampang. Skrip lan paramèter tes ana ing direktori .
- Ing tataran sampeyan kudu njlèntrèhaké carane nerbitaké asil test dijupuk ing tataran Test kanggo panyimpenan external, contone, kanggo GitLab Pages utawa sistem laporan khusus. GitLab Pages mbutuhake direktori ./public ora kosong lan paling ora ngemot file index.html sawise tes rampung. Sampeyan bisa maca babagan nuansa layanan GitLab Pages. .
Conto cara ngekspor data:
- saka JMeter kanggo ,
- saka Yandex.Tank kanggo .
Pandhuan persiyapan kirim:
- HTML statis ing ,
- menyang InfluxDB banjur menyang .
Ing conto demo, pipa kanthi tes beban lan rong sumber beban (sampeyan bisa mateni sing ora perlu) katon kaya iki:
Apache JMeter bisa ngasilake laporan HTML dhewe, saengga luwih nguntungake kanggo nyimpen ing GitLab Pages nggunakake alat standar. Iki kaya laporan Apache JMeter:
Ing conto demo kanggo Yandex.Tank, sampeyan mung bakal weruh ing bagean kanggo GitLab Pages. Sajrone testing, Tank bisa nyimpen asil menyang database InfluxDB, lan saka ing kono bisa ditampilake, contone, ing Grafana (konfigurasi wis rampung ing file. ). Iki minangka laporan Tank ing Grafana:
Ringkesan
Ing artikel kasebut, aku ngomong babagan konsep "ujian beban minangka layanan" (ujian beban minangka layanan). Ide utama yaiku nggunakake infrastruktur blumbang agen beban sing wis dikonfigurasi, gambar docker sumber beban, sistem laporan lan pipa sing nggabungake ing GitLab CI adhedhasar cithakan .gitlab-ci.yml sing prasaja (contone ). Kabeh iki didhukung dening tim insinyur otomatisasi cilik lan ditiru kanthi panyuwunan tim produk. Muga-muga iki bakal mbantu sampeyan nyiapake lan ngetrapake skema sing padha ing perusahaan sampeyan. Matur nuwun kanggo manungsa waé!
PS Aku pengin ngucapake matur nuwun marang kanca-kancaku, Sergey Kurbanov lan Nikolai Yusev, kanggo bantuan teknis karo implementasi konsep testing beban minangka layanan ing perusahaan kita.
penulis: - Wakil Kepala Teknologi lan Proses Pangembangan (DevOps) ing Positive Technologies
Source: www.habr.com