API & API OTOMASYON
Herkese Merhaba :)
Bu yazıyla Api ve Api Otomasyon hakkında birçok bilginin daha erişilebilir olmasını amaçladık. Yazımız iki parçadan oluşacaktır. Birinci parçada api otomasyonun önemi sebebiyle api, api testleri ve api otomasyon hakkında detaylandırılmış bilgiler yer alacaktır.
İkinci parçada NLP ve yapay zekanın test otomasyondaki yeri hakkında bilgilendirme yapacağız. Bildiğiniz gibi doğal dil işleme; yapay zeka ve bilgisayar biliminde insan makine etkileşiminin etkili bir şekilde sürdürülebilmesi için anahtar bir alan. Yapay Zeka ve NLP’nin öneminden bahsetmişken şirketimizin bu konulardaki önemli projelerini incelemeniz için yazımızda sizi yönlendirecek linki paylaştık. Ayrıca yapay zeka tabanlı otomasyon toolları hakkında bilgilendirme yapacağız. Demo yapabilmeniz için bu toolların linklerini sizlerle paylaşmanın faydalı olacağını düşündük. Yazımızın ikinci parçasının linkini de yazının sonunda sizinle paylaşıyoruz.
Keyifli okumalar. :)
Türkü Cemre SOLDAŞ (Artificial Intelligence Quality Assurance Specialist) Kader MERCİMEKOĞLU (Artificial Intelligence Quality Assurance Specialist)
1.API Nedir ?
Bir uygulama programı arabirimi (API), yazılım uygulamaları oluşturmak için bir dizi rutin, protokol ve araçtır.Temel olarak bir API, yazılım bileşenlerinin nasıl etkileşime girmesi gerektiğini belirtir. Ayrıca API’ler, GUI bileşenlerini programlarken kullanılır . İyi bir API, tüm yapı taşlarını sağlayarak bir program geliştirmeyi kolaylaştırır . Bir programcı daha sonra blokları bir araya getirir. [1]
API, uygulamaların arka uç sistemlerle (Backend) iletişim kurmasını sağlar. Normalde bu uygulamalar, Köprü Metni Biçimlendirme Dili (HTML) web sayfaları aracılığıyla geri döner. Kullanıcılar bir web sayfasına tepki verdiğinde, yani kullanıcı arayüzünde bir istek gönderdiklerinde, bu istek istenen servis veritabanına gönderilir. Ardından hizmet, istenen verileri eXtension Markup Language (XML) formatı veya JavaScript Object Notation (JSON) formatında geri döndürür. Bunun nedeni veritabanının rastgele bir formülde değil, kendi yapılarında döndürülmesidir. XML ve JSON formatları verileri oluşturur ve kullanıcılardan veya istemcilerden sunuculara veri gönderir veya tam tersi gerçekleşir.
XML 1997 yılında geliştirilmiştir. HTML gibi tanımlayıcı etiketler kullanır ve verileri yapılandırmaya hiyerarşik yol sağlar.
JSON 2001 yılında geliştirilmiştir. JSON, JavaScript dilinden türetildiği için, insanlar tarafından kolayca okunabilir. Çok hafif olmak için daha az karakter ile yoğunlaşabilir. Bu iki format,veritabanlarını, nesnelerin durumlarını paketlemeye ve taşımaya yardımcı olur.
Bu kaynaklar sözde CRUD temel alınarak getirilir, düzenli olarak Oluştur, Oku,Güncelle, Sil anlamına gelir. Yalnızca Köprü Metni Aktarım Protokolü (HTTP) yöntemleri üzerinden kullanıcılar İlet, Kaynakları Al, Koy, Sil yapabilir. Temsili Durum Aktarımı (REST) API’si bu şekilde işler.
Başka bir API türü, Uzaktan Yordam Çağrıları (RPC) yöntemiyle hizmetleri çağıran Basit Nesne Erişim Protokolüdür (SOAP). REST API yalnızca Tekdüzen Kaynak Konum belirleyici (URL) yolu üzerinden hizmetleri çağırır. SOAP; veritabanını HTTP üzerinden aktaran REST API’nin aksine, bunu HTTP, Basit Posta Aktarım Protokolü (SMTP) ve Dosya Aktarım Protokolü (FTP) kullanarak da yapar. [2]
1.1. API Mimarileri
1.1.1. Rest
REST (Representational State Transfer) istemci-sunucu arasında hızlı ve kolay şekilde iletişim kurulmasını sağlayan bir servis yapısıdır. REST, servis yönelimli mimari üzerine oluşturulan yazılımlarda kullanılan bir veri transfer yöntemidir. HTTP üzerinde çalışır ve diğer alternatiflere göre daha basittir. Minimum içerikle veri alıp gönderdiği için de daha hızlıdır. İstemci ve sunucu arasında XML veya JSON verilerini taşıyarak uygulamaların haberleşmesini sağlar. REST standartlarına uygun yazılan web servislerine RESTful servisler denir.
1.1.2. Soap
SOAP en temel anlamda, internet üzerinden küçük miktarda bilgileri yada mesajları aktarma protokoludur. SOAP mesajları XML formatındadırlar ve genellikle HTTP protokolu(bazende TCP/IP) kullanılarak gönderilirler. SOAP ,XML tabanlı kullanıma mecbur bırakır. Bu konuda esnek değildir. [3]
1.1.3. JSON-RPC ve XML-RPC
Bir RPC, bir uzak prosedürel çağrı protokolüdür. XML-RPC, çağrılarını kodlamak için XML’i kullanırken JSON-RPC, kodlama için JSON’u kullanır. Her iki protokol de basittir. Bir çağrı birden çok parametre içerebilir ve bir sonuç bekler. REST için farklı bir mimari gerektiren birkaç temel özelliği vardır:
· Yöntemleri çağırmak için tasarlanmıştır, oysa REST protokolleri belgelerin transferini (kaynak gösterimleri) içerir. Veya başka bir deyişle, REST kaynaklarla çalışır, RPC ise eylemlerle ilgilidir.
· URI, sunucuyu tanımlar, ancak parametrelerinde hiçbir bilgi içermez, oysa REST’te URI, sorgu parametreleri gibi ayrıntıları içerir. [4]
Günümüzde birçok firma SOAP API’den REST API’ye geçiş yapmıştır. Sebep SOAP API performansının REST API performansı kadar yetenekli olmadığı gerçeğinde yatmaktadır. SOAP API’ye kıyasla REST API’nin avantajları; öğretici kod olması, JavaScript’ten daha kolay çağrılması ve daha az CPU yoğunluğudur.[2]
1.2. API Türleri
API’ler tasarlandıkları kullanım alanlarına göre sınıflandırılabilmektedir. Bunlar genel olarak veritabanı API’leri, işletim sistemi API’leri, uzak API’ler ve Web API’leridir.
1.2.1. Uzak API’ler(Remote API): Farklı makinelerde çalışan uygulamalar arasında standart iletişim sağlamak için kullanılır. Bir yazılım, fiziksel olarak farklı bir yerde bulunan kaynaklara ulaşmak için uzak APIlerden yararlanır. Birbirinden farklı yerlerde bulunan uygulamalar genellikle internet üzerinden veri alışverişini yaparlar.
1.2.2. Web API’ler(Web API): API sınıfının en yaygın olan tipidir. Web APIler, client- servermimarisi ile inşa edilmiş iki farklı web temelli sistem arasında makine kodları aracılığıyla iletişim sağlarlar. Bu tip APIler, web uygulamaları tarafından HTTP iletilen isteklere server tarafından cevap verilmesi ile haberleşirler. Web tabanlı API türleri şu şekildedir:
· Open API (Public API): Minimum kısıtlama ile geliştiriciler ve diğer kullanıcılar tarafından herkesin kullanımına açık API’lerdir. Kayıt API Anahtarı, OAuth kullanımını gerektirebilir veya tamamen açık olabilir. Verilere veya hizmetlere erişmek için harici kullanıcılara odaklanırlar.
· Internal API (Private API): Harici kullanıcılardan gizlenir ve yalnızca dahili sistemler tarafından açığa çıkarılır. Internal API’ler, şirket dışındaki tüketim için değil, daha çok daha iyi üretkenlik ve hizmetlerin yeniden kullanımı için farklı dahili geliştirme ekiplerinde kullanılmak üzere tasarlanmıştır.
· Partner API: Stratejik iş ortaklarına veya stratejik iş ortakları tarafından sunulan API’lerdir. Herkese açık değildir ve bunlara erişmek için özel yetkilere ihtiyaçlar vardır. Open API’ler gibi, Partner API’ler de buzdağının görünen kısmıdır çünkü bunlar en görünür olanlardır ve şirket sınırlarının ötesinde iletişim kurmak için kullanılırlar.
· Composite API: Composite API’ler birden çok veri veya hizmet API’sini birleştiren API’lerdir. Bir API oluşturma aracının API düzenleme yetenekleri kullanılarak oluşturulurlar. Geliştiricilerin tek bir aramada birkaç uç noktaya erişmesine izin verir.
1.2.3. Veritabanı API’leri: Veritabanı yönetim sistemi ile uygulama arasındaki iletişim sağlar. Yazılımcılar veri tabanındaki verilere ulaşmak için sorgularla çalışırlar. Bu tip apiler sayesinde verilerin listelenmesi, koşullu olarak alınabilmesi, silinmesi ve değiştirebilmesi gibi farklı görevler yerine getirilir. Günümüzde en popüler veri tabanı APIleri Oracle, MongoDB, MySQL,PostgreSQL, CouchDB ‘dir.
1.2.4. İşletim Sistemi API’leri: Her işletim sistemi, bilgisayar donanım kaynaklarının nasıl kullanılması gerektiğini belirten API’ler sağlarlar. Örneğin, Windows bunu Windows API’yle gerçekleştirirken, Linux kernel-user space API ve kernel internal API ile kullanıcıların hizmetine sunar. [5]
2.1. API Testi
API testi, uygulama programlama arayüzlerinin doğrudan test edilmesini içerir. Entegrasyonun bir parçası olarak API testi, API mantığının güvenlik, kullanılabilirlik, güvenilirlik, test edilebilirlik ve ölçeklenebilirlik beklentileriyle eşleşip eşleşmediğini belirler. API’ler bir GUI’ye sahip olmadığı için mesaj katmanında test edilir.
API testi TA’da özellikle de Çevik metodolojiyi takip eden TA’da kritik hale gelir çünkü API’ler hizmet veya uygulama mantığının birincil arabirimi olarak hizmet ederler. Şimdiye kadar API tabanlı çözümler kullanan birçok ortam ve cihaz türü vardır. Bunlar mobil uygulamalar, web uygulamaları, bulut uygulamaları, TV uygulamaları ve Nesnelerin İnterneti (IoT) cihazlarıdır. Onlar karmaşık bir API mimarisinde yazılım sistemlerine bağlanırlar, bunlarla entegre olurlar ve yazılım sistemlerini genişletirler. Şirketlerin API’lerini test etme stratejisine bağlı olarak API’lerinin çoklu görevlerini test etmek için farklı API testi türleri vardır.Bunlar; birim testi,fonksiyonel test,güvenlik testi,yük testi ve çalışma zamanı hata testidir.
2.1.1 Birim Testi ve Fonksiyonel Test
Geliştiriciler kodlama yaparken birim testler oluşturur. Birim testler genellikle açıktır ve öngörülebilir kod tabanlıdır.
Bir yazılımın ayrı birimlerinin veya bileşenlerinin test edildiği bir yazılım testi türüdür. Amaç, yazılım kodunun her biriminin beklendiği gibi çalıştığını doğrulamaktır. Birim test, geliştiriciler tarafından bir uygulamanın geliştirilmesi sırasında yapılır. Birim testleri bir kod bölümünü izole eder ve doğruluğunu onaylar. Birim, bireysel bir işlev, yöntem, prosedür, modül veya nesne olabilir.
Birim test, entegrasyon testinden önce yapılan ilk test seviyesidir. Birim testi, genellikle geliştirici tarafından gerçekleştirilen bir WhiteBox test tekniğidir. [12]
Fonksiyonel testler ile testçiler; hizmetlerin veya uygulamaların gerekli kullanılabilirliği için gerekli olan işlevsel talepleri test edebilir. Bu nedenle, işlevsel testin büyük bir avantajı fonksiyonel API test otomasyonunun, durumları tercihen beklenen koşullarda yürütmesidir.
İşlevsel testte, bir testçi çekirdek kod hakkında endişelenmez, bunun yerine, beklenen çıktı ile kullanıcı gereksinimlerine dayalı çıktıyı doğrulaması gerekir.
Fonksiyonel Test’in temel amacı, sistemin fonksiyonlarını kontrol etmektir. İşlevsel testler, ön uçtan arka uç veritabanı sistemlerine kadar tüm yazılımı, donanımını ve ağ altyapısını kontrol eder. Ayrıca, beklendiği gibi tüm bileşenlerin birlikte çalışmasını sağlayan bir entegrasyon testi biçimidir.
Birim testlerinden farklı olarak, işlevsel testler size hatalar veya konumu hakkında bilgi vermez. Sadece fonksiyonun bozulduğunu söyler.[9]
2.1.2 Güvenlik Testi
Güvenlik testleri genellikle sızma testi, bulanıklaştırma testi, erişim kontrolü, şifreleme ve kimlik doğrulamasını içerir.
API Güvenliği, API’lerin benzersiz güvenlik açıklarını ve güvenlik risklerini anlamak ve azaltmak için stratejilere ve çözümlere odaklanır.
· Bozuk Nesne Düzeyinde Yetkilendirme
API’ler, nesne tanımlayıcılarını işleyen uç noktaları açığa çıkarma eğilimindedir ve bu da geniş bir saldırı yüzeyi Düzey Erişim Kontrolü sorunu yaratır. Kullanıcıdan gelen bir girdiyi kullanarak bir veri kaynağına erişen her fonksiyonda nesne düzeyinde yetkilendirme kontrolleri düşünülmelidir.
· Bozuk Kullanıcı Kimlik Doğrulaması
Kimlik doğrulama mekanizmaları genellikle yanlış uygulanır ve saldırganların kimlik doğrulama belirteçlerini tehlikeye atmasına veya diğer kullanıcıların kimliklerini geçici veya kalıcı olarak varsaymak için uygulama kusurlarından yararlanmasına olanak tanır. Bir sistemin istemciyi ya da kullanıcıyı tanımlama yeteneğinden ödün vermek, genel olarak API güvenliğini tehlikeye atar.
· Kaynak Eksikliği ve Hız Sınırlaması
API’ler, istemci/kullanıcı tarafından talep edilebilecek kaynakların boyutu veya sayısı konusunda herhangi bir kısıtlama getirmez. Bu, yalnızca API sunucusu performansını etkileyerek Hizmet reddine yol açmakla kalmaz, aynı zamanda kaba kuvvet gibi kimlik doğrulama kusurlarına da açık kapı bırakır.
· Bozuk İşlev Düzeyi Yetkilendirmesi
Farklı hiyerarşilere, gruplara ve rollere sahip karmaşık erişim kontrol politikaları ve idari ve düzenli işlevler arasında net olmayan bir ayrım, yetkilendirme kusurlarına yol açma eğilimindedir. Saldırganlar, bu sorunlardan yararlanarak diğer kullanıcıların kaynaklarına ve/veya yönetim işlevlerine erişim elde eder.[10]
2.1.3 Yük testi
Yük testi, fonksiyonel olmayan bir test türüdür. Uygulamaların davranışlarını sadece büyük miktarda trafik altında değil, aynı zamanda uygulamanın hedefi için kullanıcı yüklerinin gerçek zamanlı sayısı ile her gün nasıl performans gösterdiklerini test etmek için de kullanılan bir test tekniğidir.
Yük testi ile testçiler esas olarak maksimum çalışma kapasitesini ve darboğazını, kullanıcı miktarını eşzamanlı ve kademeli olarak azaltarak veya artırarak anlamaya çalışırlar. Yük testleri normal veya en yoğun zamanda yapılabilir.
2.1.4 Çalışma zamanı hata testi
Çalışma zamanı hata tespiti istisna testi, yarış durumu testi, kaynak sızıntısı testi gibi bazı TA türlerinin konseptine dayanmaktadır.
Bir uygulama çalışırken, aniden programın çökmesi, bekleneni sonlandırmak çalışma zamanı hatasıdır. Olası nedenlerden biri, kullanıcıların harf veri değeri yerine bir tamsayı değer verisi girmesi gerektiğidir.Örneğin, yanlış türde veri değeri girildikten sonra yürütme, yığın izleme adı verilen kırmızı metni döndürür. Bu kullanıcıların uyumsuzluk istisnası bir girdiye sahip olduğu anlamına gelir. API koşullarıyla TA çalışma zamanı hatası bunların nasıl olduğunu izlemek için uyumsuzluk istisnalarının ele alınacağını algılar. [2]
Birden çok iş parçacığı aynı paylaşılan koda, değişkenlere, dosyalara kilitleme veya senkronizasyon olmadan aynı anda eriştiğinde çıktıda tutarsızlık oluşur. Bu da bir yarış durumuna sebep olur.Geliştiriciler, kod yazarken genellikle kodun doğrusal bir şekilde yürütüldüğünü düşünme eğilimindedir ve birden çok iş parçacığının aynı anda yürütüldüğü web sunucusu yürütmesinin paralel yapısını ihmal ederler, bu da istenmeyen sonuçlara yol açabilir.
İş parçacığı senkronizasyonu, iki veya daha fazla eş zamanlı işlemin veya iş parçacığının, kritik bölüm olarak da bilinen belirli bir program segmentini aynı anda yürütmemesini sağlayan bir mekanizmadır. Uygun senkronizasyon teknikleri uygulanmazsa bir yarış durumu oluşabilir.[11]
3. API otomasyon
Sürekli test , bir yazılım sürümü adayıyla ilişkili iş riskleri hakkında anında geri bildirim almak için yazılım teslim hattının bir parçası olarak otomatik testler yürütme sürecidir. Sürekli test için, testin kapsamı, aşağıdan yukarıya gereksinimlerin veya kullanıcı hikayelerinin doğrulanmasından, kapsamlı iş hedefleriyle ilişkili sistem gereksinimlerinin değerlendirilmesine kadar uzanır.[7]
Test otomasyonu, halihazırda yürürlükte olan resmi bir test sürecinde tekrarlayan gerekli bazı görevleri otomatikleştirebilir veya manuel olarak yapılması zor olacak ek testler gerçekleştirebilir. Test otomasyonu, sürekli teslimat ve sürekli test için kritik öneme sahiptir.[8]
API test otomasyonunun ulaşması gereken beş önerilen hedef vardır:
• API test otomasyonunun geliştirme hızını artırması ve hızlı kaliteli geribildirim teslim etmeli
• Tüm test senaryolarının her derlemenin ardından TA ortamından geçtiğine dair güven sağlamalı
• API test otomasyonunun özelliklerin değişikliklerinden bağımsız olarak güvenilirlik ve kararlılık göstermeli
• Tüm otomatik testlerin kabul kriterlerini kapsamalı
- API test otomasyon projesinin ortak bir havuzda tasarlanıp belgelendirilmesi [2]
3.1. API Otomasyonda Kullanılan Araçlar
API otomasyonu için kullanılan çok sayıda araç mevcuttur. En çok tercih edilen araçlar hakkındaki bilgiler aşağıda verilmiştir.
3.1.1. Rest-Assured
Rest-Assured, REST hizmetini test etmeyi daha basit hale getiren açık kaynak kodlu bir Java kütüphanesidir.
Artıları:
• Birçok hazır işleve sahiptir bu da kullanıcıların bir şeyleri sıfırdan kodlaması gerekmediği anlamına gelir.
• Serenity otomasyon çerçevesiyle sorunsuz bir şekilde bütünleşir, böylece kullanıcılar UI ve REST testlerini harika raporlar oluşturan tek bir frameworkte birleştirebilir.
• Given/When/Then söz dizimini destekler.
• Kullanımı kolaydır bu sebeble kullanıcılar HTTP uzmanı olmadan test yazabilir.
- Açık kaynak kodludur.
Eksileri:
• Yalnızca Java dilini destekler.
- SOAP API’lerini desteklemez.
3.1.2. SoapUI
SoapUI geliştiricilerin REST, SOAP, GraphQL ve web hizmetlerini test etmesine olanak tanıyan bir API test aracıdır. SoapUI Pro, geliştirme ve test ekiplerine web hizmetlerinde karmaşık testler oluşturmak, çalıştırmak ve analiz etmek için güçlü bir çözüm sunar. SoapUI, test raporları, SOAP API testi ve diğerleri gibi birçok özelliğe sahiptir.
Artıları:
- Groovy kullanarak özel kodlar oluşturabilir.
- Çalışmanızı daha sonra tekrar inceleyebilmeniz için kaydeder.
Eksileri:
- Web kullanıcı arayüzü testi ve mobil uygulama testinde yardımcı olmaz.
• Bu aracın dökümantasyonu yoktur.
- Projeleri kaydetmek yeni başlayanlar için biraz kafa karıştırıcıdır.
3.1.3. Katalon Studio
Katalon Studio API, web, masaüstü uygulaması ve mobil uygulamaları test etmek için ücretsiz bir API test aracıdır. Tüm frameworkleri ve eklentileri tek bir pakette toplayarak
kolay geliştirme sağlar. Manuel ve komut dosyası modları ile hem yeni başlayanlar hem de uzmanlar için uygundur.
Artıları:
• Katalon, SOAP ve RESTfull isteklerini destekler.
• Otomatik ve keşif amaçlı testler için kullanılabilir.
- CI/CD entegrasyonunu destekler.
Eksileri:
• Kodun hatalarını ayıklamak zordur.
- Dağıtılmış test (distributed testing) desteği yoktur.
3.1.4. Karate DSL
Cucumber kitaplığını temel alan Karate DSL API tabanlı BDD testlerinin basit bir şekilde oluşturulmasına yardımcı olur. API test otomasyonunu, ve performans testini tek bir frameworkte birleştirir. Test uzmanlarının, etki alanına özgü bir dil kullanarak web hizmetleri için anlamlı testler oluşturmasına olanak tanır.
Artıları:
• Karate DSL parallel test koşumunu destekler.
• Konfigürasyon geçişine izin verir.
• Karate DSL GraphQL’i test etmek için iyi bir seçenektir.
- JSON’un yanı sıra XML’i de destekler.
Eksileri:
• Araç, kutunun dışında yetkilendirme şemalarına sahip değildir.
- Kod desteği çok zaman alıcı ve maliyetlidir.
3.1.5. Postman
Postman bir masaüstü uygulamasının yanı sıra bir web sürümü de sunar ve API hizmetlerini test etmek için kullanılabilir. Kullanıcının koleksiyonlarını ekip üyeleri ile kolayca paylaşmasını sağlar.
Artıları:
• Kullanımı diğerlerine göre daha kolaydır.
• Metot çağrılarında parametrelerin ayarlanması kolaydır.
• Oluşturulan istekler koleksiyonlar içinde saklanabilir ve paylaşılabilir.
- API geliştirme imkanı da sunar.
Eksileri:
• İşletme için fiyatlandırma yüksektir.
• Enterprise sürümünün kurulumu ve kullanımı kolaydır, ancak istek sayısı sınırlıdır.
- Aynı anda birden fazla API test etmek mümkün değildir.
3.1.6. Jmeter
Apache Jmeter API’lerin yük ve performans testleri için kullanılan bir yazılımdır. İşlevsel API testi için yaygın olarak kullanılır.
Artıları:
• JMeter, statik ve dinamik kaynak performans testlerinde kullanılabilir.
• Geliştiricilerin test sonuçlarını tekrar oynatmasına olanak tanır.
- JMeter’in arayüzü kullanıcı dostudur ve bir komut satırı arayüzünde kullanılabilir.
Eksileri:
• Yetenekli test uzmanları gerektirir.
• Javascript’i desteklemez ve buna bağlı olarak AJAX isteklerini otomatik olarak desteklemez.
- GUI modunda bellek tüketimi yüksektir, bu da birçok kullanıcı için hata vermesine neden olur.
3.1.7. Paw
Paw, MacOS için özel olarak tasarlanmış bir API test aracıdır. İster bir API üreticisi olun, ister bir kullanıcısı olun, Paw HTTP istekleri oluşturmanıza, bir sunucunun yanıtını incelemenize ve hatta istemci kodu oluşturmanıza yardımcı olur.
Artıları:
• Kullanımı kolay bir arayüze sahiptir.
• Diğer API test araçlarına kıyasla performans açısından daha kararlıdır.
- Ayrıca çok boyutlu ortam ayarlarına sahiptir.
Eksileri:
• Şu anda Paw, yalnızca MacOS kullanıcıları tarafından kullanılabilir.
- Yüksek fiyatlı bir üründür.
3.1.8. Apigee
Apigee, API testleri için kullanılan bir araçtır. Google Cloud’un bir parçası olan Apigee, API yönetimi özellikleri sunar. Apigee, kullanıcıların API performansını ölçmesine ve test
etmesine ve Swagger gibi diğer düzenleyicileri kullanarak API’leri desteklemesine ve oluşturmasına olanak tanır. Apigee API’ler ve uygulamalar için özel olarak tasarlanmıştır.
Artıları:
• API trafiğini, hata oranlarını ve yanıt sürelerini izleyerek performans sorunlarını tanımlar.
• Node.js’yi destekler
• Kontrol etmek kolaydır.
- Çok adımlıdır ve JavaScript tarafından desteklenmektedir.
Eksileri:
• Apigee nesnelerinde JSON.stringify kullanılamaz.
• Proxy’de aynı anda yalnızca bir kullanıcı etkin olabilir.
- UI, kullanıcıların hedef sunucular eklemesine izin verir, ancak kullanıcıların SSL’yi açmak için API’yi kullanması gerekir. [6]
3.1.9. Cognitus Runner
Cognitus Runner, API testleri için kullanılan bir araçtır. Cognitus servislerini kullanarak belli bir .xlsx veri setini test etmek istediğiniz zaman kullanmak için ETİYA tarafından geliştirilmiş bir projedir. Gerekli API bilgileri yazıldıktan sonra Basic API request atılabilir yada yüklenen bir data dosyası da belirli kolonlar seçilip testlerde kullanılabilir. Ayrıca koşum sonrası oluşturulan test raporu da .xlsx formatında export edilebilir.
Artıları:
· Gerekli API bilgileri yazıldıktan sonra Basic API request atılabilir.
· Mevcutta bulunan bir dataset kullanılarak içerisindeki veriler test edilebilir. İstekleri tek tek atmak yerine toplu bir koşum ve test takibi imkanı sunar.
· Bir kurulum yapma gereksinimi yoktur.
Eksileri:
· Vpn erişimi gerekli olan ortamlarda test koşumu yapılamaz.
· Dosya yükleme API’leri kullanılamaz.
İkinci parça: İkinci parça: https://medium.com/@cemresoldas/test-otomasyonda-yapay-zeka-nlp-87e40a46607f
Referanslar
1. Ozan Eser,2019,Postman ile Backend API Otomasyonuna İlk Adım, https://medium.com/@ozaneseriu/postman-ile-backend-API-otomasyonuna-i%CC%87lk- ad%C4%B1m-13573eacc0c2
2. Minh Ly, 2018, Creating API Test Automation of a Service for Company X
3. Canan Gök,2018, REST / SOAP API Nedir? Farkları Nelerdir? ,
https://medium.com/android-t%C3%BCrkiye/rest-API-kavramlar%C4%B1-soap-ile- farklar%C4%B1–4c6f19ddbc6c
4. https://stoplight.io/API-types/
5. Ali Söylemez,2020, API Nedir?, https://bylge.com/p/API-nedir-nasil-kullanilir-ve-neden- onemlidir-5fd78b8bcc5ad600077c310c
6. Vyom Srivastava,2020, Top 25+ API Testing Tools, https://nordicAPIs.com/top-25-API-testing- tools/
7. Wayne Ariola ve Cynthia Dunlop,2015,DevOps: Hataları Müşterilere Daha Hızlı İtiyor musunuz?
8. Kolava, Adam; Huizinga, Dorota (2007). Otomatik Hata Önleme: Yazılım Yönetiminde En İyi Uygulamalar. Wiley-IEEE Bilgisayar Topluluğu Basını. s. 74. ISBN’si 978–0–470–04212–0.
9. Hiral Jadav, 2020, Unit Testing vs Functional Testing: A Guide On Why, What & How https://www.zealousweb.com/unit-testing-vs-functional-testing-a-guide-on-why-what-how/
10. https://owasp.org/www-project-API-security/
11. Sarvesh Pandey, 2016 Testing Race Conditions in Web Applications
