Testcontainers'ı kullanmak, test senaryolarıyla çalışma sürecini kökten geliştirdi. Bu araç sayesinde entegrasyon testleri için ortamlar oluşturmak daha kolay hale geldi ( makalesine bakın). Artık veritabanlarının, mesaj aracılarının ve diğer hizmetlerin farklı sürümlerine sahip kapları kolayca başlatabiliyoruz. Entegrasyon testleri için Testcontainers'ın vazgeçilmez olduğu kanıtlanmıştır. Kafka ile Test Etmede Yalıtım Yük testi, fonksiyonel teste göre daha az yaygın olsa da çok daha keyifli olabilir. Grafikleri incelemek ve belirli bir hizmetin performansını analiz etmek gerçek bir zevk getirebilir. Bu tür görevler nadirdir ancak benim için özellikle heyecan vericidirler. Bu makalenin amacı, normal entegrasyon testlerinin yazıldığı şekilde, yük testi için bir kurulum oluşturmaya yönelik bir yaklaşımı göstermektir: Gradle proje ortamında Testcontainer'ları kullanan Spock testleri şeklinde. Gatling, WRK ve Yandex.Tank gibi yük testi araçları kullanılır. Yük Testi Ortamı Oluşturma Araç seti: Gradle + Spock Framework + Testcontainers. Uygulama değişkeni ayrı bir Gradle modülüdür. Kullanılan yük testi araçları Gatling, WRK ve Yandex.Tank'tır. Test nesnesiyle çalışmanın iki yaklaşımı vardır: Yayınlanan görsellerin test edilmesi; Projenin kaynak kodundan görseller oluşturmak ve test etmek. İlk durumda, projenin versiyonundan ve değişikliklerinden bağımsız bir dizi yük testimiz var. Bu yaklaşımın gelecekte sürdürülmesi daha kolaydır ancak yalnızca yayınlanan görüntülerin test edilmesiyle sınırlıdır. Elbette bu görüntüleri yerel olarak manuel olarak oluşturabiliriz, ancak bu daha az otomatiktir ve tekrarlanabilirliği azaltır. Gerekli görüntüler olmadan CI/CD'de çalıştırıldığında testler başarısız olur. İkinci durumda testler hizmetin en son sürümü üzerinde gerçekleştirilir. Bu, yük testlerinin CI'ya entegre edilmesine ve hizmet sürümleri arasında performans verileri değişikliklerinin elde edilmesine olanak tanır. Ancak yük testleri genellikle birim testlerden daha uzun sürer. Bu tür testleri kalite kapısının bir parçası olarak CI'ya dahil etme kararı size bağlıdır. Bu makale ilk yaklaşımı ele almaktadır. Spock sayesinde karşılaştırmalı analiz için hizmetin birden fazla sürümü üzerinde testler gerçekleştirebiliyoruz: where: image | _ 'avvero/sandbox:1.0.0' | _ 'avvero/sandbox:1.1.0' | _ Bu makalenin amacının tam ölçekli yük testi değil, test alanının organizasyonunu göstermek olduğunu unutmamak önemlidir. Hedef Hizmet Test nesnesi için, bir uç nokta yayınlayan ve istekleri işlemek için harici bir kaynaktan gelen verileri kullanan Sandbox adlı basit bir HTTP hizmetini ele alalım. Hizmetin bir veritabanı var. Dockerfile dahil olmak üzere hizmetin kaynak kodu, proje deposunda mevcuttur. spring-sandbox Modül Yapısına Genel Bakış Makalenin ilerleyen kısımlarında ayrıntılara girerken, kompozisyonunun anlaşılmasını sağlamak için Gradle modülünün yapısına kısa bir genel bakışla başlamak istiyorum: load-tests load-tests/ |-- src/ | |-- gatling/ | | |-- scala/ | | | |-- MainSimulation.scala # Main Gatling simulation file | | |-- resources/ | | | |-- gatling.conf # Gatling configuration file | | | |-- logback-test.xml # Logback configuration for testing | |-- test/ | | |-- groovy/ | | | |-- pw.avvero.spring.sandbox/ | | | | |-- GatlingTests.groovy # Gatling load test file | | | | |-- WrkTests.groovy # Wrk load test file | | | | |-- YandexTankTests.groovy # Yandex.Tank load test file | | |-- java/ | | | |-- pw.avvero.spring.sandbox/ | | | | |-- FileHeadLogConsumer.java # Helper class for logging to a file | | |-- resources/ | | | |-- wiremock/ | | | | |-- mappings/ # WireMock setup for mocking external services | | | | | |-- health.json | | | | | |-- forecast.json | | | |-- yandex-tank/ # Yandex.Tank load testing configuration | | | | |-- ammo.txt | | | | |-- load.yaml | | | | |-- make_ammo.py | | | |-- wrk/ # LuaJIT scripts for Wrk | | | | |-- scripts/ | | | | | |-- getForecast.lua |-- build.gradle Proje deposu - . https://github.com/avvero/testing-bench Çevre Yukarıdaki açıklamadan hizmetin iki bağımlılığı olduğunu görüyoruz: https://external-weather-api.com hizmeti ve bir veritabanı. Açıklamaları aşağıda verilecektir, ancak şemanın tüm bileşenlerinin Docker ortamında iletişim kurmasını sağlayarak başlayalım - ağı açıklayacağız: def network = Network.newNetwork() ve her bileşen için ağ takma adları sağlayın. Bu son derece kullanışlıdır ve entegrasyon parametrelerini statik olarak tanımlamamıza olanak tanır. WireMock ve yük testi yardımcı programları gibi bağımlılıkların çalışması için yapılandırma gerekir. Bunlar, konteynere aktarılabilecek parametreler veya konteynerlere bağlanması gereken tüm dosya ve dizinler olabilir. Ayrıca yaptıkları işin sonuçlarını da konteynerlerden almamız gerekiyor. Bu görevleri çözmek için iki dizi dizin sağlamamız gerekir: — modülün kaynak dizini, doğrudan konumunda. workingDirectory load-tests/ — ölçümler ve günlükler de dahil olmak üzere çalışmanın sonuçlarının dizini. Bununla ilgili daha fazla bilgiyi raporlar bölümünde bulacaksınız. reportDirectory Veri tabanı Sandbox hizmeti, veritabanı olarak Postgres'i kullanır. Bu bağımlılığı şu şekilde tanımlayalım: def postgres = new PostgreSQLContainer<>("postgres:15-alpine") .withNetwork(network) .withNetworkAliases("postgres") .withUsername("sandbox") .withPassword("sandbox") .withDatabaseName("sandbox") Bildirim, Sandbox hizmetinin veritabanına bağlanmak için kullanacağı ağ takma adını belirtir. Veritabanıyla entegrasyon açıklamasını tamamlamak için hizmetin aşağıdaki parametrelerle sağlanması gerekir: postgres 'spring.datasource.url' : 'jdbc:postgresql://postgres:5432/sandbox', 'spring.datasource.username' : 'sandbox', 'spring.datasource.password' : 'sandbox', 'spring.jpa.properties.hibernate.default_schema': 'sandbox' Veritabanı yapısı, Flyway kullanılarak uygulamanın kendisi tarafından yönetildiğinden, testte herhangi bir ek veritabanı manipülasyonuna gerek yoktur. https://external-weather-api.com'a Yönelik Alaycı İstekler Gerçek bileşeni bir kapta çalıştırma olanağımız, gerekliliğimiz veya isteğimiz yoksa, API'si için bir örnek sağlayabiliriz. https://external-weather-api.com hizmeti için WireMock kullanılır. WireMock konteynerinin beyanı şu şekilde görünecektir: def wiremock = new GenericContainer<>("wiremock/wiremock:3.5.4") .withNetwork(network) .withNetworkAliases("wiremock") .withFileSystemBind("${workingDirectory}/src/test/resources/wiremock/mappings", "/home/wiremock/mappings", READ_WRITE) .withCommand("--no-request-journal") .waitingFor(new LogMessageWaitStrategy().withRegEx(".*https://wiremock.io/cloud.*")) wiremock.start() WireMock sahte yapılandırma gerektirir. talimatı, yerel dosya yolu ile Docker kapsayıcısının içindeki yol arasındaki dosya sistemi bağlamasını açıklar. Bu durumda, yerel makinedeki dizini, WireMock konteynerinin içindeki dizinine bağlanacaktır. withFileSystemBind "${workingDirectory}/src/test/resources/wiremock/mappings" /home/wiremock/mappings Aşağıda dizindeki dosya kompozisyonunu anlamak için proje yapısının ek bir kısmı bulunmaktadır: load-tests/ |-- src/ | |-- test/ | | |-- resources/ | | | |-- wiremock/ | | | | |-- mappings/ | | | | | |-- health.json | | | | | |-- forecast.json Sahte yapılandırma dosyalarının WireMock tarafından doğru şekilde yüklendiğinden ve kabul edildiğinden emin olmak için bir yardımcı kapsayıcı kullanabilirsiniz: helper.execInContainer("wget", "-O", "-", "http://wiremock:8080/health").getStdout() == "Ok" Yardımcı kapsayıcı şu şekilde açıklanmaktadır: def helper = new GenericContainer<>("alpine:3.17") .withNetwork(network) .withCommand("top") Bu arada, IntelliJ IDEA 2024.1 sürümü ve IDE, sahte yapılandırma dosyaları oluşturulurken öneriler sunuyor. WireMock desteğini sundu Hedef Hizmet Başlatma Yapılandırması Sandbox hizmet konteynerinin bildirimi aşağıdaki gibi görünür: def javaOpts = ' -Xloggc:/tmp/gc/gc.log -XX:+PrintGCDetails' + ' -XX:+UnlockDiagnosticVMOptions' + ' -XX:+FlightRecorder' + ' -XX:StartFlightRecording:settings=default,dumponexit=true,disk=true,duration=60s,filename=/tmp/jfr/flight.jfr' def sandbox = new GenericContainer<>(image) .withNetwork(network) .withNetworkAliases("sandbox") .withFileSystemBind("${reportDirectory}/logs", "/tmp/gc", READ_WRITE) .withFileSystemBind("${reportDirectory}/jfr", "/tmp/jfr", READ_WRITE) .withEnv([ 'JAVA_OPTS' : javaOpts, 'app.weather.url' : 'http://wiremock:8080', 'spring.datasource.url' : 'jdbc:postgresql://postgres:5432/sandbox', 'spring.datasource.username' : 'sandbox', 'spring.datasource.password' : 'sandbox', 'spring.jpa.properties.hibernate.default_schema': 'sandbox' ]) .waitingFor(new LogMessageWaitStrategy().withRegEx(".*Started SandboxApplication.*")) .withStartupTimeout(Duration.ofSeconds(10)) sandbox.start() Önemli parametreler ve JVM ayarları şunları içerir: Çöp toplama olayı bilgilerinin toplanması. JVM performans verilerini kaydetmek için Java Flight Recorder'ın (JFR) kullanılması. Ayrıca dizinler, hizmetin tanılama sonuçlarını kaydetmek için yapılandırılmıştır. Kerestecilik Test senaryosu yazma ve yapılandırma aşamasında muhtemelen gerekli olan herhangi bir konteynerin loglarını bir dosyaya görmeniz gerekiyorsa, konteyneri tanımlarken aşağıdaki talimatı kullanabilirsiniz: .withLogConsumer(new FileHeadLogConsumer("${reportDirectory}/logs/${alias}.log")) Bu durumda, bir dosyaya sınırlı miktarda günlük yazılmasına izin veren sınıfı kullanılır. Bunun nedeni, yük testi senaryolarında günlüğün tamamına ihtiyaç duyulmaması ve hizmetin düzgün çalışıp çalışmadığını değerlendirmek için kısmi bir günlüğün yeterli olmasıdır. FileHeadLogConsumer Yük Testlerinin Uygulanması Yük testi için birçok araç vardır. Bu makalede bunlardan üçünü kullanmayı düşünmeyi öneriyorum: Gatling, Wrk ve Yandex.Tank. Her üç araç da birbirinden bağımsız olarak kullanılabilir. mitralyöz Gatling, Scala'da yazılmış açık kaynaklı bir yük test aracıdır. Karmaşık test senaryolarının oluşturulmasına olanak tanır ve ayrıntılı raporlar sunar. Gatling'in ana simülasyon dosyası modüle bir Scala kaynağı olarak bağlanır ve sözdizimi vurgulama ve dokümantasyon referansı için yöntemler arasında gezinme dahil olmak üzere IntelliJ IDEA'nın tüm destek yelpazesini kullanarak çalışmayı kolaylaştırır. Gatling için konteyner konfigürasyonu aşağıdaki gibidir: def gatling = new GenericContainer<>("denvazh/gatling:3.2.1") .withNetwork(network) .withFileSystemBind("${reportDirectory}/gatling-results", "/opt/gatling/results", READ_WRITE) .withFileSystemBind("${workingDirectory}/src/gatling/scala", "/opt/gatling/user-files/simulations", READ_WRITE) .withFileSystemBind("${workingDirectory}/src/gatling/resources", "/opt/gatling/conf", READ_WRITE) .withEnv("SERVICE_URL", "http://sandbox:8080") .withCommand("-s", "MainSimulation") .waitingFor(new LogMessageWaitStrategy() .withRegEx(".*Please open the following file: /opt/gatling/results.*") .withStartupTimeout(Duration.ofSeconds(60L * 2)) ); gatling.start() Kurulum diğer kapsayıcılarla hemen hemen aynıdır: raporlara yönelik dizini bağlayın. reportDirectory Yapılandırma dosyalarının dizinini bağlayın. workingDirectory Simülasyon dosyalarının dizinini bağlayın. workingDirectory Ek olarak parametreler konteynere iletilir: Sandbox hizmetinin URL değerini içeren ortam değişkeni. Bununla birlikte, daha önce de belirtildiği gibi, ağ takma adlarının kullanılması, URL'nin doğrudan senaryo koduna sabit kodlanmasına olanak tanır. SERVICE_URL Belirli bir simülasyonu çalıştırmak için komutu. -s MainSimulation Neyin nereye iletildiğini anlamak için proje kaynak dosyası yapısını burada hatırlatıyoruz: load-tests/ |-- src/ | |-- gatling/ | | |-- scala/ | | | |-- MainSimulation.scala # Main Gatling simulation file | | |-- resources/ | | | |-- gatling.conf # Gatling configuration file | | | |-- logback-test.xml # Logback configuration for testing Bu son kapsayıcı olduğundan ve tamamlanmasının ardından sonuç almayı beklediğimizden, beklentiyi belirledik. Bu mesaj konteyner kayıtlarında göründüğünde veya saniye sonra test sona erecektir. .withRegEx(".*Please open the following file: /opt/gatling/results.*") 60 * 2 Bu aracın senaryolarının DSL'sine girmeyeceğim. Kullanılan senaryonun kodunu kontrol edebilirsiniz. proje deposundan Wrk basit ve hızlı bir yük test aracıdır. Minimum kaynakla önemli bir yük oluşturabilir. Temel özellikler şunları içerir: Wrk İstekleri yapılandırmak için Lua komut dosyaları desteği. Çoklu iş parçacığı nedeniyle yüksek performans. Minimum bağımlılıkla kullanım kolaylığı. Wrk için konteyner yapılandırması aşağıdaki gibidir: def wrk = new GenericContainer<>("ruslanys/wrk") .withNetwork(network) .withFileSystemBind("${workingDirectory}/src/test/resources/wrk/scripts", "/tmp/scripts", READ_WRITE) .withCommand("-t10", "-c10", "-d60s", "--latency", "-s", "/tmp/scripts/getForecast.lua", "http://sandbox:8080/weather/getForecast") .waitingFor(new LogMessageWaitStrategy() .withRegEx(".*Transfer/sec.*") .withStartupTimeout(Duration.ofSeconds(60L * 2)) ) wrk.start() Wrk'un Sandbox hizmetine yapılan isteklerle çalışmasını sağlamak için Lua betiği aracılığıyla istek açıklaması gereklidir, bu nedenle betik dizinini bağlarız. Komutu kullanarak, hedef hizmet yönteminin betiğini ve URL'sini belirterek Wrk'yi çalıştırıyoruz. Wrk, sonuçlarına göre günlüğe beklentileri belirlemek için kullanılabilecek bir rapor yazar. workingDirectory Yandex.Tank Yandex.Tank, Yandex tarafından geliştirilen bir yük test aracıdır. JMeter ve Phantom gibi çeşitli yük testi motorlarını destekler. Yük testi sonuçlarını saklamak ve görüntülemek için ücretsiz hizmetini kullanabilirsiniz. Overload İşte konteyner yapılandırması: copyFiles("${workingDirectory}/src/test/resources/yandex-tank", "${reportDirectory}/yandex-tank") def tank = new GenericContainer<>("yandex/yandex-tank") .withNetwork(network) .withFileSystemBind("${reportDirectory}/yandex-tank", "/var/loadtest", READ_WRITE) .waitingFor(new LogMessageWaitStrategy() .withRegEx(".*Phantom done its work.*") .withStartupTimeout(Duration.ofSeconds(60L * 2)) ) tank.start() Sandbox için yük testi yapılandırması iki dosyayla temsil edilir: ve . Kapsayıcı açıklamasının bir parçası olarak, yapılandırma dosyaları, çalışma dizini olarak bağlanacak olan dosyasına kopyalanır. Neyin nereye iletildiğini anlamak için proje kaynak dosyalarının yapısı aşağıda verilmiştir: load.yaml ammo.txt reportDirectory load-tests/ |-- src/ | |-- test/ | | |-- resources/ | | | |-- yandex-tank/ | | | | |-- ammo.txt | | | | |-- load.yaml | | | | |-- make_ammo.py Raporlar JVM performans kayıtları ve günlükleri de dahil olmak üzere test sonuçları dizinine kaydedilir; burada her test çalışmasının zaman damgasını temsil eder. build/${timestamp} ${timestamp} Aşağıdaki raporlar incelemeye sunulacaktır: Çöp Toplayıcı günlükleri. WireMock günlükleri. Hedef hizmet günlükleri. Wrk günlükleri. JFR (Java Uçuş Kaydı). Gatling kullanılmışsa: Toplama raporu. Günlükleri toplama. Wrk kullanılmışsa: Wrk günlükleri. Yandex.Tank kullanıldıysa: ek yüklemeyle birlikte Yandex.Tank sonuç dosyaları. Overload'a Yandex.Tank günlükleri. Raporların dizin yapısı aşağıdaki gibidir: load-tests/ |-- build/ | |-- ${timestamp}/ | | |-- gatling-results/ | | |-- jfr/ | | |-- yandex-tank/ | | |-- logs/ | | | |-- sandbox.log | | | |-- gatling.log | | | |-- gc.log | | | |-- wiremock.log | | | |-- wrk.log | | | |-- yandex-tank.log | |-- ${timestamp}/ | |-- ... Çözüm Yük testi, yazılım geliştirme yaşam döngüsünde çok önemli bir aşamadır. Bir uygulamanın çeşitli yük koşulları altında performansını ve kararlılığını değerlendirmeye yardımcı olur. Bu makale, test ortamının kolay ve verimli bir şekilde kurulmasına olanak tanıyan Testcontainer'ları kullanarak bir yük testi ortamı oluşturmaya yönelik bir yaklaşım sundu. Test kapsayıcıları, entegrasyon testleri için ortamların oluşturulmasını önemli ölçüde basitleştirerek esneklik ve izolasyon sağlar. Yük testi için bu araç, gerekli kapsayıcıların farklı hizmet ve veritaban sürümleriyle konuşlandırılmasına olanak tanıyarak testlerin yürütülmesini kolaylaştırır ve sonuçların tekrarlanabilirliğini artırır. Gatling, Wrk ve Yandex.Tank için sağlanan yapılandırma örneklerinin yanı sıra konteyner kurulumu, çeşitli araçların etkili bir şekilde nasıl entegre edileceğini ve test parametrelerinin nasıl yönetileceğini gösterir. Ek olarak, uygulama performansını analiz etmek ve geliştirmek için gerekli olan test sonuçlarının günlüğe kaydedilmesi ve kaydedilmesi süreci de açıklandı. Bu yaklaşım gelecekte daha karmaşık senaryoları desteklemek ve diğer izleme ve analiz araçlarıyla entegrasyonu sağlamak üzere genişletilebilir. Bu makaleye gösterdiğiniz ilgi için teşekkür ederiz ve faydalı testler yazma çabanızda iyi şanslar!
