Yazılım Test Mühendisliği Dersleri

YTM Dersleri: Bölüm 11

YTM Dersleri: Bölüm 11

NFR Testleri | Performans, Güvenlik, Yük, Stres ve Kullanılabilirlik | yazilimtestmuhendisligi.com

NFR Testleri: Performans, Güvenlik, Yük, Stres ve Kullanılabilirlik

Bir yazılımın “ne yaptığı” kadar “ne kadar iyi yaptığı” da önemlidir. Bu rehberde fonksiyonel olmayan gereksinim (NFR) testlerini; performans, yük, stres, güvenlik ve kullanılabilirlik boyutlarıyla ele alıyoruz.

Performans Testi Yük / Stres Testi Güvenlik Testi OWASP Top 10 Kullanılabilirlik

i NFR Testlerine Giriş

Fonksiyonel Olmayan Gereksinim (Non-Functional Requirement / NFR) testleri, bir yazılımın ne yaptığını değil, nasıl yaptığını ölçer: ne kadar hızlı, ne kadar güvenli, kaç kullanıcıyı aynı anda kaldırabildiği ve kullanıcı için ne kadar kolay/anlaşılır olduğu.

Fonksiyonel Gereksinim

  • “Kullanıcı sepete ürün ekleyebilmeli”
  • Doğru/yanlış (evet/hayır) şeklinde test edilir
  • Test edilir: Özellik çalışıyor mu?

Fonksiyonel Olmayan Gereksinim (NFR)

  • “Sepete ekleme işlemi 2 saniyeden kısa sürmeli”
  • Ölçülebilir bir eşik/kalite seviyesiyle test edilir
  • Test edilir: Özellik ne kadar iyi çalışıyor?
NFR testleri genellikle geliştirme sürecinin sonlarına bırakılır, ancak performans ve güvenlik sorunlarının mimari düzeyde kök nedenleri olabileceğinden, bu testlerin erken aşamalarda (mimari tasarım, temel altyapı kurulumu sırasında) da göz önünde bulundurulması gerekir.

1 Performans Testi ve Temel Metrikler

Performans testi, bir sistemin belirli koşullar altında ne kadar hızlı, kararlı ve verimli çalıştığını ölçer. Aşağıdaki metrikler, hemen hemen her performans test raporunun temelini oluşturur:

< 2s
Yanıt Süresi (Response Time)
500 req/s
Verim (Throughput)
%0.1
Hata Oranı (Error Rate)
%70
CPU / Bellek Kullanımı
MetrikNe ÖlçerNeden Önemli
Response Time (Yanıt Süresi)Bir isteğin gönderilmesinden yanıt alınmasına kadar geçen süreKullanıcı deneyiminin doğrudan algılanan hızı
Throughput (Verim)Sistemin birim zamanda işleyebildiği istek sayısıSistemin kapasitesini gösterir
Error Rate (Hata Oranı)Başarısız isteklerin toplam isteklere oranıYük altında sistemin kırılma noktasını gösterir
Resource UtilizationCPU, bellek, disk I/O kullanım oranlarıDarboğazın (bottleneck) hangi bileşende olduğunu gösterir
Concurrent UsersAynı anda sistemi kullanan kullanıcı sayısıGerçek dünya yük senaryolarını simüle etmek için temel parametre
İpucu: Tek bir “ortalama yanıt süresi” yeterli değildir — 95. ve 99. persentil (p95/p99) değerlerine de bakın. Ortalama 300ms olan bir sistemde, kullanıcıların %5’i 3 saniye bekliyor olabilir; bu fark sadece persentil analiziyle ortaya çıkar.

2 Yük, Stres, Spike ve Dayanıklılık Testleri

Sistemin farklı yük koşullarındaki davranışını anlamak için dört temel test türü kullanılır. Her biri, farklı bir soruya cevap arar.

📊 Yük Testi (Load)

Beklenen normal/yoğun kullanıcı sayısında sistemin davranışını ölçer. Soru: “Normal yoğunlukta sistem stabil mi?”

🔥 Stres Testi (Stress)

Yükü kapasitenin üzerine çıkararak sistemin kırılma noktasını bulur. Soru: “Sistem ne zaman ve nasıl çöküyor?”

⚡ Spike Testi

Ani ve kısa süreli aşırı yük artışına sistemin tepkisini test eder. Soru: “Ani trafik patlamasında (kampanya, viral içerik) ne olur?”

⏳ Dayanıklılık Testi (Soak)

Orta düzey yükü uzun süre (saatler/günler) sürdürerek bellek sızıntısı gibi zamanla ortaya çıkan sorunları bulur. Soru: “Sistem uzun vadede stabil mi?”

Sık yapılan hata: Sadece yük testi yapıp stres ve dayanıklılık testlerini atlamak. Bir sistem normal yükte mükemmel çalışabilir ama beklenmedik bir kampanya trafiğinde (spike) çökebilir ya da günler süren çalışmada yavaş yavaş bellek tüketip (memory leak) sonunda çökebilir — bu sorunlar sadece ilgili test türüyle ortaya çıkar.

Örnek Araç: k6 ile Basit Bir Yük Testi Script’i

// yuk_testi.js - k6 ile 50 sanal kullanıcıyla 2 dakikalık yük testi
import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
    vus: 50,           // eş zamanlı sanal kullanıcı sayısı
    duration: '2m',     // test süresi
};

export default function () {
    const res = http.get('https://api.ornek-magaza.com/urunler');
    check(res, { 'durum kodu 200': (r) => r.status === 200 });
    sleep(1);
}

3 Güvenlik Testi ve OWASP Top 10

Güvenlik testi, bir uygulamanın kötü niyetli kullanıcılara karşı verinin ve sistemin bütünlüğünü, gizliliğini ve erişilebilirliğini koruyup korumadığını doğrular. OWASP (Open Worldwide Application Security Project), en yaygın web güvenlik açıklarını “OWASP Top 10” listesiyle düzenli olarak yayınlar.

  • 1
    Broken Access Control

    Kullanıcıların yetkisi olmayan verilere/işlemlere erişebilmesi (örn. URL’deki ID değiştirilerek başkasının siparişini görüntüleme).

  • 2
    Cryptographic Failures

    Hassas verilerin (şifre, kart bilgisi) şifrelenmeden veya zayıf yöntemlerle saklanması/iletilmesi.

  • 3
    Injection (SQL Injection, XSS)

    Kullanıcı girdisinin doğrulanmadan sorgu veya sayfa içine enjekte edilmesiyle veri sızdırma veya kod çalıştırma.

  • 4
    Insecure Design

    Güvenlik düşünülmeden tasarlanmış mimari — sonradan yama ile tam çözülemeyen yapısal zafiyetler.

  • 5
    Security Misconfiguration

    Varsayılan şifreler, gereksiz açık portlar, hata mesajlarında aşırı bilgi ifşası.

  • 7
    Identification and Authentication Failures

    Zayıf parola politikaları, oturum yönetimi hataları, eksik çok faktörlü doğrulama (MFA).

Test Mühendisi İçin Temel Güvenlik Test Senaryoları

  • Girdi doğrulama: Form alanlarına ' OR '1'='1 gibi SQL injection denemeleri yapılmalı.
  • XSS testi: Metin alanlarına girilip çalıştırılıp çalıştırılmadığı kontrol edilmeli.
  • Yetkilendirme testi: Bir kullanıcının URL/ID değiştirerek başka bir kullanıcının verisine erişip erişemediği test edilmeli.
  • Oturum yönetimi: Çıkış yaptıktan sonra eski oturum token’ının geçersiz hale geldiği doğrulanmalı.
  • HTTPS zorunluluğu: Hassas veri taşıyan tüm isteklerin şifreli (TLS) kanaldan geçtiği kontrol edilmeli.
Araçlar: OWASP ZAP ve Burp Suite, web uygulamalarını otomatik olarak tarayıp yaygın güvenlik açıklarını tespit eden en popüler açık kaynak/ticari araçlardandır. Bu araçlar, manuel penetrasyon testinin yerini almasa da hızlı bir ilk tarama için değerlidir.

4 Kullanılabilirlik (Usability) Testi

Kullanılabilirlik testi, bir uygulamanın hedef kullanıcılar tarafından ne kadar kolay öğrenilebildiğini, verimli kullanılabildiğini ve hata yapmaya ne kadar açık olduğunu değerlendirir. Jakob Nielsen’in 10 Kullanılabilirlik Sezgiseli (Usability Heuristics), bu alanda en çok referans alınan çerçevelerden biridir.

1
Sistem Durumunun Görünürlüğü

Kullanıcı her zaman ne olduğunu bilmelidir (yükleniyor göstergesi, ilerleme çubuğu).

2
Gerçek Dünya ile Eşleşme

Sistem, kullanıcının aşina olduğu dili ve kavramları kullanmalıdır, teknik jargon değil.

3
Kullanıcı Kontrolü ve Özgürlüğü

Kullanıcı yanlış bir işlemden kolayca geri dönebilmelidir (“Geri Al”, “İptal”).

4
Tutarlılık ve Standartlar

Aynı eylem, uygulama genelinde her zaman aynı şekilde ifade edilmelidir.

5
Hata Önleme

Hata mesajı göstermek yerine, hatanın oluşmasını en baştan engelleyen tasarım tercih edilmelidir.

6
Hatırlamak Yerine Tanımak

Kullanıcı bilgiyi hatırlamak zorunda kalmamalı, arayüz seçenekleri görünür kılmalıdır.

Kullanılabilirlik Testi Nasıl Ölçülür?

YöntemNe Ölçer
Task Success RateKullanıcıların verilen görevi (örn. “bir ürün satın alın”) yardım almadan tamamlama oranı
Time on TaskBir görevi tamamlamak için harcanan süre
SUS (System Usability Scale)10 soruluk standart bir anketle 0-100 arası kullanılabilirlik puanı üretir
Error RateKullanıcıların görev sırasında yaptığı hata sayısı
İpucu: Kullanılabilirlik testi için 5-8 gerçek kullanıcıyla yapılan moderasyonlu bir test oturumu, çoğu kritik kullanılabilirlik sorununu (Nielsen’in araştırmalarına göre sorunların ~%85’ini) ortaya çıkarmak için genellikle yeterlidir — yüzlerce kullanıcıya ihtiyaç yoktur.

Sonuç ve Öneriler

NFR testleri, “çalışıyor mu?” sorusunun ötesine geçip “iyi çalışıyor mu, güvenli mi, kullanıcı dostu mu?” sorularına cevap arar. Performans ve yük/stres testleri sistemin dayanıklılığını; güvenlik testleri verinin ve kullanıcının korunmasını; kullanılabilirlik testleri ise ürünün gerçek insanlar tarafından etkin şekilde kullanılabildiğini garanti eder.

Altın kural: NFR gereksinimlerini proje başında, ölçülebilir ve net sayılarla tanımlayın (örn. “sayfa 2 saniyeden hızlı yüklenmeli”, “sistem 10.000 eş zamanlı kullanıcıyı desteklemeli”). Belirsiz hedefler (“hızlı olmalı”, “güvenli olmalı”) test edilemez — her NFR, somut bir kabul kriterine dönüştürülmelidir.
Başa Dön →

yazilimtestmuhendisligi.com — Nihat Ük

Bu içerik eğitim amaçlı hazırlanmıştır. © 2026

Yorum bırakın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir