Daha önceki yazımızda SoapUI Test Structure yapısından bahsetmiştik. Bu yazımızda SoapUI ile birlikte Web Servis Testleri’nin nasıl yapıldığından bahsedeceğiz.

Bu kısımda öncelikle Web Servis Test Otomasyonu için gerekli SoapUI fonksiyonlarını iyi anlamak gerekiyor.

1. Properties Kullanımı

SOAP projelerinde istek mesajının içerisinde yer alan bazı alanları farklı seviyelerde tanımladıktan sonra herhangi bir projede kullanmamıza olanak sağlayan yapılara Properties denir.

1.1. Global Level Properties

Global tanımladığımız Properties’leri her projede kullanabiliriz.

Preferences-Global Properties-”+” ile ekliyoruz.

1.2. Project Level Properties

Proje üzerine geldikten sonra Custom Properties tabına tıkladıktan sonra “+” ile proje levelinde Properties tanımı yapıyoruz. Bu Properties ancak projemiz özelinde kullanılabilir. Farklı bir projede, bu proje için tanımlanan Properties kullanılamaz.

1.3. Test Case Level Properties

Test Case düzeyinde tanımlanan Properties yanlızca o Test Case için kullanılabilir olurlar.

1.4. Test Step Level Properties

Test üzerine geldikten sonra sağ tık ile Add Step ve ardından Properties seçildikten sonra bizden bir isim vermemizi isteyecektir. İsim verildikten sonra Test Step Level Properties adımını eklemiş oluyoruz.

Open Editor dedikten sonra Properties ekranından ekleme yapabiliriz.

2.Property Transfer Kullanımı

Test Steps üzerine geldikten sonra sağ tık ile Add Step ve ardından Property Transfer seçildikten sonra “+” ile transfer için bir isim giriyoruz ve ardından Ok diyoruz.

Örneğin; 3. Stepten dönen response içerisindeki bir değeri Properties Test Step’e atamak istiyoruz. Bunun için aşağıdaki yolu izlemeliyiz.

Source : 3. Step’i seçiyoruz.
Property : 3.Step’ten dönen response içerisinde bir değer seçmek istiyoruz. Response seçiyoruz.
Source alanı içinde yer alan pencereye alacağımız değerin yolunu gösteriyoruz.
Target : Atama yapmak istediğimiz Step’i seçiyoruz.
Property : Transfer yapmak istediğimiz Property’i seçiyoruz.

Property transferin birçok kullanım şekli var. Response’dan dönen bir değeri başka bir Test Case’de ya da Proje’de de kullanabiliriz. Response’dan dönen değeri başka bir Test Case ya da Test Step’in herhangi bir adımında Request’e transfer edebiliriz. Bizim yukarıda yaptığımız kısmın hem kullanımı basit hem de takip edilebilirliği daha kolaydır.

3.Add Assertion

SoapUI ile web servis testlerini E2E otomatik olarak koşturabiliriz. Bunu sağlamamız için en büyük destekçimiz Assertions’lardır.

Aşağıdaki gibi Assertions’a tıkladığımızda Assertions tanımlayabildiğimiz , Assertion’ları konfigüre edebildiğimiz bir ekran karşımıza çıkmaktadır. Öncelikle hangi Assertions’ları nasıl kullanabiliriz sorusuna yanıt vermeye çalışacağım.

+” ikonuna tıkladığımızda aşağıdaki ekrandan eklemek istediğimiz Assertion’ı seçiyoruz ve sonrasında onunla ilgili düzenlemeleri yapacağımız ekrana gidiyoruz.

3.1. Xpath Match

Response içerisinde gelen belirli bir değer için gösterdiğimiz yol ve değeri beklenen değer olarak atayıp web servis sonucunda gelen değer için Test Step’in passed ya da fail olarak görülmesi sağlanabilir.

Property content – Xpath Match – Add – Assertions’a isim verilir ve Ok butonu ile aşağıdaki ekran açılır.

Örneğin Response içerisindeki Return Code’a göre matchleme yapacağız.

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
 <soap:Body>
<AddResponse xmlns="http://tempuri.org/">
<AddResult>6</AddResult>
</AddResponse>
 </soap:Body>
</soap:Envelope>

Sonrasında Response içerisindeki değerin yolunu göstermek için Declare’e tıkladıktan sonra aşağıdaki şekilde AddResult için path gösteriyoruz.

declare namespace soap='http://schemas.xmlsoap.org/soap/envelope/';
declare namespace ns1='http://tempuri.org/';
//*:AddResult

Sonrasında Select from Current dediğimizde ReturnMessage alanında dönen değerin Expected Result alanında görüntülendiğini görebiliriz. Save dedikten sonra bu Step için ReturnMessage Success dışında bir değer döndüğünde Step’imiz fail olarak görüntülenecek ve Test Case’i fail olarak raporlanacaktır.

3.2. XQuery Match

XQuery Match, hedef özellikten içerik seçmek ve sonucu beklediğiniz değerle karşılaştırmak için bir XQuery ifadesi kullanır. Bu onaylama, XPath Match onaylaması gibi çalışır, ancak XPath yerine kontrol edilecek XML düğümünü seçmek için bir XQuery ifadesi kullanır.

Bu durum, aşağıdaki avantajlara yol açar:

  • Bir XML sonucuna ihtiyacınız olan düğümleri seçebilir ve birleştirebilirsiniz.
  • Herhangi bir sıraya sonuç koyabilir, XML mesaj öğesi sırasından bağımsız Assertions oluşturabilirsiniz.
  • Bu Assertions, yalnızca XML verisi içeren Request ve Response için geçerlidir.

Nasıl kullanıldığını bir örnek vererek göstermeye çalışalım;

Property Content – XQuery Match – Add – Assertions’a isim verilir ve Ok butonuna basılır.

XQuery Match Configuration ekranında Declare dedikten sonra namespace tanımlarının import edildiği görülür.

Sonrasında, aşağıdaki kod ile AddResult değerinin belli bir değere eşit olduğu durumda Assertion’u passed, eşit olmadığı her durum için fail olarak değerlendirilmesini ve Test Case’in bu doğrultuda raporlanmasını sağlayabiliriz.

declare namespace soap='http://schemas.xmlsoap.org/soap/envelope/';
declare namespace ns1='http://tempuri.org/';
<result>{for $a in //*:AddResult
return
if ($a!="6") then  "<pass>AssertionFailed</pass>"
else  " <fail> AssertionPassed </fail> "
}</result>

 

3.3. Response SLA

Response SLA Assertion’ları belirli bir zaman sınırı içinde response beklediğimiz durumlarda kullanabileceğimiz Assertion çeşididir.

SLA – Response SLA – Add dedikten sonra Assertion için isim verilir ve Ok denilir.

Response SLA Assertion configure ekranından ms türünden response time için bir sınır belirliyoruz. Bu sınırı aşan durumlarda Case fail olacaktır.

4.SoapUI ile Örnek Bir Web Servis Otomasyon Çalışması Yapılması

Yazı serimizin bu kısmına kadar anlatımı yapılan SoapUI fonksiyonları sayesinde örnek bir Web Servis Otomasyonu çalışmasını yapabiliriz.

Projemizin Adı : Calculator
Test Steps

  1. Toplama
  2. Çıkarma
  3. Çarpma
  4. Bölme

Kullanacağımız wsdl aşağıdaki gibidir.

http://www.dneonline.com/calculator.asmx

1.Adımda;

Projemize Test Suite oluşturduktan sonra Test Case sonrasında da bir adet Properties step ekliyoruz.

2.Adımda;

Aşağıdaki Property’leri step içerisindeki Properties adımına ekliyoruz.

  • ToplamaSonuç
  • ÇıkarmaSonuç
  • ÇarpmaSonuç
  • BölmeSonuç
  • Sayı1
  • Sayı2

3.Adımda;

Bir Soap Request Step’i ekliyoruz. Öncelikle aşağıdaki gibi Request içerisine Properties içerisinde yer alan değerleri import edecek yapıyı kuruyoruz.

4.Adımda;

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:mer="http://xmlns.ttnet.com.tr/BL/MernisBL">
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tem="http://tempuri.org/">
   <soapenv:Header/>
   <soapenv:Body>
      <tem:Add>
         <tem:intA>${Properties#Sayı1}</tem:intA>
         <tem:intB>${Properties#Sayı2}</tem:intB>
      </tem:Add>
   </soapenv:Body>
</soapenv:Envelope>

Burada her seferinde intA ve intB değerini elle girmemek için Property olarak eklediğim değeri çekmesini sağlamak için aşağıdaki ekran görüntüsünde olduğu gibi Request içerisinde kullanılacak datayı import etmesini sağlıyorum.

İki şekilde de request içerisine ilgili alanı ekleyebiliriz. İstersek Request içerisinde aşağıdaki ifadeye yer vererek ekleyebiliriz.

${Property Lokasyonu#Property ismi}

Bir diğer yöntem ise Request’e eklemek istediğimiz alana gelerek ekran görüntüsünde yer alan kırılım ile eklemektir.

Daha sonra bu servis için hatalı bir servis çağrısı yapılır.

Eksik değer gönderdiğimiz için servis cevabının başarılı olmadığı görülmektedir. Bu durumda faultcode karakteristiği ile gelen değerde beklediğimiz değer soap:Client. Bu değere göre bir “XQuery assertions” eklememiz gerekmektedir.

Öncelikle Declare dedikten sonra aşağıdaki gibi Xquery ifadesini yazıyoruz. Bu durumda stepimiz faultcode soap:Client döndüğünde fail ,diğer durumlar için passed olacaktır.

5.Adımda;

Şimdi Çıkarma işlemi için bir Soap Request Step’i ekliyoruz.

Request içerisinde yer alan aşağıdaki alanlar için Get Data ile Properties’lerdeki değerleri atamamız gerekmektedir.

<tem:intA>${Properties#Sayı1}</tem:intA>
<tem:intB>${Properties#Sayı2}</tem:intB>

Daha sonra Response’da beklediğimiz değerlere göre Assertions ekleyebiliriz.

Başarılı tetiklenen çıkarma işleminde SubstartResult için bir değer dönmesini bekliyoruz. Bu durumda Xpath Match kullanarak “Return Code 100” gelmeyen durumlarda bu adımın fail olmasını sağlamalıyız.

Öncelikle Add Assertions ile Xpath Match ekliyoruz. Configuration ekranından Declare ile namaspace tanımlarını import ediyoruz. Sonrasında Returncode için kontrol edilmesini istediğimiz alanın path’ini gösterip, Expected Result belirliyoruz. Burada Test‘e tıklayarak Xpath Match ‘in doğru oluşturulup oluşturulmadığını kontrol edebiliriz.

6.Adımda;

Şimdi Çarpma işlemi için bir Soap isteğini Step olarak ekleyelim.
Aşağıdaki değerlerin GetData methodu kullanılarak alınması ya da elle yazılması gerekmektedir.

<tem:intA>${Properties#Sayı1}</tem:intA>
<tem:intB>${Properties#Sayı2}</tem:intB>

7.Adımda;

Şimdi Bölme işlemi için bir Soap isteğini Step olarak ekleyelim.

Yine aynı şekilde bölme işlemi requesti için alanları alalım. Burada farklı bir şey yapalım. Öncelikle Çarpma sonucundan dönen değeri Properties içerisinde yer alan ÇarpmaSonuç Properties’ine atayalım. Daha sonra ÇarpmaSonuç Properties’ini Bölme işlemi içerisinde kullanarak bir servis çağrısından dönen değerin başka bir servis çağrısı Request’inde nasıl kullanabiliriz bunu görmüş olalım.

Öncelikle Property Transfer adımında aşağıdaki gibi ilgili düzenlemeleri yapmamız gerekiyor.

Sonrasında Bölme isteğinin içeriğini aşağıdaki gibi yapıyoruz.

<tem:intA>${Properties#Çarpma Sonuç}</tem:intA>
<tem:intB>${Properties#Sayı2}</tem:intB>

 

Şimdi oluşturduğumuz Test Case’imizi Editör üzerinden run edelim. Run ettiğimiz sırada TestCase Log alanından step by step takibini yapabiliriz. Editör üzerinden istediğimiz Test Step’e tıklayarak o Test Step detayına gidebiliriz.

Bu yazıda SoapUI ile Web Servis Test Otomasyonu’nun nasıl yapılacağını en temel seviyede aktarmaya çalıştım. Web Servis Test Otomasyonu yapmadan önce yaptığımız 4 farklı istekte 8 alanı tek tek elle girmek gerekirken, son durumda yalnızca Properties içerisinde yer alan değerleri değiştirmek yeterli olabilecek duruma geldi. Yazımda anlattığım bilgiler ışığında, sizler de sürekli kullanmak durumunda kaldığınız ve içeriklerini çok fazla değiştirerek istek atmak zorunda kaldığınız web servisleriniz için otomasyon projeleri oluşturabilir, oluşturduğunuz senaryoları tek bir ekrandan takip edebilirsiniz.

 

İbrahim Yılmaz

Yazılım Test Mühendisi

 

Kaynaklar:

http://www.dneonline.com/calculator.asmx

http://testingfreak.com/step-by-step-process-to-perform-automation-test-using-soapui/

https://www.soapui.org/test-automation/running-functional-tests.html

https://www.guru99.com/webservice-testing-beginner-guide.html

 

SoapUI-Web Servis Testleri Nasıl Yapılır? yazı dizisinin tüm linkleri aşağıdadır;

https://egemsoft.net/yazilim-test/2019/07/30/soap-ui-web-service-testleri-nasil-yapilir-part-1-genel-terimler-ve-kavramlar/

https://egemsoft.net/yazilim-test/2019/10/10/soapui-web-servis-testleri-nasil-yapilir-part2-test-structure/