Postman ile API testi nasıl yapılır?
Merhabalar, bu yazımda sizlerle Postman kullanımı ile ilgili faydalı olduğunu düşündüğüm bilgiler paylaşacağım ve kendi hazırladığım RestApi olan AysRestApi özelinde anlatımlar yaparak ekran görüntüleri paylaşıyor olacağım. QA mühendisler olarak hayatımızı kolaylaştıran ve yazılım dünyasında en çok kullanılan araçlardan biri olan Postman’e hemen kısa bir giriş yapalım.
Öncelikle nedir bu postman diye soracak olursak; Postman, oluşturduğumuz ya da başkaları tarafından oluşturulan Restful apileri inceleyip, test edebildiğimiz aynı zamanda paylaşabildiğimiz harika bir araçtır. Sadece bir API’nin işlevselliğini test etmek için bir sürü kod yazma zahmetine girmeden request atabileceğimiz şık bir kullanıcı arayüzü sunar.
Collections
Şimdi ‘collections’ kısmından bahsedeceğim. Postman’deki collections, Postman’de zaten kayıtlı olan ve klasörler halinde düzenlenebilen bir grup API requestleridir. Bir collection içinde istenilen sayıda klasör oluşturulabilir. Bunun ne gibi yararı var diye soracak olursak benzer requestleri klasörlere koymak, bize taleplerimizi daha iyi organize etmemize ve belgelendirmemize yardımcı olur.
Tüm API requestleri bir koleksiyon içinde saklanabilir ve kaydedilebilir ve bu koleksiyonları Postman çalışma alanında ekip arasında paylaşabiliriz.
Koleksiyonların Avantajlarını sıralamak gerekirse;
· API’leri kolaylıkla import/export edebilme,
· Requestleri kategorilendirme,
· Requestler arası data transferi,
· API dökümantasyonu,
· Test suitleri oluşturma,
Http Request Metotları
Postman de farklı test senaryoları için farklı türde requestler bulunmaktadır.En çok kullanılanları hep birlikte inceleyelim.
GET: Bu yöntem, bilgileri URL’yi kullanarak sunucudan alır.GET, belirli bir kaynaktan veri talep etmek için kullanılır. GET, en yaygın HTTP yöntemlerinden biridir.
POST: Bu yöntem, verileri sunucuya gönderir ve veritabanında yeni girişler oluşturur. POST ile sunucuya gönderilen veriler, HTTP requestinin, request body kısmında saklanır.
PUT: Bir kaynağı oluşturmak ya da güncellemek amacıyla sunucuya veri göndermek için kullanılır.
DELETE: DELETE yöntemi, belirtilen kaynağı siler.
AysRestApi’de örnek bir requesti ve request ögelerinin altta bulunan ekran görüntülerinde görebilirsiniz.
Environment
API’ lerle çalışırken genellikle dev, prod, preprod gibi farklı ortamlara ihtiyaç duyabiliriz. Environment bize, değişkenleri kullanarak requestleri özelleştirme olanağı sağlar. Bu şekilde requestleri değiştirmeden farklı ortamlar arasında kolayca geçişler yapabiliriz. Environmentler JSON dosyaları olarak indirilip, kaydedilebilir.
Şimdi birlikte sıfırdan yeni bir ortam oluşturalım.
Kullanılan bir ortam seçimi
Sağ üstteki drop down menüden etkin bir ortam seçebiliriz. Ortamı seçtikten sonra değişkenlere ulaşıyoruz.
Variable adı çift süslü parantez içine alınır. ör. {{API_URL}}. Tek süslü parantezleri “{“ yazarak da değişken önerisi alabiliriz.
Environment variable lar Global olarak ta tanımlanabilir.Bu şekilde tanımlanmış variable lar tüm oluşturulmuş olan Environment lar içinden erişilebilir.
Not: Ortam ve global değişkenler her zaman stringler olarak saklanacaktır. Nesneleri ya da dizileri saklıyorsak, önce bunları JSON.stringify () ve geri alırken JSON.parse () yaptığımızdan emin olmalıyız.
Script kullanımı
Koleksiyonlarda testleri düzenleme
Postman’ı keşif testi yapmak için kullanırsak, requestlerin nasıl düzenlendiği ve yapılandırıldığı konusunda çok fazla endişelenmemize gerek yoktur.Ancak, API testlerimizi otomatikleştirmeye başladığımızda, organizasyon konusunda daha dikkatli olmamız gerekir. Postman’da testleri düzenlemenin ana yolu Koleksiyonlar’dır. Bir koleksiyon, esasen, çeşitli uç noktalara birden çok isteği depolayabileceğiniz bir klasördür.İlgili testleri organize bir şekilde bir arada toplamanıza izin verir ve ayrıca bir koleksiyondaki farklı testler arasında veri paylaşmayı çok daha kolay hale getirir.
Otomasyon testler yazarken, başka hangi testlerin inşa edileceğini ve gelecek için plan yapacağını önceden düşünmek işe yarar. Aralarında herhangi bir yapı veya uyum olmaksızın sadece çeşitli testler oluşturursanız, işler değiştiğinde bunları güncellemek masraflı olacaktır. Örneğin, yetkilendirmeye bakalım.
Yaptığınız çağrıları yetkilendirmek için bir bearer token kullanan bir API’niz olduğunu varsayalım. Bunun için talebi Postman de açabilir, Yetkilendirme sekmesine gidebilir ve token ı girebilirsiniz. Tek bir testle, her şey yolunda ve güzel, ancak her biri bu belirteçten yararlanan 25 farklı uç noktanızın olup olmadığını ve ardından belirtecin güvenlik nedeniyle ayda bir değiştiğini hayal edin. Bu, her ay Postman e gitmeniz, 25 isteğin her birini açmanız ve her birindeki token ı güncellemeniz gerektiği anlamına gelir. Bu fazlasıyla zamanımızı alır.
Bunun yerine, bu çalışmadan bizi kurtarmak için bir koleksiyon kullanabiliriz. Tüm bu 25 isteği aynı koleksiyona kaydetmiş olsaydık, koleksiyonun yanındaki 3 noktayı tıklayıp düzenleme seçeneğini seçebiliriz.
Daha sonra oradaki yetkilendirme sekmesine gidip bearer token yerleştirebilir ve koleksiyonu güncelleyebiliriz. Bunu yaptıktan sonra, koleksiyondaki her teste gidebilir ve Yetkilendirme sekmesinde “ Inherit auth from parent “ seçeneğini belirleyebiliriz.
Bu kurulumla, bearer tokenın bir sonraki kullanım süresi dolduğunda, sadece koleksiyona giderek onu orada güncellemek için gitmemiz gerekir. Bu değişiklik anında 25 uç noktamızın tümüne yansıtılır. Bu bize fazlasıyla zaman tasarrufu sağlar.
Variables
Bir koleksiyonla testler arasında kolayca paylaşabileceğiniz tek şey yetkilendirme değildir. Ayrıca testler arasında paylaşılabilecek değişkenler de oluşturabiliriz. Koleksiyonu düzenleyerek ve Variables sekmesine giderek bir koleksiyona yeni değişkenler ekleyebilirsiniz.
Programlamaya benzer şekilde, değişkenler değerleri farklı yerlerde yeniden kullanmanıza yardımcı olur ve bu da otomatik testlerimizdeki verileri yönetmeyi çok daha kolay hale getirir.
Postman Test Scriptleri
Eğer requestimize gelirsek Tests yazan bir tabımız olduğunu görürüz.
Burada, requeste test ekleyebilirsiniz. Postman’daki test komut dosyaları JavaScript’te yazılır, ancak JavaScript bilmiyorsanız, Postman, başlamanız için bazı yerleşik kod snippetleri içerir. Sağ tarafta, aralarından seçim yapabileceğiniz bir dizi farklı snippet göreceksiniz. Biraz aşağı kaydırın ve Durum kodu: Kod 200 adında bir tane göreceksiniz. Bu, bir API çağrısında başlamak için iyi bir kontroldür. Başarılı API çağrıları bir 200 kodu döndürmelidir ve başarılı olmasını beklediğimiz bir çağrı gönderdiğimiz sürece, 200 dönüş koduna sahip olmasını beklemeliyiz. Bu snippet bağlantısını tıkladığınızda şuna benzeyen bir test eklediğini göreceksiniz:
Şimdi, bu requesti gönderirseniz, isteği daha önce olduğu gibi gönderir, ancak yanıt geri geldiğinde yanıt kodunun 200 olup olmadığını kontrol eder. İsteği gönderdikten sonra, aşağı kaydırırsanız test sonuçlarını görebilirsiniz. Test Sonuçları sekmesi altında.
Devam edin ve testte beklenen durumu 200 yerine 400 olarak değiştirin ve requesti tekrar gönderin. Şimdi test sonuçlarının altında, 400 kodunun beklendiğini ancak bunun yerine 200 aldığını söyleyen bir başarısızlık göreceksiniz. Artık Postman’da başarılı ve başarısız sonuçların nasıl görüneceğini bildiğinize göre, testi 200 olup olmadığını düzgün bir şekilde kontrol edecek şekilde değiştirebilirsiniz, böylece bir dahakine pass olur.
Validasyon Nedir?
Bir API üzerinde API’nin ihtiyaç duyduğu elemanları veya öğeleri ya da akışların önceden belirlenmiş ihtiyaçları karşılayıp karşılamadığını ve analiz kapsamında akışın doğru veya hatalı olduğunun raporlarını görmemize ve geliştiricilere yol göstermesine olanak sağlayan bir otomasyondur.
Şema Validasyonu
Postman API’sinde kullanılan herhangi bir JSON Objesinin (Request Body, Environment Değişkeni..v.b.), beklendiği niteliklere veya yapıya sahip olup olmadığının test otomasyon kodları bütünüdür.
Yukardaki ekran görüntüsünde olduğu gibi ilk 5 satırdaki kod bir şema validasyon kodudur. Buradaki şema validasyon kodu AysRestApi’nin Environment değişkeninden ‘’AysUserSchema’’ ismiyle tanımlanmış değerindeki JSON nesnesini response body içerisinde gelen nesneyle karşılaştırıp validasyonunu sağlamaktadır.
AysUserSchema değeri alttaki gibidir;
Pre Request Testleri
API Üzerinde, henüz request atılmadan önce yapılması istenen özellikle Request nesnesi üzerindeki validasyonların veya assert testlerinin yapıldığı test otomasyon kodları bölümüdür.
Buradaki pre-request test kodu request henüz sunucuya ulaşmadan çalıştırılarak valide edilir.
İlk 2 satır requestin headerına AysRestApiKey isimli değer olarak Environment değişkenleri içerisindeki aynı isimli değişkenin değerini eklemektedir, bu şekilde request sunucuya çıkmadan önce apikey headerının ekli olduğunu garanti etmektedir.
4.satırdaki kodlar yukarıdaki eklenen header ın değerinin undefined olmaması gerektiğini valide eder.
Post Testleri
Pre-Request Testleri gibi aynı şekilde, API Response’u alındıktan sonra, Response nesnesi üzerinde validasyon veya assert testlerin yapıldığı test otomasyon kodları bölümüdür.
7. satırdan itibaren response üzerinde 3 tane assert test validasyon kontrolü bulunmaktadır.Bunlar sırasıyla;
· Gelen response un içerisinde user property si olması gerektiği ve bu user property sinin bir object niteliği taşıması kontrolüdür.(8.satır)
· Gelen response status kodunun 201(created) statüsünde olması gerektiğinin kontrolüdür.(12.satır)
· Gelen response un JsonBody formatında olup bu body içerisinde error propertysi ve ya niteliği taşımaması gerektiğinin kontrolüdür.(17.satır)
Bu test kodlarının tümünün sonuçları için başarılı olması durumunda test result aşağıdaki gibi pass olacak şekilde geldiği görülür.
Bu test kodlarının kısmen veya bütün olarak başarısız olması durumunda ise aşağıdaki gibi fail olacak şekilde geldiği görülür.
MockServer Nasıl Çalışır?
Request gönderdiğinizde, MockServer Kolleksiyonunuzdaki requestlere kaydedilmiş bir example response var ise, bu response’u direkt olarak, response body olarak döndürür.
Bir Request birden fazla example’a sahip olabilmektedir.
MockServer hangi ilgili requestte hangi isimli example’i cevap vereceğini, Request Header içerisindeki “x-mock-response-name” değerindeki aynı isimli example ile eşleştirerek karar verir.
Bir request içerisinde kaydedilmiş herhangi bir example yok ise, MockServer bu istek için bir 404 Not Found cevabı verir.
MockServer avantajları
- Bir API henüz backend geliştirmeleri başlamadan, ilgili entegrasyon noktalarına, kişi veya kurumlara geliştirilme süresini beklemeden veya başlanmadan, hazır halde sunulabilir.
- Proje geliştirilmeden önce, MockServer ile API üzerindeki test ve testkodları önceden yazılabilinir.
- Authentication veya Anonim olarak API kurgusu önceden tamamlanabilinir.
- API Endpointler arası bağımlılıklar önceden görülebilinir ve akış diagramları sağlaması yapılabilinir.
- QA mühendisleri herhangi bir geliştiriciye ihtiyaç duymadan veya geliştirme konusunun tamamlanmasını beklemeden, kendi teknik analiz süreçlerini tamamlayabilir.
- MockServer ile bir ortam sunucusu simule edileceği için, gerçek sunucu ve kurulu sunucu hizmetlerine veya konfigurasyona ihtiyaç duymaz, sunucu ihtiyacını ise tamamiyle ortadan kaldırır.
- Bir uygulama, hayata geçmeden önce teknik arkaplan servis veya hizmetleri MockServer ile API Prototipi olarak sunulabilinir, değerlendirme ve analizi yapılabilinir.
Yazımı burada bitirirken keyifli bir okuma süreci geçirmiş olduğunuzu umuyorum. Vakit ayırdığınız için teşekkürler :)
Görsel Kaynaklar:
