Çalışan yazılım ile yük altında çalışan yazılım aynı şey değildir. Bir özellik, her işlevsel testi geçebilir, hatasız yayınlanabilir ve gerçek trafik geldiğinde ilk seferde çökebilir. Performans testi, bu boşluğu kapatan disiplindir: bir sistemin boşta iken doğru olup olmadığını değil, meşgul olduğunda nasıl davrandığını ölçer.
Bu kılavuz, performans testinin ne olduğunu, ana türlerini, bir sonucu tanımlayan metrikleri ve modern bir test sürecine nasıl uyduğunu açıklar.
Performans testi nedir?
Performans testi, tanımlanmış bir iş yükü altında bir sistemin hızını, kararlılığını ve ölçeklenebilirliğini değerlendirir. "Bu özellik çalışıyor mu?" diye sormaz. Bunun yerine "Ne kadar hızlı, ne kadar dayanabilir ve yeterince yüklendiğinde ne olur?" diye sorar.
Bu ayrım önemlidir. İşlevsel test ve performans testi farklı soruları yanıtlar ve farklı hataları yakalar. Bir giriş bitiş noktası (endpoint) her seferinde doğru token'ı döndürebilir ve yine de yük altında bunu yapmak dört saniye sürebilir. İşlevsel testler geçer; kullanıcılar terk eder. Performans testi, ikinci sorunu ortaya çıkaran şeydir.
Performans testinin çıktısı basit bir geçme veya kalma değildir. Bu bir profildir: bu yük altında, sistem bu kadar hızlı yanıt verir, bu verimi sürdürür ve bu noktanın ötesine itildiğinde bu şekilde başarısız olur. Bu profil, bir ekibin kapasiteyi planlamasına, gerçekçi hizmet seviyeleri belirlemesine ve yayın öncesinde gerilemeleri yakalamasına olanak tanır.
Performans testinin ana türleri
Performans testi, her biri farklı bir soruyu yanıtlamak için farklı bir yük şekli uygulayan bir test türleri ailesidir.
Temel test (Baseline testing), sistemi normal, beklenen yük altında çalıştırır ve sonucu kaydeder. Bu temel, sonraki her testin karşılaştırıldığı referanstır. Bu olmadan, bir sayının iyi mi, kötü mü, yoksa sadece farklı mı olduğunu anlayamazsınız.
Yük testi (Load testing), beklenen en yüksek trafiği uygular ve sistemin dayanıklı olduğunu doğrular: yanıt süreleri bütçe dahilinde kalır, hatalar sıfıra yakın kalır. Sistemin normal yoğun bir günü atlatabildiğini doğrular.
Stres testi (Stress testing), kapasiteyi kasıtlı olarak aşar, sistem bozulana veya başarısız olana kadar yükü artırır. Amaç, kırılma noktasını bulmak ve hata modunu gözlemlemektir. Kademeli bozulma, daha yavaş ama yine de hizmet veren durum kabul edilebilir; veri kaybı veya ardışık hatalar kabul edilemez.
Ani yük testi (Spike testing), yükte ani ve keskin bir sıçrama uygular ve sonra tekrar düşürür. Flaş indirimleri, haber olaylarını ve diğer ani yoğunlukları modeller. Sabit trafik için optimize edilmiş bir sistem, yeterince hızlı ölçeklenemediği için ani bir yükte başarısız olabilir.
Kapasite testi (Capacity testing), sistemin hedeflerini karşılarken kaldırabileceği maksimum yükü bulur. Cevap, doğrudan kapasite planlaması ve otomatik ölçeklendirme eşikleri için kullanılan somut bir sayıdır.
Dayanıklılık testi (Soak testing), kararlılık veya süreklilik testi olarak da adlandırılır, yavaş hataları (bellek sızıntıları, kaynak tükenmesi, kademeli yavaşlama) ortaya çıkarmak için orta düzeyde bir yükü uzun bir süre boyunca sürdürür. Bunlar kısa süreli çalıştırmalarda görünmez ve yalnızca saatler içinde ortaya çıkar.
Çoğu ekip, temel, yük ve dayanıklılık testlerini standart olarak yürütür ve yüksek veya tahmin edilemez trafiğe sahip sistemler için stres ve ani yük testlerini ekler.
Bir sonucu tanımlayan metrikler
Bir performans testi, ondan okuduğunuz metrikler kadar faydalıdır.
Yanıt süresi, istekten yanıta kadar geçen süredir. Her zaman bir dağılım olarak okuyun. Ortalama yanıltıcıdır; sağlıklı bir ortalama, on kat daha kötü olan bir 99. yüzdelik dilimi gizleyebilir. Gerçek kullanıcıların fark ettiği ve şikayet ettiği şey yavaş kuyruktur.
Verim (Throughput), zaman birimi başına tamamlanan iş hacmidir, genellikle saniye başına istektir. Toplam istek sayısının test süresine bölünmesiyle hesaplanır ve sistemin gerçek kapasitesini temsil eder.
Eşzamanlılık (Concurrency), eşzamanlı kullanıcı veya bağlantı sayısıdır. Sistem kapasitesi, yanıt süresinin kabul edilebilir eşiği aştığı eşzamanlılık seviyesi olarak sıkça belirtilir.
Hata oranı (Error rate), yük altında başarısız olan isteklerin yüzdesidir. Hızlı kalan ancak yüksek eşzamanlılıkta istekleri başarısız etmeye başlayan bir sistem başarılı olmamıştır; güvenilir olmayan hız, performans değildir.
CPU ve bellek kullanımı (CPU and memory utilization), diğer sayıların neden değiştiğini açıklar. Gecikme süresi artarken CPU %100'e sabitlenmişse, sistem işlemciye bağlıdır. Gecikme süresi artarken CPU boşta ise, darboğaz aşağı akışta, genellikle bir veritabanı, bir kilit veya harici bir bağımlılıkta bulunur.
Tam bir sonuç bir cümle gibi okunur: bu eşzamanlılıkta, verim burada zirve yaptı, 95. yüzdelik dilim yanıt süresi buydu, hata oranı şuydu ve sunucu bu kaynağa bağlıydı.
Performans testi sürecin neresinde yer alır?
Performans testi eskiden bir projenin sonuna doğru, uzman bir ekip tarafından lansmandan önce bir kez yapılan tek bir kapıydı. Bu model, neredeyse her değişiklikle performans gerilediği için sürekli yayınlanan sistemler için başarısız olur. Yeni bir sorgu, eklenen bir entegrasyon, indekslenmemiş bir sütun, her biri hiçbir işlevsel testin tespit edemediği bir gecikmeyi sessizce ekler.
Daha iyi model, performansı doğruluk gibi ele alır: sürekli kontrol edilir, bir bütçeyle. Kritik yollar için bir yanıt süresi ve hata oranı bütçesi tanımlayın. Bir regresyonun çekme isteğinde derlemeyi başarısız etmesi için CI/CD'de hafif bir yük testi çalıştırın. Daha uzun çalışma sürelerinin kabul edilebilir olduğu, planlanmış yayın öncesi testler için ağır stres ve dayanıklılık testlerini saklayın.
Çoğu sistem için, performans testinin en değerli yeri API katmanıdır. API'ler temel mantığı taşır, hızlı ve belirleyici bir şekilde çağrılabilirler ve uğraşılması gereken değişken bir kullanıcı arayüzüne sahip değillerdir. API'leri yük altında test etmek, güvenilir sayılar sağlar; API performans testi bu odaklanmış yaklaşımı ayrıntılı olarak ele alır. Performans testlerini işlevsel API testlerinin yanında tutmak, her değişikliğin hem doğruluk hem de hız açısından aynı anda kontrol edildiği anlamına gelir.
Yaygın performans testi hataları
Performans testi, güven veren, ancak yanlış sonuçlar üretecek şekilde yapılması kolaydır. Birkaç hata tekrar tekrar ortaya çıkar.
Gerçekçi olmayan altyapıya karşı test etme. Bir geliştirici dizüstü bilgisayarında veya üretim kaynaklarının bir kısmına sahip bir hazırlık ortamında yapılan bir yük testi, hiçbir anlam ifade etmeyen sayılar üretir. Üretime olabildiğince yakın altyapıda test yapın.
Isınma etkilerini göz ardı etme. Birçok sistem, önbellekler dolarken ve bağlantı havuzları açılırken çalıştırmanın ilk birkaç saniyesinde yavaşlar. Soğuk başlangıcı ve kararlı durumu birlikte ölçmek yanıltıcı bir ortalama üretir. Isınma penceresini atlayın veya ayrı olarak raporlayın.
Yüzdelikler yerine ortalamaları okuma. Bu hata çok yaygın olduğu için tekrar etmeye değer. 200 ms'lik ortalama bir yanıt süresi, üç saniyelik bir 99. yüzdelik dilimi gizleyebilir. Ortalama, kimsenin gerçekten yapmadığı bir isteği tanımlar; yüzdelikler ise gerçek kullanıcıları tanımlar.
Gerçekçi olmayan veri kullanma. Her isteği aynı kullanıcı kimliği veya aynı ürünle test etmek, veritabanının her şeyi önbellekten sunması anlamına gelir. Gerçek trafik veri kümesi boyunca yayılır, soğuk satırlara ve önbellek kaçaklarına vurur. Test verilerini buna uygun şekilde değiştirin.
Bir bitiş noktasını izole olarak test etme. Gerçek kullanıcılar iş akışları boyunca hareket eder: giriş yapar, göz atar, arar, ödeme yapar. Tek bir bitiş noktasına yüklenmek, birkaç bitiş noktasının aynı veritabanı ve bağlantı havuzu için rekabet ettiğinde ortaya çıkan çekişmeyi gözden kaçırır. Sadece bireysel çağrıları değil, gerçekçi çok adımlı senaryoları test edin.
Testi tek seferlik bir işlem olarak ele alma. Lansman öncesi tek bir performans testi, bir sonraki özellik yayınlandığı anda geçerliliğini yitirir. Performans sürekli olarak geriler, bu nedenle testin de sürekli çalışması gerekir.
Bu altı hatadan kaçınmak, bir kararı bilgilendiren bir performans testi ile rahatlatıcı ama anlamsız yeşil bir onay işareti üreten bir performans testini ayıran şeyin çoğunluğudur.
Apidog ile performans testleri çalıştırma
Apidog, yük testini API tasarımı ve işlevsel test için kullanılan aynı çalışma alanına entegre eder, böylece performans kontrolleri ayrı bir araç veya API tanımının ayrı bir kopyasını gerektirmez.
Bir bitiş noktasını veya çok adımlı bir test senaryosunu alırsınız, işlevsel olarak geçtiğini onaylarsınız, ardından yapılandırılmış sayıda sanal kullanıcı altında belirli bir süre boyunca çalıştırırsınız. Apidog yükü kademeli olarak artırır ve yanıt süresi yüzdeliklerini, verimi ve hata oranını canlı olarak raporlar, böylece performansın değiştiği tam eşzamanlılık seviyesini görebilirsiniz. Tek bir makine üzerindeki yükün ötesinde, senaryo aynı tanımı koruyarak JMeter'a dışa aktarılır.
Aynı test senaryosu hem işlevsel hem de performans çalıştırmalarına hizmet ettiği için, iki yerine tek bir yapıtı korursunuz. Halihazırda sahip olduğunuz bir bitiş noktasını profillemek için Apidog'u indirin.
Sıkça sorulan sorular
Performans testi ile işlevsel test arasındaki fark nedir? İşlevsel test, yazılımın doğru sonuçlar üretip üretmediğini kontrol eder. Performans testi, yük altında bunu ne kadar hızlı ve güvenilir bir şekilde yaptığını kontrol eder. Her ikisi de gereklidir; hiçbiri diğerinin yerine geçmez.
Hangi performans testi türünü önce çalıştırmalıyım? Temel (Baseline) sonra yük (Load). Temel, size normal koşullar altında bir referans verir; yük testi, sistemin beklenen en yüksek trafiği atlattığını doğrular. Oradan stres, ani yük ve dayanıklılık testlerini ekleyin.
Ortalama yanıt süresi yerine neden yüzdelikler kullanılmalı? Ortalama, ortalamaya doğru çekilir ve yavaş kuyruğu gizler. 95. ve 99. yüzdelik dilimler, en şanssız isteklerin ne deneyimlediğini ortaya çıkarır ve kullanıcılar bu kuyruğu hisseder.
Performans testi otomatikleştirilebilir mi? Evet. Hafif bir yük testi, her değişiklikte CI'da iyi çalışır, regresyonda derlemeyi başarısız eden tanımlanmış bir bütçeyle. Daha ağır stres ve dayanıklılık testleri genellikle her commit'te çalıştırılmaktan ziyade planlanır.
Performans testi geliştirme döngüsünün neresinde başlamalıdır? Çoğu ekibin düşündüğünden daha erken. Gerçek altyapı olmadan nihai gecikme sayılarını elde edemezsiniz, ancak tasarım sırasında bütçeler oluşturabilir ve test senaryolarını yazabilirsiniz. Bir bitiş noktası işlevsel hale gelir gelmez temel bir yük testi çalıştırmak, sorunları düzeltmenin ucuz olduğu sırada yakalar.
Performans testinden kim sorumludur? Modern ekiplerde bu paylaşılır. Geliştiriciler kendi değişiklikleri üzerinde hafif yük kontrolleri yapar; QA daha geniş test senaryolarını ve bütçeleri sahiplenir; operasyonlar veya SRE, üretime benzer altyapıyı ve sunucu tarafı metrikleri sağlar. Bunu tek bir uzmanın işi olarak ele almak, performans sorunlarının üretime ulaşmasına neden olur.
Bir performans testi ne kadar sürmelidir? Isınma penceresini geçip kararlı bir duruma ulaşacak kadar uzun, genellikle bir yük testi için birkaç dakika. Dayanıklılık testleri ise tasarıma göre saatler veya günler sürer, çünkü amaçları kısa süreli çalıştırmaların gözden kaçırdığı yavaş bozulmaları ortaya çıkarmaktır.