Gatling ile Performans Test Uygulaması — 2

Korhan Hergüner
QaColony
Published in
6 min readApr 23, 2018
Gatling

Hi guys 😃 diyerek kaldığımız yerden devam ediyoruz. Gatling ile Performans Test Uygulaması serisinde ilk bölümde; web sitesi geliştirmesi sonrasında beni sayfam yavaş yükleniyor denildiğinde hangi noktaların geliştirilmesi gerektiği incelendi yani kısaca nasıl daha performanslı bir site geliştiririz ve bunu nasıl test edebiliriz. İkinci bölümün içeriği sitemizi gerçek zamanlı olarak test etmek için kullandığımız araçlar hakkında konuşuyor olacağız.

Projenin örneği github QaColony sayfasında yer almaktadır.

Malzeme Listesi 😃

  • Fidder web proxy
  • Gatling 2.3.0
  • Maven
  • Java 1.7+
  • Scala 2.12.3

Gatling bizim web sayfamızı yada arkaplandaki servisleri test etmek için kullandığımız test ortamı aracıdır. Tabanında yazılımıcı birini ister sürükle bırakda bir noktaya kadar demi 😁 aslında play&record denilen bir özelliğide var ama ben pek kullanmaktan yana değilim çünkü Https yani 443 port özelliği olan bir sayfaya yük testi için script hazırlarken kayıt esnasında sertifika problemi yaşadım ve dışarıdan import ederken sertifika nasıl elde edilir yada benzeri bir problemle zaman kaybı yaşamıştım. Bizde QaColony ekibi olarak bu problemleri aşmanın en hızlı yolu Telerik Fiddler aracı sayesinde web akışını dinleyerek request yapısını ortaya çıkartıyoruz.

Fiddler

Fiddler kullanım sebebini söyle anlatasam daha iyi olur herhalde, herhangi bir site yada servis için script hazırlarken sizin client tarafından server tarafına göndereceğiniz header bilgisine ihtiyaç vardır. Header bilgisini elde etmeninde en kolay yöntemi fiddler kullanıp akışı dinleyerek yapabilirsiniz. Fiddler bize aşağıdaki gibi header bilgisini döndürdükten sonra scriptte kullanabiliriz.

Anasayfa'nın header bilgisi"Host" -> "github.com",
"Connection" -> "keep-alive",
"Cache-Control" -> "max-age=0",
"Upgrade-Insecure-Requests" -> "1",
"User-Agent" -> "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36",
"Accept" -> "text/html, application/xhtml+xml, application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8",
"Referer" -> "https://github.com/", "Accept-Encoding" -> "gzip, deflate, br",
"Accept-Language" -> "en-US,en;q=0.9,tr;q=0.8,da;q=0.7"

Test için web sayfasında takip edeceğimiz akış aşağıdaki gibidir. Kullanıcı ilk olarak

  1. Github anasayfasına istekte bulunur.
  2. Login sayfası ziyaret eder ve burada bize body olarak dönen HTML sayfasından TOKEN bilgisi ve COMMIT bilgisi alırız. Bu iki önemli bilgi ile kullanıcı adı ve şifre ile birlikte post edilir.
  3. Giriş onaylandıktan sonra user araması yapıyoruz. Tabikide kimi arıyoruz kherguner 😃 🙌 yani bu yazı dizisini hazırlayan kişi
  4. Yukarıdaki işlem sırası tamamlandıktan sonra logout sayfasına istekte bulunup dönen HTML body içerisinden logout için gerekli olan Token bilgisini alıp utf8 parametresi ile birlikte post yapıyoruz
  5. Logout sonrası yeniden anasayfa gidiyoruz
Yük Testi Senaryosu

Gatling ile projeyi oluşturken maven kullandık çünkü bağımlılıkları yönetmek daha kolay oluyor. Aşağıdaki kod bloğunda scala 2.12.3 versiyonu, gatling versiyonunu <gatling.version>2.3.0</gatling.version> olarak set ediyoruz.

Artık buradan sonra bütün servisleri tek tek açıklamaktansa sadece login servisini nasıl hazırlandığını anlatacağım 😜 ama korkmayın diğer servislerde buradaki mantıkla doğru orantılı hadi o zaman login servisini anlatma başlayalım.

Yukarıdaki kod blogu Login servisine aittir. Login servisi için ‘github.com/login, github.com/session ve github.com/’ 3 farklı servise istekte bulunduk. Web sayfası için istekte bulunurken iki temel yöntem olan GET yada POST metotlarını kullandık. Her bir istek için 3 farklı header bilgi tanımlandı fakat burada header bilgileri MAP tipinde tanımlıyoruz ve her bir istekte header bilgilerini headers(MAP:TYPE) metodu içine set ediyoruz. Web sayfasına istekte bulunma yöntemi POST ise formparam(“key”,”value”) metodunu kullanarak http isteğine değerlerimizi ekliyoruz. Check metodunun temel yapısı if gibidir diye biliriz burada http isteğinden dönen cevabın 200 olup olmadığını kontrol ediyoruz eğer 200 dışında her hangi bir değer gelirse o istek false dönecektir.

Response Body
<input type="hidden" name="authenticity_token" value="o7A5rdWXN+BGKMch7qtxO2RMfU/zHD5jhlQ2PZzMwTdobzccuIi7N98C9TqUfVQ4ETObzA7zFHAqlEWpMUudCw==">
Kontrol Yöntemi
check(css("input:nth-of-type(2)", "value").saveAs("TokenUserName"))
check(css("input:nth-of-type(3)", "value").saveAs("Commit"))

Yukarıdaki kod css selector kullanımı için bir örnektir. İlk olarak github.com/login sayfasına istekte bulunup response body içerisinde bize bir sonraki aşamada gerekli olan iki değeri yakalamak gerek TokenUserName ve Commit değerlerini session değişkenimize kayıt ediyoruz. İlk Check blogunun anlamı input tipinde birden fazla değer dönüyor fakat bu dönenler içinden bize ikinci olanın value değerini al ve bunu session içinde TokenUserName olarak tut.

CSV Okuma
private val userDocumentation = csv("user.csv").circular
Post Yöntemi
formParam("authenticity_token", session => {session ("TokenUserName").as[String]})
formParam("login", """${email}""") formParam("password","""${password}""")
Response Kod Check
check(status.in(200,302))

Css selector ile elde ettiğimiz TokenUserName değerini session içinden alıp key değeri “authenticity_token” olan sorguya value değeri olarak set ediyoruz. İkinci formparam yöntemi bir dosyadan okuyup 59. kod satırında okuma işlemi yapıyoruz sonrasında CSV dosyasındaki sütun ismi ile (“””${email}””") çağırıyoruz. Http cevabını kontrol etmek için 72. satırda bize dönen kod 200 yada 302 olabilir diyoruz şayet 302 olursa sayfa işlem neticesinde bizi başka bir sayfaya yönlendirmiştir.

Yukarıdaki bölümde örnek bir servis çağrısını anlatmıştık. Simdi bu bölümde senaryo nasıl kurulur ona bir göz atalım, Öncellikle ilk olarak Gatling’in sağladığı Simulation sınıfından kalıtım alarak başlıyoruz. 10, 11 ve 12. satırlarda testimize dışarıdan çalıştırabilmek için gerekli parametreleri alabilmek için tanımladık. Sonra http konfigürasyonları için baseurlhangi web sitesi”, diasableFollowRedirectbenim isteğim dışında yönlendirme yapma” ve diasableWarmuptest öncesi default olarak gatling.io test yapar” kullandık. 19 ile 28. satırlar arasında senaryo yapısı hazırlanıyor burada dikkat edilmesi gereken nokta servisler yazdığımız sırada çalışıyor. Son olarak setup metodunu kullanarak az önce kurmuş olduğumuz senaryoyu çağırıyoruz ve inject metoduna kullanıcıları sisteme nasıl dahil edeceğimizi yazıyoruz. Buradaki atOnceUsers metotu kullanıcıları bir anda sisteme dahil eder, ilk bölümde bahsettiğim gibi sakın 20K kullanıcıyı sisteme bir anda dahil etmeyin 😯 son olarak setup metotu için 14. satırda ayarlarını yaptığımız protocol bağlantısını ekliyoruz. Test sırasında isteğe bağlı olarak assertion yapısını kullanıp test geneli hakkında istatistiksel bilgiler tutabiliriz.

Scenario Definiton

Test bittiği zaman size en son satırda oluşturduğu html formatındaki dosyanın local adresini ekrana yazar ve o adresi alıp tarayıcıya yapıştırdığınızda size yukarıdaki grafiğe benzer bir ekran açılacaktır. Local’de test sonuçlarının toplandığı yer target/gatling/results altında yapmış olduğunuz testlere ait sonuçları bulabilirsiniz. Bu arada Gatling test sonuçlarını sistemin timestamp alıp klasör adıyla isimlendirir. Test sonuçlarına baktığımızda ise bir sayfanın ortalama olarak 3 sn altında cevap vermesi beklenir.

Test Sonucu
Test sonucu 2

Biz beIN medya çatısı altında bulunan web sayfaları yada servislerin performanslarını gatling kullanarak test ediyoruz. Örnek olarak GS -FB derbisi için bütün servisleri ve ön yüz testleri ayrı ayrı yapılır, bütün sunucu ortamları derbi ortamındaki gibi hazır hale geldikten sonra performans testi başlar. Test esnasında ortalama 20K kullanıcı ile performans testi yapılır yada stress olması gerekiyorsa 5K kullanıcı ile sürekli play sayfasının yenilemesi yapılır.

Gatling bizim için bir test ortamı olarak kullanılmaktadır, bizi daha profesyonel yapan noktalar test automation olarak jenkins job’larını kullanmak, AWS ec2 sunucuları kullanarak istediğimiz tipte gerçek makineler kullanmak koşum sonrası her makinedeki test sonuçları toplanıp genel bir sonuç olarak bize slack üzerinden test sonucunu göndermektedir ve son olarak Grafana ile gerçek zamanlı olarak testi izleme ortamı oluşturduk.

Grafana Reel Time monitor

Öncelikle bu konu hakkında pek türkçe kaynak yok denilebilir bu yüzden türkçe yazmaya karar verdim ama yakında bu yazı serisini ingilizce olarak yayınlayacağım, Gatling ile proje geliştirme konusunda anlatacaklarım bu kadar umarım yazılanlar işinize yarar.

Bir Performans Mühendisi Atasözü “Bana 20K kullanıcı ver sana performans testi verim... ” 🙌

Bana buradan yada aşağıdaki linkten ulaşabilirsiniz
LinkedIn:
www.linkedin.com/in/korhan-herguner
Mail: korhanherguner@gmail.com
Twitter:https://twitter.com/kherguner2

--

--