Performans Testi Nedir? Nasıl Yapılır? En Önemli 10 Kural ve Dikkat Edilmesi Gerekenler

Performans Testi, bir uygulamanın yalnızca yoğun kullanıcı trafiği altında çöküp çökmediğini görmekten çok daha kapsamlı bir test ve ölçüm sürecidir. Temel amaç, uygulamanın belirli çalışma koşulları altında nasıl davrandığını doğru şekilde ölçmek, elde edilen metrikleri analiz etmek ve sonuçları anlamlı biçimde raporlamaktır. Bu nedenle performans testine başlamadan önce neyin test edileceğinin, hangi senaryoların çalıştırılacağının, test verilerinin nasıl oluşturulacağının, test ortamının nasıl yapılandırılacağının ve yükün nereden ve nasıl üretileceğinin belirlenmesi gerekir. Performans testi yalnızca web uygulamalarına yönelik değildir; API'ler, veritabanları, dosya işleyen uygulamalar, masaüstü uygulamaları ve farklı sistemlerle çalışan entegrasyonlar da performans açısından değerlendirilebilir. Test sürecinin en önemli noktalarından biri doğru bir referans oluşturmaktır. Öncelikle sistemin normal koşullardaki davranışı ölçülmeli, ardından yük kontrollü şekilde artırılarak Response Time, CPU, RAM, Database Bağlantıları, Connection Pool ve diğer ilgili metriklerde meydana gelen değişimler gözlemlenmelidir. Ancak doğru bir performans sonucu elde etmek için yalnızca sanal kullanıcı sayısını artırmak yeterli değildir. Gerçekçi test verisi kullanılmalı, test ortamı mümkün olduğunca production ortamına yakın ve temiz olmalı, uygulamanın mimarisi ve çalışma şekli anlaşılmalıdır. Bunun yanında yalnızca başarılı işlemlerden oluşan Happy Path senaryolarına bağlı kalınmamalı; timeout, dış entegrasyonların cevap vermemesi, servis hataları, cache'in temizlenmesi ve retry davranışları gibi negatif senaryolar da test edilmelidir. Özellikle mikroservis mimarilerinde kontrolsüz retry mekanizmaları zincirleme bir retry storm oluşturarak sistemi daha büyük bir performans problemine sürükleyebilir. Kısacası iyi bir performans testi, yalnızca sistemin ne kadar yük taşıdığını değil, hangi koşullarda, ne ölçüde ve neden performans kaybettiğini ortaya koymalıdır. Bu ölçümler, darboğazların belirlenmesini, kapasitenin anlaşılmasını ve sistemin gerçek kullanım koşullarındaki davranışının daha doğru değerlendirilmesini sağlar. Böylece test sonuçları teknik kararlar için somut bir temel oluşturur.

Security ve Test Engineer İçin En İyi Test ve Güvenlik Uygulamaları: Burp Suite, Telerik, IntelliJ ve Eclipse

Günümüzde yazılım projelerinde güvenlik ve kalite süreçleri birbirinden ayrı düşünülemeyecek kadar önemli hale gelmiştir. Bir Security Engineer, uygulamaların güvenlik açıklarını tespit etmek, HTTP/HTTPS trafiğini analiz etmek ve saldırı senaryolarını kontrollü şekilde test etmek için başta Burp Suite olmak üzere farklı güvenlik araçlarından yararlanır. Burp Suite, özellikle web uygulaması ve API güvenlik testlerinde sektörün en yaygın kullanılan çözümlerinden biridir. Ücretsiz Community Edition temel ihtiyaçlar için kullanılabilirken, Professional ve Enterprise sürümleri daha gelişmiş özellikler ve kurumsal güvenlik süreçleri sunar. Diğer taraftan Test Engineer veya Test Automation Engineer tarafında amaç, uygulamanın fonksiyonlarının doğru çalıştığını sürekli ve tekrarlanabilir şekilde doğrulamaktır. Telerik Test Studio bu noktada web ve masaüstü uygulamalarında test otomasyonu, regression testleri ve fonksiyonel testler için kullanılan önemli araçlardan biridir. Java tabanlı otomasyon projelerinde ise IntelliJ IDEA ve Eclipse doğrudan test aracı olmaktan çok, otomasyon kodlarının geliştirildiği güçlü IDE'ler olarak öne çıkar. Selenium, NUnit, JUnit, TestNG veya REST Assured gibi framework ve kütüphaneler bu IDE'ler üzerinden projelere dahil edilebilir. IntelliJ IDEA'nın ücretsiz temel özellikleri yanında gelişmiş özellikler sunan Ultimate sürümü bulunurken, Eclipse tamamen ücretsiz ve açık kaynak bir IDE olarak kullanılabilir. Dolayısıyla Security Engineer için Burp Suite, Test Engineer için Telerik Test Studio, IntelliJ IDEA veya Eclipse farklı ihtiyaçlara cevap veren önemli araçlardır. Kurumsal projelerde bu araçların birlikte kullanılması, güvenlik, kalite ve otomasyon süreçlerinin daha bütüncül yönetilmesini sağlayabilir. Test ve güvenlik ekipleri açısından doğru aracı seçmek, yalnızca kullanılan yazılımın özelliklerine değil, projenin teknoloji altyapısına, test stratejisine ve ekibin yetkinliklerine de bağlıdır.

Apache JMeter REST API Token Yönetimi: Master-Slave Yapısında Token Kullanımı

Apache JMeter ile REST API performans testleri gerçekleştirirken kimlik doğrulama amacıyla kullanılan Bearer Token, JWT veya benzeri erişim tokenlarının nasıl yönetileceği özellikle distributed test mimarisinde önem kazanır. Master ve 4-5 slave makineden oluşan bir JMeter altyapısında tokenı doğrudan User Defined Variables üzerinden GUI'de tanımlamak operasyonel açıdan oldukça pratiktir. Örneğin master makinedeki test planında TOKEN isimli bir değişken oluşturup değerine gerçek tokenı yazabilir ve HTTP Header Manager içerisinde "Authorization: Bearer ${TOKEN}" şeklinde kullanabilirsiniz. Distributed test başlatıldığında JMeter test planını remote engine'lere gönderdiği için slave makinelerde ayrıca ayrı bir TOKEN değişkeni oluşturmanız veya her slave için ayrı bir text/CSV dosyası hazırlamanız gerekmez. Bu yaklaşım özellikle tüm slave makinelerin aynı REST API'ye, aynı kullanıcı hesabı veya aynı yetkilendirme tokenı ile eriştiği senaryolarda yönetimi ciddi şekilde kolaylaştırır. Token tek noktadan değiştirilir ve test planı üzerinden tüm remote engine'lere uygulanır. Ancak burada önemli bir güvenlik ayrımı vardır: Tokenı GUI'deki User Defined Variables alanına yazmak, tokenın güvenli şekilde saklandığı anlamına gelmez. Değer JMX test planının içerisinde bulunabileceğinden, JMX dosyasına erişebilen kişiler tokenı görebilir. Ayrıca test planının paylaşılması, versiyon kontrol sistemine alınması veya başka ortamlara taşınması durumunda tokenın da istemeden paylaşılması riski oluşur. Dolayısıyla GUI yöntemi operasyonel basitlik açısından avantajlı, ancak secret yönetimi açısından tek başına ideal değildir. Token değerini bir text veya CSV dosyasında tutmak ise test planı ile secret değerini birbirinden ayırma avantajı sağlar. JMX dosyasını açan kişi doğrudan token değerini görmez; test planında yalnızca ${TOKEN} değişkeni bulunur ve değer CSV Data Set Config gibi bir mekanizma üzerinden okunabilir. Ancak Distributed JMeter mimarisinde burada farklı bir operasyonel yük ortaya çıkar.

Apache JMeter'da Gizli Kalan Detaylar: Distributed Test Yaparken Neden Response Body Göremezsiniz?

Performans Testi dünyasında Apache JMeter, uzun yıllardır sektör standardı olarak kullanılan güçlü araçlardan biri olmaya devam ediyor. Ancak JMeter’ı sadece çalıştırabilmek yeterli değildir; asıl fark, onu doğru mimariyle ve verimli bir iş akışıyla kullanabilmektir. Özellikle Distributed Test (Dağıtık Test) mimarisine geçen ekiplerin sıkça karşılaştığı kritik bir durum vardır: slave sunucular üzerinden test çalıştırıldığında View Results Tree listener içerisinde response body verisinin görünmemesi. Bu durum çoğu zaman yanlış bir arıza algısına yol açar ve “sistem bozuldu mu?” sorusunu gündeme getirir. Oysa bu bir hata değil, JMeter’ın ölçeklenebilirlik ve performans odaklı tasarımının bilinçli bir sonucudur. Slave node’lar, test yükünü üretmeye odaklanırken gereksiz veri transferini minimize eder; response body gibi ağır içerikler master node’a taşınmaz. Bunun yerine yalnızca metrik ve istatistiksel veriler iletilir. Bu yaklaşım, network bant genişliğini koruyarak testin gerçek yük senaryosuna daha yakın kalmasını sağlar. Bu nedenle en sağlıklı test yaklaşımı belirli bir standardizasyon gerektirir. Öncelikle senaryolar local ortamda, düşük kullanıcı yüküyle çalıştırılmalı ve response body doğrulaması yapılmalıdır. Yeşil Run butonu ile yapılan bu ilk kontrol, testin doğruluğunu garanti altına alır. Ancak bu adımdan sonra distributed mimariye geçilmeli ve Remote Start All komutu ile gerçek yük testi başlatılmalıdır. Bu disiplinli yaklaşım, hem debug süresini ciddi ölçüde azaltır hem de test sonuçlarının güvenilirliğini artırır. Doğru iş akışı ile JMeter, sadece bir test aracı değil, kurumsal performans mühendisliğinin stratejik bir bileşenine dönüşür. Bu yazıda, JMeter arayüzünde günlük hayatı kolaylaştıran; çoğu dokümanda geçmeyen ama deneyimle öğrenilen pratik ipuçlarını bir araya getirdim.

Modern API Test Stratejileri: WireMock ile Servis Sanallaştırma ve REST Assured ile Güçlü Otomasyon

Modern yazılım geliştirme dünyasında, API ekosistemlerinin karmaşıklığı arttıkça test süreçlerinde karşılaşılan darboğazlar da bir o kadar kritik hale geliyor. Özellikle mikroservis mimarilerinde bir servisi test etmek için ona bağlı olan onlarca farklı dış bağımlılığın (External Dependencies) her an stabil çalışmasını beklemek, test süreçlerini ciddi şekilde yavaşlatan ve "test flakiness" dediğimiz kararsızlık durumlarına yol açan en büyük unsurdur. İşte bu noktada servis sanallaştırma, yani "Service Virtualization" kavramı devreye girerek test ekiplerine tam bağımsızlık kazandırıyor. WireMock Studio gibi gelişmiş araçlar, bu bağımlılıkları ortadan kaldırarak gerçek servislerin davranışlarını, hata kodlarını ve gecikme sürelerini mükemmel bir doğrulukla simüle etmemize olanak tanıyor. Ancak işin asıl zorlayıcı ve stratejik kısmı, bu sanal servislerin sunduğu "test datası" kalitesinde yatıyor. Bugünün kurumsal uygulamaları; Türkiye Cumhuriyeti kimlik numaraları (TCKN), vergi kimlik numaraları (VKN), araç plakaları, şasi numaraları (VIN), pasaport detayları, ehliyet sınıfları ve oldukça karmaşık adres bilgileri gibi çok geniş bir yelpazede veri ile çalışır. Test ortamlarında gerçek kullanıcı verilerini kullanmak, hem KVKK ve GDPR gibi katı veri gizliliği regülasyonları açısından devasa riskler barındırır hem de her test koşuşunda aynı tutarlı veriye ulaşmayı neredeyse imkansız kılar. Bu nedenle, servis sanallaştırma ile entegre bir şekilde çalışan sentetik test datası üretimi, kaliteli bir test otomasyon mimarisinin olmazsa olmazıdır. Örneğin, bir sigorta veya bankacılık uygulamasını test ederken, gerçek bir araç şasisi veya geçerli bir plaka formatına sahip ama anonimleştirilmiş verilere anlık olarak ihtiyaç duyarsınız. Bu spesifik verilerin sanal servisler üzerinden "on-the-fly" (anlık) üretilmesi, testlerin hem gerçekçiliğini artırır hem de her türlü "negatif senaryo" veya "uç durum" (edge case) için sınırsız bir veri havuzu oluşturulmasını sağlar.

Apache JMeter ile Dynamic API Correlation: Response Verisini Sonraki Request Path’ine Aktarma (Performans Testi)

Modern API Test otomasyonlarında en kritik ihtiyaçlardan biri, bir request sonucunda oluşan dinamik verinin sonraki adımlarda doğru şekilde kullanılabilmesidir. Özellikle OTP, transactionId, orderId, token veya sessionId gibi runtime sırasında üretilen veriler statik olmadığı için performans ve entegrasyon testlerinde manuel değer kullanımı sürdürülebilir değildir. Bu nedenle test senaryolarının response içinden veri okuyup bunu otomatik olarak sonraki request’lere taşıyabilmesi gerekir. Apache JMeter, bu ihtiyacı JSON Extractor ve variable management mekanizmalarıyla oldukça verimli şekilde karşılar. Bu çalışmada, OTP akışı üzerinden örnek bir correlation senaryosu ele alınmıştır. İlk aşamada SEND endpoint’ine POST request atılarak OTP süreci başlatılır ve API response içerisinde dinamik olarak bir otpId oluşturulur. Ardından JMeter üzerinde konumlandırılan JSON Extractor ile bu değer response body’den parse edilerek değişken olarak saklanır. Bir sonraki aşamada çalışan VERIFY request’i ise bu değeri manuel tanımlamak yerine runtime sırasında otomatik olarak path parametresine inject eder. Böylece test akışı tamamen dinamik hale gelir ve her çalıştırmada yeni üretilen otpId üzerinden doğrulama işlemi gerçekleştirilir. Verify işleminde kullanılan otpCode alanı bu senaryoda sabit olup "111111" değeri ile gönderilmektedir; dolayısıyla ek bir veri üretimine ihtiyaç duyulmaz. Bu yaklaşım, sadece OTP senaryoları için değil, request chaining gerektiren tüm API workflow’larında reusable ve maintainable test scriptleri geliştirmek için temel bir pattern olarak değerlendirilebilir.

Apache Jmeter Response Assertion Kullanımı ve Performans Maliyetleri

Apache JMeter, yazılım uygulamalarının performansını test etmek için kullanılan ücretsiz ve açık kaynaklı bir araçtır. Java tabanlı olan bu araç, özellikle servis olarak bilinen API katmanlarını, Web arayüzlerini, veri tabanları ve diğer servislerin yük altında nasıl davrandığını ölçmek için tercih edilir. JMeter sayesinde geliştiriciler ve test uzmanları, sistemin farklı senaryolarda ne kadar dayanıklı olduğunu görerek performans darboğazlarını önce den tespit edebilirler. Genelde test ortamlarında Production (Canlı) olarak bilinen ortama en yakın Branch olan PREPROD ortamda performans testleri koşulur ve senaryolar bu ortama göre üretilir. Canlı ortama en yakın simüle edilebilecek yer burası olduğu için. Uygulamanın ücretsiz olması, JMeter aracının en büyük avantajlarından biridir. Lisans maliyeti olmadığı için her ölçekteki kurum ve ekip tarafından rahatlıkla kullanılabilir. Ayrıca açık kaynak yapısı sayesinde sürekli gelişmekte, topluluk desteğiyle yeni eklentiler ve özellikler kazanmaktadır. Kullanıcılar, test senaryolarını kolayca kaydedebilir, düzenleyebilir ve görselleştirilmiş raporlar alabilir. JMeter’ın sunduğu bir diğer önemli fayda, esnekliğidir. Tek bir sunucu üzerindeki küçük testlerden, yüzlerce kullanıcıyı aynı anda simüle eden geniş kapsamlı yük testlerine kadar her ölçekte kullanılabilir. Bu sayede hem yazılım geliştirme aşamasında, hem de canlıya geçiş öncesinde güvenilir sonuçlar elde edilir. Sonuç olarak Apache JMeter, maliyetsiz oluşu ve güçlü özellikleriyle performans testlerinde yaygın ve etkili bir çözümdür. Bu yazımda Apache JMeter ile ilgili Response Assertion ve sunucu maliyetleri ile ilgili bilgi vermenin yanında not aldığım birkaç ufak bilgilerde sizlerle maddeler şeklinde paylaşmaya çalışacağım.

Istanbul Software Testing Conference (ISTC) 2024 & Uluslararası Test Konferansı

Test dünyası adına güzel bir aktivite olan ve sektörün öncülerinin buluştuğu uluslararası Istanbul Software Testing Conference (ISTC) 2024 Test Konferansı 23-24 Mayıs 2024 tarihlerinde düzenlenmiştir. Konferansın ilk günü sunumlar ve paneller ile birlikte tüm gün Elite World Grand İstanbul Küçükyalı otelde yapılırken ikinci oturum ise eğitim sunumu olup öğlene kadar süren ve Palladium Tower binası B1 katında yapılacak olup olan Rik Marselis katılımlarıyla gerçekleşecek olan Keşifsel Test Çalıştayı (Workshop) gerçekleştirilmiştir. Organizasyonu Padran Bilgi Teknolojileri A.Ş. düzenlemiş olup (Okan Çakmak) Test Konferansları arasında oldukça başarılı bir organizasyondur. Organizasyonda etiket olarak bu yıl #ISTC ve #ISTC2024 kullanılmıştır. Organizasyon detayları için (iststc.com) adresini inceleyebilirsiniz. Açılış konuşmacısı (Keynote Speaker) ve bir sonraki günkü eğitimci ise Rik Marselis olup Test dünyasında tanınan sektörün öncülerindendir. ISTC konferansı benim gözlemim ile çok başarılı olup seneye de katılmayı düşünüyorum. Özellikle bu tip konferansların Online (Virtual) değil de direkt canlı olarak organize edilmesini daha değerli ve etkili buluyorum. Çünkü çalışma hayatında bu tip etkinliklere Online katılınca ister istemez bir yandan işiniz ve mailleriniz ile boğulduğunuz için konferansa tam odaklanamıyorsunuz ve organizasyondan edineceğiniz test dünyasına ait yeni haberleri öğrenemiyor zamanınız çöp oluyor. Istanbul Software Testing Conference (ISTC) etkinliği için bazı kısa kısa notlar aldım ve yazımda sizlerle bunları paylaşacağım. Birkaç senedir ana tema Test Otomasyon ve DevOps olarak işlenirken bu sene ve gelecek senelerin teması ise Test ve Yapay Zeka (AI) olacaktır. Özellikle test senaryolarının yapay zeka araçları tarafından üretilmesi ve bu senaryoların DevOps süreçlerine entegre edilme konusu önümüzdeki yılların ana konularından biri olacaktır.

Oracle Database ORA-14402 Updating Partition Key Column Would Cause A Partition Change Hatası ve Çözümü

Oracle Database sistemlerinde Data manipüle işlemleri yaparken özellikle Test Database ortamlarında karşınıza Update ve Edit işlemi yaparken ORA-14402 Updating Partition Key Column Would Cause A Partition Change hatası ile karşılaşabilirsiniz. Bu hata genelde ilgili tabloda Grant yetkinizin olmadığını göstermektedir. Tam yetki her zaman Database Admin’leri tarafında olup testçi ve analizciler için bu yetkiler her tablo ve şemalarda olmayabilir. En temel çözüm ise Database üzerinde işlem yaptığınız kullanıcı (User) için DML yetkisi yani Grant vermekten geçer. Bazı durumlarda Grant yetkisini tablo için alsanız bile bir kolonu Update ederken yine Partition hatası alabilirsiniz. Bunun ise iki çözümü vardır. İlk olanı TOAD üzerinden Data sekmesi yanındaki Partitions kısmına gelip o tabloya bağlı diğer kolonları DISABLED konumdan ENABLED konuma getirmeniz gerekmektedir. Tabii bir testçi olarak buna yetkiniz olmayabilir bunun için üzerinde çalışma yaptığınız Database Admin yetkilisi ile görüşmeniz gerekebilir. Eğer Data manipüle etmek istediğiniz kolonun başka bir tablonun kolonu ile bağlantısı yoksa bu Partition hatasını almazsınız ve direkt Update işlemi yapabilirsiniz. İkinci çözüm olarak ise bunu daha çok testçi arkadaşlar tercih edecektir; ilgili tablonun Insert SQL cümleciğini komple alıp sonra tablodan o Data blokunu komple silmeniz (DELETE) etmenizdir. Sonrasında Insert SQL kodu üzerinde manipüle edeceğiniz yeri değiştirip tekrardan SQL Script’i TOAD üzerinden çalıştırmanız yeterli olacaktır. Bu sayede Partition hatası almaz ve direkt kendi işinizi kendiniz halletmiş olursunuz.

SoapUI Open Source Kullanarak Excel'den Data Çekerek Servis Data Driven Testing Yapmak ve Test Suite Değişken Kullanım İşlemleri

SoapUI Open Source ve servis testleri için bir amme hizmeti ile daha karşınızdayım. Kurumsal test hayatında SOAP ve Rest servis testleri için kullandığımız SoapUI uygulamasında oluşturduğunuz bir Excel veri setinden data çekerek nasıl Data testi yapacağınızı detaylı bir şekilde bu makalede anlatacağım. Aynı işlemin daha basit yolunu SoapUI programının ücretli versiyonu yani Enterprise ürünü olan ReadyAPI ile daha basit yapılabiliyor. Ben Data Driven Testing işlemlerini ücretsiz versiyon olan SoapUI Open Source üzerinden sizlere anlatacağım. Anlatacağım işlemi evde kendi kişisel bilgisayarınızda önce tatbik ediniz sonra iş yerinde aynı mantık ile ufak değişiklikler ile profesyonel olarak kullanabilirsiniz. Bir önceki SoapUI Open Source makalemde Test Suite oluşturma ve kişisel bilgisayarınıza SoapUI Open Source uygulamasını nasıl kurabileceğinizi anlatmıştım. İşlem yapacağımız servis için Data Driven Testing yaparken de önce servisimiz için bir Test Suite oluşturmamız gerekecektir. Bu işlemleri bu makalemde anlatmayacağım bu yüzden SoapUI Open Source Test Suite Oluşturmak isimli bir önceki makalemi okuyabilirsiniz. Burada hem kurulumdan hem de bir SOAP servisi için Test Suite oluşturmadan detaylı bahsetmiştim, buradaki yönergeleri izleyerek Data testi yapacağınız SOAP servisi için bir Test Suite oluşturabilirsiniz. Eğer SoapUI Open Source kurulumu ve Test Suite işlemlerini tamamladıysanız artık Data Driven Testing işlemlerine geçebiliriz.

Jenkins’te Plugin Güncelleme Mesajları ve Uyarıları, Oracle WebLogic Sunucu Restart İşlemi ve Jenkins’te Paket Oluşturma İşlemleri

DevOps araçlarından Jenkins'te sizlere bu yazımda güncel Jenkins LTS ortamına gelen bazı Plugin güncellemelerini ve onla birlikte yansıyan uyarı mesajlarından bahsedeceğim. Bu mesajlar genelde eklenti yönetim paneli olan Plugin Manager sayfasında sarı, mavi ve kırmızı olarak önem seviyesine göre mesajlar şeklinde gözükmektedir. Sarı ve mavi olanlar genelde çok problem çıkarmaz iken kırmızı olanları güncellemek var olan sistemi bozabilir ve hatalar ile karşılaşabilirsiniz bu yüzden açıklamayı iyice okuyup güncelleme yapmanızı tavsiye ederim. Standart birçok eklentiye gelen sarı ve mavi renkli uyarı mesajlarını ben aşağıda sizlerle paylaşacağım. Ayrıca Jenkins LTS'nin son versiyonu olan 2.346.3 ile birlikte gelen birçok eklenti güncellemesi olup bazı eklentileri siz Manuel yüklemiş olmasanız bile otomatik sistemde yüklenmiş olmasının sebebi bazı eklentiler başka Plugin paketlerine bağımlılık (Dependency) duyduğu için otomatik kurulmuştur. Bu yüzden Plugin Manager panelinden bu eklentiyi kullanmıyorum o zaman kaldırayım gibi bir gaflete düşmeyin çünkü başka bir eklentinin bağımlılığı olabilir. Makalemde hem Plugin güncellemelerini hem de Oracle WebLogic Restart işlemi ve bazı Jenkins ile ilgili yeni öğrendiğim bilgileri maddeler halinde sizlerle paylaşacağım.

API Servis Testleri için SoapUI Open Source Kurulumu ve Test Suite Oluşturma Rehberi

API Servis testleri için piyasada en çok kullanılan SoapUI, Postman, ReadyAPI gibi profesyonel araçlardan ücretsiz olan ve SmartBear Software tarafından geliştirilen SoapUI Open Source aracının Windows makinelerde kurulumundan ve kullanımından bahsedeceğim. Hem SOAP hem de REST servis testleri için kullanabileceğiniz bu uygulamada SOAP servisi için Test Suite oluşturma rehberi de sizler için hazırladım. SoapUI aracını daha profesyonel şekilde kullanmak için buna benzer birkaç makale sizlerle önümüzdeki zamanlarda paylaşmaya çalışacağım. İlk olarak SoapUI Open Source uygulamasını Windows makinelere kurulumu ile yazıma başlamak istiyorum. Google'da SoapUI Open Source Download olarak arattığınızda resimdeki gibi SoapUI'ın resmî sitesine girip ücretsiz sürümü indirebilirsiniz. ReadyAPI uygulaması ise lisanlı bir ürün olup kullanmak için ücret ödemeniz gerekmektedir. SoapUI Open Source üzerinden Basic olarak Load ve Security test senaryoları da ayrıca koşabilirsiniz. Genel anlamda SOAP ve REST servis testleri için kullanışlı bir araçtır. Uygulamayı bilgisayara indirdiğiniz zaman kurulum için EXE dosyasını çalıştırmanız yeterli olacaktır. Güncel sürüm olarak 5.7.0 şu an mevcuttur. Next yönergeleri ile kurulumu ilerletebilirsiniz.

JAVA'da Veri tabanı Tablolarından JPA Entity Oluşturma İşlemleri

Java projelerinde Data Model oluşturmak için sizlere bugün Eclipse IDE üzerinden JPA Entity işlemlerinin nasıl yapıldığı hakkında bilgiler vereceğim. Genelde yazılım ve test otomasyon projelerinde bu yöntem çokça işimize yaramaktadır. Özellikle test otomasyon projeleri ile ilgilenenler ve SOAP/REST servisleri için test otomasyonu yazanlar servislerdeki Response yani dönen cevabı aynı zamanda veri tabanından da kontrol etmek için bu yönteme ihtiyaç duymaktadır. SOAP servis testleriniz için Java dili ile test otomasyon projesi yazmak istiyorsanız ayrıca Java SOAP (JAX-WS) konusu ile ilgilenebilirsiniz. Otomasyon Framework alt yapınızı JAX-WS yapısına göre hazırlayıp POM.XML dosyalarınızda SOAP servis adreslerinizi belirterek bu yapıyı kullanabilirsiniz. JAX-WS yapısı ile servis otomasyon senaryolarınızı yazabilir ve Data Model ile de bu yazdığınız senaryo sonuçlarının cevaplarını veri tabanından ayrıca kontrol edebilirsiniz. Hem Response hem de Database tarafında bu şekilde çift kontrol sağlamış olursunuz. Yazıma başlamadan önce Eclipse IDE programının hangi versiyonunu ve nereden indireceğinizi sizlerle paylaşmak istiyorum. Ayrıca JAVA projelerinizde Eclipse dışında diğer popüler olan IDE uygulaması IntelliJ IDEA programını da kullanabilirsiniz. Özellikle JUnit alt yapısı ile test otomasyon yazan birçok kurum bu IDE'yi kullanmaktadır.

Jenkins Plugins Güncelleme ve Yeni Kullanıcı (User) Ekleme İşlemleri

Jenkins, Bilgi Teknolojileri dünyasında özellikle kurumsal firmalar tarafından kullanılan bir CI/CD (Continuous Integration/Continuous Delivery) aracı olup DevOps veya DevSecOps süreçlerinin vazgeçilmez bir uygulamasıdır. Bir uygulamanın geliştirme aşamasından, test aşaması sonra da canlı ortama alınması yani Production sürecine giden yoldaki tüm aşamalarda Jenkins önemli bir rol oynar. Jenkins paneline aşina olmak ve başlangıç için bazı konfigürasyonları ara ara yazarak sizlerle paylaşacağım. Bu yazımda en temel ve basit ayarlar olan Plugin (Eklenti) güncelleme ve yeni bir kullanıcı ekleme nasıl yapılır konusunda sizlerle bilgi vermeye çalışacağım. Öncelikle şunu söylemeliyim, Jenkins çok gelişmiş bir araç olup birçok farklı amaç için kullanılabilir. Paket yönetimi, test otomasyonu, güvenlik testlerinden geçme süreçleri gibi farklı farklı bir uygulamanın son kullanıcıya ulaşmadan önceki tüm operasyonel ve geliştirme aşamalarını burada planlayabilirsiniz. İleriye dönük ve otomatik süreçler tanımlayıp birçok işlemi manuel yapmaktan da kurtulursunuz. Jenkins temelde Java dilinde yazılmıştır ve lokal bilgisayarınıza Windows kurulum dosyasını indirerek JDK kurulumu ile paralel olarak çok basit bir şekilde kurabilir ve inceleyebilirsiniz.

Postman ve SoapUI Üzerinden Yapılan Servis Çağrılarındaki Proxy Hatası ve Çözümü - SoapUI REST Servise Access Token Bilgisi Eklemek

Rest servis testlerini gerçekleştirmek için kullandığımız uygulamalar olan Postman ve SoapUI'da bazı zamanlar Response çıktısı olarak Proxy hata cevapları alabiliriz. Bunun sebebi servis üzerinde yapılan SSL sertifika değişikliği veya güncellenmesinden kaynaklanabilmektedir. Rest servisler üzerinden aldığımız Proxy Error benzeri hataları baypas edip testlerimize tekrardan nasıl devam edeceğimizi bu makalede anlatmaya çalışacağım. Bir de SoapUI üzerinden Rest bir servis için Access Token bilgisinin nasıl Import edileceği hakkında sizlere bilgi vereceğim. Fakat ilk olarak Proxy hatası ve çözümü ile başlamak istiyorum.

Oracle Database ORA-01855: ÖÖ/Ö.Ö. veya ÖS/Ö.S. Gerekli Hatası ve Çözümü

Oracle tabloları üzerinde test çalışması yaparken yeni karşılaştığım bir hatayı ve çözümünü sizlerle paylaşacağım. Java'da yazdığım data maniple testi sırasında bu hatayı almıştım. Oracle Database'de bir veriyi güncellemek istediğimde Java kodu ile yazdığım JUnit testi ile gönderdiğim test kodu aşağıdaki gibi konsolda hata mesajı verdi.

* ORA-01855: ÖÖ/Ö.Ö. veya ÖS/Ö.S. Gerekli

* ORA-01855: AM/A.M. or PM/P.M. Required

IBM Meet Up Eğitimi: Microservis Mimarisi ve Containers Yapıları - İstanbul Marriott Hotel Asia

IBM Meet Up eğitimleri olan Microservis Mimarisi ve Containers Yapıları ile ilgili bilgi verici eğitime geçen ay şirket olarak katıldık. IBM Developer Advocate tarafından verilen eğitimde Microservis mimarisi, REST ve SOAP servisleri, Şirketlerin Microservis yapısına geçmeli mi geçmemeli mi ayrımı, Containers yapılar olan Kubernetes, Docker gibi ürünler hakkında uygulamalı sunum şeklinde bilgiler edindim.

SoapUI Uygulaması Kullanarak Rest Servisi ile Token Bilgisi Alma Yöntemi

SoapUI yazılımı Soap ve Rest servis testleri ve simülasyonu için kullanılan SmartBear firmasına ait bir yazılımdır. SoapUI Open Source uygulamasını Rest API servislerinde kullanmak için ücretsiz olarak 5.5.0 sürümünü SmartBear'ın sitesinden indirebilirsiniz. Rest servisleri için piyasada en çok kullanılan Postman uygulaması genelde tercih edilir fakat ben bu makalemde SoapUI kullanarak bir Rest Token servisinden Token bilgisi almaya anlatacağım. SoapUI uygulamasını ilk açtığınızda yukarıdaki ikonlar olan panel kısmından REST ikonuna tıklayıp Rest Token servis adresini yazarak eklemeniz gerekir. Bu adresin DNS yönlendirmeleri yapıldı ise URL şeklinde (https://servisadres/auth/token) size verilebilir veya direkt IP adresi şeklinde de (https://123.34.34.11/auth/token) olabilir.

Performans Testi Aracı Apache JMeter’da Random Variable Oluşturmak

Performans Testi Aracı Apache JMeter’da belli aralıklarda sayısal değer üretmek için Random Variable özelliğini nasıl kullanacağınızı anlatacağım. İlk olarak Thread Group altında sağ tıklayarak Add > Config Element > Random Variable sekmesini seçerek ilgili alanı oluşturabilirsiniz.

Performans Testi Aracı Apache JMeter’da REST API Servis Senaryosu Oluşturma Rehberi 3

Apache JMeter’da REST API Performans Testleri için daha önce yazdığım iki makalemde JMX kalıbı oluşturmayı ve genel hatları ile Rest Api servis testlerini yapabilmek için alt yapıyı geliştirmeyi göstermiştim. Detaylı incelemek için Rehber 1 ve Rehber 2 yazılarımı inceleyebilirsiniz. Bu yazımda HTTP Request oluşturma ile devam edeceğim.

İlk olarak Thread Group'un altında olacak şekilde HTTP Request sekmemizi oluşturalım. Thread Group sekmesine sağ tıklayıp Add > Sampler > HTTP Request özelliğini ekleyebilirsiniz. Daha sonra aşağıdaki resmi örnek olarak Rest Servis için gerekli alanları doldurabiliriz.