ما هو الفرق بين نيومان وبوستمان؟

Newman و Postman ليسا منافسين؛ هما مرحلتان في نفس سير العمل. تستخدم Postman لتصميم الطلبات، كتابة الاختبارات، واستكشاف واجهات API يدويًا. ثم تستخدم Newman لتشغيل نفس المجموعات من سطر الأوامر داخل CI/CD أو أي مهمة غير مراقبة.

جرّب Apidog اليوم

الفكرة العملية بسيطة: اكتب الاختبارات في Postman، شغّلها آليًا باستخدام Newman. إذا كان Postman هو مكان التأليف والتجربة، فإن Newman هو المشغّل الذي يجعل هذه الاختبارات قابلة للتنفيذ داخل GitHub Actions أو Jenkins أو GitLab CI أو أي نظام بناء آخر.

ما هو Postman

Postman منصة رسومية للعمل مع واجهات API. من خلالها يمكنك:

• إنشاء طلبات HTTP.
• تنظيم الطلبات داخل Collections و Folders.
• استخدام Environments لتخزين متغيرات مثل baseUrl و token.
• كتابة اختبارات JavaScript داخل تبويب Tests.
• تشغيل الطلبات يدويًا أثناء التطوير والتصحيح.

مثال لاختبار داخل Postman:

pm.test("Status code is 200", function () {
    pm.response.to.have.status(200);
});

pm.test("Order total is a positive number", function () {
    const body = pm.response.json();
    pm.expect(body.total).to.be.a("number");
    pm.expect(body.total).to.be.above(0);
});

هذا النوع من الاختبارات مفيد أثناء تطوير API أو التحقق من استجابة endpoint جديدة. يمكنك إرسال الطلب، فحص الاستجابة، تعديل headers أو body، ثم إعادة التشغيل بسرعة.

لكن Postman ليس الخيار الأفضل للتنفيذ غير المراقب. تشغيل Collection من الواجهة الرسومية مناسب للمطور الجالس أمام الجهاز، لكنه غير مناسب لخادم CI لا يستطيع النقر على زر Run.

للمزيد حول سير العمل اليدوي، راجع دليل كيفية اختبار واجهات برمجة التطبيقات باستخدام Postman.

ما هو Newman

Newman هو مشغّل Collections الرسمي لـ Postman عبر سطر الأوامر. يتم توزيعه كحزمة npm، ويشغّل ملفات Postman Collection بصيغة JSON بدون واجهة رسومية.

ثبّت Newman:

npm install -g newman

ثم شغّل Collection:

newman run orders-api.postman_collection.json \
  --environment staging.postman_environment.json

يقوم Newman بتنفيذ:

• كل الطلبات داخل Collection.
• سكربتات pre-request.
• اختبارات pm.test.
• المتغيرات الموجودة داخل Environment.
• التقارير عبر الطرفية أو reporters مثل JUnit.

الأهم أنه يعيد exit code مناسبًا:

• 0 عند نجاح الاختبارات.
• قيمة غير صفرية عند فشل أي اختبار.

هذا السلوك هو ما يسمح لأنظمة CI/CD بإفشال build تلقائيًا عند فشل اختبارات API.

مقارنة سريعة بين Postman و Newman

الجانب	Postman	Newman
الواجهة	تطبيق سطح مكتب رسومي	سطر أوامر بدون واجهة
الاستخدام الأساسي	التأليف، التصحيح، الاستكشاف	التنفيذ الآلي وغير المراقب
مكان التشغيل	جهاز المطور	CI، الطرفية، المجدولات
التكلفة	طبقة مجانية وخطط مدفوعة	مفتوح المصدر ومجاني
التثبيت	تطبيق سطح مكتب	حزمة npm
الاختبارات	تُكتب وتُشغّل في التطبيق	يشغّل نفس الاختبارات
التقارير	داخل واجهة Postman	CLI و JUnit ومبلّغون إضافيون
الأفضل في	التكرار التفاعلي	التشغيل المتكرر والقابل للبرمجة

ملف Collection بصيغة JSON هو نقطة الربط بينهما: تنشئه في Postman، ثم تشغّله في Newman.

تشغيل Newman داخل CI/CD

النمط العملي لاستخدام Newman في CI/CD يكون كالتالي:

1. صدّر Collection من Postman كملف JSON.
2. صدّر Environment المستخدم كملف JSON.
3. أضف الملفات إلى المستودع.
4. ثبّت Newman داخل pipeline.
5. شغّل newman run.
6. اترك exit code يحدد نجاح أو فشل build.

مثال هيكل ملفات:

api-tests/
  orders-api.postman_collection.json
  staging.postman_environment.json

مثال تشغيل محلي:

newman run api-tests/orders-api.postman_collection.json \
  --environment api-tests/staging.postman_environment.json

مثال داخل GitHub Actions:

- name: Run API tests
  run: |
    npm install -g newman
    newman run api-tests/orders-api.postman_collection.json \
      --environment api-tests/staging.postman_environment.json \
      --reporters cli,junit \
      --reporter-junit-export results.xml

استخدام --reporters cli,junit مفيد لأن:

• cli يعرض النتائج في logs.
• junit ينتج ملف XML يمكن لأنظمة CI قراءته وعرضه كتقرير اختبار.

لشرح أوسع، راجع أتمتة اختبارات API في CI/CD وأتمتة اختبارات API باستخدام GitHub Actions.

خيارات Newman مفيدة في التنفيذ الآلي

تشغيل اختبارات تعتمد على بيانات

إذا كنت تريد تشغيل نفس Collection على عدة مدخلات، استخدم --iteration-data مع ملف CSV أو JSON:

newman run orders-api.postman_collection.json \
  --environment staging.postman_environment.json \
  --iteration-data test-data/orders.csv

مثال CSV:

orderId,expectedStatus
1001,200
1002,200
9999,404

داخل Postman يمكنك قراءة القيم كمتغيرات:

const expectedStatus = Number(pm.iterationData.get("expectedStatus"));

pm.test("Status code matches expected value", function () {
    pm.response.to.have.status(expectedStatus);
});

إيقاف التنفيذ عند أول فشل

استخدم --bail إذا كنت تريد فشلًا سريعًا داخل pipeline:

newman run orders-api.postman_collection.json \
  --environment staging.postman_environment.json \
  --bail

هذا مفيد في smoke tests حيث لا تحتاج إلى متابعة باقي الطلبات بعد فشل أساسي.

تحديد مهلة الطلبات

لتجنب تعليق job بسبب خدمة لا تستجيب:

newman run orders-api.postman_collection.json \
  --environment staging.postman_environment.json \
  --timeout-request 10000

القيمة هنا بالمللي ثانية، أي 10 ثوانٍ.

إضافة تأخير بين الطلبات

إذا كانت API لديها rate limits:

newman run orders-api.postman_collection.json \
  --environment staging.postman_environment.json \
  --delay-request 500

هذا يضيف تأخيرًا قدره 500ms بين الطلبات.

تشغيل Folder محدد فقط

لتشغيل smoke tests بدل تشغيل المجموعة كاملة:

newman run orders-api.postman_collection.json \
  --environment staging.postman_environment.json \
  --folder "Smoke Tests"

هذا يسمح لك ببناء أكثر من job:

• Job سريع عند كل Pull Request.
• Job كامل ليليًا أو قبل النشر.

مثال عملي: تقسيم الاختبارات في CI

يمكنك تشغيل smoke tests على كل pull request:

- name: Run smoke API tests
  run: |
    npm install -g newman
    newman run api-tests/orders-api.postman_collection.json \
      --environment api-tests/staging.postman_environment.json \
      --folder "Smoke Tests" \
      --bail

ثم تشغيل regression tests كاملة على الفرع الرئيسي:

- name: Run full API regression tests
  run: |
    npm install -g newman
    newman run api-tests/orders-api.postman_collection.json \
      --environment api-tests/staging.postman_environment.json \
      --reporters cli,junit \
      --reporter-junit-export results.xml

بهذا تحصل على feedback سريع أثناء المراجعة، واختبار أوسع قبل الدمج أو النشر.

أخطاء شائعة عند الانتقال من Postman إلى Newman

1. نسيان تمرير Environment

إذا كان الطلب يعتمد على متغير مثل:

{{baseUrl}}/orders

فسيعمل في Postman إذا كانت البيئة مفعّلة، لكنه سيفشل في Newman إذا لم تمرر البيئة:

newman run orders-api.postman_collection.json \
  --environment staging.postman_environment.json

لا تعتمد على إعدادات محلية داخل Postman. صدّر البيئة ومررها صراحة.

2. استخدام قيم ثابتة داخل الطلبات

بدل كتابة URL ثابت:

https://staging.example.com/orders

استخدم متغيرًا:

{{baseUrl}}/orders

ثم اجعل baseUrl داخل environment:

{
  "values": [
    {
      "key": "baseUrl",
      "value": "https://staging.example.com",
      "enabled": true
    }
  ]
}

هذا يجعل نفس Collection قابلة للتشغيل ضد staging أو production-like environments.

3. الاعتماد على حالة Postman Cloud

Newman يشغّل ملفات JSON المصدّرة. إذا كانت المجموعة تعتمد على متغيرات متزامنة في حساب Postman أو إعدادات جلسة محلية، فقد لا تظهر هذه القيم في CI.

اختبر دائمًا الملف المصدّر محليًا:

newman run exported_collection.json \
  --environment exported_environment.json

إذا نجح محليًا عبر Newman، سيكون أقرب للنجاح داخل CI.

4. نسيان إعادة التصدير

ملف Collection داخل المستودع هو لقطة من Postman. إذا عدّل أحدهم Collection داخل Postman ولم يعِد التصدير، فسيستمر CI في تشغيل النسخة القديمة.

تعامل مع التصدير كجزء من عملية التغيير:

1. عدّل Collection في Postman.
2. شغّلها محليًا.
3. صدّر JSON.
4. شغّلها عبر Newman.
5. أضف الملفات إلى commit.

متى تستخدم Postman ومتى تستخدم Newman

استخدم Postman عندما يكون العمل تفاعليًا:

• تصميم endpoint جديدة.
• تجربة API خارجية.
• تصحيح request فاشل.
• بناء الاختبارات لأول مرة.
• فحص response يدويًا.

استخدم Newman عندما يكون العمل آليًا:

• تشغيل الاختبارات عند كل Pull Request.
• تشغيل smoke tests بعد النشر.
• تشغيل regression tests ليليًا.
• توليد تقارير داخل CI.
• جعل فشل API test يفشل build تلقائيًا.

القاعدة العملية: Postman للتأليف، Newman للتشغيل.

إذا كنت تريد خيارات لتشغيل Collections في CI بدون الاعتماد على Newman، راجع تشغيل مجموعات Postman في CI بدون Newman.

بديل موحد: Apidog

إعداد Postman مع Newman يتطلب تصدير Collections، مزامنة ملفات JSON، وتشغيل أداة منفصلة داخل CI. يجمع Apidog تصميم واجهات API، تصحيح الطلبات، وبناء سيناريوهات الاختبار الآلية في منصة واحدة.

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

يدعم Apidog أيضًا تصميم API، الخوادم الوهمية، واختبار الأداء داخل نفس مساحة العمل. يمكنك تنزيل Apidog واستخدام ميزات الاختبار مجانًا. ولمقارنة الأدوات، راجع قائمة أفضل بدائل Postman لاختبار API.

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

هل Newman بديل لـ Postman؟

لا. Newman لا ينشئ Collections ولا يحررها. هو يشغّل Collections فقط. ما زلت تحتاج إلى Postman أو أداة أخرى لتأليف الطلبات وكتابة الاختبارات.

هل Newman مجاني؟

نعم. Newman مفتوح المصدر ومجاني، ويتم توزيعه كحزمة npm. Postman لديه طبقة مجانية وخطط مدفوعة، لكن Newman نفسه لا يتطلب تكلفة استخدام.

هل تعمل اختبارات Postman بنفس الطريقة في Newman؟

نعم. Newman يشغّل نفس سكربتات pm.test ومنطق الطلبات المستخدم في Postman Collection Runner. لذلك إذا كانت Collection تعمل في Postman، فمن المتوقع أن تعمل بنفس السلوك عبر Newman عند تمرير نفس البيئة والمتغيرات.

كيف يعرف CI أن الاختبارات فشلت؟

عند فشل أي اختبار، يخرج Newman برمز حالة غير صفري. أنظمة CI تقرأ هذا الرمز وتعلّم job أو build كفاشل.

مثال:

newman run orders-api.postman_collection.json \
  --environment staging.postman_environment.json

إذا فشل اختبار واحد، سيفشل الأمر، وبالتالي يفشل job.

هل يمكن تشغيل Newman بدون تثبيت Node.js؟

نعم، باستخدام Docker. بدل تثبيت Node.js و npm داخل بيئة CI، يمكنك استخدام صورة Docker الخاصة بـ Newman:

docker run --rm \
  -v "$PWD:/etc/newman" \
  postman/newman run /etc/newman/orders-api.postman_collection.json \
  --environment /etc/newman/staging.postman_environment.json

هذا مفيد عندما تريد بيئة تشغيل معزولة وثابتة داخل CI.