Bir yazılımın sıradan bir salı sabahı sorunsuz çalışması, en yoğun gününde de aynı şekilde çalışacağı anlamına gelmez. Sigorta acenteleri için yoğunluk belirli dönemlerde yoğunlaşabilir: ay sonları, kampanya dönemleri, araç alım satımının arttığı mevsimler ya da toplu yenileme takvimleri. Bu dönemlerde aynı anda çok daha fazla kullanıcı sisteme girer, çok daha fazla teklif sorgusu başlatılır. Yük testi, bu yoğunluğu gerçek kullanıcılar yaşamadan önce kontrollü bir ortamda canlandırmaktır.
Test türleri ve amaçları
"Yük testi" genel bir şemsiye terimdir; altında farklı soruları yanıtlayan test türleri bulunur.
- Yük testi: Beklenen en yoğun kullanım seviyesinde sistem hedeflenen yanıt sürelerini koruyabiliyor mu?
- Stres testi: Beklenenin ötesinde bir yükte sistem nerede ve nasıl zorlanıyor? Zorlandığında kontrollü biçimde mi yavaşlıyor, yoksa tamamen mi duruyor?
- Ani yük testi: Kullanıcı sayısı çok kısa sürede katlandığında sistem bu sıçramayı nasıl karşılıyor?
- Dayanıklılık testi: Orta düzey bir yük saatlerce sürdüğünde bellek sızıntısı, bağlantı birikmesi ya da yavaş yavaş artan yanıt süreleri görülüyor mu?
Gerçekçi bir senaryo nasıl kurulur?
Yük testinin değeri, senaryonun gerçek kullanıma ne kadar benzediğine bağlıdır. Tek bir sayfayı binlerce kez çağırmak, sistemin gerçek davranışını göstermez.
Kullanıcı davranış karışımı
Gerçek kullanıcılar farklı işler yapar: Kimi müşteri arar, kimi yeni kayıt oluşturur, kimi teklif başlatır, kimi rapor alır. Senaryo, bu işlerin gerçek kullanım oranlarına yakın bir karışımını içermelidir. Bu oranlar, gözlemlenebilirlik verilerinden elde edilebilir.
Branş bazında ayrım
Trafik, kasko ve DASK sorguları farklı adımlardan geçer ve farklı servislere bağlanır. Yoğun dönemlerde bu branşların dağılımı da değişebilir. Senaryoda her branşın ayrı bir akış olarak tanımlanması, darboğazın hangi akışta oluştuğunu görmeyi sağlar.
Düşünme süresi
Gerçek bir kullanıcı bir ekranı açtıktan sonra birkaç saniye okur, sonra bir sonraki adıma geçer. Bu bekleme süresinin senaryoya eklenmemesi, gerçekte olmayan bir yük deseni üretir.
Dış servisler: test edilmeyecek olan
Yük testinde sigorta şirketlerinin servislerine gerçek istekler göndermek kabul edilemez; hem bu servisleri yorar hem de gerçek sorgu kayıtları oluşturur. Bunun yerine dış servisler, gerçekçi yanıt süreleri ve zaman zaman hata döndüren taklit servislerle değiştirilir. Böylece yazılımın kendi kapasitesi ölçülür, dış servis yavaşladığında sistemin nasıl davrandığı da güvenle denenebilir.
Neyi ölçmeli?
- Yanıt süresi dağılımı: Ortalama değil, yavaş isteklerin oluşturduğu dilimler.
- Hata oranı: Yük arttıkça hangi noktada hatalar başlıyor?
- Kaynak kullanımı: İşlemci, bellek, veritabanı bağlantı havuzu ve kuyruk uzunlukları.
- Toparlanma: Yük azaldığında sistem ne kadar sürede normale dönüyor?
Tipik bulgular
Yük testleri genellikle beklenmedik yerlerde darboğaz ortaya çıkarır. Sık rastlanan örnekler şunlardır:
- Düşük yükte fark edilmeyen ama yoğunlukta veritabanını zorlayan dizinsiz bir sorgu,
- Küçük tutulmuş bir bağlantı havuzu nedeniyle isteklerin sırada beklemesi,
- Rapor oluşturma gibi ağır bir işin, teklif sorgularıyla aynı kaynakları paylaşması,
- Dış servis yavaşladığında zaman aşımı ayarlarının uzun olması nedeniyle isteklerin birikmesi.
Her bulgu için bir iyileştirme yapılır ve test tekrarlanır. Amaç tek seferlik bir rapor değil, iyileştirmelerin etkisini ölçen döngüsel bir süreçtir.
Kontrollü yavaşlama tasarımı
Hiçbir sistem sınırsız yükü kaldıramaz. Önemli olan, sınıra yaklaşıldığında sistemin nasıl davrandığıdır. İyi tasarlanmış bir sistem, kritik işleri korurken daha az acil işleri erteler. Örneğin yoğunluk anında teklif sorguları ve oturum açma öncelikli tutulurken, ağır raporlar sıraya alınabilir. Kullanıcıya da "raporunuz hazırlanıyor, hazır olduğunda bildirim alacaksınız" gibi açık bir mesaj gösterilir.
Ne zaman test etmeli?
Yük testleri yalnızca büyük sürümlerden önce değil, düzenli aralıklarla ve bilinen yoğun dönemlerden önce yapılmalıdır. Altyapıda ya da veritabanında yapılan önemli değişikliklerden sonra da tekrar edilmesi, gizli bir gerilemenin erken fark edilmesini sağlar.
Acenteler açısından
Yük testlerinin acente için anlamı, en çok ihtiyaç duyulan anda yazılımın yavaşlamamasıdır. Yoğun bir günde teklif programının ya da CRM ekranlarının takılması, doğrudan iş kaybı anlamına gelebilir. Yazılım sağlayıcınıza yoğun dönemlere nasıl hazırlandığını ve sistemin yük altında nasıl davrandığını sormak, bu konuda bilinçli bir değerlendirme yapmanızı sağlar.
Test ortamı ve kapasite planlaması
Yük testinin sonuçlarının anlamlı olması, testin yapıldığı ortamın canlı ortama ne kadar benzediğine bağlıdır. Daha küçük sunucularla, farklı yapılandırmalarla ya da çok az veriyle kurulmuş bir ortamda elde edilen sonuçlar, canlıdaki davranışı yanlış yansıtabilir. Bu nedenle yük testi ortamının, kaynak boyutları, yapılandırma ve veri hacmi açısından canlıya mümkün olduğunca yakın tutulması gerekir. Veri hacmi için maskelenmiş ya da sentetik olarak üretilmiş büyük veri setleri kullanılır.
Yük testlerinin bir diğer çıktısı da kapasite planlamasıdır. Testler, sistemin hangi kaynağının ilk tükendiğini ve kullanıcı sayısı arttıkça kaynak ihtiyacının nasıl büyüdüğünü gösterir. Bu bilgi, yeni acenteler katıldıkça altyapının ne zaman ve hangi yönde genişletilmesi gerektiğini önceden planlamayı sağlar. Otomatik ölçeklendirme kullanılan sistemlerde ise ölçeklendirme kurallarının yük altında gerçekten beklendiği gibi tetiklendiği ve yeni kaynakların yeterince hızlı devreye girdiği yine yük testleriyle doğrulanır.
Yük testi sonuçlarının bir rapor hâlinde saklanması ve bir sonraki testle karşılaştırılması da önemlidir. Aynı senaryonun farklı tarihlerde verdiği sonuçlar, sistemin kapasitesinin yeni özelliklerle birlikte nasıl değiştiğini gösterir ve sessiz performans gerilemelerini erkenden ortaya çıkarır.
Sonuç
Yük testi, yazılımın sınırlarını kullanıcılardan önce keşfetmenin yoludur. Gerçekçi senaryolar, branş bazında ayrım, taklit dış servisler ve döngüsel iyileştirme ile yoğun dönemler sürpriz olmaktan çıkar ve planlanabilir hâle gelir.