Yazılım Yük Testi: Kaç Kullanıcı Değil, Hangi İş Yükü?

İş yükünü kullanıcı davranışıyla tarif edin

Önce gerçek akışların bir karışımını çıkarın. Kullanıcıların ne kadarı arama yapıyor, ne kadarı dosya yüklüyor, ne kadarı sipariş veriyor? Veri hacmi ve kullanılan hesapların dağılımı da testin parçasıdır. Aynı küçük kaydı tekrar tekrar okumak, büyük müşteri kataloğuyla çalışmayı temsil etmeyebilir.

Eşzamanlı kullanıcı sayısı ile saniyedeki yeni istek sayısını ayırın. Yavaşlayan sistemde açık oturumlar artabilir ama tamamlanan işler azalabilir. Bu nedenle test raporunda başlayan, tamamlanan ve başarısız olan işler birlikte görünmelidir. Tek bir gösterge kapasiteyi açıklamaz.

Test türünü beklenen riske göre seçin

Grafana k6 rehberi düşük yükte doğrulama, olağan yük, stres, uzun süreli yük ve ani artış gibi farklı test türlerini ayırır. [1] Bunlar aynı soruyu cevaplamaz. Kampanya başlangıcındaki ani artış ile saatlerce çalışan toplu işin bellek davranışı ayrı risklerdir.

Her testin amacı ve durdurma koşulu yazılı olsun. Test yalnızca yetkili ortamlarda yapılmalı; üçüncü taraf ödeme, mesaj veya API hizmetlerine izinsiz yüksek yük gönderilmemelidir. Dış bağımlılıkları temsil eden güvenli test yöntemleri ve sağlayıcı koşulları birlikte değerlendirilmelidir.

Örnek: kampanya günü ürün araması

Varsayımsal mağazada normalde müşteriler doğrudan ürün sayfasına gelirken kampanyada arama ve filtre kullanımı artıyor. Sadece ana sayfayı yükleyen test başarılı olsa bile arama veritabanı yavaşlayabilir. İş karışımı değiştiği için testin temsil gücü düşmüştür.

Tablodaki senaryo performans sonucu veya kapasite garantisi değildir. Gerçek kullanım verisiyle uyarlanması gereken bir test planıdır.

Sadece yanıt süresini değil doğruluğu da ölçün

Hızlı dönen yanlış toplam başarılı işlem sayılmamalıdır. Yük altında stok rezervasyonu, çift kayıt ve eksik işlem gibi iş sonuçlarını doğrulayın. Google SRE izleme yaklaşımı, gecikmenin yanında trafik, hata ve doygunluk gibi sinyalleri ele alır. [2]

Ortalama değerin yanında dağılımın yavaş kısmını inceleyin. Belirli müşteri grubu veya büyük kayıtlar diğerlerinden farklı etkilenebilir. Önbellekli ve önbelleksiz durumları ayırın; tek sefer ısınmış sistemle yapılan test ilk ziyaret deneyimini temsil etmeyebilir.

Darboğazı ölçmeden sunucu büyütmeyin

CPU kullanımı yüksek göründüğünde nedenini araştırın. Gereksiz tekrar sorguları, eksik indeks, dış servis beklemesi veya aşırı eşzamanlı iş farklı çözümler gerektirir. Donanım büyütmek bazı durumda yardımcı olur, fakat yanlış iş modelini kalıcı olarak gizleyebilir.

Değişiklikleri tek tek uygulayıp aynı test koşulunda tekrar karşılaştırın. Veri seti, sürüm, altyapı ve iş yükü değiştiyse sonuçların karşılaştırılabilirliğini belirtin. “Yüzde elli hızlandı” gibi iddialar ancak ölçüm kapsamı ve başlangıç değeriyle anlamlıdır.

Teslimde yeniden çalıştırılabilir test isteyin

Test betikleri, sentetik veri hazırlama yöntemi, kabul koşulları ve sonuç raporu teslim edilsin. Rapor hangi dış bağımlılıkların gerçek, hangilerinin taklit edildiğini açıklasın. Böylece sonraki sürümde aynı kontrol tekrarlanabilir.

Yayın sonrası kapasite gözlemi de planlanmalıdır. Test ortamı üretimin her koşulunu temsil etmeyebilir. Beklenmedik yükte hangi özelliğin sınırlandırılacağı, kimin uyarılacağı ve müşteriye ne gösterileceği önceden belirlenmelidir.

Sık sorulan sorular

### Tek bir yük testi bütün performans riskini bitirir mi? Hayır. Farklı yük biçimleri farklı sorunlar ortaya çıkarabilir. Kritik akışlar ve beklenen kullanım değiştikçe test kapsamı güncellenmelidir.

Çok kullanıcıyla test yapmak her zaman daha gerçekçi mi?

Ancak davranış ve veri dağılımı da gerçek kullanımı temsil ediyorsa. Yanlış senaryoda büyük sayı üretmek, doğru kapasite bilgisi sağlamaz.