Salah satu masalah yang sering dihadapi oleh vendor perisian berbilang produk ialah pertindihan kecekapan jurutera - pembangun, penguji dan pentadbir infrastruktur - pada hampir setiap pasukan. Ini juga terpakai kepada jurutera mahal - pakar dalam bidang ujian beban.
Daripada melakukan tugas langsung mereka dan menggunakan pengalaman unik mereka untuk membina proses ujian beban, pilih metodologi, metrik optimum dan tulis autotest mengikut profil beban, jurutera selalunya perlu menggunakan infrastruktur ujian dari awal, mengkonfigurasi alatan beban dan membenamkannya. sendiri dalam sistem CI, menyediakan pemantauan dan penerbitan laporan.
Anda boleh mencari penyelesaian kepada beberapa masalah organisasi dalam ujian yang kami gunakan di Positive Technologies dalam . Dan dalam yang ini, saya akan bercakap tentang kemungkinan menyepadukan ujian beban ke dalam saluran paip CI biasa menggunakan konsep "ujian beban sebagai perkhidmatan" (ujian beban sebagai perkhidmatan). Anda akan mempelajari cara dan imej docker sumber beban yang boleh digunakan dalam saluran paip CI; cara menyambung sumber beban ke projek CI anda menggunakan templat binaan; rupa saluran paip demo untuk menjalankan ujian beban dan menerbitkan hasilnya. Artikel ini mungkin berguna untuk jurutera ujian perisian dan jurutera automasi dalam CI yang memikirkan seni bina sistem beban mereka.
Intipati konsep
Konsep ujian beban sebagai perkhidmatan membayangkan keupayaan untuk menyepadukan alat beban Apache JMeter, Yandex.Tank dan rangka kerja anda sendiri ke dalam sistem penyepaduan berterusan sewenang-wenangnya. Demo adalah untuk GitLab CI, tetapi prinsipnya adalah biasa untuk semua sistem CI.
Ujian beban sebagai perkhidmatan ialah perkhidmatan berpusat untuk ujian beban. Ujian beban dijalankan dalam kumpulan ejen khusus, hasilnya diterbitkan secara automatik dalam Halaman GitLab, Influx DB dan Grafana atau dalam sistem pelaporan ujian (TestRail, ReportPortal, dll.). Automasi dan penskalaan dilaksanakan semudah yang mungkin - dengan menambah dan membuat parameter templat gitlab-ci.yml biasa dalam projek GitLab CI.
Kelebihan pendekatan ini ialah keseluruhan infrastruktur CI, agen beban, imej docker sumber beban, saluran paip ujian dan laporan penerbitan diselenggara oleh jabatan automasi berpusat (jurutera DevOps), manakala jurutera ujian beban boleh menumpukan usaha mereka pada pembangunan ujian dan analisis keputusan mereka, tanpa berurusan dengan isu infrastruktur.
Untuk kesederhanaan penerangan, kami akan menganggap bahawa aplikasi sasaran atau pelayan yang sedang diuji telah digunakan dan dikonfigurasikan lebih awal (skrip automatik dalam Python, SaltStack, Ansible, dll. boleh digunakan untuk ini). Kemudian keseluruhan konsep ujian beban sebagai perkhidmatan sesuai dengan tiga peringkat: penyediaan, ujian, penerbitan laporan. Butiran lanjut mengenai rajah (semua gambar boleh diklik):
Konsep dan definisi asas dalam ujian beban
Semasa menjalankan ujian beban, kami cuba mematuhi , gunakan istilah yang sesuai dan metrik yang disyorkan. Saya akan memberikan senarai pendek konsep dan definisi utama dalam ujian beban.
Muatkan agen - mesin maya di mana aplikasi akan dilancarkan - sumber beban (Apache JMeter, Yandex.Tank atau modul beban tulisan sendiri).
Matlamat ujian (sasaran) - pelayan atau aplikasi dipasang pada pelayan yang akan dikenakan beban.
Senario ujian (kes ujian) - satu set langkah berparameter: tindakan pengguna dan tindak balas yang dijangkakan terhadap tindakan ini, dengan permintaan dan tindak balas rangkaian tetap, bergantung pada parameter yang ditentukan.
Profil atau muatkan pelan (profil) - pada (Bahagian 4.2.4, ms. 43) profil beban mentakrifkan metrik yang penting untuk ujian tertentu dan pilihan untuk menukar parameter beban semasa ujian. Anda boleh melihat contoh profil dalam rajah.
Ujian β skrip dengan set parameter yang telah ditetapkan.
Pelan ujian (pelan ujian) - satu set ujian dan profil beban.
Testran (testrun) - satu lelaran menjalankan satu ujian dengan senario beban yang dilaksanakan sepenuhnya dan laporan yang diterima.
Permintaan rangkaian (permintaan) β Permintaan HTTP yang dihantar daripada ejen kepada sasaran.
Sambutan rangkaian (tindak balas) β Sambutan HTTP dihantar daripada sasaran kepada ejen.
Kod respons HTTP (status respons HTTP) - kod respons standard daripada pelayan aplikasi.
Transaksi ialah kitaran permintaan-tindak balas yang lengkap. Transaksi dikira dari mula menghantar permintaan (permintaan) hingga selesai menerima respons (respon).
Status urus niaga - sama ada mungkin untuk melengkapkan kitaran permintaan-tindak balas dengan jayanya. Jika terdapat sebarang ralat dalam kitaran ini, maka keseluruhan transaksi dianggap tidak berjaya.
Masa tindak balas (latensi) - masa dari akhir menghantar permintaan (permintaan) hingga permulaan menerima respons (respon).
Muatkan metrik β ciri-ciri perkhidmatan yang dimuatkan dan agen beban yang ditentukan dalam proses ujian beban.
Metrik asas untuk mengukur parameter beban
Antara yang paling biasa digunakan dan disyorkan dalam metodologi (ms 36, 52) metrik ditunjukkan dalam jadual di bawah. Metrik serupa untuk ejen dan sasaran disenaraikan pada baris yang sama.
Metrik untuk ejen beban
Metrik sistem sasaran atau aplikasi yang sedang diuji di bawah beban
Bilangan vCPU dan ingatan RAM,
Cakera - ciri "besi" agen beban
CPU, Memori, Penggunaan cakera - dinamik CPU, memori dan pemuatan cakera
dalam proses ujian. Biasanya diukur sebagai peratusan daripada
nilai maksimum yang tersedia
throughput rangkaian (pada ejen beban) - throughput
antara muka rangkaian pada pelayan,
tempat ejen beban dipasang.
Biasanya diukur dalam bait sesaat (bps)
throughput rangkaian(pada sasaran) - lebar jalur antara muka rangkaian
pada pelayan sasaran. Biasanya diukur dalam bait sesaat (bps)
Pengguna maya- bilangan pengguna maya,
melaksanakan senario beban dan
meniru tindakan pengguna sebenar
Status pengguna maya, Lulus/Gagal/Jumlah β bilangan yang berjaya dan
status pengguna maya yang tidak berjaya
untuk senario beban, serta jumlah bilangannya.
Secara amnya dijangka semua pengguna dapat menyelesaikannya
semua tugas anda yang dinyatakan dalam profil muatkan.
Sebarang ralat bermakna pengguna sebenar tidak akan dapat melakukannya
menyelesaikan masalah anda apabila bekerja dengan sistem
Permintaan sesaat (minit)- bilangan permintaan rangkaian sesaat (atau minit).
Ciri penting ejen beban ialah berapa banyak permintaan yang boleh dihasilkannya.
Malah, ini adalah tiruan akses kepada aplikasi oleh pengguna maya
Respons sesaat (minit)
- bilangan respons rangkaian sesaat (atau minit).
Ciri penting perkhidmatan sasaran: berapa banyak
menjana dan menghantar respons kepada pertanyaan dengan
ejen pemuatan
Status respons HTTPβ bilangan kod tindak balas yang berbeza
daripada pelayan aplikasi yang diterima oleh ejen beban.
Sebagai contoh, 200 OK bermaksud panggilan yang berjaya,
dan 404 - bahawa sumber itu tidak ditemui
Latency (masa tindak balas) - masa dari akhir
menghantar permintaan (request) sebelum mula menerima respon (respon).
Biasanya diukur dalam milisaat (ms)
Masa tindak balas transaksiβ masa satu transaksi lengkap,
penyiapan kitaran permintaan-tindak balas.
Ini adalah masa dari mula menghantar permintaan (permintaan)
sehingga selesai menerima respons (respon).
Masa transaksi boleh diukur dalam saat (atau minit)
dalam beberapa cara: pertimbangkan minimum,
maksimum, purata dan, sebagai contoh, persentil ke-90.
Bacaan minimum dan maksimum adalah melampau
status prestasi sistem.
Persentil kesembilan puluh adalah yang paling biasa digunakan,
kerana ia menunjukkan kebanyakan pengguna,
beroperasi dengan selesa pada ambang prestasi sistem
Transaksi sesaat (minit) - bilangan lengkap
transaksi sesaat (minit),
iaitu berapa banyak permohonan itu dapat diterima dan
memproses permintaan dan mengeluarkan respons.
Sebenarnya, ini adalah daya pemprosesan sistem
Status urus niaga , Lulus / Gagal / Jumlah - nombor
berjaya, tidak berjaya dan jumlah urus niaga.
Bagi pengguna sebenar yang tidak berjaya
urus niaga itu sebenarnya bermakna
ketidakupayaan untuk bekerja dengan sistem di bawah beban
Gambarajah Skema Ujian Beban
Konsep ujian beban adalah sangat mudah dan terdiri daripada tiga peringkat utama, yang telah saya nyatakan: Sediakan-Laporan-Ujian, iaitu, menyediakan matlamat ujian dan menetapkan parameter untuk sumber beban, kemudian melaksanakan ujian beban dan, pada akhirnya, menjana dan menerbitkan laporan ujian.
Nota skema:
- QA.Tester ialah pakar dalam ujian beban,
- Sasaran ialah aplikasi sasaran yang anda ingin tahu kelakuannya di bawah beban.
Pengelas entiti, peringkat dan langkah dalam rajah
Peringkat dan langkah
Apa yang sedang berlaku
Apa yang ada di pintu masuk
Apakah output
Sediakan: peringkat persediaan untuk ujian
LoadParameters
Tetapan dan permulaan
pengguna
parameter beban,
pilihan metrik dan
penyediaan rancangan ujian
(muatkan profil)
Pilihan tersuai untuk
permulaan ejen beban
Pelan ujian
Tujuan ujian
VM
Penggunaan awan
mesin maya dengan
ciri-ciri yang diperlukan
Tetapan VM untuk ejen beban
Skrip automasi untuk
penciptaan VM
VM dikonfigurasikan masuk
awan
Hantar
Persediaan dan penyediaan OS
persekitaran untuk
kerja ejen muat
Tetapan persekitaran untuk
ejen muatan
Skrip automasi untuk
tetapan persekitaran
Persekitaran yang disediakan:
OS, perkhidmatan dan aplikasi,
perlu untuk kerja
ejen muatan
LoadAgents
Pemasangan, konfigurasi dan parameterisasi
ejen pemuatan.
Atau memuat turun imej docker dari
sumber beban prakonfigurasi
Muatkan imej docker sumber
(YAT, JM atau rangka kerja tulisan sendiri)
tetapan
ejen muatan
Sediakan dan sedia
untuk bekerja ejen beban
Ujian: peringkat pelaksanaan ujian beban. Sumber ialah ejen beban yang digunakan dalam kumpulan ejen khusus untuk GitLab CI
Muatkan
Memulakan Ejen Muatan
dengan rancangan ujian yang dipilih
dan parameter beban
Pilihan Pengguna
untuk permulaan
ejen muatan
Pelan ujian
Tujuan ujian
Log pelaksanaan
ujian beban
Log sistem
Dinamik perubahan dalam metrik matlamat dan ejen beban
Jalankan Ejen
Pelaksanaan Agen
banyak skrip ujian
menurut
memuatkan profil
Interaksi Agen Muatan
untuk tujuan ujian
Pelan ujian
Tujuan ujian
Balak
Koleksi log "mentah".
semasa ujian beban:
memuatkan rekod aktiviti ejen,
keadaan sasaran ujian
dan VM menjalankan ejen
Log pelaksanaan
ujian beban
Log sistem
Metrik
Mengumpul metrik "mentah" semasa ujian
Dinamik perubahan dalam metrik matlamat
dan ejen muatan
Laporan: peringkat penyediaan laporan ujian
Generator
Pemprosesan dikumpul
sistem pemuatan dan
sistem pemantauan "mentah"
metrik dan log
Pembentukan laporan dalam
bentuk yang boleh dibaca manusia
mungkin dengan unsur
penganalisis
Log pelaksanaan
ujian beban
Log sistem
Dinamik perubahan dalam metrik
sasaran dan ejen muatan
Log "mentah" yang diproses
dalam format yang sesuai untuk
muat naik ke storan luaran
Laporan beban statik,
boleh dibaca oleh manusia
Publish
Penerbitan laporan
tentang beban
ujian dalam luaran
perkhidmatan
Diproses "mentah"
log dalam format yang sesuai
untuk memunggah ke luar
repositori
Disimpan dalam luaran
laporan penyimpanan pada
beban, sesuai
untuk analisis manusia
Menyambung sumber beban dalam templat CI
Mari kita beralih ke bahagian praktikal. Saya ingin menunjukkan bagaimana pada beberapa projek dalam syarikat kami telah melaksanakan konsep ujian beban sebagai perkhidmatan.
Pertama, dengan bantuan jurutera DevOps kami, kami mencipta kumpulan ejen khusus dalam GitLab CI untuk menjalankan ujian beban. Untuk tidak mengelirukan mereka dalam templat dengan yang lain, seperti himpunan himpunan, kami menambahkan teg pada ejen ini, : memuatkan. Anda boleh menggunakan sebarang teg lain yang boleh difahami. Mereka bertanya GitLab CI Runners.
Bagaimana untuk mengetahui kuasa yang diperlukan oleh perkakasan? Ciri-ciri ejen beban - bilangan vCPU, RAM dan Cakera yang mencukupi - boleh dikira berdasarkan fakta bahawa Docker, Python (untuk Yandex.Tank), ejen GitLab CI, Java (untuk Apache JMeter) harus dijalankan pada ejen . Untuk Java di bawah JMeter, ia juga disyorkan untuk menggunakan sekurang-kurangnya 512 MB RAM dan, sebagai had atas, .
Oleh itu, berdasarkan pengalaman kami, kami mengesyorkan menggunakan sekurang-kurangnya 4 vCPU, 4 GB RAM, 60 GB SSD untuk ejen beban. Daya pengeluaran kad rangkaian ditentukan berdasarkan keperluan profil beban.
Kami terutamanya menggunakan dua sumber beban - imej Apache JMeter dan Yandex.Tank docker.
ialah alat sumber terbuka daripada Yandex untuk ujian beban. Seni bina modularnya adalah berdasarkan penjana permintaan HTTP berasaskan hit tak segerak berprestasi tinggi Phantom. Tangki mempunyai pemantauan terbina dalam sumber pelayan yang sedang diuji melalui protokol SSH, secara automatik boleh menghentikan ujian di bawah keadaan tertentu, boleh memaparkan keputusan kedua-dua dalam konsol dan dalam bentuk graf, anda boleh menyambungkan modul anda kepadanya untuk mengembangkan fungsi. Ngomong-ngomong, kami menggunakan Tangki semasa ia belum lagi arus perdana. Dalam artikel "Β» anda boleh membaca kisah bagaimana kami melakukan ujian beban dengannya pada tahun 2013 adalah salah satu produk syarikat kami.
ialah alat ujian beban sumber terbuka daripada Apache. Ia boleh digunakan dengan baik untuk menguji kedua-dua aplikasi web statik dan dinamik. JMeter menyokong sejumlah besar protokol dan cara untuk berinteraksi dengan aplikasi: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, dll.), SOAP / REST Webservices, FTP, TCP, LDAP, SMTP(S), POP3( S) ) dan IMAP(S), pangkalan data melalui JDBC, boleh melaksanakan perintah shell dan berfungsi dengan objek Java. JMeter mempunyai IDE untuk mencipta, menyahpepijat dan melaksanakan rancangan ujian. Terdapat juga CLI untuk operasi baris arahan pada mana-mana sistem pengendalian Java yang serasi (Linux, Windows, Mac OS X). Alat ini boleh menjana laporan ujian HTML secara dinamik.
Untuk kemudahan penggunaan dalam syarikat kami, untuk keupayaan penguji sendiri mengubah dan menambah persekitaran, kami membuat binaan imej docker sumber beban pada GitLab CI dengan penerbitan ke dalaman . Ini menjadikannya lebih cepat dan lebih mudah untuk menyambungkannya dalam saluran paip untuk ujian beban. Bagaimana untuk melakukan docker push to registry melalui GitLab CI - lihat .
Kami mengambil fail docker asas ini untuk Yandex.Tank:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]Dan untuk Apache JMeter yang ini:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Anda boleh membaca cara sistem integrasi berterusan kami berfungsi dalam artikel "'.
Templat dan saluran paip
Contoh templat untuk menjalankan ujian beban tersedia dalam projek . Π Anda boleh membaca arahan untuk menggunakan templat. Dalam templat itu sendiri (file ) terdapat nota tentang tanggungjawab setiap langkah.
Templat ini sangat mudah dan menunjukkan tiga peringkat ujian beban yang diterangkan dalam rajah di atas: menyediakan, menguji dan menerbitkan laporan. Bertanggungjawab untuk ini : Sediakan, Uji dan Laporkan.
- Pentas harus digunakan untuk prakonfigurasi sasaran ujian atau menyemak ketersediaannya. Persekitaran untuk sumber beban tidak perlu dikonfigurasikan, ia pra-dibina sebagai imej docker dan disiarkan dalam pendaftaran docker: hanya nyatakan versi yang dikehendaki pada peringkat Ujian. Tetapi anda boleh membina semula dan membuat imej anda sendiri yang diubah suai.
- Pentas digunakan untuk menentukan sumber beban, menjalankan ujian dan menyimpan artifak ujian. Anda boleh memilih mana-mana sumber beban: Yandex.Tank, Apache JMeter, anda sendiri atau semuanya bersama-sama. Untuk melumpuhkan sumber yang tidak diperlukan, cuma ulas atau padamkan kerja. Titik kemasukan untuk sumber beban:
- Parameter pelancaran untuk Yandex.Tank dinyatakan dalam .,
- Parameter permulaan Apache JMeter dinyatakan dalam fail .
Nota: Templat konfigurasi pemasangan digunakan untuk menyediakan interaksi dengan sistem CI dan tidak membayangkan penempatan logik ujian di dalamnya. Untuk ujian, titik masuk ditentukan, di mana skrip bash kawalan terletak. Kaedah menjalankan ujian, menjana laporan dan skrip ujian itu sendiri mesti dilaksanakan oleh jurutera QA. Dalam demo, untuk kedua-dua sumber muat, permintaan halaman utama Yandex digunakan sebagai ujian paling mudah. Skrip dan parameter ujian berada dalam direktori .
- Di pentas anda perlu menerangkan cara menerbitkan keputusan ujian yang diperoleh pada peringkat Ujian ke storan luaran, contohnya, ke Halaman GitLab atau sistem pelaporan khas. Halaman GitLab memerlukan direktori ./public tidak kosong dan mengandungi sekurang-kurangnya fail index.html selepas ujian selesai. Anda boleh membaca tentang nuansa perkhidmatan GitLab Pages. .
Contoh cara mengeksport data:
- dari JMeter ke ,
- daripada Yandex.Tank ke .
Menyiarkan arahan persediaan:
- Statik HTML masuk ,
- ke InfluxDB dan kemudian ke .
Dalam contoh demo, saluran paip dengan ujian beban dan dua sumber beban (anda boleh melumpuhkan yang tidak perlu) kelihatan seperti ini:
Apache JMeter boleh menjana laporan HTML itu sendiri, jadi lebih menguntungkan untuk menyimpannya dalam Halaman GitLab menggunakan alat standard. Beginilah rupa laporan Apache JMeter:
Dalam contoh demo untuk Yandex.Tank, anda hanya akan melihat dalam bahagian untuk Halaman GitLab. Semasa ujian, Tangki boleh menyimpan keputusan ke pangkalan data InfluxDB, dan dari sana ia boleh dipaparkan, sebagai contoh, dalam Grafana (konfigurasi dilakukan dalam fail ). Beginilah rupa laporan Tank di Grafana:
Ringkasan
Dalam artikel itu, saya bercakap tentang konsep "ujian beban sebagai perkhidmatan" (ujian beban sebagai perkhidmatan). Idea utama ialah menggunakan infrastruktur kumpulan ejen beban yang diprakonfigurasikan, imej docker sumber beban, sistem pelaporan dan saluran paip yang menggabungkannya dalam GitLab CI berdasarkan templat .gitlab-ci.yml yang mudah (contoh ). Semua ini disokong oleh pasukan kecil jurutera automasi dan direplikasi atas permintaan pasukan produk. Saya harap ini akan membantu anda dalam menyediakan dan melaksanakan skim yang sama di syarikat anda. Terima kasih atas perhatian!
PS Saya ingin mengucapkan ribuan terima kasih kepada rakan sekerja saya, Sergey Kurbanov dan Nikolai Yusev, atas bantuan teknikal dengan pelaksanaan konsep ujian beban sebagai perkhidmatan di syarikat kami.
Pengarang: - Timbalan Ketua Teknologi dan Proses Pembangunan (DevOps) di Positive Technologies
Sumber: www.habr.com