Çok ürünlü yazılım satıcılarının sıklıkla karşılaştığı sorunlardan biri, hemen hemen her ekipte mühendislerin (geliştiriciler, test uzmanları ve altyapı yöneticileri) yetkinliklerinin tekrarlanmasıdır. Bu, yük testi alanında uzman olan pahalı mühendisler için de geçerlidir.
Mühendislerin doğrudan görevlerini yapmak ve bir yük testi süreci oluşturmak, bir metodoloji seçmek, en uygun ölçümleri yapmak ve yük profillerine göre otomatik testler yazmak için benzersiz deneyimlerini kullanmak yerine genellikle test altyapısını sıfırdan kurması, yükleme araçlarını yapılandırması ve bunları yerleştirmesi gerekir. CI sistemlerinde kendileri, izleme ve raporların yayınlanmasını kurun.
Pozitif Teknolojiler'de kullandığımız testlerde bazı organizasyonel sorunlara çözüm bulabilirsiniz. . Ve bu sefer, "hizmet olarak yük testi" (hizmet olarak yük testi) kavramını kullanarak yük testlerini ortak bir CI boru hattına entegre etme olasılığından bahsedeceğim. CI işlem hattında yük kaynaklarının nasıl ve hangi docker görüntülerinin kullanılabileceğini öğreneceksiniz; bir derleme şablonu kullanarak yük kaynaklarını CI projenize nasıl bağlayacağınız; yük testlerini çalıştırmak ve sonuçları yayınlamak için demo boru hattının nasıl göründüğü. Makale, yük sistemlerinin mimarisini düşünen CI'deki yazılım test mühendisleri ve otomasyon mühendisleri için yararlı olabilir.
kavramın özü
Bir hizmet olarak yük testi kavramı, Apache JMeter, Yandex.Tank yükleme araçlarını ve kendi çerçevelerinizi keyfi bir sürekli entegrasyon sistemine entegre etme yeteneğini ifade eder. Demo GitLab CI için olacak, ancak ilkeler tüm CI sistemlerinde ortaktır.
Hizmet olarak yük testi, yük testi için merkezi bir hizmettir. Yük testleri özel aracı havuzlarında yürütülür, sonuçlar otomatik olarak GitLab Sayfalarında, Influx DB ve Grafana'da veya test raporlama sistemlerinde (TestRail, ReportPortal, vb.) yayınlanır. Otomasyon ve ölçeklendirme, GitLab CI projesine olağan gitlab-ci.yml şablonunu ekleyerek ve parametrelendirerek mümkün olduğunca basit bir şekilde uygulanır.
Bu yaklaşımın avantajı, tüm CI altyapısının, yük aracılarının, yük kaynaklarının docker görüntülerinin, test boru hatlarının ve raporların yayınlanmasının merkezi bir otomasyon departmanı (DevOps mühendisleri) tarafından sürdürülmesi ve yük testi mühendislerinin çabalarını test geliştirmeye odaklayabilmesidir. ve sonuçlarının analizi, altyapı sorunları ile uğraşmadan.
Açıklamanın basit olması için, test edilen hedef uygulamanın veya sunucunun zaten dağıtılmış ve önceden yapılandırılmış olduğunu varsayacağız (bunun için Python, SaltStack, Ansible vb.'deki otomatik komut dosyaları kullanılabilir). O halde, bir hizmet olarak yük testi kavramının tamamı üç aşamaya uyar: raporların hazırlanması, test edilmesi, yayınlanması. Diyagramla ilgili daha fazla ayrıntı (tüm resimler tıklanabilir):
Yük testinde temel kavramlar ve tanımlar
Yük testlerini gerçekleştirirken aşağıdakilere uymaya çalışıyoruz: , uygun terminolojiyi ve önerilen ölçümleri kullanın. Yük testindeki ana kavramların ve tanımların kısa bir listesini vereceğim.
Yük ajanı - uygulamanın başlatılacağı sanal makine - yük kaynağı (Apache JMeter, Yandex.Tank veya kendi kendine yazılan bir yük modülü).
Test hedefi (hedef) - yüklenecek sunucu veya sunucuda kurulu uygulama.
Test senaryosu (test durumu) - bir dizi parametreli adım: belirtilen parametrelere bağlı olarak sabit ağ istekleri ve yanıtları ile kullanıcı eylemleri ve bu eylemlere beklenen tepkiler.
Profil veya yük planı (profil) - içinde (Bölüm 4.2.4, s. 43) yük profilleri, belirli bir test için kritik olan metrikleri ve test sırasında yük parametrelerini değiştirme seçeneklerini tanımlar. Şekilde profil örneklerini görebilirsiniz.
Ölçek — önceden belirlenmiş bir dizi parametreye sahip bir komut dosyası.
Test planı (test planı) - bir dizi test ve bir yük profili.
Testran (test çalıştırması) - tamamen yürütülen bir yük senaryosu ve alınan raporla bir test çalıştırmanın bir tekrarı.
Ağ isteği (istek) — Bir aracıdan bir hedefe gönderilen bir HTTP isteği.
Ağ yanıtı (yanıt) — Hedeften aracıya gönderilen bir HTTP yanıtı.
HTTP yanıt kodu (HTTP yanıt durumu) - uygulama sunucusundan standart yanıt kodu.
İşlem, eksiksiz bir istek-yanıt döngüsüdür. Bir işlem, bir istek (talep) göndermenin başlangıcından bir yanıt (yanıt) almanın tamamlanmasına kadar sayılır.
İşlem Durumu - istek-yanıt döngüsünü başarıyla tamamlamanın mümkün olup olmadığı. Bu döngüde herhangi bir hata varsa, işlemin tamamı başarısız kabul edilir.
Yanıt süresi (gecikme) - bir istek (istek) göndermenin sonundan bir yanıt (yanıt) almaya başlamaya kadar geçen süre.
Metrikleri yükle - yük testi sürecinde belirlenen yüklenen hizmetin ve yük etkeninin özellikleri.
Yük parametrelerini ölçmek için temel metrikler
Metodolojide en sık kullanılan ve önerilenlerden bazıları (s. 36, 52) metrikler aşağıdaki tabloda gösterilmektedir. Ajan ve hedef için benzer metrikler aynı satırda listelenir.
Yükleme aracısı için metrikler
Yük altında test edilen hedef sistem veya uygulamanın ölçümleri
Numara vCPU ve hafıza RAM,
Disk - yük maddesinin "demir" özellikleri
işlemci, Bellek, Disk kullanımı - CPU, bellek ve disk yükleme dinamikleri
test sürecinde. Genellikle yüzde olarak ölçülür
maksimum kullanılabilir değerler
Ağ verimi (yük aracısında) - verim
Sunucudaki ağ arabirimi,
yük aracının kurulu olduğu yer.
Genellikle bayt/saniye (bps) cinsinden ölçülür
Ağ verimi(hedefte) - ağ arayüzü bant genişliği
hedef sunucuda. Genellikle bayt/saniye (bps) cinsinden ölçülür
Sanal kullanıcılar- sanal kullanıcı sayısı,
yük senaryolarının uygulanması ve
gerçek kullanıcı eylemlerini taklit etme
Sanal kullanıcı durumu, Başarılı/Başarısız/Toplam — başarılı ve
sanal kullanıcıların başarısız durumları
yük senaryoları ve bunların toplam sayısı için.
Genellikle tüm kullanıcıların tamamlaması beklenir.
yük profilinde belirtilen tüm görevleriniz.
Herhangi bir hata, gerçek bir kullanıcının yapamayacağı anlamına gelir.
sistemle çalışırken sorununuzu çözün
Saniye başına istek sayısı (dakika)- saniye (veya dakika) başına ağ isteklerinin sayısı.
Bir yükleme aracısının önemli bir özelliği, kaç tane istek üretebileceğidir.
Aslında bu, sanal kullanıcıların uygulamaya erişiminin bir taklididir.
Saniyedeki yanıt sayısı (dakika)
- saniye (veya dakika) başına ağ yanıtlarının sayısı.
Hedef hizmetin önemli bir özelliği: ne kadar
ile sorgulara yanıtlar oluşturun ve gönderin
yükleme ajanı
HTTP yanıt durumu— farklı yanıt kodlarının sayısı
yükleme aracısı tarafından alınan uygulama sunucusundan.
Örneğin, 200 OK, başarılı bir çağrı anlamına gelir,
ve 404 - kaynağın bulunamadığını
Gecikme (tepki süresi) - sondan itibaren geçen süre
bir yanıt (yanıt) almaya başlamadan önce bir istek (istek) göndermek.
Genellikle milisaniye (ms) cinsinden ölçülür
İşlem yanıt süresi— tamamlanmış bir işlemin süresi,
istek-yanıt döngüsünün tamamlanması.
Bu, isteğin (istek) gönderilmesinin başlangıcından itibaren geçen zamandır
bir yanıt (yanıt) almanın tamamlanmasına kadar.
İşlem süresi saniye (veya dakika) cinsinden ölçülebilir
çeşitli şekillerde: minimumu göz önünde bulundurun,
maksimum, ortalama ve örneğin yüzde 90.
Minimum ve maksimum okumalar aşırı
sistem performans durumu.
Doksanıncı yüzdelik en sık kullanılandır,
çoğu kullanıcının gösterdiği gibi,
sistem performansının eşiğinde rahatça çalışma
Saniye başına işlem sayısı (dakika) - tamamlananların sayısı
saniyedeki işlemler (dakika),
yani, uygulamanın ne kadarını kabul edebildiği ve
istekleri işlemek ve yanıtları vermek.
Aslında, bu sistemin verimidir
İşlem Durumu , Geçti / Kaldı / Toplam - sayı
başarılı, başarısız ve toplam işlem sayısı.
Gerçek kullanıcılar için başarısız
işlem aslında şu anlama gelir
yük altında sistemle çalışamama
Yük Testi Şematik Diyagramı
Yük testi kavramı çok basittir ve daha önce bahsettiğim üç ana aşamadan oluşur: Test Raporu Hazırlayani test hedeflerinin hazırlanması ve yük kaynakları için parametrelerin ayarlanması, ardından yük testlerinin yürütülmesi ve sonunda bir test raporunun oluşturulması ve yayınlanması.
Şematik notlar:
- QA.Tester, yük testi konusunda uzmandır,
- Hedef, yük altındaki davranışını öğrenmek istediğiniz hedef uygulamadır.
Diyagramdaki varlıkların, aşamaların ve adımların sınıflandırıcısı
Aşamalar ve adımlar
Neler oluyor
girişte ne var
çıktı nedir
Hazırla: test için hazırlık aşaması
Yük Parametreleri
Ayarlama ve başlatma
kullanıcı
yük parametreleri,
ölçüt seçimi ve
test planı hazırlama
(yük profili)
için özel seçenekler
yük aracı başlatma
Test planı
testin amacı
VM
Bulut dağıtımı
ile sanal makine
gerekli özellikler
Yükleme aracısı için sanal makine ayarları
için otomasyon betikleri
sanal makine oluşturma
VM yapılandırıldı
bulut
env
işletim sistemi kurulumu ve hazırlığı
çevre için
yük acentesi çalışması
için ortam ayarları
yük ajanı
için otomasyon betikleri
ortam ayarları
Hazırlanan ortam:
İşletim sistemi, hizmetler ve uygulamalar,
iş için gerekli
yük ajanı
LoadAgent'lar
Kurulum, konfigürasyon ve parametrelendirme
yükleme ajanı
Veya bir liman işçisi görüntüsü indirmek
önceden yapılandırılmış yük kaynağı
Kaynak liman işçisi görüntüsünü yükle
(YAT, JM veya kendi kendine yazılan çerçeve)
Ayarlar
yük ajanı
Kurun ve hazır olun
iş yük acentesi
Test: yük testlerinin yürütme aşaması. Kaynaklar, GitLab CI için ayrılmış aracı havuzlarında dağıtılan yük aracılarıdır
Yük
Load Agent'ı Başlatma
seçilen test planı ile
ve yük parametreleri
Kullanıcı Seçenekleri
başlatma için
yük ajanı
Test planı
testin amacı
Yürütme günlükleri
yük testleri
Sistem günlükleri
Hedef ölçütlerindeki ve yük aracısındaki değişikliklerin dinamiği
Aracıları Çalıştır
Aracı Yürütme
bir sürü test betiği
uyarınca
yük profili
Aracı Etkileşimini Yükle
test amaçlı
Test planı
testin amacı
Kayıtlar
"Ham" günlüklerin toplanması
yük testi sırasında:
yük aracı faaliyet kayıtları,
test hedefinin durumu
ve aracıyı çalıştıran VM
Yürütme günlükleri
yük testleri
Sistem günlükleri
Metrikleri
Test sırasında "ham" metrikleri toplama
Hedef metriklerindeki değişikliklerin dinamikleri
ve yük maddesi
Rapor: test raporu hazırlama aşaması
Jeneratör
Toplanan işleniyor
yükleme sistemi ve
izleme sistemi "ham"
ölçümler ve günlükler
içinde bir raporun oluşturulması
insan tarafından okunabilir form
elemanlarla mümkün
Analistler
Yürütme günlükleri
yük testleri
Sistem günlükleri
Metriklerdeki değişikliklerin dinamikleri
hedef ve yük aracı
İşlenmiş "ham" günlükler
uygun bir formatta
harici depolamaya yüklemeler
Statik yük raporu,
insan tarafından okunabilir
Yayınlamak
raporun yayınlanması
yük hakkında
harici test
hizmet
İşlenmiş "ham"
uygun bir formatta günlükler
dışarıya boşaltmak için
tonozlar
Harici olarak kaydedildi
depolama raporları
yük, uygun
insan analizi için
Yük kaynaklarını CI şablonunda bağlama
Pratik kısma geçelim. Şirketteki bazı projelerde nasıl olduğunu göstermek istiyorum. bir hizmet olarak yük testi kavramını hayata geçirdik.
İlk olarak, DevOps mühendislerimizin yardımıyla, yük testleri yapmak için GitLab CI'da özel bir aracı havuzu oluşturduk. Bunları şablonlarda derleme havuzları gibi başkalarıyla karıştırmamak için bu aracılara etiketler ekledik, : yük. Diğer anlaşılır etiketleri kullanabilirsiniz. Onlar sorar GitLab CI Çalıştırıcıları.
Donanım tarafından gerekli güç nasıl bulunur? Yük aracılarının özellikleri - yeterli sayıda vCPU, RAM ve Disk - aracı üzerinde Docker, Python (Yandex.Tank için), GitLab CI aracısı, Java (Apache JMeter için) çalışıyor olması gerektiği gerçeğine dayanarak hesaplanabilir. . JMeter altındaki Java için ayrıca minimum 512 MB RAM kullanılması önerilir ve üst sınır olarak, .
Bu nedenle, deneyimlerimize dayanarak, yük aracıları için en az 4 vCPU, 4 GB RAM, 60 GB SSD kullanmanızı öneririz. Ağ kartının verimi, yük profilinin gereksinimlerine göre belirlenir.
Esas olarak iki yük kaynağı kullanıyoruz - Apache JMeter ve Yandex.Tank liman işçisi görüntüleri.
yük testi için Yandex'in açık kaynaklı bir aracıdır. Modüler mimarisi, Phantom'un yüksek performanslı eşzamansız isabet tabanlı HTTP istek üretecine dayanmaktadır. Tank, SSH protokolü aracılığıyla test edilen sunucunun kaynaklarının yerleşik olarak izlenmesine sahiptir, belirtilen koşullar altında testi otomatik olarak durdurabilir, sonuçları hem konsolda hem de grafikler şeklinde görüntüleyebilir, modüllerinizi bağlayabilirsiniz işlevselliğini genişletmek için. Bu arada, Tankı henüz ana akım olmadığında kullandık. Makalede "» 2013 yılında onunla nasıl yük testi yaptığımızın öyküsünü okuyabilirsiniz. firmamızın ürünlerinden biridir.
Apache'den açık kaynaklı bir yük testi aracıdır. Hem statik hem de dinamik web uygulamalarını test etmek için eşit derecede kullanılabilir. JMeter çok sayıda protokolü ve uygulamalarla etkileşim kurma yollarını destekler: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, vb.), SOAP / REST Web hizmetleri, FTP, TCP, LDAP, SMTP(S), POP3( S) ) ve IMAP(S), JDBC aracılığıyla veritabanları, kabuk komutlarını yürütebilir ve Java nesneleri ile çalışabilir. JMeter, test planları oluşturmak, hata ayıklamak ve yürütmek için bir IDE'ye sahiptir. Ayrıca herhangi bir Java uyumlu işletim sisteminde (Linux, Windows, Mac OS X) komut satırı işlemi için bir CLI vardır. Araç, dinamik olarak bir HTML test raporu oluşturabilir.
Şirketimizde kullanım kolaylığı için, test edenlerin ortamı değiştirip ekleyebilmeleri için GitLab CI'da yük kaynaklarının docker görüntülerini dahili olarak yayınladık. . Bu, yük testleri için bunları boru hatlarına bağlamayı daha hızlı ve daha kolay hale getirir. Docker, GitLab CI aracılığıyla kayıt defterine nasıl gönderilir - bkz. .
Yandex.Tank için şu temel docker dosyasını aldık:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]Ve Apache JMeter için bu:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Sürekli entegrasyon sistemimizin nasıl çalıştığını “ yazımızdan okuyabilirsiniz.'.
Şablon ve ardışık düzen
Projede yük testleri yapmak için bir şablon örneği mevcuttur. . Şablonu kullanma talimatlarını okuyabilirsiniz. Şablonun kendisinde (dosya ) her adımın neyden sorumlu olduğuna dair notlar vardır.
Şablon çok basittir ve yukarıdaki şemada açıklanan yük testinin üç aşamasını gösterir: raporların hazırlanması, test edilmesi ve yayınlanması. Bunun sorumlusu : Hazırla, Test Et ve Raporla.
- evre test hedeflerini önceden yapılandırmak veya kullanılabilirliklerini kontrol etmek için kullanılmalıdır. Yük kaynakları ortamının yapılandırılması gerekmez, bunlar liman işçisi görüntüleri olarak önceden oluşturulur ve liman işçisi kayıt defterine gönderilir: Test aşamasında istenen sürümü belirtmeniz yeterlidir. Ancak bunları yeniden oluşturabilir ve kendi değiştirilmiş görüntülerinizi oluşturabilirsiniz.
- evre yük kaynağını belirtmek, testleri çalıştırmak ve test yapılarını depolamak için kullanılır. Herhangi bir yük kaynağını seçebilirsiniz: Yandex.Tank, Apache JMeter, kendi yükleme kaynağınız veya hepsi bir arada. Gereksiz kaynakları devre dışı bırakmak için işi yorumlayın veya silin. Yük kaynakları için giriş noktaları:
- Yandex.Tank için başlatma parametreleri .,
- Apache JMeter başlangıç parametreleri dosyada belirtilmiştir .
Not: Derleme yapılandırma şablonu, CI sistemiyle etkileşim kurmak için kullanılır ve içine test mantığının yerleştirilmesi anlamına gelmez. Testler için, kontrol bash betiğinin bulunduğu giriş noktası belirtilir. Test çalıştırma, rapor oluşturma ve test komut dosyalarının kendileri QA mühendisleri tarafından uygulanmalıdır. Demoda her iki yük kaynağı için de en basit test olarak Yandex ana sayfa isteği kullanılmıştır. Komut dosyaları ve test parametreleri dizindedir .
- Sahnede Test aşamasında elde edilen test sonuçlarının harici depolamalara, örneğin GitLab Sayfalarına veya özel raporlama sistemlerine nasıl yayınlanacağını açıklamanız gerekir. GitLab Sayfaları, testler tamamlandıktan sonra ./public dizininin boş olmamasını ve en az bir index.html dosyası içermesini gerektirir. GitLab Sayfaları hizmetinin nüansları hakkında bilgi edinebilirsiniz. .
Verilerin nasıl dışa aktarılacağına ilişkin örnekler:
- JMeter'dan şuraya ,
- Yandex.Tank'tan .
Kurulum talimatlarını gönderme:
- HTML statiği ,
- InfluxDB'ye ve ardından .
Demo örneğinde, yük testleri ve iki yük kaynağı (gereksiz olanı devre dışı bırakabilirsiniz) içeren ardışık düzen şuna benzer:
Apache JMeter kendisi bir HTML raporu oluşturabilir, bu nedenle standart araçları kullanarak GitLab Sayfalarına kaydetmek daha karlı olur. Apache JMeter raporu şu şekilde görünür:
Yandex.Tank demo örneğinde yalnızca GitLab Sayfaları bölümünde. Test sırasında Tank, sonuçları InfluxDB veritabanına kaydedebilir ve oradan örneğin Grafana'da görüntülenebilir (yapılandırma dosyada yapılır ). Tank'ın raporu Grafana'da böyle görünüyor:
Özet
Yazıda "load test as a service" (load test as a service) kavramından bahsettim. Ana fikir, önceden yapılandırılmış yük aracı havuzlarının altyapısını, yük kaynaklarının docker görüntülerini, raporlama sistemlerini ve bunları basit bir .gitlab-ci.yml şablonuna (örnek) dayalı GitLab CI'da birleştiren bir işlem hattını kullanmaktır ). Tüm bunlar, küçük bir otomasyon mühendisleri ekibi tarafından desteklenir ve ürün ekiplerinin talebi üzerine çoğaltılır. Umarım bu, şirketinizde benzer bir plan hazırlamanıza ve uygulamanıza yardımcı olur. İlginiz için teşekkür ederim!
Not: Şirketimizde bir hizmet olarak yük testi konseptinin uygulanmasıyla ilgili teknik yardımları için meslektaşlarım Sergey Kurbanov ve Nikolai Yusev'e çok teşekkür etmek istiyorum.
yazar: - Milletvekili Positive Technologies'te Teknoloji ve Geliştirme Süreçleri (DevOps) Başkanı
Kaynak: habr.com