CI/CD İçin 10 API Test Otomasyon Aracı

API'niz kendi makinenizde çalışıyor. Sonra bir ekip arkadaşı bir değişiklik birleştiriyor, bir yanıt alanı yeniden adlandırılıyor ve üç aşağı akış hizmeti sabah 2'de üretimde çöküyor. Kimse bunu fark etmedi çünkü testler yalnızca birisi bir GUI'de "Gönder" düğmesine basmayı hatırladığında çalışıyordu. Bir istek yazmak ile onu her commit'te gerçekten çalıştırmak arasındaki bu boşluğu API test otomasyon araçları kapatmak için vardır.

Zor kısım bir test yazmak değildir. Asıl zor olan, her pull request'te çalışacak, bir sözleşme bozulduğunda derlemeyi başarısız kılacak ve bir insanın on saniyede okuyabileceği bir rapor sunacak şekilde bütün bir paketi işlem hattınıza bağlamaktır. Seçtiğiniz araç, bu bağlantının ne kadarını elle yazacağınızı ve ne kadarını sizin için yapacağını belirler. Bazıları her şeyi kodla yazmanızı ister. Diğerleri size görsel bir düzenleyici sunar ancak CI/CD sınırında sizi yalnız bırakır.

Bir API test otomasyon aracını CI/CD için iyi yapan nedir?

Listeye geçmeden önce, işte çıta. Bir araç, bu şeyleri iyi yaptığında işlem hattınızda bir yer edinir:

• Başsız yürütme. Komut satırından veya Docker imajından GUI olmadan, manuel tıklama olmadan ve işlem hattınızın okuyabileceği gerçek bir çıkış kodu ile çalışır.
• Makine tarafından okunabilir raporlar. JUnit XML, böylece CI panosu test başına geçme/kalma durumunu gösterir, ayrıca insanlar ve panolar için HTML veya JSON.
• Ortam yönetimi. Testleri düzenlemeden temel URL'leri, token'ları ve değişkenleri geliştirme, hazırlık ve üretim ortamları arasında değiştirebilirsiniz.
• Veri odaklı çalıştırmalar. Bir CSV veya JSON dosyası besleyin ve aynı senaryoyu birçok girdi üzerinde çalıştırın.
• Gerçek kırılmayı yakalayan iddialar. Sadece "200 döndürdü mü?" değil, durum kodları, yanıt gövdeleri, JSON şeması ve yanıt süresi.
• Düşük bakım. API değiştiğinde, testleri güncellemek bir kod duvarını yeniden yazmak anlamına gelmemelidir.

Bu kontrol listesini elinizin altında bulundurun. Aşağıdaki her araç buna göre puanlanmıştır.

1. Apidog

Apidog hepsi bir arada bir API platformudur: tasarım, hata ayıklama, taklit, dokümantasyon ve test tek bir çalışma alanında. Test otomasyonu için önemli olan kısım, görsel taraf ile komut satırı tarafının nasıl bağlandığıdır. Bir test senaryosunu görsel olarak oluşturursunuz; istekleri zincirleyerek, adımlar arasında veri geçirerek ve fazladan kod yazmadan iddialar ekleyerek. Ardından bir npm paketi olan Apidog CLI, bu senaryoyu işlem hattınızda başsız olarak çalıştırır.

Bu süreklilik, satış noktasıdır. Çoğu araçta bir yerde tasarım yapar ve CI/CD için testi kodda yeniden ifade edersiniz. Apidog ile elle hata ayıklamış olduğunuz senaryo, işlem hattınızın çalıştırdığı esardır. Tercüme adımı yok, "yerel olarak test ettiğim" ile "commit'te çalışan" arasında sapma yok.

Bir işlem hattına dahil etmek birkaç dakika sürer. CLI'yi kurun ve bir senaryoyu kimliğine göre çalıştırın:

npm install -g apidog-cli
apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989 -r html,cli

Bu kimlikleri ezberlemek zorunda değilsiniz. Uygulamada bir test senaryosunu açın, CI/CD sekmesine geçin, komut satırı seçeneğini seçin, bir erişim belirteci oluşturun ve Apidog, senaryo kimliği ve ortam kimliği zaten doldurulmuş olarak sizin için tam komutu oluşturur. Bunu işlem hattı adımınıza kopyalayın ve işiniz bitti.

Bayraklar doğrudan yukarıdaki CI/CD kontrol listesine karşılık gelir. Tek bir senaryo için -t ile kapsamı, bir klasör için -f ile veya belirli bir test paketi için --test-suite ile seçin. Hedef ortamı -e ile seçin. Bir veri dosyasından -d ile tekrarları yönlendirin. Raporlayıcıları -r ile seçin; burada junit CI panonuzu besler ve html size göz atılabilir bir rapor verir. Hata davranışını --on-error ile kontrol edin; burada end ilk bozuk adımda hızlıca başarısız olur. Gerçekçi bir işlem hattı adımı şöyle görünür:

apidog run --access-token $APIDOG_ACCESS_TOKEN \
  -t 605067 -e 1629989 \
  -r html,junit --out-dir ./test-reports \
  --on-error end

Bir GitHub Actions iş akışında, bu tek bir iş adımı haline gelir. CLI'yi önbelleğe alma ve raporları yapıt olarak yükleme dahil olmak üzere tam kurulum, Apidog CLI ve GitHub Actions kılavuzunda ele alınmıştır.

Apidog'un uygun olduğu yerler: tasarımdan otomatik testlere kadar tek bir doğruluk kaynağı isteyen ekipler ve testleri betikler yerine görsel bir düzenleyicide sürdürmeyi tercih eden kişiler. QA mühendislerinizin hepsi JavaScript'te akıcı değilse, bu eşiği büyük ölçüde düşürür. API testi için Apidog ve Postman karşılaştırmasına bakın.

Daha az uygun olduğu yerler: ekibiniz her testi depoda kod olarak tutmaya, diğer kaynak dosyaları gibi pull request'lerde incelemeye kararlıysa, kod-öncelikli bir framework iş akışınıza daha iyi uyabilir. Apidog senaryoları platformda saklar, ancak Git dallarıyla senkronize olur.

2. Newman ile Postman

Postman, çoğu geliştiricinin ilk başvurduğu araçtır ve iyi bir nedenden dolayı. İstek oluşturucusu mükemmel, koleksiyon formatı bir endüstri standardı ve dokümantasyon ile taklit özellikleri olgunlaşmıştır. Otomasyon için Postman, komut satırı koleksiyon çalıştırıcısı Newman ile eşleşir.

Newman, bir Postman koleksiyonunu başsız olarak çalıştırır ve bir raporlayıcı paketi aracılığıyla JUnit XML dahil olmak üzere raporlar yayınlar. İş akışı şöyledir: Postman GUI'sinde oluşturun ve hata ayıklayın, koleksiyonu dışa aktarın veya senkronize edin, ardından CI'da Newman ile çalıştırın.

npm install -g newman
newman run my-collection.json -e staging.postman_environment.json \
  -r cli,junit --reporter-junit-export results.xml

Postman'ın iyi yaptığı şeyler: büyük ekosistem, bol miktarda öğretici ve neredeyse her API ekibinin halihazırda koleksiyonları vardır. Newman kararlı ve iyi anlaşılmıştır.

Garipleştiği yerler: iddialar her isteğin "Testler" sekmesindeki JavaScript içinde bulunur, bu nedenle önemsiz olmayan doğrulama, betik yazmayı ve bakımını gerektirir. GUI koleksiyonu ile dışa aktarılan JSON'ı bir ekip içinde senkronize tutmak disiplin gerektirir. Birçok ekip, koleksiyonlar büyüdükçe bir duvara çarpar; eğer durum buysa, Postman alternatifleri derlemesi ve Postman olmadan API testi seçenekleri size yol gösterecektir.

3. REST Assured

REST Assured, REST hizmetlerini test etmek için bir Java DSL'dir. Eğer backend'iniz zaten Java ise ve ekibiniz JUnit ve Maven veya Gradle kullanıyorsa, bu doğal bir seçimdir. Testler akıcı bir şekilde okunur:

given()
    .header("Authorization", "Bearer " + token)
.when()
    .get("/v1/orders/42")
.then()
    .statusCode(200)
    .body("status", equalTo("shipped"));

İyi yaptığı şeyler: doğrudan JVM test yaşam döngüsüne bağlanır, böylece zaten kullandığınız herhangi bir derleme aracıyla CI'da çalışır ve raporlama Surefire ve mevcut panolarınız aracılığıyla akar. Akıcı sözdizimi okunabilir ve etkileyicidir.

Garipleştiği yerler: yalnızca Java tabanlıdır ve gerçek kod yazıp sürdürmeniz gerekir. Görsel bir düzenleyici yoktur, bu nedenle Java yazmayan QA çalışanları dışlanır. Kurulumu, sadece bir dosya çalıştıran bir CLI'dan daha ağırdır.

4. Playwright

Playwright en çok tarayıcı uçtan uca testiyle bilinir, ancak APIRequestContext'u onu güvenilir bir API test çalıştırıcısı yapar, özellikle de bir paketin hem UI hem de API kontrollerini karıştırması gerektiğinde. Çok dilli (TypeScript, Python, Java, .NET) ve araçları cilalanmıştır.

import { test, expect } from '@playwright/test';

test('order is created', async ({ request }) => {
  const res = await request.post('/v1/orders', {
    data: { sku: 'A-100', qty: 2 },
  });
  expect(res.status()).toBe(201);
});

İyi yaptığı şeyler: API ve UI testleri için tek bir framework, paralel yürütme ve birinci taraf GitHub Actions desteğiyle güçlü bir CI hikayesi. Trace görüntüleyici hata ayıklama için gerçekten kullanışlıdır.

Garipleştiği yerler: kod-öncelikli olup tarayıcı testi için inşa edilmiştir, bu nedenle saf API paketleri ihtiyaç duymayabilecekleri framework ağırlığını taşır. Diğer kod çalıştırıcılarıyla karşılaştırma için, CI/CD'de API testleri nasıl otomatikleştirilir konusuna bakın.

5. Karate

Karate, kendi Gherkin tarzı sözdizimine sahip özel bir API test çerçevesidir, bu nedenle testler neredeyse düz İngilizce gibi okunur ve bunları yazmak için programlama geçmişine sahip olmanıza gerek yoktur.

Scenario: fetch a user
  Given url 'https://api.example.com'
  And path 'users', 7
  When method get
  Then status 200
  And match response.name == 'Ada Lovelace'

İyi yaptığı şeyler: dahili JSON ve XML iddiaları, veri odaklı testler, paralel yürütme ve dahili raporlama. JVM üzerinde çalışır ancak Java yazmazsınız. Sözleşme testi ve taklit etme tek bir araçta desteklenir.

Garipleştiği yerler: Gherkin-JavaScript karışımı sözdizimi öğrenilmesi gereken başlı başına bir şeydir ve karmaşık akışlarda hata ayıklama zor olabilir. Yine de Maven veya Gradle aracılığıyla çalışır, bu nedenle JVM araçları bir ön koşuldur.

6. SoapUI / ReadyAPI

SoapUI, test senaryoları oluşturmak için bir GUI ile SOAP ve REST testi için uzun süredir kullanılan bir araçtır. ReadyAPI, daha büyük ekipler için ekstra özelliklere sahip ücretli ticari sürümüdür. Açık kaynak SoapUI, testrunner komut satırı aracı aracılığıyla CI'da çalışır.

İyi yaptığı şeyler: diğer araçların daha zayıf olduğu kurumsal ve eski ortamlarda hala önemli olan SOAP ve WSDL için güçlü destek. Ücretli katmanda veri odaklı test ve güvenlik taraması olgundur.

Garipleştiği yerler: arayüzü eski hissettiriyor ve ücretsiz sürümü ReadyAPI'den gözle görülür şekilde daha sınırlı. Java tabanlı çalıştırıcı ağır olabilir. Bunu aşmayı düşünen ekipler genellikle ReadyAPI ve Jenkins alternatifini değerlendirir.

7. k6

k6, JavaScript ile betiklenmiş ve Go tabanlı bir motor tarafından çalıştırılan yük ve performans testi için tasarlanmıştır. İlk olarak işlevsel bir test aracı değildir, ancak bir performans çalışmasına işlevsel kontroller ekleyebilirsiniz ve eklemeniz gerekir, birçok ekip bunu işlem hatlarında her ikisi için de kullanır.

import http from 'k6/http';
import { check } from 'k6';

export default function () {
  const res = http.get('https://api.example.com/health');
  check(res, { 'status is 200': (r) => r.status === 200 });
}

İyi yaptığı şeyler: mükemmel performans ve yük testi, temiz bir betikleme modeli ve CI için güçlü bir CLI. Eşikler, bir isteğin hata vermesi yerine gecikme gerilediğinde bir derlemeyi başarısız kılmanıza olanak tanır.

Garipleştiği yerler: işlevsel iddialar, özel test araçlarına kıyasla temel düzeydedir, bu nedenle birinin yerine bir tamamlayıcıdır. Odak noktanız yük ise, diğer API yük testi araçlarıyla karşılaştırın.

8. Schemathesis

Schemathesis farklı bir açıdan yaklaşır: onu bir OpenAPI veya GraphQL şemasına işaret ettiğinizde, bir insanın yazmayı düşünmeyeceği uç durumlar da dahil olmak üzere test senaryolarını otomatik olarak oluşturur. Komut satırından çalışan bir Python aracıdır.

pip install schemathesis
schemathesis run https://api.example.com/openapi.json --checks all

İyi yaptığı şeyler: özellik tabanlı test, uç noktalarınıza beklenmedik girdiler atarak gerçek hataları bulur ve şema her şeyi yönlendirdiği için neredeyse hiç test yazma gerektirmez. CI'da temiz bir şekilde çalışır ve sözleşme ihlallerini yakalamada gerçekten güçlüdür.

Garipleştiği yerler: yalnızca şemanın tanımladığı şeyleri test eder, bu nedenle test kaliteniz spesifikasyonunuzun kalitesine bağlıdır. Elle yazılmış iş akışı senaryoları için tasarlanmamıştır ve çıktının yorumlanması biraz öğrenme gerektirir.

9. Hoppscotch

Hoppscotch, hafif, açık kaynaklı bir API istemcisidir ve genellikle daha ağır masaüstü araçlara hızlı, tarayıcı tabanlı bir alternatif olarak tanımlanır. CI'da koleksiyonları çalıştırabilen bir CLI'si (hopp) vardır.

npm install -g @hoppscotch/cli
hopp test my-collection.json

İyi yaptığı şeyler: ücretsiz, açık kaynaklı, hızlı yüklenir ve kendi kendine barındırılabilir olması, her şeyi şirket içinde tutmak isteyen ekiplere hitap eder. CLI, koleksiyon çalıştırmalarını bir işlem hattına dahil eder.

Garipleştiği yerler: köklü araçlardan daha genç ve daha az özellik derinliğine sahip, CLI ve otomasyon hikayesi hala olgunlaşıyor ve karmaşık veri odaklı senaryoları özel olarak inşa edilmiş test platformlarındakinden daha zor ifade ediliyor.

10. Bruno

Bruno, açık kaynaklı bir API istemcisidir ve belirgin bir tasarım seçeneği sunar: koleksiyonlar, doğrudan Git deponuzda düz metin dosyaları (Bru adı verilen bir işaretlemede) olarak saklanır, böylece testler diğer kaynaklar gibi sürümlenir. CLI'si CI'da koleksiyonları başsız olarak çalıştırır.

npm install -g @usebruno/cli
bru run --env staging

İyi yaptığı şeyler: Git-yerel, depodaki dosyalar modeli, her testin pull request'lerde bulut senkronizasyonu olmadan incelenmesini isteyen ekipler için temiz bir uyum sağlar. Çevrimdışı öncelikli ve gizlilik dostudur ve CLI, işlem hatlarına basitçe entegre olur.

Garipleştiği yerler: iddialar hala betiklemeye dayanır, Bru formatı öğrenilmesi gereken bir başka şeydir ve çevreleyen ekosistem (taklit, dokümanlar, büyük ekip işbirliği) hepsi bir arada platformlardan daha hafiftir. Evrensel bir seçimden ziyade belirli bir felsefeye güçlü bir uyum sağlar.

Hızlı karşılaştırma

Nasıl seçilir?

Tek bir kazanan yok. Doğru araç, yığınınız ve testleri kimin yazdığına bağlıdır.

Ekibiniz dili akıcı bir şekilde kullanıyorsa, her testi depoda tutmak istiyorsa ve pull request'lerde testleri inceliyorsa kod-öncelikli bir framework (REST Assured, Playwright, Karate) seçin. Maliyeti bakımdır: API değiştiğinde, birisi kodu günceller.

Şema veya yük uzmanı (Schemathesis, k6) bir araç seçin, ancak tüm strateji olarak değil, bir tamamlayıcı olarak. Kendi işlerinde mükemmeldirler ve bunun dışında zayıftırlar.

QA ve geliştiricilerin testleri aynı yerde oluşturmasını istediğinizde ve elle hata ayıkladığınız testin işlem hattınızın çalıştırdığı şeyin aynısı olmasını istediğinizde Apidog gibi görsel-artı-CLI bir platform seçin. Bu, diğer çoğu aracın açık bıraktığı tasarım-CI boşluğunu kapatır ve aynı çalışma alanında tasarım, taklit ve dokümanları kapsar. Otomasyon tarafına daha derinlemesine bakmak için Apidog test paketleri kılavuzunu okuyun. Bağlamaya hazır olduğunuzda, Apidog'u indirin ve GitHub Actions rehberini veya Jenkins entegrasyon kılavuzunu takip edin.

Ne seçerseniz seçin, amaç aynıdır: her commit'te çalışan testler, bir sözleşme bozulduğunda derlemeyi başarısız kılan testler ve bir insana saniyeler içinde neyin yanlış gittiğini söyleyen testler.

Sıkça Sorulan Sorular

API testi ile API test otomasyonu arasındaki fark nedir?

API testi, bir uç noktanın doğru davrandığını kontrol etmektir: doğru durum kodu, doğru gövde, doğru hata işleme. API test otomasyonu, bu kontrollerin bir zaman çizelgesine göre veya her commit'te, kimsenin "Gönder"e tıklamasına gerek kalmadan kendi kendine çalışmasını sağlamaktır. Otomasyon, tek seferlik bir kontrolü bir güvenlik ağına dönüştüren şeydir. İyi bir API testi otomasyonu kurulumu, her pull request'te aynı testleri çalıştırır.

API testlerini otomatikleştirmek için kod yazmam gerekiyor mu?

Hayır, her zaman değil. REST Assured ve Playwright gibi kod-öncelikli framework'ler bunu gerektirir, ancak Apidog gibi görsel-artı-CLI araçları, test senaryolarını bir düzenleyicide oluşturmanıza ve yine de bunları CI'da başsız çalıştırmanıza olanak tanır. Ortak iddialar için sıfır betik yazarsınız ve sadece bir senaryo özel mantık gerektirdiğinde koda başvurursunuz.

Bu araçlar GitHub Actions veya Jenkins'te çalışabilir mi?

Evet. Bu listedeki her araç, bir komut satırı çalıştırıcısı veya bir derleme aracı eklentisi içerir ki bu, bir CI sisteminin ihtiyaç duyduğu tek şeydir. Çalıştırıcıyı kuran ve testlerinizi yürüten bir adım eklersiniz, ardından JUnit raporunu yayınlarsınız, böylece pano her test için geçme ve kalma durumunu gösterir. Tam bir örnek için GitHub Actions kılavuzuna bakın.

Özel QA mühendisleri olmayan bir ekip için hangi araç en iyisidir?

Görsel bir araç, eşiği en çok düşürür, çünkü geliştiriciler ayrı bir test framework'ü öğrenmek zorunda kalmadan testler oluşturabilir ve sürdürebilir. Apidog ve GUI tabanlı istemciler buraya uyar. Kod-öncelikli framework'ler, ekibinden birinin test kodu yazma ve inceleme konusunda rahat olduğunu varsayar.

API test otomasyonu için ücretsiz seçenekler var mı?

Evet. Newman, REST Assured, Playwright, Karate, k6, Schemathesis, Hoppscotch ve Bruno açık kaynaklıdır ve Apidog'un ücretsiz bir katmanı vardır. En iyi ücretsiz API testi araçları derlemesi, her bir ücretsiz katmanın aslında neler içerdiğini daha derinlemesine ele alır.

API her değiştiğinde otomatik testlerin bozulmasını nasıl engellerim?

Tekrarlardan kaçının ve iddiaları odaklı tutun. Tüketicileriniz için önemli olan alanları test edin, her yanıtın her baytını değil. Şema odaklı araçlar, spesifikasyon değiştiğinde otomatik olarak güncellenir ve görsel araçlar, kodu yeniden yazmaktan daha hızlı küçük düzenlemeler yapmayı sağlar. Bakımı düşük tutmak için API testi en iyi uygulamalarını takip edin.