Salah satu masalah yang sering dihadapi vendor perangkat lunak multi-produk adalah duplikasi kompetensi para insinyur - pengembang, penguji, dan administrator infrastruktur - di hampir setiap tim. Ini juga berlaku untuk insinyur mahal - spesialis di bidang pengujian beban.
Alih-alih melakukan tugas langsung mereka dan menggunakan pengalaman unik mereka untuk membangun proses pengujian beban, memilih metodologi, metrik optimal, dan menulis pengujian otomatis sesuai dengan profil beban, para insinyur seringkali harus menggunakan infrastruktur pengujian dari awal, mengonfigurasi alat muat, dan menyematkannya diri mereka sendiri dalam sistem CI, mengatur pemantauan dan publikasi laporan.
Anda dapat menemukan solusi untuk beberapa masalah organisasi dalam pengujian yang kami gunakan di Positive Technologies . Dan yang satu ini, saya akan berbicara tentang kemungkinan mengintegrasikan tes beban ke dalam pipa CI umum menggunakan konsep "pengujian beban sebagai layanan" (pengujian beban sebagai layanan). Anda akan mempelajari bagaimana dan gambar sumber beban buruh pelabuhan mana yang dapat digunakan dalam pipeline CI; cara menyambungkan sumber beban ke proyek CI Anda menggunakan template build; bagaimana tampilan pipeline demo untuk menjalankan pengujian beban dan memublikasikan hasilnya. Artikel ini mungkin berguna untuk insinyur pengujian perangkat lunak dan insinyur otomasi di CI yang sedang memikirkan arsitektur sistem beban mereka.
Inti dari konsep
Konsep pengujian beban sebagai layanan menyiratkan kemampuan untuk mengintegrasikan alat muat Apache JMeter, Yandex.Tank, dan kerangka kerja Anda sendiri ke dalam sistem integrasi berkelanjutan yang sewenang-wenang. Demo akan untuk GitLab CI, tetapi prinsipnya sama untuk semua sistem CI.
Pengujian beban sebagai layanan adalah layanan terpusat untuk pengujian beban. Tes beban dijalankan di kumpulan agen khusus, hasilnya dipublikasikan secara otomatis di GitLab Pages, Influx DB dan Grafana atau di sistem pelaporan pengujian (TestRail, ReportPortal, dll.). Otomasi dan penskalaan diimplementasikan sesederhana mungkin - dengan menambahkan dan membuat parameter template gitlab-ci.yml biasa dalam proyek GitLab CI.
Keuntungan dari pendekatan ini adalah bahwa seluruh infrastruktur CI, agen beban, gambar buruh pelabuhan dari sumber beban, pipa pengujian, dan laporan penerbitan dikelola oleh departemen otomasi terpusat (insinyur DevOps), sementara insinyur pengujian beban dapat memfokuskan upaya mereka pada pengembangan pengujian dan analisis hasil mereka, tanpa berurusan dengan masalah infrastruktur.
Untuk mempermudah deskripsi, kami akan menganggap bahwa aplikasi target atau server yang diuji telah diterapkan dan dikonfigurasi sebelumnya (skrip otomatis dengan Python, SaltStack, Ansible, dll. dapat digunakan untuk ini). Kemudian seluruh konsep pengujian beban sebagai layanan masuk ke dalam tiga tahap: persiapan, pengujian, publikasi laporan. Detail lebih lanjut tentang diagram (semua gambar dapat diklik):
Konsep dasar dan definisi dalam pengujian beban
Saat melakukan tes beban, kami mencoba untuk mematuhinya , gunakan terminologi yang sesuai dan metrik yang direkomendasikan. Saya akan memberikan daftar singkat konsep dan definisi utama dalam pengujian beban.
Agen beban - mesin virtual tempat aplikasi akan diluncurkan - sumber beban (Apache JMeter, Yandex.Tank atau modul beban yang ditulis sendiri).
Sasaran tes (target) - server atau aplikasi diinstal pada server yang akan dimuat.
Skenario pengujian (test case) - sekumpulan langkah berparameter: tindakan pengguna dan reaksi yang diharapkan terhadap tindakan ini, dengan permintaan dan respons jaringan tetap, bergantung pada parameter yang ditentukan.
Profil atau rencana muat (profil) - di (Bagian 4.2.4, p.43) profil beban menentukan metrik yang sangat penting untuk pengujian tertentu dan opsi untuk mengubah parameter beban selama pengujian. Anda dapat melihat contoh profil pada gambar.
Tes β skrip dengan kumpulan parameter yang telah ditentukan sebelumnya.
Rencana pengujian (test-plan) - satu set tes dan profil beban.
Testran (testrun) - satu iterasi menjalankan satu pengujian dengan skenario beban yang dijalankan sepenuhnya dan laporan yang diterima.
Permintaan jaringan (permintaan) β Permintaan HTTP dikirim dari agen ke target.
Respons jaringan (respons) β Respons HTTP dikirim dari target ke agen.
Kode respons HTTP (status respons HTTP) - kode respons standar dari server aplikasi.
Transaksi adalah siklus permintaan-respons yang lengkap. Suatu transaksi dihitung dari awal pengiriman permintaan (request) sampai dengan selesainya penerimaan tanggapan (response).
Status transaksi - apakah mungkin berhasil menyelesaikan siklus permintaan-respons. Jika ada kesalahan dalam siklus ini, maka seluruh transaksi dianggap tidak berhasil.
Waktu respons (latensi) - waktu dari akhir pengiriman permintaan (permintaan) hingga awal penerimaan tanggapan (tanggapan).
Memuat metrik β karakteristik layanan dimuat dan agen beban ditentukan dalam proses pengujian beban.
Metrik dasar untuk mengukur parameter beban
Beberapa yang paling umum digunakan dan direkomendasikan dalam metodologi (hal. 36, 52) metrik ditunjukkan pada tabel di bawah ini. Metrik serupa untuk agen dan target dicantumkan pada baris yang sama.
Metrik untuk agen beban
Metrik sistem atau aplikasi target yang sedang diuji di bawah beban
Nomor vCPU dan memori RAM,
Piringan - karakteristik "besi" dari agen beban
CPU, Memori, penggunaan Disk - dinamika CPU, memori dan pemuatan disk
dalam proses pengujian. Biasanya diukur sebagai persentase dari
nilai maksimum yang tersedia
throughput jaringan (on load agent) - throughput
antarmuka jaringan di server,
tempat agen beban dipasang.
Biasanya diukur dalam byte per detik (bps)
throughput jaringan(sesuai target) - bandwidth antarmuka jaringan
pada server tujuan. Biasanya diukur dalam byte per detik (bps)
Pengguna maya- jumlah pengguna virtual,
mengimplementasikan skenario beban dan
meniru tindakan pengguna nyata
Status pengguna virtual, Lulus/Gagal/Total β jumlah yang berhasil dan
status pengguna virtual yang tidak berhasil
untuk skenario pemuatan, serta jumlah totalnya.
Secara umum diharapkan semua pengguna dapat menyelesaikannya
semua tugas Anda ditentukan dalam profil beban.
Kesalahan apa pun berarti bahwa pengguna sebenarnya tidak akan bisa melakukannya
memecahkan masalah Anda ketika bekerja dengan sistem
Permintaan per detik (menit)- jumlah permintaan jaringan per detik (atau menit).
Karakteristik penting dari agen beban adalah berapa banyak permintaan yang dapat dihasilkannya.
Faktanya, ini adalah tiruan dari akses ke aplikasi oleh pengguna virtual
Respons per detik (menit)
- jumlah respons jaringan per detik (atau menit).
Karakteristik penting dari target layanan: seberapa banyak
menghasilkan dan mengirim respons ke kueri dengan
agen pemuatan
Status respons HTTPβ jumlah kode respons yang berbeda
dari server aplikasi yang diterima oleh agen beban.
Misalnya, 200 OK berarti panggilan berhasil,
dan 404 - bahwa sumber daya tidak ditemukan
Latensi (waktu respons) - waktu dari akhir
mengirimkan permintaan (request) sebelum mulai menerima tanggapan (response).
Biasanya diukur dalam milidetik (ms)
Waktu respons transaksiβ waktu satu transaksi penuh,
menyelesaikan siklus permintaan-respons.
Ini adalah waktu dari awal pengiriman permintaan (permintaan)
sampai selesai menerima tanggapan (respons).
Waktu transaksi dapat diukur dalam detik (atau menit)
dalam beberapa cara: mempertimbangkan minimum,
maksimum, rata-rata dan, misalnya, persentil ke-90.
Pembacaan minimum dan maksimum sangat ekstrem
status kinerja sistem.
Persentil kesembilan puluh adalah yang paling umum digunakan,
seperti yang ditunjukkan sebagian besar pengguna,
beroperasi dengan nyaman di ambang kinerja sistem
Transaksi per detik (menit) - jumlah lengkap
transaksi per detik (menit),
yaitu, seberapa banyak aplikasi dapat menerima dan
memproses permintaan dan mengeluarkan tanggapan.
Faktanya, ini adalah throughput sistem
Status transaksi , Lulus / Gagal / Total - angka
sukses, gagal dan jumlah total transaksi.
Untuk pengguna nyata tidak berhasil
transaksi sebenarnya akan berarti
ketidakmampuan untuk bekerja dengan sistem di bawah beban
Diagram Skema Pengujian Beban
Konsep pengujian beban sangat sederhana dan terdiri dari tiga tahap utama, yang telah saya sebutkan: Persiapkan-Uji-Laporan, yaitu menyiapkan tujuan pengujian dan menyetel parameter untuk sumber beban, kemudian menjalankan pengujian beban, dan pada akhirnya, membuat dan menerbitkan laporan pengujian.
Catatan skematis:
- QA.Tester adalah pakar dalam pengujian beban,
- Target adalah aplikasi target yang ingin Anda ketahui perilakunya saat dimuat.
Pengklasifikasi entitas, tahapan dan langkah dalam diagram
Tahapan dan langkah
Apa yang terjadi
Apa yang ada di pintu masuk
Apa outputnya
Siapkan: tahap persiapan untuk pengujian
LoadParameter
Pengaturan dan inisialisasi
pengguna
memuat parameter,
pilihan metrik dan
persiapan rencana uji
(memuat profil)
Opsi khusus untuk
inisialisasi agen beban
Rencana pengujian
Tujuan pengujian
VM
Penerapan cloud
mesin virtual dengan
karakteristik yang dibutuhkan
Pengaturan VM untuk agen beban
Skrip otomasi untuk
pembuatan VM
VM dikonfigurasi di
awan
lingkungan
Pengaturan dan persiapan OS
lingkungan untuk
pekerjaan agen beban
Pengaturan lingkungan untuk
agen beban
Skrip otomasi untuk
pengaturan lingkungan
Lingkungan yang disiapkan:
OS, layanan dan aplikasi,
diperlukan untuk bekerja
agen beban
Agen Beban
Instalasi, konfigurasi dan parameterisasi
agen pemuatan.
Atau mengunduh gambar buruh pelabuhan dari
sumber beban yang telah dikonfigurasi sebelumnya
Muat gambar buruh pelabuhan sumber
(YAT, JM atau kerangka kerja yang ditulis sendiri)
Pengaturan
agen beban
Siapkan dan siapkan
untuk bekerja agen beban
Test: tahap pelaksanaan tes beban. Sumber adalah agen beban yang diterapkan di kumpulan agen khusus untuk GitLab CI
Beban
Memulai Agen Beban
dengan rencana pengujian yang dipilih
dan memuat parameter
Opsi Pengguna
untuk inisialisasi
agen beban
Rencana pengujian
Tujuan pengujian
Log eksekusi
tes beban
Log sistem
Dinamika perubahan dalam metrik sasaran dan agen beban
Jalankan Agen
Eksekusi Agen
banyak skrip pengujian
Menurut
memuat profil
Memuat Interaksi Agen
untuk tujuan pengujian
Rencana pengujian
Tujuan pengujian
Log
Kumpulan log "mentah".
selama pengujian beban:
memuat catatan aktivitas agen,
keadaan sasaran percobaan
dan VM yang menjalankan agen
Log eksekusi
tes beban
Log sistem
Metrik
Mengumpulkan metrik "mentah" selama pengujian
Dinamika perubahan dalam metrik tujuan
dan agen beban
Laporan: tahap persiapan laporan ujian
Generator
Pemrosesan dikumpulkan
sistem pemuatan dan
sistem pemantauan "mentah"
metrik dan log
Pembuatan laporan di
bentuk yang dapat dibaca manusia
mungkin dengan elemen
analis
Log eksekusi
tes beban
Log sistem
Dinamika perubahan dalam metrik
target dan agen beban
Log "mentah" yang diproses
dalam format yang cocok untuk
upload ke penyimpanan eksternal
Laporan beban statis,
dapat dibaca manusia
Menerbitkan
Publikasi laporan
tentang beban
pengujian di eksternal
layanan
Diproses "mentah"
log dalam format yang sesuai
untuk bongkar ke eksternal
tempat penyimpanan
Disimpan di eksternal
laporan penyimpanan aktif
muat, pas
untuk analisis manusia
Menghubungkan sumber beban dalam template CI
Mari beralih ke bagian praktis. Saya ingin menunjukkan caranya pada beberapa proyek di perusahaan kami telah menerapkan konsep pengujian beban sebagai layanan.
Pertama, dengan bantuan teknisi DevOps kami, kami membuat kumpulan agen khusus di GitLab CI untuk menjalankan uji beban. Agar tidak membingungkan mereka dalam template dengan yang lain, seperti kumpulan perakitan, kami menambahkan tag ke agen ini, : memuat. Anda dapat menggunakan tag lain yang dapat dimengerti. Mereka bertanya Pelari GitLab CI.
Bagaimana cara mengetahui daya yang dibutuhkan oleh perangkat keras? Karakteristik agen beban - jumlah vCPU, RAM, dan Disk yang memadai - dapat dihitung berdasarkan fakta bahwa Docker, Python (untuk Yandex.Tank), agen GitLab CI, Java (untuk Apache JMeter) harus dijalankan pada agen . Untuk Java di bawah JMeter, disarankan juga untuk menggunakan RAM minimal 512 MB dan, sebagai batas atas, .
Jadi, berdasarkan pengalaman kami, kami merekomendasikan untuk menggunakan setidaknya 4 vCPU, RAM 4 GB, SSD 60 GB untuk agen beban. Throughput kartu jaringan ditentukan berdasarkan persyaratan profil beban.
Kami terutama menggunakan dua sumber beban - gambar docker Apache JMeter dan Yandex.Tank.
adalah alat sumber terbuka dari Yandex untuk pengujian beban. Arsitektur modularnya didasarkan pada generator permintaan HTTP berbasis hit asinkron performa tinggi Phantom. Tangki memiliki pemantauan bawaan terhadap sumber daya server yang diuji melalui protokol SSH, dapat menghentikan pengujian secara otomatis dalam kondisi tertentu, dapat menampilkan hasilnya baik di konsol maupun dalam bentuk grafik, Anda dapat menghubungkan modul Anda untuk itu untuk memperluas fungsionalitas. Omong-omong, kami menggunakan Tank saat itu belum umum. Di dalam artikel "Β» Anda dapat membaca kisah tentang bagaimana kami melakukan pengujian beban dengannya pada tahun 2013 adalah salah satu produk perusahaan kami.
adalah alat pengujian beban open source dari Apache. Ini dapat digunakan dengan baik untuk menguji aplikasi web statis dan dinamis. JMeter mendukung sejumlah besar protokol dan cara untuk berinteraksi dengan aplikasi: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, dll.), Layanan Web SOAP / REST, FTP, TCP, LDAP, SMTP(S), POP3( S) ) dan IMAP(S), database melalui JDBC, dapat menjalankan perintah shell dan bekerja dengan objek Java. JMeter memiliki IDE untuk membuat, men-debug, dan menjalankan rencana pengujian. Ada juga CLI untuk operasi baris perintah pada sistem operasi yang kompatibel dengan Java (Linux, Windows, Mac OS X). Alat ini dapat menghasilkan laporan pengujian HTML secara dinamis.
Untuk kemudahan penggunaan di dalam perusahaan kami, untuk kemampuan penguji itu sendiri untuk mengubah dan menambahkan lingkungan, kami membuat gambar buruh pelabuhan dari sumber beban di GitLab CI dengan publikasi ke internal . Ini membuatnya lebih cepat dan lebih mudah untuk menghubungkannya dalam jaringan pipa untuk uji beban. Bagaimana melakukan docker push to registry melalui GitLab CI - lihat .
Kami mengambil file buruh pelabuhan dasar 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 dapat membaca cara kerja sistem integrasi berkelanjutan kami di artikel "'.
Templat dan saluran pipa
Contoh template untuk melakukan uji beban tersedia di proyek . Di Anda dapat membaca petunjuk penggunaan template. Di template itu sendiri (file ) ada catatan tentang tanggung jawab setiap langkah.
Templatnya sangat sederhana dan menunjukkan tiga tahap pengujian beban yang dijelaskan dalam diagram di atas: menyiapkan, menguji, dan menerbitkan laporan. Bertanggung jawab untuk ini : Mempersiapkan, Menguji, dan Melaporkan.
- Panggung harus digunakan untuk melakukan prakonfigurasi target pengujian atau memeriksa ketersediaannya. Lingkungan untuk sumber beban tidak perlu dikonfigurasi, mereka dibuat sebelumnya sebagai gambar buruh pelabuhan dan diposting di registri buruh pelabuhan: cukup tentukan versi yang diinginkan pada tahap Uji. Tetapi Anda dapat membangunnya kembali dan membuat gambar modifikasi Anda sendiri.
- Panggung digunakan untuk menentukan sumber beban, menjalankan pengujian, dan menyimpan artefak pengujian. Anda dapat memilih sumber beban apa pun: Yandex.Tank, Apache JMeter, milik Anda, atau semuanya. Untuk menonaktifkan sumber yang tidak perlu, cukup beri komentar atau hapus pekerjaan. Titik masuk untuk sumber beban:
- Parameter peluncuran untuk Yandex.Tank ditentukan dalam file .,
- Parameter startup Apache JMeter ditentukan dalam file .
Catatan: Templat konfigurasi rakitan digunakan untuk menyiapkan interaksi dengan sistem CI dan tidak menyiratkan penempatan logika pengujian di dalamnya. Untuk tes, titik masuk ditentukan, di mana skrip bash kontrol berada. Metode menjalankan pengujian, membuat laporan, dan skrip pengujian itu sendiri harus diterapkan oleh teknisi QA. Dalam demo, untuk kedua sumber pemuatan, permintaan halaman utama Yandex digunakan sebagai pengujian paling sederhana. Skrip dan parameter uji ada di direktori .
- Di panggung Anda perlu menjelaskan cara memublikasikan hasil pengujian yang diperoleh pada tahap Pengujian ke penyimpanan eksternal, misalnya, ke Halaman GitLab atau sistem pelaporan khusus. Halaman GitLab mengharuskan direktori ./public tidak kosong dan berisi setidaknya file index.html setelah pengujian selesai. Anda dapat membaca tentang nuansa layanan GitLab Pages. .
Contoh cara mengekspor data:
- dari JMeter ke ,
- dari Yandex.Tank ke .
Memposting petunjuk penyiapan:
- Statika HTML di ,
- ke InfluxDB dan kemudian ke .
Dalam contoh demo, pipeline dengan uji beban dan dua sumber beban (Anda dapat menonaktifkan yang tidak perlu) terlihat seperti ini:
Apache JMeter dapat menghasilkan laporan HTML sendiri, sehingga lebih menguntungkan untuk menyimpannya di Halaman GitLab menggunakan alat standar. Seperti inilah tampilan laporan Apache JMeter:
Dalam contoh demo untuk Yandex.Tank, Anda hanya akan melihat di bagian untuk Halaman GitLab. Selama pengujian, Tank dapat menyimpan hasilnya ke database InfluxDB, dan dari sana hasilnya dapat ditampilkan, misalnya di Grafana (konfigurasi dilakukan di file ). Begini tampilan laporan Tank di Grafana:
Ringkasan
Dalam artikel tersebut, saya berbicara tentang konsep "load testing as a service" (pengujian beban sebagai layanan). Gagasan utamanya adalah menggunakan infrastruktur kumpulan agen beban yang telah dikonfigurasi sebelumnya, gambar buruh pelabuhan dari sumber beban, sistem pelaporan, dan saluran pipa yang menggabungkannya dalam GitLab CI berdasarkan templat .gitlab-ci.yml sederhana (contoh ). Semua ini didukung oleh tim kecil insinyur otomasi dan direplikasi atas permintaan tim produk. Saya harap ini akan membantu Anda dalam mempersiapkan dan menerapkan skema serupa di perusahaan Anda. Terima kasih atas perhatian Anda!
PS Saya ingin mengucapkan terima kasih yang sebesar-besarnya kepada rekan-rekan saya, Sergey Kurbanov dan Nikolai Yusev, atas bantuan teknis dalam penerapan konsep pengujian beban sebagai layanan di perusahaan kami.
Penulis: - Wakil Kepala Teknologi dan Proses Pengembangan (DevOps) di Teknologi Positif
Sumber: www.habr.com