Sınav Haftası Öncesi Yük Testi: Eğitim Platformunda Hangi Senaryolar Denenmeli?

Sınav günü sabah dokuzda binlerce öğrenci aynı dakikada giriş yapmaya çalıştığında, sıradan bir ders gününde sorunsuz çalışan platform bile yavaşlayabilir. Eğitimde yük dönemseldir: sınav saatleri ve dönem başları normal günün katlarına çıkar. Bir yük testi bu yoğunluğu sınav gününü beklemeden, kontrollü bir ortamda önceden yaşatmanızı sağlar. Bu yazıda sınav haftası öncesinde hangi senaryoların denenmesi gerektiğini ve sonuçların nasıl okunacağını sade bir dille anlatıyoruz.

01Önce gerçek yoğunluğu tanımlayın

Senaryo yazmadan önce üç soruya yanıt arayın: Kaç kişi, aynı anda, ne yapıyor? Kayıtlı kullanıcı sayısı ile aynı anda etkin kullanıcı sayısı çok farklı iki rakamdır. Test hedefini ikincisine göre koymanız gerekir. Geçen dönemin giriş kayıtları ve sınav başlangıç saatleri bu rakamı çıkarmak için iyi bir kaynaktır.

• Eş zamanlı kullanıcı: Sınavın ilk dakikalarında oturumda olması beklenen kişi sayısı.
• Tepe dakika: Yoğunluğun saatlik değil, dakikalık dağılımı. Sınav başlamadan önceki beş dakika çoğu zaman günün en dik noktasıdır.
• İşlem karışımı: Giriş, soru sayfası açma, yanıt kaydetme ve dosya yükleme işlemlerinin yaklaşık oranları.
• Büyüme payı: Bu dönem eklenen sınıf, şube ya da öğrenci sayısı.

Varsayımsal bir örnek: 4.000 kayıtlı öğrencisi olan bir platformda sınava ilk beş dakikada yaklaşık 1.500 öğrenci giriyorsa, test hedefi 4.000 değil, 1.500 eş zamanlı kullanıcı ve girişlerdeki ani yığılma olmalıdır. Rakamlar yalnızca örnektir; kendi kayıtlarınızla değiştirin ve hedefe bir güvenlik payı ekleyin.

02Sınav haftası öncesi yük testi için temel senaryolar

Tek bir ortalama yük senaryosu sınav gününü temsil etmez. Yoğunluğun şekli değiştikçe zorlanan bileşen de değişir. Aşağıdaki altı senaryo çoğu eğitim platformu için başlangıç listesi olarak kullanılabilir:

1. Ani giriş yığılması: Kullanıcı sayısı kısa sürede hedefe çıkarılır. Kimlik doğrulama, oturum açma ve ilk sayfanın yanıt süresi izlenir.
2. Süren sınav yükü: Yük, sınav süresi boyunca sabit tutulur. Yanıt kaydetme ve otomatik kayıt gibi yazma ağırlıklı işlemler veri tabanını uzun süre meşgul eder. Bellek sızıntısı ve bağlantı havuzu tükenmesi gibi sorunlar ancak bu uzunlukta bir testte görünür.
3. Bitişte toplu gönderim: Süre dolarken öğrencilerin büyük kısmı aynı anda sınavı teslim eder. Teslimlerin kuyruğa alınıp alınmadığı ve hiçbir yanıtın kaybolmadığı bu senaryoda doğrulanır.
4. Dönem başı karışık yük: Ders kaydı, içerik görüntüleme, ödev yükleme ve bildirimler birlikte çalışır. Karışık yük, tek tek hızlı görünen işlemlerin birbirini yavaşlattığını ortaya çıkarır.
5. Canlı ders ve sınavın çakışması: Aynı saatte hem canlı ders hem sınav varsa video ve toplantı entegrasyonları ile ortak altyapı birlikte yüklenir.
6. Hata ve yeniden deneme: Bağlantısı kopan öğrenciler sayfayı yeniler. Bu davranış kısa sürede ek istek dalgası yaratır. Testte bir kısım kullanıcının isteği kasıtlı olarak tekrarlanmalıdır.

03Test ortamını ve veriyi hazırlayın

Test sonucunun anlamlı olması için ortamın üretime benzemesi gerekir. Daha küçük bir sunucuda alınan sonucu doğrudan çarpmak güvenilir bir tahmin vermez. Başlamadan önce şu noktaları kontrol edin:

• Ortam boyutu: Sunucu, veri tabanı ve önbellek yapılandırması üretime olabildiğince yakın olmalı. Veri tabanında gerçekçi hacimde kayıt bulunmalı.
• Sentetik veri: Gerçek öğrenci verisi kullanmayın. Eğitimde işlenen verinin önemli bölümü çocuklara aittir; test için üretilmiş kullanıcılar ve sahte sınav içeriği hem riski hem uyum yükünü azaltır. Kişisel veri işleme ilkeleri için Kişisel Verileri Koruma Kurumu sayfalarına bakabilirsiniz.
• Üçüncü taraf servisler: E-posta, SMS, tek oturum açma ve video servislerine gerçek yük göndermeden önce sağlayıcının test ortamını ya da izin verilen sınırları öğrenin.
• Kapsam, yetki ve zamanlama: Hangi adresin, hangi saatte, kimin onayıyla test edileceği yazılı olmalı. Bu sıra güvenlik testlerinde olduğu gibi yük testinde de geçerlidir; mantığı için sızma testi öncesi hazırlık yazımıza göz atabilirsiniz.
• İzleme: Test başlamadan önce sunucu, veri tabanı ve uygulama metrikleri toplanıyor olmalı. Ölçülmeyen şey sonradan okunamaz.

04Yük testi sonuçları nasıl okunur?

Sonuç raporu çoğu zaman bir rakam tablosudur. Hangi rakamın ne anlama geldiğini bilmek, gereksiz paniği de gereksiz rahatlığı da önler.

• Ortalama yerine yüzdelik dilim: Ortalama yanıt süresi kabul edilebilir görünürken yavaş istekler gizlenebilir. p95 ya da p99 değerleri, kullanıcıların en yavaş deneyimini gösterir. web.dev Core Web Vitals belgeleri de değerlendirmeyi ortalamayla değil, yüzdelik dilimle yapar.
• Hata oranı: Hata oranının hangi kullanıcı sayısında yükselmeye başladığına bakın. Zaman aşımları ve sunucu hataları bu eşiği gösterir.
• Eğrinin şekli: Yük arttıkça yanıt süresi yumuşakça mı uzuyor, yoksa belirli bir noktada aniden mi kırılıyor? Kırılma noktası, sınav günü için asıl sınırınızdır.
• Sunucu tarafı metrikler: İşlemci, bellek, veri tabanı bağlantıları ve kuyruk uzunluğu istemci tarafı sonuçlarla birlikte okunmalı. Microsoft Learn üzerindeki Azure Load Testing belgesi bu eşleştirmenin neden önemli olduğunu anlatır.

Ortalama sakin görünür; sınav günü öğrencinin yaşadığı ise dağılımın yavaş ucudur.

Örneğin ortalama yanıt süresi düşükken p95 belirgin biçimde yüksekse, öğrencilerin bir bölümü ötekilerden çok daha yavaş bir deneyim yaşıyor demektir. Bu bölüm sınav sırasında en çok şikâyet üreten gruptur. Rapor okuma mantığının e-ticaret tarafındaki karşılığı için kampanya dönemi yük testi sonuçlarını okuma yazımıza da bakabilirsiniz.

05Bulguları aksiyona çevirin ve yeniden test edin

Yük testi bir kez yapılıp rapora dönüştürülen bir iş değildir. Değerini, bulguların düzeltilip yeniden ölçülmesiyle kazanır.

1. Darboğazları sıralayın: En erken kırılan bileşeni bulun. Çoğu zaman tek bir sorgu, tek bir servis ya da tek bir bağlantı havuzu sınırı sonucu belirler.
2. Bir seferde bir değişiklik yapın: Aynı anda birden çok ayar değiştirirseniz neyin işe yaradığını anlayamazsınız.
3. Dayanıklılık önlemlerini değerlendirin: Otomatik ölçeklenen bulut altyapısı, kuyruklu sınav teslimi, sık kullanılan içerik için önbellek ve aşırı yükte bekleme ekranı bu aşamada gündeme gelir.
4. Aynı senaryoyu tekrarlayın: Düzeltmenin etkisini aynı koşullarda yeniden ölçün ve ilk sonuçla karşılaştırın.
5. Sınav günü provası yapın: Kimin izleyeceğini, hangi eşikte kimin devreye gireceğini ve sorun çıkarsa hangi adımların izleneceğini yazılı hale getirin.

06Sık sorulan sorular

Yük testini sınav takviminden ne kadar önce yapmalıyız?

Sabit bir süre yoktur. Önemli olan, bulgulara göre düzeltme yapıp testi tekrarlayacak zamanın kalmasıdır. Planı sınav takviminden geriye doğru kurun ve ilk turda sorun çıkarsa en az bir yeniden test turu ayırın.

Testi canlı sistemde mi yapmalıyız?

Genellikle üretime benzer ayrı bir ortam daha güvenlidir. Canlı sistemde test yapılacaksa yetki ve zaman penceresi önceden netleştirilmeli, gerçek kullanıcıları etkilemeyecek sınırlar konmalıdır. Sınav ya da canlı ders sırasında test yapılmamalıdır.

Yük testi geçildiyse sınavda sorun çıkmaz mı?

Hayır. Test, modellediğiniz senaryo kadar gerçekçidir; gerçek öğrenci davranışı farklı olabilir. Test riski azaltır ama ortadan kaldırmaz. Bu yüzden sınav günü canlı izleme ve net bir müdahale planı da gereklidir.

Sonuç olarak sınav haftasına hazırlık; gerçek yoğunluğu tanımlamak, doğru senaryoları seçmek, sonuçları yüzdelik dilimlerle okumak ve düzeltmeleri yeniden ölçmekten oluşur. Platformunuz için risk bazlı bir test planı oluşturmak isterseniz Test ve Kalite Güvence hizmet sayfamızı inceleyebilirsiniz.