Memuat pengujian sebagai layanan CI untuk pengembang



Salah satu masalah yang sering ditemui vendor perangkat lunak multi-produk adalah duplikasi kompetensi insinyur - pengembang, penguji, dan administrator infrastruktur - di hampir setiap tim. Ini juga berlaku untuk insinyur mahal - ahli di bidang pengujian beban.

Alih-alih terlibat dalam tanggung jawab langsung mereka dan menggunakan pengalaman unik mereka untuk membangun proses pengujian beban, memilih metodologi, metrik optimal, dan menulis swa uji sesuai profil beban, insinyur sering harus menggunakan infrastruktur pengujian dari awal, mengkonfigurasi alat beban, dan menanamkannya dalam sistem CI, konfigurasikan pemantauan dan publikasi laporan.

Anda dapat menemukan solusi untuk beberapa masalah organisasi dalam pengujian yang kami gunakan di Positive Technologies di artikel lain . Dan dalam hal ini saya akan berbicara tentang kemungkinan mengintegrasikan tes beban ke dalam pipa CI umum menggunakan konsep "pengujian beban sebagai layanan". Anda akan belajar bagaimana dan gambar buruh pelabuhan sumber beban mana yang dapat digunakan dalam pipa CI; Bagaimana menghubungkan sumber pemuatan ke proyek CI Anda menggunakan templat perakitan; seperti apa bentuk pipa demo untuk menjalankan uji beban dan menerbitkan hasil. Artikel ini mungkin berguna untuk insinyur pengujian perangkat lunak dan insinyur otomatisasi di CI yang telah memikirkan arsitektur sistem beban mereka.

Esensi konsep


Konsep pengujian beban sebagai layanan menyiratkan kemampuan untuk mengintegrasikan Apache JMeter, Yandex.Tank alat beban dan kerangka kerja sendiri ke dalam sistem integrasi berkesinambungan yang sewenang-wenang. Demo adalah untuk GitLab CI, tetapi prinsip-prinsipnya dinyatakan umum untuk semua sistem CI.

Pengujian beban sebagai layanan adalah layanan terpusat untuk melakukan pengujian beban. Tes beban dijalankan di kumpulan agen khusus, hasilnya dipublikasikan secara otomatis di Halaman GitLab, Influx DB dan Grafana atau dalam sistem pelaporan pengujian (TestRail, ReportPortal, dll.). Otomasi dan penskalaan diwujudkan sesederhana mungkin - dengan menambahkan dan membuat parameter template gitlab-ci.yml yang biasa dalam proyek GitLab CI.

Keuntungan dari pendekatan ini adalah bahwa seluruh infrastruktur CI, agen beban, gambar buruh pelabuhan dari sumber beban, pipa uji dan publikasi laporan didukung oleh departemen otomatisasi pusat (insinyur DevOps), dan insinyur pengujian beban dapat memfokuskan upaya mereka pada pengembangan pengujian dan analisis hasil mereka, tanpa berurusan dengan masalah infrastruktur.

Untuk kesederhanaan deskripsi, kami mengasumsikan bahwa aplikasi uji target atau server sudah dikerahkan dan dikonfigurasikan sebelumnya (untuk ini, skrip otomatis dengan Python, SaltStack, Ansible, dll dapat digunakan). Kemudian seluruh konsep pengujian stres sebagai layanan cocok dengan tiga tahap: persiapan, pengujian, publikasi laporan . Lebih detail pada diagram (semua gambar dapat diklik):




Saat melakukan tes stres, kami mencoba mematuhi standar dan metodologi ISTQB , kami menggunakan terminologi yang sesuai dan metrik yang direkomendasikan. Saya akan memberikan daftar pendek konsep dasar dan definisi dalam pengujian beban.

Load agent (agen beban) - mesin virtual tempat aplikasi akan diluncurkan - sumber beban (Apache JMeter, Yandex.Tank atau modul beban yang ditulis sendiri).

Tujuan pengujian (target) adalah server atau aplikasi yang diinstal pada server yang akan dimuat.

Test case (test case) - serangkaian langkah parameter: tindakan pengguna dan reaksi yang diharapkan untuk tindakan ini, dengan permintaan dan respons jaringan tetap, tergantung pada parameter yang ditentukan.

Profil atau rencana pemuatan (profil) - dalam metodologi ISTQB ( bagian 4.2.4, hal. 43), profil pemuatan menentukan metrik yang penting untuk pengujian tertentu dan opsi untuk mengubah parameter beban selama pengujian. Anda dapat melihat contoh profil pada gambar. Tes adalah skrip dengan set parameter yang telah ditentukan. Rencana uji - test suite dan memuat profil. Testrun (testrun) - satu iterasi menjalankan satu tes dengan skenario beban yang dieksekusi penuh dan laporan yang diterima. Network Request (request) - Permintaan HTTP yang dikirim dari agen ke target. Respons jaringan (respons) - Respons HTTP yang dikirim dari target ke agen.












Status respons HTTP adalah kode respons standar dari server aplikasi.
Transaksi (transaksi) - siklus penuh "permintaan - respons." Transaksi dihitung dari mulai mengirim permintaan (request) hingga penyelesaian menerima tanggapan (response).

Status transaksi (status transaksi) - apakah mungkin untuk berhasil menyelesaikan siklus "permintaan-respons". Jika ada kesalahan dalam loop ini, maka seluruh transaksi dianggap tidak berhasil.

Waktu respons (latensi) - waktu mulai dari akhir pengiriman permintaan (permintaan) hingga awal menerima tanggapan (tanggapan).

Metrik pemuatan (metrik) - karakteristik layanan yang dimuat dan agen pemuatan ditentukan selama proses pengujian beban.

Metrik dasar untuk mengukur parameter beban


Beberapa metrik yang paling umum dan direkomendasikan dalam metodologi ISTQB (hlm. 36, 52) ditunjukkan pada tabel di bawah ini. Metrik serupa untuk agen dan target ditampilkan pada baris yang sama.

Memuat Metrik AgenMetrik dari sistem target atau aplikasi yang diuji dalam beban
Jumlah   vCPU dan memori RAM ,
Disk - "besi" karakteristik agen beban
CPU , Memori, Penggunaan disk - dinamika memuat prosesor, memori, dan disk
saat pengujian. Biasanya diukur sebagai persentase dari
nilai maksimum yang tersedia.
Network throughput (on load agent) β€”
,
.
(bps)
Network throughput(on target) β€”
. (bps)
Virtual usersβ€” ,

Virtual users status, Passed/Failed/Total β€”

, .

,
, .
,
Requests per second (minute)β€” ( ).

: .
Responses per second (minute)
β€” ( ).

:

HTTP responses statusβ€”
, .
, 200 OK ,
404 β€”
Latency ( ) β€”
(request) (response).
(ms)
Transaction response timeβ€” ,
Β« β€” Β».
(request)
(response).

( )
: ,
, , , 90- .
β€”
.
,
,
Transactions per second (minute) β€”
(),

.
Transactions status , Passed / Failed / Total β€”
, .





Skema dasar pengujian beban sangat sederhana dan terdiri dari tiga tahap utama, yang telah saya sebutkan: Mempersiapkan - Tes - Laporan , yaitu, menyiapkan tujuan pengujian dan menetapkan parameter untuk sumber beban, kemudian melakukan pengujian beban dan, akhirnya, menghasilkan dan menerbitkan laporan tentang pengujian. Catatan untuk skema:





  • QA.Tester - pakar pengujian stres,
  • Target adalah aplikasi target yang Anda perlu tahu perilakunya di bawah beban.

Klasifikasi entitas, tahapan, dan langkah-langkah dalam diagram


Tahapan dan LangkahApa yang terjadiApa yang ada di pintu masukApa outputnya
Siapkan: tahap persiapan ujian
Parameter bebanMengatur dan menginisialisasi parameter beban
pengguna
,
memilih metrik, dan
menyiapkan rencana pengujian
(memuat profil)


-
VM




Env




:
, ,

LoadAgents,
.
-
-
(, JM )



Test: . , GitLab CI
Load
-



-



RunAgents




-
Logs«»
:
,

,


Metrics«»
Report:
Generator

«»


,





«»
,

,
Publish


«»
,



,

CI-


Mari kita beralih ke bagian praktis. Saya ingin menunjukkan bagaimana pada beberapa proyek di Positive Technologies kami menerapkan konsep pengujian beban sebagai layanan.

Pertama, dengan bantuan insinyur DevOps kami, kami menciptakan kumpulan agen khusus di GitLab CI untuk menjalankan uji beban. Agar tidak membingungkan mereka dalam template dengan yang lain, seperti kumpulan rakitan, kami menambahkan tag ke agen ini, tag : memuat. Anda dapat menggunakan tag yang jelas lainnya. Mereka diatur selama pendaftaran GitLab CI Runners.

Bagaimana cara mengetahui daya yang dibutuhkan oleh perangkat keras? Karakteristik agen beban - vCPU, RAM dan Disk dalam jumlah yang cukup - dapat dihitung berdasarkan Docker, Python (untuk Yandex.Tank), agen GitLab CI, Java (untuk Apache JMeter) harus dijalankan pada agen tersebut. Untuk Java di bawah JMeter, Anda juga disarankan untuk menggunakan minimum 512 MB RAM dan, sebagai batas atas, 80% dari memori yang tersedia .

Dengan demikian, berdasarkan pengalaman kami, kami sarankan untuk menggunakan setidaknya 4 vCPU, 4 GB RAM, 60 GB SSD untuk agen beban. Bandwidth kartu jaringan ditentukan berdasarkan persyaratan profil beban.

Kami terutama menggunakan dua sumber beban - gambar buruh pelabuhan Apache JMeter dan Yandex.Tank.

Yandex. Terima kasih- Ini adalah alat open source Yandex untuk pengujian stres. Arsitektur modularnya didasarkan pada generator permintaan HTTP berbasis hit asinkron kinerja tinggi Phantom. Tangki memiliki built-in pemantauan sumber daya dari server yang diuji menggunakan protokol SSH, dapat secara otomatis menghentikan tes sesuai dengan kondisi yang diberikan, dapat menampilkan hasil baik ke konsol dan dalam bentuk grafik, Anda dapat menghubungkan modul Anda ke sana untuk memperluas fungsionalitas. Ngomong-ngomong, kami menggunakan Tank saat itu belum mainstream. Dalam artikel " Yandex.Tank dan Automation of Load Testing ", Anda dapat membaca kisah tentang bagaimana, pada 2013, kami menggunakannya untuk melakukan pengujian beban PT Appllication Firewall - salah satu produk perusahaan kami.

Apache JMeterAdalah alat open source untuk melakukan pengujian stres Apache. Ini dapat digunakan dengan sama baiknya untuk menguji aplikasi web statis dan dinamis. JMeter mendukung sejumlah besar protokol dan cara 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), basis data 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 bekerja pada baris perintah Java OS yang kompatibel (Linux, Windows, Mac OS X). Alat ini secara dinamis dapat menghasilkan laporan pengujian HTML.

Untuk kemudahan penggunaan dalam perusahaan kami, untuk kemampuan penguji untuk mengubah dan menambahkan lingkungan, kami membuat gambar buruh pelabuhan dari sumber beban di GitLab CI dengan publikasi dalam daftar buruh pelabuhan internal pada Artifactory . Dengan cara ini ternyata lebih cepat dan lebih mudah untuk menghubungkan mereka dalam saluran pipa untuk uji beban. Cara membuat push docker dalam registri melalui GitLab CI - lihat instruksi .

File buruh pelabuhan dasar untuk Yandex. Terima kasih kami mengambil ini:

Dockerfile 
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]

Dan untuk Apache JMeter yang satu ini:

Dockerfile 
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]

Anda dapat membaca bagaimana sistem integrasi berkesinambungan kami bekerja di artikel " Otomasi proses pengembangan: bagaimana kami menerapkan ide-ide DevOps dalam Teknologi Positif ".

Templat dan pipa


Contoh template untuk melakukan tes beban tersedia di proyek beban demo . Anda dapat membaca instruksi untuk menggunakan templat di file readme . Dalam template itu sendiri (file .gitlab-ci.yml ) ada catatan tentang apa yang bertanggung jawab atas langkah ini atau itu.

Templat ini sangat sederhana dan menunjukkan tiga tahap pengujian beban yang dijelaskan di atas dalam diagram: persiapan, pengujian, dan publikasi laporan. Bertanggung jawab untuk itu direktori tahapan : Mempersiapkan, Tes, dan Laporan .

  1. Prepare . , - docker registry: Test. .
  2. Test , . : Yandex.Tank, Apache JMeter, . job-. :

    : CI- . , bash-. , β€” QA-. . ./tests.
  3. Report , Test, , GitLab Pages . GitLab Pages , ./public index.html. GitLab Pages .

    , :
    :

Dalam contoh demo, pipa dengan tes beban dan dua sumber beban (Anda dapat menonaktifkan yang tidak perlu) terlihat seperti ini: Apache JMeter dapat menghasilkan laporan HTML itu sendiri, sehingga lebih menguntungkan untuk menyimpannya di Halaman GitLab menggunakan alat biasa. Seperti inilah laporan Apache JMeter: Dalam demo untuk Yandex.Tank, Anda hanya akan melihat laporan teks palsu di bagian GitLab Pages. Selama pengujian, Tank dapat menyimpan hasilnya ke database InfluxDB, dan dari sana mereka dapat ditampilkan, misalnya, di Grafana (konfigurasi dilakukan dalam file ./tests/example-yandextank-test.yml ). Seperti inilah 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 menyatukannya dalam GitLab CI berdasarkan pada templat .gitlab-ci.yml yang sederhana (contoh dengan referensi ). Semua ini didukung oleh tim kecil insinyur otomasi dan direplikasi atas permintaan tim produk. Saya harap ini membantu Anda dalam mempersiapkan dan mengimplementasikan skema serupa di perusahaan Anda. Terima kasih atas perhatian Anda!

PS Saya ingin mengucapkan terima kasih banyak kepada kolega saya, Sergey Kurbanov dan Nikolay Yusev, atas bantuan teknis dengan implementasi konsep pengujian beban sebagai layanan di perusahaan kami.

Penulis :Timur Gilmullin - wakil. Kepala Teknologi dan Proses Pengembangan (DevOps), Teknologi Positif

All Articles