developen

Uygulamaların yük testlerini yaparken dikkat ettiğimiz birkaç noktayı sizlerle paylaşmak isterim.

Yük testlerini birkaç farklı amaç için yapıyor olabiliriz. Bu testleri kimi zaman sistemin “performansını”, bazen “stabilitesini” yada “sağlamlığını” test etmek için yaparız. Bazı özel koşullarda da sistem üzerindeki hafıza taşması hatalarını dürtüklemek için sistemi yüklediğimiz de olur. Hangi sebeple bu testleri yapıyor olursak olalım, dikkat etmemiz gereken bazı noktalar mevcuttur.

Testlerimizin hedefleri bulunmalıdır : Test aktivitesi, sürekli tekrarladığımız gibi, belirli bir amaca yönelik gerçeklenmelidir. Testleri ne için yaptığımız, hangi durumların hata sayılacağı ve bulunan hatalar ile ilgili neler yapacağımızı önceden belirlemeliyiz. Aksi durumlarda çok ilginç sorular ile kendimizi başbaşa bulmamız işten değildir. Örneğin “Sistem, bu durumda 12 saniyede tepki verebilmekte” ve bunun “iyi” yada “kötü” bir durum olduğu konusunda bir fikriniz yok. Böyle bir durum ile karşılaştıysanız, tüm test sisteminizi kapatıp, ofisinizin camına “Test Mühendisi Aranıyor” ilanı yapıştırmanız en doğrusu olur.

Sanal kullanıcılarınız, gerçek kullanıcılar gibi davranmalıdır : Bu çok çetrefilli bir nokta gibi gelebilir ama sizi temin ederim ziyaretçileriniz her seferinde aynı ürünü sepetlerine atmayacaklardır. Böyle bir durumda dikkat etmemiz gereken diğer bir nokta da, “performans optimizasyonu” konusunun popüler bir konu olmasıdır. Yani, muhtemelen sistemde önbelleklenebilir herşey önbelleklenmektedir. Siz yazılım ile ilgili performansı test ederken, aslında basit bir G/Ç testi yapıyor bulabilirsiniz kendinizi. Bu sebeple yalvarırım ana sayfanıza “GET / HTTP/1.1” istemi gönderip durarak yük testi yapmayı bırakın!

Testlerinize gerçek hayattaki sorunları da ekeleyin : Sizin ağınızda paket kaybı oluyor mu? Eğer yanıtınız “Hayır” ise size bir kötü haberimiz var. Kullanıcılarınızın bu tip sorunları ne yazık ki mevcut. Bu demek oluyor ki sunucularınız bir miktar işlem gücünü ellerine geçen paketleri sıralamak, düzenlemek ve hata düzeltmek için kullanacaklardır. Emin olun, uydu bağlantısı ile ağa bağlı bir sistem üzerinde, hava kapalıyken oluşan erişim darboğazlarını görmemiş olsaydım bunlardan hiç söz etmeyecektim. Yaptığınız testlerde, test altyapınızın hijyenik bir ortam olduğunu unutmamanız gereklidir. Eğer bir bankacılık, sigortacılık yada telekominikasyon uygulaması gibi yük altında ve dağınık bir sistemin testlerini yapıyorsanız belki bazı araçları incelemek isteyebilirsiniz.

Gerçek kullanıcıların özgür seçim şansının olduğunu unutmayın : Evet uygulama içerisinde bir işi yapmak için birden fazla yolunuz mevcut. Eminim bu yollardan en fazla kaynak tüketenine yer vermek size iyi bir fikir gibi geliyor. Fakat sürekli aynı akışın takibi öngörülemeyen önbellekleme durumlarına sebep olabilir. Eğer böyle bir önbellekleme söz konusu değilse, sizi temin ederim, test betiklerinize bu seçim şansını tanımak, yapacağınız ek donanım yatırımından daha ucuz olacaktır. Her koşulda gerçeğe en yakını simüle etmek en doğru çözümdür.

Test betiklerinizi test edin : Hangi aracı kullanıyorsanız kullanın, yazdığınız test betiklerinin davranışlarını incelemenize olanak tanıyan özellikler bulunacaktır. Tek kullanıcı olarak betiklerinizin doğru çalıştığından emin olduktan sonra, çok kullanıcı olarak da benzer bir başarımda çalışacağından emin olmalısınız. Bunun için betiğiniz içerisine test kodu yazmaktan çekinmeyin.

Teyid (assertion) kodlarınızı yazarken bazı sorunlar ile karşılaşmanız olasıdır. Örneğin birden fazla sanal kullanıcının tek bir dosyaya yazması sıkıntılı bir durumdur. Bunu thread-safe bir yöntem ile tek bir dosyaya kaydetmek yerine ayrı bir Web Sunucusu üzerinde, basit bir PHP/ASP/JSP betiğine HTTP GET/POST metodları ile göndermeniz daha kolay olacaktır. Bu şekilde öncelikle küçük bir miktar sanal kullanıcı ile sisteminizin ve betiklerinizin durumunu test edip akabinde gerçek teste geçebilirsiniz. Gerçek test sırasında betikleriniz içerisindeki test kodlarını çıkarmanızı tavsiye ederim.

Peki bunlara dikkat etmez isek yaptığımız test ne ifade eder?

Yukarıdaki önerilere uyulmadığı durumlarda, yaptığınız test, gerçek sistemi her durumda alttan sınırlayacaktır.

Bir saniye.. Bu ne demek şimdi?

Beraber inceleyelim.

Yukarıdaki önerilere uymadığımız durumlarda sistem, bizim beklediğimizden her zaman daha iyi bir performans sunacaktır. Örneğin sürekli aynı ürünün bilgilerini görüntüleyen sanal kullanıcılarımız veri erişim katmanımızı gerçek hayattan daha az yorabilir. Bu sayede testlerimizde detay sayısı azaldıkça, gerçek sistemi her zaman alttan sınırlayan sonuçlar gözlemleriz. Bu bilinen bir tekniktir ve bazı durumlarda kontrollü olarak kullanılır. Eminim siz de güdümlü füze sistemlerinin yada uzay mekiklerinin her test vakası için birer tane göndererek test edilmediğinin farkındasınız.

Lakin buradaki acı veren nokta şöyledir. Testlerinizi yaptınız ve grafikte en altta görünen A değerlerini elde ettiniz. Bu değerler sistemi alttan sınırlayan durumlar. Peki gerçek sistemin performansı bu değerlerin üzerindeki B değerleri mi, yoksa en üstteki C değerleri midir? Eğer yük testi uygulayacaksanız, test altındaki sistemi çok iyi tanımalısınız. Eğer atladığınız detayların sistem üzerindeki etkilerini bilemiyorsanız, bunları mutlaka test setlerinize ekleyin.

Bu testleri gerçeklerken unutmayın ki yapılacak donanım yatırımı ve sistemin servis vermesi aşamasındaki her anında, yapmakta olduğunuz testin sonuçları referans olarak kullanılacaktır.