Hizmet · Yazılım Testi ve Kalite Güvencesi

Yük ve Stres Testleri

İzmir'li bir ev tekstili markasını düşünelim. Kendi e-ticaret sitesi var, Kasım'daki büyük indirim günlerine hazırlanıyor. Geçen yıl tanınmış bir fenomen akşam dokuzda ürün bağlantısını paylaştığında site yirmi dakika boyunca hata sayfası göstermiş, sepetler boşalmış, müşteri hizmetleri ertesi gün şikâyetlerle dolmuş. Bu yıl hem televizyon reklamı hem de daha büyük bir kampanya planlanıyor. Sistemin buna dayanıp dayanmayacağını tahmin etmek yerine ölçmek mümkün. Yük testi, belirli sayıda sanal ziyaretçiyi sitede gezdirir, ürün aratır, sepete ekletir ve ödeme adımına götürür. Bu sırada yanıt sürelerini ve hataları ölçer, sistemin ilk nerede tıkandığını gösterir: veritabanı mı, uygulama sunucusu mu, ödeme sağlayıcısına giden bağlantı mı, yoksa stok bilgisini pazaryerleriyle eşitleyen servis mi? Sonuç, “site hızlı” ya da “yavaş” gibi bir izlenim değil, yönetimin anlayacağı sayılarla yazılmış bir rapordur.

Talep gönderin Hizmet neleri kapsıyor

p95 ve p99

ortalama yerine gerçekçi ölçü

k6, JMeter, Gatling

uygulamaya göre seçilir

Gerçek senaryo

kayıt ve analitikten türetilir

Yeniden ölçüm

her iyileştirmeden sonra

Hizmetin kapsamı

Amacımız bir grafik üretmek değil, “o akşam site ayakta kalır mı” sorusuna gerekçeli bir cevap vermek.

Kapsamı mühendislerimizle netleştirin

Trafik modeli

Sunucu kayıtları, GA4 ya da Matomo verilerinden en yoğun dakikayı ve ziyaretçilerin ne yaptığını çıkarır, beklenen kampanya yoğunluğuna göre büyütürüz.

Senaryolar

Gezinme, arama, filtreleme, sepete ekleme, üye girişi ve iyzico ya da PayTR test modunda ödeme. Her sanal ziyaretçi farklı ürün ve veriyle çalışır, aynı isteği binlerce kez tekrarlamaz.

Test türleri

Kademeli artan yük, bir anda gelen ani sıçrama, saatlerce süren dayanıklılık testi ve sistemin kırılma noktasını bulan stres testi.

Anlamlı ölçütler

Yanıt süresinin 95. ve 99. yüzdelik değerleri, hata oranı ve saniyedeki işlem sayısı. Ortalama bir saniye iyi görünür, ama her yirmi ziyaretçiden biri on saniye bekliyorsa sorun vardır.

Darboğazın yerini bulmak

Test sırasında işlemci, bellek, veritabanı bağlantı havuzu, yavaş sorgular ve kuyruk uzunlukları mevcut izleme aracınızdan ya da geçici olarak kurduğumuz panolardan anbean takip edilir.

Üçüncü taraf limitleri

Ödeme sağlayıcısı, kargo API'si, SMS ve e-posta gönderimi, pazaryeri stok eşitlemesi: kendi sisteminiz dayansa bile bu servislerin saatlik ya da dakikalık sınırları darboğaz olabilir.

Etkisine göre iyileştirmeler

Eksik indeksler, önbellek, CDN ayarları, sunucu kapasitesi ve gerekiyorsa sanal bekleme odası. Her öneri tahmini emekle birlikte sıralanır ve uygulandıktan sonra yeniden ölçülür.

Çalışma adımları

Takvimi kampanya tarihinden geriye doğru kurarız. İlk ölçüm, düzeltmeler ve ikinci ölçüm için toplam dört haftalık bir pay idealdir.

Hedef cümlesi

Örneğin: “Saat 21:00-21:30 arasında 15.000 ziyaretçi, sayfaların %95'i 2 saniyenin altında, hata oranı %1'in altında.”

Ortam ve izinler

Canlıya benzer ortam, gerçekçi veri hacmi, senaryo betikleri ve barındırma firması, CDN ve ödeme sağlayıcısına yapılan bildirimler.

Ölçüm koşuları

Önce kademeli yük, sonra ani sıçrama ve dayanıklılık, her koşudan sonra kısa bir ara değerlendirme.

Düzelt ve karşılaştır

Etkisi en yüksek düzeltmeler uygulanır, aynı senaryolar yeniden koşulur ve iki sonuç yan yana raporlanır.

Test öncesinde barındırma ve güvenlik sağlayıcınıza haber verin. Kısa sürede gelen on binlerce istek, DDoS koruması ya da web uygulama güvenlik duvarı tarafından saldırı olarak algılanabilir. Bu durumda test yarıda kesilir, hatta test makinelerinin IP adresleri engellenir. Test saatini ve kaynak IP adreslerini önceden bildirmek, hem testin sağlıklı sonuç vermesini hem de gereksiz alarmları önler.

Sık sorulan sorular

Mümkünse canlıya benzer ayrı bir ortamda. Canlı sistemde test gerekiyorsa, trafiğin en düşük olduğu saatte, önceden anlaşılmış bir pencerede ve sağlayıcılarınızı bilgilendirerek yaparız.

Tam olarak değil. Gerçek ziyaretçiler sayfalar arasında okur, düşünür, bekler. Bu yüzden sanal kullanıcıların bekleme sürelerini analitik verinizden alırız. Önemli olan kişi sayısından çok, saniyede sunucuya düşen istek ve işlem sayısıdır.

Yük üreten bulut makineleri ve gerekiyorsa geçici olarak büyütülen test ortamı için küçük bir altyapı maliyeti oluşur. Tutarı test planında ayrı bir satır olarak önceden görürsünüz.

En az dört hafta önce. İlk test genellikle birkaç darboğaz ortaya çıkarır. Bunların düzeltilmesi ve ikinci ölçüm için zaman gerekir, son hafta yapılan bir test yalnızca kötü haberi erken öğrenmenizi sağlar.

Evet. Betikleri çoğunlukla k6 ile kod olarak yazar ve deponuza bırakırız. Küçük bir sürümü CI hattınıza eklenebilir, böylece her büyük değişiklikten sonra performansın gerileyip gerilemediği otomatik olarak görülür.

Bu alandaki diğer hizmetler

Alanın tamamını görün

Hizmet Fonksiyonel Testler Teslim aldığınız yazılımın, iş kurallarınızı gerçekten doğru uygulayıp uygulamadığını bağımsız bir gözle kontrol ederiz Hizmet Test Otomasyonu Her değişiklikten sonra birkaç dakika içinde neyin bozulduğunu söyleyen otomatik testler Hizmet Kullanılabilirlik ve UX Testleri İnsanların sitenizde ya da uygulamanızda nerede takılıp vazgeçtiğini gerçek kullanıcılarla bulun Hizmet Sızma Testleri Uygulamanızdaki açıkları, gerçek saldırganlardan önce izinli saldırılarla bulun

Yoğun günden önce sayılara bakalım

Önünüzdeki kritik tarih ne ve o gün kaç ziyaretçi bekliyorsunuz? Size bir hedef cümlesi ve geriye doğru kurulmuş bir takvim önerelim.

E-posta
office@apply.tr

Çalışma saatleri
Pazartesi-Cuma, 09:00-18:00 (Türkiye saati), yanıt bir iş günü içinde

Görüşmeler
Microsoft Teams ya da Google Meet üzerinden görüntülü görüşme

Bu talebin yanıtlanması için bilgilerimin Apply tarafından KVKK aydınlatma metninde anlatıldığı şekilde işlenmesini kabul ediyorum