أفضل أدوات اختبار API المستندة إلى الطرفية لعام 2026

لقد انتقل اختبار واجهة برمجة التطبيقات (API) من الواجهة الرسومية (GUI). تعمل الاختبارات الآن في حاويات التكامل المستمر (CI) بدون شاشة عرض مرفقة، وعلى صناديق التطوير التي تصل إليها فقط عبر SSH، وتحت وكلاء الذكاء الاصطناعي الذين لا يتحدثون إلا لغة الأوامر (shell). في جميع هذه الأماكن الثلاثة، يمثل الطرفية (terminal) المكان الذي ينجح فيه الاختبار أو يفشل دون مراقبة بشرية.

تُصنف هذه المقالة الأدوات التي تقوم بعمل اختبار حقيقي من موجه الأوامر (shell prompt). تعني "المعتمدة على الطرفية" هنا أن الحلقة الكاملة تعمل في واجهة الأوامر: التثبيت من مدير الحزم، تشغيل أمر واحد، قراءة رمز الخروج. يزن التصنيف التأكيدات المدمجة، والتدفقات متعددة الخطوات، والتقارير الجاهزة للتكامل المستمر (CI)، وحالة الصيانة. لا تزال العملاء اليدوية مثل curl تحتل مكانة قرب النهاية، لأن كل سير عمل في الطرفية يعتمد عليها بين تشغيل الاختبارات. للحصول على مسح أوسع يشمل الأدوات الرسومية (GUI) والأدوات المستضافة، راجع قائمة أفضل أدوات اختبار واجهة برمجة التطبيقات المجانية.

ما الذي يفصل أداة الاختبار عن العميل

يرسل عميل الطرفية طلبًا ويُظهر لك الاستجابة. أما أداة اختبار الطرفية فتقيّم الاستجابة وتُبلغ عن الحكم كرمز خروج يمكن لخط أنابيبك الاعتماد عليه. المجموعة الثانية هي جوهر هذه القائمة، وتحددها أربع سمات:

• تأكيدات مدمجة. فحوصات الحالة، والرؤوس، ومحتوى الجسم تنتمي إلى الأداة، وليس إلى كومة من لاصق jq.
• رموز خروج ذات معنى. صفر عند النجاح، وغير صفر عند الفشل، لذلك يفشل CI البناء تلقائيًا.
• قابلية التكرار. تعيش الاختبارات في ملفات أو مشاريع يمكنك إصدارها وإعادة تشغيلها، وليس في سجل أوامر (shell history) الخاص بك.
• التقارير. إخراج يمكن أن يقرأه الإنسان في الطرفية ويمكن للوحة معلومات تحليلها كـ JSON أو JUnit أو HTML.

مع تحديد المعايير، إليك الأدوات العشر التي تستحق وقتك في عام 2026.

1. Apidog CLI: تأليف مرئيًا، وتشغيل بدون واجهة مستخدم في أي مكان

Apidog هي منصة API شاملة تغطي التصميم والاختبار والمحاكاة والتوثيق. Apidog CLI (apidog-cli على npm) هو ذراعها الطرفي. يمكنك بناء سيناريوهات الاختبار في المحرر المرئي، مع طلبات متسلسلة ومتغيرات مستخرجة وتأكيدات، ثم يقوم apidog run بتنفيذها من أي واجهة أوامر ويسلم خط أنابيبك رمز خروج نظيفًا.

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

# Copy the exact command from your scenario's CI/CD tab
apidog run -t <scenario_id> -e <env_id> -r cli

لا تخمن المعرفات. افتح السيناريو في Apidog، وانتقل إلى علامة التبويب CI/CD، وانسخ الأمر الذي تم إنشاؤه. تغطي أدوات إعداد التقارير cli وhtml وjson وjunit، وتُكتب إلى apidog-reports/، بحيث يغذي التشغيل نفسه الطرفية ولوحة المعلومات ومخزن القطع الأثرية. تسحب عمليات التشغيل المعتمدة على البيانات التكرارات من ملفات CSV أو JSON. يكون الإخراج JSON منظمًا مع agentHints.nextSteps، مما يسمح لوكيل برمجة الذكاء الاصطناعي بتشغيل مجموعة واختيار حركته التالية دون كشط الشاشة. يتطلب Node.js 16 أو أحدث.

الأفضل لـ: الفرق التي ترغب في تأليف سيناريوهات معقدة ومتعددة الخطوات في محرر وتشغيلها بشكل متطابق على جهاز كمبيوتر محمول، وفي CI، ومن قبل الوكلاء. القيد الصادق: ليست مفتوحة المصدر وليست مرسلًا مخصصًا. تعيش السيناريوهات في مشروع Apidog، لذا هذا هو خيار المنصة المتكاملة بدلاً من أداة HTTP بسيطة. يغطي الدليل الكامل لـ Apidog CLI مجموعة الأوامر الكاملة.

2. Hurl: اختبارات نصية عادية في ثنائي Rust واحد

يقوم Hurl بتشغيل طلبات HTTP المكتوبة بتنسيق نص عادي ويؤكد على الاستجابات. تم بناؤه في Rust فوق libcurl ويأتي كثنائي واحد، لذلك لا يوجد وقت تشغيل للتثبيت. تُقرأ الاختبارات تقريبًا كـ HTTP خام، مما يسهل مراجعتها في طلب سحب.

brew install hurl   # or: 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   # non-zero exit if an assertion fails

الأفضل لـ: فحوصات على غرار العقود واختبارات الدخان التي تحتفظ بها في التحكم في الإصدار كنص قابل للقراءة. تجعل علامة --test منه بوابة طبيعية للتكامل المستمر (CI). القيد الصادق: يركز على HTTP، لذلك لن يشغل gRPC أو يولد حمولة، وتعني المنطق المعقد المزيد من ملفات .hurl بدلاً من لغة برمجة نصية.

3. Newman: تشغيل مجموعات Postman بدون واجهة مستخدم

Newman هو مشغل سطر الأوامر مفتوح المصدر لمجموعات Postman (Apache-2.0). إذا كان فريقك يكتب الطلبات والاختبارات بالفعل في Postman، فإن Newman يشغل تلك المجموعة بالضبط من طرفية بدون واجهة رسومية. يمكنك تصدير المجموعة والبيئة كـ JSON وتوجيه Newman إلى الملفات.

npm install -g newman

newman run collection.json -e staging.json

الأفضل لـ: الفرق التي تستخدم Postman وتريد تشغيل المجموعات الموجودة في خط أنابيب دون الحاجة إلى مقاعد إضافية. يخرج برمز غير صفري عندما يفشل الاختبار، لذلك تغلق بوابة CI بشكل نظيف. القيد الصادق: يشغل فقط مجموعات بتنسيق Postman، ولا يزال التأليف يحدث في واجهة Postman الرسومية. يقوم بتنفيذ الاختبارات؛ لا يساعدك على كتابتها.

4. Postman CLI: البديل الرسمي لـ Newman

إن Postman CLI هو مشغل Postman الخاص والمغلق المصدر. على عكس Newman، فإنه يسجل الدخول إلى حساب Postman الخاص بك ويمكنه تشغيل مجموعة بمعرفها، مباشرة من مساحة العمل، مع إرسال النتائج إلى سحابة Postman.

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

postman collection run <collection_id> -e <environment_id>

الأفضل لـ: فرق Postman التي تريد تشغيل مجموعات مرتبطة بالسحابة دون تصدير ملفات JSON. القيد الصادق: إنه مغلق المصدر ومرتبط بحساب Postman، ووجود مشغلين رسميين يخلق ارتباكًا حقيقيًا حول أيهما يجب اعتماده. توضح مقارنة Postman CLI مقابل Newman متى يكون كل منهما منطقيًا.

5. Bruno CLI: مجموعات متوافقة مع Git، تُشغل باستخدام bru

يخزن Bruno المجموعات كملفات نصية عادية .bru في مجلدات عادية، بحيث تعيش الطلبات في مستودعك مثل أي كود آخر. يقوم واجهة سطر الأوامر الخاصة به، @usebruno/cli، بتشغيل هذه المجموعات من الطرفية باستخدام الأمر bru، بدون الحاجة إلى حساب سحابي.

npm install -g @usebruno/cli

# Run every request in the current collection folder
bru run --env staging

الأفضل لـ: الفرق التي تريد مراجعة المجموعات في طلبات السحب وتشغيلها دون اتصال بالإنترنت، مع معالجة التأكيدات والبرمجة النصية في نفس الملفات. يكتب تقارير JSON وJUnit وHTML لـ CI. القيد الصادق: التأليف بالنص العادي يناسب المطورين أكثر من الفرق المختلطة، والنظام البيئي أصغر من Postman. انظر كيف يقارن بمشغل Apidog في Bruno CLI مقابل Apidog CLI.

6. Schemathesis: مخططك يكتب الاختبارات

يسلك Schemathesis طريقًا مختلفًا: يقرأ مخطط OpenAPI أو GraphQL الخاص بك ويولد آلاف حالات الاختبار منه، باستخدام اختبار قائم على الخصائص مبني على Hypothesis من Python. بدلاً من كتابة كل حالة، تتركه يقوم بـ "تغبيش" المدخلات للعثور على أخطاء 500، وانتهاكات المخطط، والاستجابات التي تكسر العقد الذي تعد به وثائقك.

pip install schemathesis

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

الأفضل لـ: اكتشاف الأخطاء النادرة التي لم يفكر أحد في كتابة اختبار لها، خاصة قبل الإصدار. إنه أحد أقوى الحجج للحفاظ على مخطط دقيق. القيد الصادق: يحتاج إلى مخطط حقيقي للعمل منه، ويمكن لواجهة برمجة تطبيقات كبيرة أن تنتج ضوضاء ستقوم بتصفيتها باستخدام الأدوات والخيارات.

7. Step CI: ملف YAML واحد لكل تدفق متعدد الخطوات

يصف Step CI سير عمل واجهة برمجة التطبيقات في ملف YAML واحد: الخطوات، القيم الملتقطة، والفحوصات. يغطي REST، GraphQL، gRPC، tRPC، وSOAP في سير عمل واحد ويتحقق من صحتها مقابل مخطط OpenAPI. يعمل نفس الملف على جهاز كمبيوتر محمول وفي خط أنابيب.

npm install -g stepci

stepci run workflow.yml

الأفضل لـ: تسلسلات تسجيل الدخول ثم استخدام الرمز المميز الموصوفة بشكل تعريفي، بدون برمجة نصية. القيد الصادق: يحمل وقت تشغيل Node، وقد تباطأت وتيرة الإصدار، لذا تحقق من نشاط المستودع الأخير قبل بناء خط أنابيب عليه.

8. curl: الأساس المثبت بالفعل

يأتي curl مع macOS، ومعظم توزيعات Linux، وإصدارات Windows الحالية، لذا فإن أخف تثبيت هو عدم التثبيت. إنه العميل المرجعي الذي تقيس كل أداة أخرى نفسها وفقه، ومع -w وربط الأوامر (shell glue) يمكن أن يعمل كأداة اختبار بسيطة.

# POST JSON and print only the HTTP status
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}'

الأفضل لـ: الطلبات لمرة واحدة، والسكريبتات، والبيئات المقيدة حيث لا يمكن تثبيت أي شيء جديد. القيد الصادق: التأكيدات هي بالكامل من صنعك. تقوم بتحويل الإخراج إلى jq، وتقارن القيم بنفسك، وتدير رموز الخروج يدويًا. إنه يرسل ويُظهر؛ لا يختبر. يغطي دليل بدائل curl لاختبار REST API ما يجب اللجوء إليه عندما لا يكون ذلك كافيًا.

9. HTTPie و xh: طلبات يدوية قابلة للقراءة

جعل HTTPie طلبات الطرفية قابلة للقراءة: الأمر هو http، وحقول JSON هي أزواج key=value، وتعود الاستجابات ملونة ومنسقة. يعيد xh تنفيذ نفس بناء الجملة في Rust كثنائي ثابت واحد، مع بدء تشغيل أسرع وعلامة --curl التي تطبع أمر curl المكافئ.

http POST api.example.com/users name=acme plan=pro   # HTTPie
xh   POST api.example.com/users name=acme plan=pro   # same syntax, one binary

الأفضل لـ: استكشاف واجهة برمجة التطبيقات يدويًا أثناء بناء الاختبارات الحقيقية في مكان آخر. القيد الصادق: كلاهما عملاء، وليس مشغلات. يحمل HTTPie وقت تشغيل Python؛ يتداول xh مجموعة ميزات أصغر مقابل السرعة. لا يؤكد أي منهما على الاستجابة.

10. k6: عندما يكون السؤال عن الحمل

يجيب k6 على سؤال مختلف: ليس "هل هذه الاستجابة صحيحة" بل "هل تصمد تحت حركة المرور". إنه ثنائي Go واحد من Grafana، مكتوب بلغة JavaScript، مع عتبات تحول اختبار التحميل إلى بوابة نجاح/فشل. عند تجاوز عتبة، يخرج k6 بقيمة غير صفرية، وهو ما يقرأه CI كفشل.

brew install k6

k6 run load.js   # vus, duration, and thresholds defined in the script

الأفضل لـ: فحوصات الأداء التي تعيش في نفس المستودع مثل الاختبارات الوظيفية وتعمل من جهاز كمبيوتر محمول أو خط أنابيب. القيد الصادق: إنها أداة تحميل تحت ترخيص AGPL-3.0، وليست عميل اختبار وظيفي، والسيناريوهات ذات المعنى تعني تعلم واجهة برمجة تطبيقات JavaScript الخاصة بها.

تفضل شيئًا تفاعليًا؟

إذا كنت تريد واجهة تشبه Postman دون مغادرة الواجهة الطرفية، فهذه فئة منفصلة: عملاء واجهة المستخدم النصية (TUI) مثل atac وposting يرسمون محررات طلبات كاملة داخل الطرفية. يقومون باستكشاف واجهات برمجة التطبيقات؛ لا يقومون بإغلاق خطوط الأنابيب. تغطي قائمة أفضل عملاء واجهة برمجة تطبيقات REST الطرفية وTUI هذا الجانب بالتفصيل.

جدول المقارنة

كيف تختار

ابدأ من الوظيفة، وليس الأداة. إذا كانت الاختبارات موجودة بالفعل في Postman، فسيقوم Newman أو Postman CLI بتشغيلها غدًا. إذا كنت تريد الاختبارات كنص قابل للمراجعة في مستودعك، فإن Hurl وBruno CLI هما الخياران الأقوى. إذا كان لديك مخطط OpenAPI قوي، أضف Schemathesis ودعه يبحث عن الأخطاء التي لم تتوقعها. احتفظ بـ curl وxh للطبقة اليدوية، وأحضر k6 في اليوم الذي يتحول فيه السؤال من الصحة إلى القدرة.

اختر Apidog CLI عندما تفضل تأليف السيناريوهات في محرر مرئي وتشغيلها في أي مكان آخر. إنه الخيار الوحيد هنا حيث يحمل نفس المشروع أيضًا تصميم واجهة برمجة التطبيقات الخاصة بك، والبيانات الوهمية، والتوثيق، وهو ما يشرحه المقال Apidog CLI: عميل API الذي يعيش في طرفيتك. للحصول على صورة أوسع للاختبار وراء هذه الاختيارات، يوضح دليل استراتيجيات اختبار واجهة برمجة التطبيقات مكان كل طبقة.

الأسئلة الشائعة

هل يمكنني اختبار واجهات برمجة التطبيقات بالكامل من الطرفية؟ نعم. قم بتأليف الاختبارات كملفات (Hurl, Bruno, Step CI) أو في محرر مرئي (Apidog, Postman)، ثم قم بتشغيلها بدون واجهة مستخدم باستخدام واجهة سطر الأوامر المطابقة. كل مشغل في هذه القائمة يعيد رمز خروج، وهو كل ما يحتاجه CI.

ما الفرق بين عميل API للطرفية وأداة الاختبار؟ يرسل العميل (curl, HTTPie, xh) طلبًا ويُظهر الاستجابة. تؤكد أداة الاختبار (Apidog CLI, Hurl, Newman) على الاستجابة وتفشل برمز خروج غير صفري. يستكشف العملاء؛ وتغلق أدوات الاختبار.

أي من هذه الأدوات تعمل في خطوط أنابيب CI؟ جميع المشغلات: apidog run، وhurl --test، وnewman run، وpostman collection run، وbru run، وschemathesis run، وstepci run، وk6 run جميعها تخرج برمز غير صفري عند الفشل. للحصول على مثال لخط أنابيب عامل، انظر كيفية تشغيل اختبارات Apidog CLI في GitHub Actions.

هل يتعامل أي من هذه الأدوات مع اختبار التحميل؟ k6 هو المتخصص في التحميل هنا، مع عتبات كبوابات نجاح/فشل. الأدوات الأخرى تتحقق من الصحة، وليس القدرة، لذلك تقوم العديد من الفرق بإقران مشغل وظيفي واحد مع k6.

هل أحتاج إلى مواصفات OpenAPI لاستخدام هذه الأدوات؟ Schemathesis فقط يتطلبها، لأنه يولد الاختبارات من المخطط. في كل مكان آخر، تساعد المواصفات بدلاً من أن تكون عائقًا: Apidog يستورد OpenAPI 3.x و Swagger 2.0 ومجموعات Postman، ويمكن لـ Step CI التحقق من صحة الاستجابات مقابل مخطط.

النمط في جميع الأدوات العشر هو نفسه: التأليف يريد الراحة، والتشغيل يريد واجهة أوامر. اختر المكان الذي تريد كتابة الاختبارات فيه، ثم تأكد من أن المشغل يسلم خط أنابيبك رمز خروج. إذا كنت تريد كلا الجزأين من منصة واحدة، قم بتنزيل Apidog، وقم ببناء سيناريو واحد في المحرر، وأسقط أمر apidog run الخاص به في CI لإغلاق الحلقة.