SoapUI’ye Yeni Başlayanlar İçin Giriş
SoapUI’yi indirdiniz ve yüklediniz. Akıllıca bir hareket, mükemmelliği test etme yolundasınız! Ancak SoapUI çok kapsamlı bir araçtır ve bazen onu bütünüyle anlamak biraz zaman alabilir. İşte SoapUI’nin nasıl kullanılacağına dair 10 temel ipucu; bunları takip etmek sizi daha iyi bir test uzmanı yapmayabilir, ancak sizi daha yetkin bir kullanıcı haline getirecektir ve bu iyi bir ilk adımdır.
Lütfen aşağıdakilere dikkat edin: Bu ipuçları çok basittir. Tamamen yeni başlayanların yapma eğiliminde olduğu bazı yaygın hatalara dayanmaktadır, ancak sofistike kullanıcılar için biraz basit görünebilir.
SoapUI ile nasıl etkileşim kurulacağına dair önemli bir prensiple çok basit bir şekilde başlayacağız.
İpucu1) Üzerine Sağ Tıkla
Bu ilk ipucu basit görünebilir, ancak bunu yumuşak bir başlangıç olarak düşünün.
SoapUI çok derin bir TestWare’dir ve bu nedenle yapabileceğiniz çok şey vardır. Ne yazık ki çoğu insan mevcut tüm özellikleri asla keşfedemez çünkü SoapUI pek… buna “Menülerde Boğa” diyelim.
Basit bir ipucu; SoapUI arayüzünde nerede olursanız olun, etkileşimde bulunmak istediğiniz herhangi bir öğeye Sağ Tıklayın ve ne göründüğüne bakın, şaşırabilirsiniz. Bu çok basit, ancak SoapUI’nin tamamen sağ tıklama ile ilgili olduğunu anladığınızda, yazılımla çalışmak çok daha kolay hale gelecektir.
Bir sonraki ipucu SoapUI’de testlerinizi nasıl yapılandıracağınızı ele alacak.
İpucu 2) Testlerinizi bir TestCase içine yerleştirin
SoapUI’nin testlerinizi En İyi Uygulamalara dayalı olarak nasıl ele almanızı istediğine dair belirli bir yapı vardır ve bu yapıyı kullanmaktan çok fayda sağlarsınız. Bu yapıyı kullanmak çok zor değildir, çoğu test uzmanı testleri zaten bu şekilde yapılandırır. Şöyle çalışır: TestSuites adı verilen ve TestCases adı verilen gerçek testleri içeren bir test grubunuz vardır. Bir TestCase, sırayla TestSteps adı verilen bir dizi adım içerebilir. İşte bu kadar.
TestSuite, TestCase, TestStep yapısını takip ederseniz kazanacağınız çok şey vardır. Testlerin yeniden kullanımı daha kolaydır; testleri klonlayabilir veya kopyalayabilir ve diğer testlerden bunlara başvurabilirsiniz. Ayrıca bunları LoadUI’de LoadTests olarak çalıştırmak çok daha kolaydır. Yapının sadece teknik faydaları olmayacak, aynı zamanda sizin için de test yapmayı kolaylaştıracaktır; iyi yapılandırılmış bir test projesi, gezinmeyi kolaylaştıracak ve oluşturulan testlerin miktarı, amaçları ve yöntemleri hakkında daha net bir genel bakış sağlayacaktır.
Bir isteği nasıl alır ve bir TestCase’e koyarsınız? Sağ tıklamayı deneyin (ipucu 1’i hatırlıyor musunuz?) ve TestCase’e Ekle’yi seçin. İsteği eklemek istediğiniz bir TestCase’iniz zaten varsa, onu sürükleyip bırakabilirsiniz.
Bir sonraki ipucu, testlerinizi burada öğrendiğimiz yapıda oluşturduktan sonra nasıl adlandırmanız gerektiğini ele alacaktır.
İpucu 3) “Bir isimde ne var? Test dediğimiz şey”
SoapUI Test Yapısını kullanmanın önemini öğrendiğimize göre, şimdi testin okunabilirliğini nasıl artırabileceğimize bakalım. Yeni bir TestCase oluşturduğunuzda SoapUI size kolay bir isim sunar, bu çok yardımcıdır ve hatta bazı durumlarda çok iyi bir çözümdür, ancak ciddi bir endüstriyel TestSuite oluşturmaya çalıştığınızda değil. SoapUI’nin bir teste TestSuite 3 veya TestCase 349 gibi isimler vermesine izin vermek, bir avuç testiniz olduğunda işe yarayacaktır, ancak 3 ay veya yıl sonra TestCase 349’un ne yaptığını hatırlayacak mısınız? Ya da ReadyAPIject’i paylaştığınız Test Buddy’niz TestCase 349’un ne yaptığını anlayacak mı?
Bunun yerine biraz daha zaman harcayın ve testin ne yaptığını anlamanıza yardımcı olacak bir isim seçin, örneğin, “Müşteri Veri Güncellemelerinin çalıştığını doğrulamak için TestSuite” veya “Bayi İndirimlerinin artışını test eden TestCase ”.
Özellikle TestSuite’lerini iyi adlandırmak için çok çalışırsanız, projeyle etkileşimi çok daha kolay hale getirir, “Bayi İndirimlerinin artışını test eden TestCase”, “Bayi Koşullarını değiştirmek için TestSuite” adlı bir TestSuite’sindeyse bulmak çok daha kolaydır. Projeyi isimlendirerek çalıştıysanız, bir süre dokunmadıktan sonra yeniden öğrenmek çok daha kolay olacaktır ve ayrıca ne tür testlerin eksik olduğunu anlamanıza yardımcı olur. “Bayi İndirimlerinin artırılmasını test eden bir TestCase’im var, neden bunların azaltılmasını test eden bir tane yok”.
Teğet geçti:
Ayrıca, ipucu başlığında Shakespeare’den yapılan alıntının da tartıştığı gibi, bir öğenin adlandırılması öğenin kendisini değiştirmez mi? “Müşteri ekleme için negatif testler içeren TestSuite” TestSuite’sindeki ‘SSN’si çok uzun olan bir müşteri ekleme için TestCase’ adlı bir test, ‘TestSuite 45 ’teki ‘TestCase 2 ’den çok daha güçlü ve geçerli bir test değil midir? İşlevsel olarak aynı olsa bile mi? İşaret, göstereni değiştirmez mi? Ve burada göstereni nasıl algıladığımızdan değil, gerçek Gösterenin kendisinden bahsediyoruz.
Projenizdeki Öğeleri adlandırmak için de aynı yöntemi kullanmanız iyi bir tavsiye olacaktır; bunu yapmak hem yeni Öğeleri adlandırmayı hem de onları anlamayı kolaylaştırır.
Şimdi testlerinizi nasıl adlandıracağınıza baktığımıza göre, testlerin gerçekleştirilmesiyle ilgili bazı ipuçlarına bakacağız. Sıradaki ipucu Assertion’ların gerekliliği hakkında.
İpucu 4) İddia etmek ya da etmemek: bu asla bir soru olmamalı
SoapUI’de test etmek tamamen iddialarla ilgilidir. Bunlar olmadan bir test gerçekleştirdiğinizi düzgün bir şekilde söyleyemezsiniz. Bu da şu soruyu akla getiriyor: Peki, o zaman assertion nedir? Basitçe söylemek gerekirse, assertion’lar aldığınız şeyin beklediğiniz şey olup olmadığının kontrol edilmesidir. Bir örnek; ürün kimliğine göre bir ürün aradığım bir Web Hizmetim var. Yanıtta, ürün kimliği adlı alanda aynı ürün kimliğini bekliyorum. Manuel test yaparsam, isteği gönderirim ve ardından yanıtta eşleşen kimliği ararım. Buna asserting diyoruz. Gördüğünüz gibi assertion testin ayrılmaz bir parçasıdır, ancak test yazılımındaki testlerin oldukça büyük bir kısmı assertion’lar olmadan yapılır ve SoapUI’de bunları gerçekleştirme alışkanlığı edinmenizi istiyoruz. “Yanıtta eviware şirket adı varsa, test ettiğim hizmet çalışıyor gibi görünüyor” demek bir iddia örneği olabilir.
SoapUI’de assertion oluşturmak çok basittir; bunları SoapUI istek/yanıt düzenleyicisindeki Assertion Sekmesine giderek oluşturabilirsiniz.
Düzenleyicide New Assertion düğmesine tıklarsınız ve ardından hangi tür assertion istediğinizi seçersiniz. İlk başta, bir metin için tüm yanıtı kontrol eden Contains assertion gibi çok basit bir assertion ile başlayabilir ve daha sonra hızlı bir şekilde daha doğru XPath assertion’a geçebilirsiniz (ReadyAPI’ye bakın, XPath assertion’ları orada gerçekten basittir), yanıttaki belirli bir öğede bir metin olup olmadığını kontrol edersiniz. Contains assertions “Yanıtta ‘eviware’ metninin olmasını istiyorum” derken, XPath “Şirket Adı öğesi yanıtında ‘eviware’ metninin olmasını istiyorum” der.
Şimdi devam edin ve bir iddia oluşturun:
Ne kadar kolay olduğunu görüyor musunuz? Burada durmayın; diğer iddiaları da deneyin ve nasıl çalıştıklarını anlayın.
Şimdi SoapUI’nin bir sonraki seviyesine geçme zamanı. Yeni kullanıcılardan sıkça aldığımız bir soru; “Yanıttaki bir şeyi alıp bir sonraki İstekte nasıl kullanabilirim?” ya da SoapUI dilinde “Yanıttaki bir öğenin içeriğini nasıl aktarabilirim ve bunu bir istekteki bir öğeye nasıl koyabilirim?”. Hepsi bir sonraki ipucunda açıklanacak; İpucu 5) Özelliklerin Nasıl Aktarılacağını Öğrenin
İpucu 5) Mülklerin Nasıl Transfer Edileceğini Öğrenin
SoapUI’de assertion’lardan sonra en çok kullanılan ikinci özellik Property Transfer’dir. Bu kadar yaygın olduğu için kullanışlı olduğu aşikar, ancak ne işe yarıyor? SoapUI testlerinizdeki en yaygın senaryo muhtemelen bir yanıttaki değeri alıp bir isteğe taşımak istemenizdir; örneğin, oturum açtıktan sonra bir yanıtta bir sessionID alırsınız ve sonraki tüm isteklerde bu sessionID’yi kullanmanız gerekir. Bu çok yaygın bir senaryodur ve Property Transfers bunu başarmanıza yardımcı olur. Özelliklerin aktarılması çok önemli ve merkezi olduğu için bunu yapmanın iki yolu vardır; Özellik Aktarımı Test Adımları veya Özellik Genişletmeleri. Her ikisi de iyi çalışır, hangisini kullanacağınız kişisel zevk meselesidir.
Her ikisini de ReadyAPI’de yapmak son derece basittir ve Açık Kaynak sürümünde biraz daha zordur, ancak önemli değil; nasıl yapılacağını öğrenin!
Nasıl çalıştığını göstermek için SoapUI Örnek Projesinden bazı ekran görüntülerini görelim.
Özellik Aktarımı Adımı, değerleri seçmek ve örneğin bir istek içine yerleştirmek için XPath ifadelerini kullanan TestCase’deki (bkz. ipucu 2) bir Test Adımıdır.
Özellik Genişletmesi, diğer parçalara, örneğin SoapUI’deki bir istekte bulunan bir öğeye referans vermek için SoapUI’nin dahili biçimini kullanır
Mülkiyet Transferi hakkında daha fazlasını buradan okuyun http://www.soapui.org/Functional-Testing/transferring-property-values.html ve Mülkiyet Genişlemesi burada http://www.soapui.org/Scripting-Properties/working-with-properties.html
Sonraki İpucu; İpucu 6) Yanıtı Okuyun
İpucu 6) Yanıtı Okuyun
Bu kısa ama çok kullanışlı. Testleri yaptığınızda, Test Günlüğüne bakarak sonuçları adım adım görebilirsiniz. Bu günlük hem TestSuites hem de TestCases için mevcuttur ve size testlerin çalıştığı her adımı gösterecektir.
Test Adımına tıklarsanız gerçek sonucu görürsünüz.
Elbette bu, bir şey başarısız olduğunda çok önemlidir, ancak bir şey başarılı olduğunda da ilginçtir. Gerçek test çalışmasına bakmak, testin doğru çalıştığını doğrulamak için kullanılabilir.
Sonraki ipucu: Günlüğü kullanın!
İpucu 7) Günlüğü Okuyun
SoapUI, yazılımda neler olup bittiğini oldukça kapsamlı bir şekilde günlüğe kaydeder; testlerde neler olup bittiğine dair bilginizi artırmanın iyi bir yolu, neler olup bittiğini görmek için günlükleri kullanmayı öğrenmektir. Çok yaygın bir örneğe bakalım. Bir istek gönderdiniz, ancak SoapUI Yanıt penceresinde herhangi bir yanıt alamıyorsunuz.
SoapUI’de size neyin yanlış olabileceğini söyleyen bir dizi günlük vardır. Örneğin, aşağıdaki URL için bir HTTP testi (yani bizim gibi ölü insanlar için Testing Web) oluşturun; http://www.ghiklj.com, ve isteği gönderin. SoapUI Yanıt penceresinde hiçbir şey görmeyeceksiniz, ancak SoapUI Günlüğüne baktığınızda aşağıdakileri göreceksiniz:
Fri Jul 30 15:57:08 CEST 2010:ERROR:Exception in request: java.net.UnknownHostException: www.ghiklj.comFri Jul 30 15:57:08 CEST 2010:ERROR:An error occured [www.ghiklj.com], see error log for details Fri Jul 30 15:57:08 CEST 2010:INFO:Error getting response for [HTTP Test Request]; java.net.UnknownHostException: www.ghiklj.com
Hata Günlüğüne baktığınızda bunu görürsünüz:
Fri Jul 30 15:57:08 CEST 2010:ERROR:java.net.UnknownHostException: www.ghiklj.com java.net.UnknownHostException: www.ghiklj.comat java.net.PlainSocketImpl.connect(Unknown Source) at java.net.SocksSocketImpl.connect(Unknown Source) at java.net.Socket.connect(Unknown Source)at java.net.Socket.connect(Unknown Source) at java.net.Socket.(Unknown Source)at java.net.Socket.(Unknown Source)at org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.createSocket(DefaultProtocolSocketFactory.java:80) at org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.createSocket(DefaultProtocolSocketFactory.java:122)at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:707)at com.eviware.soapui.impl.wsdl.support.http.SoapUIMultiThreadedHttpConnectionManager$HttpConnectionAdapter.open(SoapUIMultiThreadedHttpConnectionManager.java:1666)at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:387) at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397) at com.eviware.soapui.impl.wsdl.submit.transports.http.HttpClientRequestTransport.sendRequest(HttpClientRequestTransport.java:187) at com.eviware.soapui.impl.wsdl.WsdlSubmit.run(WsdlSubmit.java:122) at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source)
Bu hata günlüğünde bir istisna olmasına rağmen, SoapUI’de bir sorun olduğu anlamına gelmez, hata mesajını daha dikkatli incelediğinizde, girdiğiniz URL’nin mevcut olmadığını hemen fark edeceksiniz. Günlükleri okumak size bu konuda yardımcı olabilir; yazılımda neler olduğunu bulmak.
İpucu 8) Hızlı bir Yük Testi yapın
Evet! Yük Testi bir ipucudur!
Vay canına, yük testi çok zaman almıyor mu? Haftalar süren hazırlıklar gerekmiyor mu? Hayır, Yük Testi hiç de korkutucu veya karmaşık değildir. Aslına bakarsanız; SoapUI’de bile kolaydır ve oluşturmanız 10 saniyeden fazla sürmez. Sadece bir Fonksiyonel Teste sağ tıklayın (Evet, yine o Sağ Tıklama var, ipucu 1’i hatırladınız mı?), Yeni Yük Testi’ni seçin ve Hey Presto, gitmeye hazırsınız!
Peki testi oluşturmanın değeri nedir? Benim için ne işe yarayacak? Bir LoadTest oluşturmak çok kolay olduğundan, bu, ek yükün az olduğu ve performans sorunları hakkında erken bulabileceğiniz herhangi bir uyarının çok yararlı olduğu anlamına gelir. Hızlı bir yük testi oluşturmak sizi gelecekte büyük bir potansiyel sıkıntıdan kurtarabilir.
Ve bunu bir adım öteye taşımak istiyorsanız, LoadUI’yi indirin ve Yük Testlerini burada çalıştırın. Çok kolay ve sezgiseldir ve aynı şekilde çalışır; sağ tıklayın ve çalıştırın. LoadUI ayrıca size testleri daha sonra ölçeklendirme olanağı da sağlar. Önce dahili makinelere dağıtılmış ve daha sonra bulut odaklı devasa dağıtılmış canavarlara!
Bu yüzden beklemeyin, ilk Yük Testinizi yapın. Bugün.
İlk 8 ipucunu takip ederek artık oldukça iyi bir SoapUI’cı olmalısınız. SoapUI ustalığının bir sonraki seviyesine ulaşmak için iki iyi ipucu ile bitireceğiz. Sırada, İpucu 9) RTFM!
İpucu 9) RTFM!
Her türlü kayıt için; yukarıdaki başlık son derece saygı ve sınırsız sevgi ile yazılmıştır. Sadece biraz şok edici ama komik olmaya çalışıyoruz ve bulabildiğimizin en iyisi bu.
Bu ipucu oldukça açık gelebilir; bu sayfayı okuyorsanız, kılavuzu okumanın değerini anlıyorsunuz demektir. Ama dürüst olalım, kimse kılavuz okumayı sevmez. Ancak kılavuz yararlı olabilir ve biz ona çok çaba ve sevgi harcadık ve ihtiyaçlarınızın çoğunu karşılayacaktır. Belgelerdeki birkaç özelliği vurgulamak istiyoruz;
- Örnek Proje.
SoapUI Kurulumunda bir örnek proje vardır (SoapUI Kurulum Klasöründeki Tutorials klasöründe). SoapUI’nin nasıl çalıştığını anlamanın harika bir yoludur. Örnek proje etrafında takip etmesi kolay bir öğretici bile var. Bunu Başlarken Bölümünde bulabilirsiniz. - SoapUI içinde arama yapın.
SoapUI, SoapUI Topluluk Forumlarında arama yapmanızı sağlayan harika bir arama işlevine sahiptir. Orada çok sayıda akıllı insan takılıyor, bu yüzden cevapları bulmak ve soru sormak için bunları kullanın. - SoapUI.org’da arama yapın.
Web sitesinde çok şık bir arama oluşturmak için çok zaman harcadık. Her zaman kullanın!
Şimdi, Forumları beğenmediyseniz veya belgeleri beğenmediyseniz veya eğitimlerin daha iyi olabileceğini düşünüyorsanız, ne yaparsınız? İpucu 10’a gidin!
İpucu 10) 3, 2, 1, Harekete geç!
Kendinizi bir SoapUI Acemisi gibi hissediyorsanız, endişelenmeyin, her hafta sizden binlercesi var. SoapUI’de siyah kuşak sahibi olmadığınız için utanarak kabininizde saklanmak yerine, dışarı çıkın, bilgi arayın ve aktif olun.
SoapUI hakkında pek çok iyi blog ve makale var, Haberlerde Bölümümüze bir göz atın. SoapUI Web Site. http://www.soapui.org/soapUI-in-the-news/
Ayrıca, SoapUI Forumlarına gidin, http://www.soapui.org/forum, ama pusuda bekleyen biri olmayın. Diğer kullanıcılarla konuşun, cevabını bildiğiniz soruları yanıtlayın ve sahip olduğunuz sorulara cevap isteyin.
Ayrıca, “Kötü!” bile olsa her türlü geri bildirimi gerçekten takdir ediyoruz çünkü bize neden berbat olduğumuzu söylerseniz daha az berbat olmak için çalışabiliriz.
İşte bu kadar!
Artık tam teşekküllü bir SoapUI Ustasısınız ve SoapUI’nin daha neler sunabileceğini araştırmaya hazırsınız. Bu ipuçlarını okuduğunuz için teşekkürler, umarız size yardımcı olmuşlardır.
Kaynak:soapui.org
Leave a Reply