2026'nın En İyi CLI Tabanlı API Test Araçları

API testi GUI'den (Grafik Kullanıcı Arayüzü) bağımsızlaştı. Testler artık ekranı olmayan CI kapsayıcılarında, yalnızca SSH üzerinden erişebildiğiniz test sunucularında (staging kutularında) ve sadece kabuk komutlarıyla çalışan yapay zeka ajanları altında çalışıyor. Bu üç ortamda da, bir insan gözetimi olmaksızın testin geçip geçmediği terminalde belli olur.

Bu derleme, gerçek test işlerini kabuk isteminden (shell prompt) yürüten araçları sıralıyor. Burada "terminal tabanlı" terimi, tüm döngünün bir kabukta çalıştığı anlamına gelir: bir paket yöneticisinden kurulum, tek bir komut çalıştırma, bir çıkış kodunu okuma. Sıralama; yerleşik onaylamaları (assertions), çok adımlı akışları, CI'ya hazır raporları ve bakım durumunu değerlendirir. curl gibi manuel istemciler, her terminal iş akışı test çalıştırmaları arasında onlara yaslandığı için, listenin sonuna yakın bir yer edinmeye devam ediyor. GUI ve barındırılan araçları içeren daha geniş bir anket için, en iyi ücretsiz API test araçları derlemesine bakın.

Bir test aracını bir istemciden ayıran nedir?

Bir terminal istemcisi bir istek gönderir ve size yanıtı gösterir. Bir terminal test aracı ise yanıtı değerlendirir ve boru hattınızın kapı görevi görebileceği bir çıkış kodu olarak kararını raporlar. İkinci grup bu listenin kalbini oluşturur ve dört özellik onu tanımlar:

• Yerleşik onaylamalar. Durum, başlıklar ve gövde kontrolleri, bir yığın jq yapıştırıcısında değil, aracın içinde olmalıdır.
• Anlamlı çıkış kodları. Geçerse sıfır, başarısız olursa sıfır olmayan bir kod, böylece CI sizin için derlemeyi başarısız kılar.
• Tekrarlanabilirlik. Testler, kabuk geçmişinizde değil, sürümleyebileceğiniz ve tekrar çalıştırabileceğiniz dosyalarda veya projelerde yaşar.
• Raporlar. Bir insanın terminalde okuyabileceği ve bir kontrol panelinin JSON, JUnit veya HTML olarak ayrıştırabileceği çıktılar.

Kriterler belirlendiğine göre, 2026'da zaman ayırmaya değer on aracı burada bulabilirsiniz.

1. Apidog CLI: Görsel olarak tasarlayın, her yerde başsız çalıştırın

Apidog, tasarım, test, modelleme ve dokümantasyonu kapsayan hepsi bir arada bir API platformudur. Apidog CLI (npm üzerinde apidog-cli), platformun terminal koludur. Zincirlenmiş istekler, çıkarılan değişkenler ve onaylamalar ile test senaryolarını görsel editörde oluşturursunuz, ardından apidog run bunları herhangi bir kabuktan yürütür ve boru hattınıza temiz bir çıkış kodu verir.

npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>

# Senaryonuzun CI/CD sekmesinden tam komutu kopyalayın
apidog run -t <scenario_id> -e <env_id> -r cli

Kimlikleri tahmin etmenize gerek yok. Apidog'da senaryoyu açın, CI/CD sekmesine gidin ve oluşturulan komutu kopyalayın. Raporcular cli, html, json ve junit'i kapsar ve apidog-reports/ dizinine yazılır, böylece aynı çalıştırma bir terminali, bir kontrol panelini ve bir eser deposunu besler. Veri odaklı çalıştırmalar, CSV veya JSON dosyalarından iterasyonları çeker. Çıktı, yapay zeka kodlama aracısının bir paketi çalıştırmasına ve ekran kazıma yapmadan sonraki hareketine karar vermesine olanak tanıyan agentHints.nextSteps ile yapılandırılmış JSON'dur. Node.js 16 veya üzeri gerektirir.

En iyi şunlar için: karmaşık, çok adımlı senaryoları bir editörde oluşturan ve bunları bir dizüstü bilgisayarda, CI'da ve ajanlar tarafından aynı şekilde çalıştıran ekipler. Dürüst sınırlama: açık kaynak değildir ve ad-hoc bir gönderici değildir. Senaryolar bir Apidog projesinde yaşar, bu nedenle bu, çıplak bir HTTP aracı yerine entegre platform seçeneğidir. Apidog CLI kapsamlı rehberi, tüm komut setini kapsar.

2. Hurl: tek bir Rust ikili dosyasında düz metin testleri

Hurl, düz metin formatında yazılmış HTTP isteklerini çalıştırır ve yanıtlar üzerinde onaylamalar yapar. libcurl üzerinde Rust ile inşa edilmiştir ve tek bir ikili dosya olarak gönderilir, bu nedenle kurulacak bir çalışma zamanı yoktur. Testler neredeyse ham HTTP gibi okunur, bu da çekme isteğinde (pull request) kolayca incelenmelerini sağlar.

brew install hurl   # veya: cargo install --locked hurl

cat > login.hurl <<'EOF'
POST https://api.example.com/login
{ "user": "acme", "pass": "s3cret" }

HTTP 200
[Asserts]
jsonpath "$.token" exists
EOF

hurl --test login.hurl   # bir onaylama başarısız olursa sıfır olmayan çıkış

En iyi şunlar için: sürüm kontrolünde okunabilir metin olarak tuttuğunuz sözleşme tarzı kontroller ve duman testleri. --test bayrağı onu doğal bir CI kapısı yapar. Dürüst sınırlama: HTTP odaklıdır, bu nedenle gRPC'yi sürmez veya yük oluşturmaz ve karmaşık mantık bir betik dilinden ziyade daha fazla .hurl dosyası anlamına gelir.

3. Newman: Postman koleksiyonlarını başsız çalıştırın

Newman, Postman koleksiyonları için açık kaynak komut satırı çalıştırıcısıdır (Apache-2.0). Ekibiniz zaten istekleri ve testleri Postman'da yazıyorsa, Newman bu tam koleksiyonu terminalden GUI olmadan çalıştırır. Koleksiyonu ve ortamı JSON olarak dışa aktarır ve Newman'ı dosyalara yönlendirirsiniz.

npm install -g newman

newman run collection.json -e staging.json

En iyi şunlar için: Postman'a yatırım yapmış ve mevcut koleksiyonlarını ekstra lisanslara ihtiyaç duymadan bir boru hattında çalıştırmak isteyen ekipler. Bir test başarısız olduğunda sıfır olmayan bir kodla çıkar, böylece CI sorunsuz bir şekilde kapı görevi görür. Dürüst sınırlama: yalnızca Postman formatındaki koleksiyonları çalıştırır ve yazım hala Postman GUI'sinde gerçekleşir. Testleri yürütür; yazmanıza yardımcı olmaz.

4. Postman CLI: Newman'a birinci taraf alternatif

Postman CLI, Postman'ın kendi kapalı kaynak çalıştırıcısıdır. Newman'dan farklı olarak, Postman hesabınıza giriş yapar ve bir koleksiyonu kimliğiyle, doğrudan çalışma alanından çalıştırabilir, sonuçlar Postman'ın bulutuna raporlanır.

postman login --with-api-key <YOUR_API_KEY>

postman collection run <collection_id> -e <environment_id>

En iyi şunlar için: JSON dosyalarını dışa aktarmak zorunda kalmadan buluta bağlı çalıştırmalar isteyen Postman ekipleri. Dürüst sınırlama: kapalı kaynaktır ve bir Postman hesabına bağlıdır, ve iki resmi çalıştırıcının olması, hangisinin benimseneceği konusunda gerçek bir kafa karışıklığı yaratır. Postman CLI vs Newman karşılaştırması, hangisinin ne zaman mantıklı olduğunu çözer.

5. Bruno CLI: Git-yerel koleksiyonlar, bru ile çalıştırın

Bruno, koleksiyonları sıradan klasörlerde düz metin .bru dosyaları olarak saklar, böylece istekler diğer kodlar gibi deponuzda yaşar. CLI'si, @usebruno/cli, bu koleksiyonları terminalden bru komutuyla çalıştırır, herhangi bir bulut hesabı gerektirmez.

npm install -g @usebruno/cli

# Mevcut koleksiyon klasöründeki her isteği çalıştırın
bru run --env staging

En iyi şunlar için: çekme isteklerinde incelenebilen ve çevrimdışı çalıştırılabilen koleksiyonlar isteyen, onaylamaları ve betiklemeyi aynı dosyalarda ele alan ekipler. CI için JSON, JUnit ve HTML raporları yazar. Dürüst sınırlama: düz metin yazma, karma ekiplerden ziyade geliştiricilere daha uygundur ve ekosistemi Postman'dan daha gençtir. Bruno CLI vs Apidog CLI makalesinde Apidog'un çalıştırıcısıyla nasıl karşılaştırıldığını görün.

6. Schemathesis: şemanız testleri yazar

Schemathesis farklı bir yol izler: OpenAPI veya GraphQL şemanızı okur ve Python'ın Hypothesis üzerine kurulu özellik tabanlı testi kullanarak bundan binlerce test durumu oluşturur. Her bir durumu yazmak yerine, 500'leri, şema ihlallerini ve dokümanlarınızın vaat ettiği sözleşmeyi bozan yanıtları bulmak için girdileri bulanıklaştırmasına izin verirsiniz.

pip install schemathesis

schemathesis run https://api.example.com/openapi.json

En iyi şunlar için: kimsenin test yazmayı düşünmediği uç durum hatalarını yakalamak için, özellikle bir sürümden önce. Doğru bir şemayı korumak için en güçlü argümanlardan biridir. Dürüst sınırlama: çalışmak için gerçek bir şemaya ihtiyaç duyar ve büyük bir API, kancalar ve seçeneklerle filtreleyeceğiniz gürültü üretebilir.

7. Step CI: Çok adımlı akış başına bir YAML dosyası

Step CI, bir API iş akışını tek bir YAML dosyasında tanımlar: adımlar, yakalanan değerler ve kontroller. Tek bir iş akışında REST, GraphQL, gRPC, tRPC ve SOAP'ı kapsar ve bir OpenAPI şemasına göre doğrular. Aynı dosya bir dizüstü bilgisayarda ve bir boru hattında çalışır.

npm install -g stepci

stepci run workflow.yml

En iyi şunlar için: betikleme olmadan bildirimsel olarak tanımlanan "giriş yap, sonra jetonu kullan" dizileri. Dürüst sınırlama: bir Node çalışma zamanı taşır ve sürüm sıklığı yavaşlamıştır, bu nedenle üzerine bir boru hattı inşa etmeden önce deponun son etkinliğini kontrol edin.

8. curl: Zaten kurulu olan temel araç

curl, macOS, çoğu Linux dağıtımı ve güncel Windows ile birlikte gelir, bu nedenle en hafif kurulum hiç kurulum yapmamaktır. Diğer tüm araçların kendisine göre ölçüldüğü referans istemcisidir ve -w ile kabuk yapıştırıcısı (shell glue) ile minimal bir test donanımı olarak işlev görebilir.

# JSON POST edin ve yalnızca HTTP durumunu yazdırın
curl -s -o /dev/null -w "%{http_code}\n" \
  -X POST https://api.example.com/orders \
  -H "Content-Type: application/json" \
  -d '{"sku":"A-102","qty":2}'

En iyi şunlar için: tek seferlik istekler, betikler ve yeni hiçbir şeyin kurulamadığı kilitli ortamlar. Dürüst sınırlama: onaylamalar tamamen DIY'dir (Kendin Yap). jq'ya yönlendirir, değerleri kendiniz karşılaştırır ve çıkış kodlarını elle yönetirsiniz. Gönderir ve gösterir; test etmez. REST API testi için curl alternatifleri kılavuzu, bunun yetersiz kaldığı durumlarda nelere başvurulacağını kapsar.

9. HTTPie ve xh: Elle okunabilir istekler

HTTPie, terminal isteklerini okunabilir hale getirdi: komut http, JSON alanları anahtar=değer çiftleridir ve yanıtlar renklendirilmiş ve biçimlendirilmiş olarak geri döner. xh, aynı sözdizimini Rust'ta tek bir statik ikili olarak yeniden uyguladı, daha hızlı başlatma ve eşdeğer curl komutunu yazdıran bir --curl bayrağı ile.

http POST api.example.com/users name=acme plan=pro   # HTTPie
xh   POST api.example.com/users name=acme plan=pro   # aynı sözdizimi, tek ikili

En iyi şunlar için: gerçek testleri başka bir yerde oluştururken API'yi elle keşfetmek. Dürüst sınırlama: ikisi de istemci, çalıştırıcı değil. HTTPie bir Python çalışma zamanı taşır; xh daha küçük bir özellik setini hız için takas eder. İkisi de bir yanıt üzerinde onaylama yapmaz.

10. k6: Soru yük olduğunda

k6 farklı bir soruyu yanıtlar: "bu yanıt doğru mu" değil, "trafik altında dayanıyor mu." Grafana'dan tek bir Go ikili dosyasıdır, JavaScript'te betiklenmiştir, bir yük testini geç/kal kapısına dönüştüren eşikler vardır. Bir eşik aşıldığında k6 sıfır olmayan bir kodla çıkar, bu da CI tarafından bir hata olarak okunur.

brew install k6

k6 run load.js   # betikte tanımlanmış vus, süre ve eşikler

En iyi şunlar için: fonksiyonel testlerle aynı depoda yaşayan ve bir dizüstü bilgisayardan veya bir boru hattından çalıştırılan performans kontrolleri. Dürüst sınırlama: AGPL-3.0 altında bir yük aracıdır, fonksiyonel bir test istemcisi değildir ve anlamlı senaryolar için JavaScript API'sini öğrenmeyi gerektirir.

Etkileşimli bir şey mi tercih edersiniz?

Kabuktan ayrılmadan Postman benzeri bir arayüz istiyorsanız, bu ayrı bir kategoridir: atac ve posting gibi TUI istemcileri terminal içinde tam istek düzenleyicileri çizer. Bunlar API'leri keşfederler; boru hatlarını engellemezler. En iyi terminal ve TUI REST API istemcileri derlemesi, bu tarafı derinlemesine kapsar.

Karşılaştırma Tablosu

Nasıl Seçilir?

Araca göre değil, işe göre başlayın. Eğer testler zaten Postman'da mevcutsa, Newman veya Postman CLI onları yarın çalıştırır. Eğer deponuzda incelenebilir metin olarak testler istiyorsanız, Hurl ve Bruno CLI en güçlü seçeneklerdir. Sağlam bir OpenAPI şemanız varsa, Schemathesis'i ekleyin ve tahmin etmediğiniz hataları avlamasına izin verin. Manuel katman için curl ve xh'yi saklayın, ve soru doğruluktan kapasiteye döndüğünde k6'yı devreye alın.

Senaryoları görsel bir editörde yazmayı ve her yerde çalıştırmayı tercih ediyorsanız Apidog CLI'yi seçin. Burada aynı projenin API tasarımınızı, sahte verilerinizi ve dokümantasyonunuzu da taşıdığı tek seçenek budur, bu durum Apidog CLI: Terminalinizde yaşayan API istemcisi makalesinde açıklanmaktadır. Bu seçimlerin arkasındaki daha geniş test resmi için, API test stratejileri kılavuzu her katmanın nereye uyduğunu haritalar.

Sıkça Sorulan Sorular

API'leri tamamen terminalden test edebilir miyim? Evet. Testleri dosya olarak (Hurl, Bruno, Step CI) veya görsel bir editörde (Apidog, Postman) yazın, ardından eşleşen CLI ile başsız çalıştırın. Bu listedeki her çalıştırıcı, CI'ın ihtiyaç duyduğu tek şey olan bir çıkış kodu döndürür.

Bir terminal API istemcisi ile bir test aracı arasındaki fark nedir? Bir istemci (curl, HTTPie, xh) bir istek gönderir ve yanıtı gösterir. Bir test aracı (Apidog CLI, Hurl, Newman) yanıta onaylamalar yapar ve sıfır olmayan bir çıkış koduyla başarısız olur. İstemciler keşfeder; test araçları kapı görevi görür.

Bunlardan hangileri CI boru hatlarında çalışır? Tüm çalıştırıcılar: apidog run, hurl --test, newman run, postman collection run, bru run, schemathesis run, stepci run ve k6 run hepsi başarısızlık durumunda sıfır olmayan bir kodla çıkar. Çalışan bir boru hattı örneği için, GitHub Actions'ta Apidog CLI testlerinin nasıl çalıştırılacağına bakın.

Bunlardan herhangi biri yük testini yönetiyor mu? k6, geç/kal eşikleriyle burada yük uzmanıdır. Diğerleri kapasiteyi değil, doğruluğu kontrol eder, bu nedenle birçok ekip bir fonksiyonel çalıştırıcıyı k6 ile eşleştirir.

Bu araçları kullanmak için bir OpenAPI belirtimine ihtiyacım var mı? Yalnızca Schemathesis, şemadan testler oluşturduğu için bir tanesine ihtiyaç duyar. Diğer her yerde bir belirtim engel değil, yardımcıdır: Apidog, OpenAPI 3.x, Swagger 2.0 ve Postman koleksiyonlarını içe aktarır ve Step CI, yanıtları bir şemaya göre doğrulayabilir.

Tüm on araçtaki desen aynıdır: yazım konfor ister, çalıştırma bir kabuk ister. Testleri nerede yazmak istediğinizi seçin, ardından çalıştırıcının boru hattınıza bir çıkış kodu verdiğinden emin olun. Her iki yarımı da tek bir platformdan istiyorsanız, Apidog'u indirin, editörde bir senaryo oluşturun ve döngüyü kapatmak için apidog run komutunu CI'ya bırakın.