Postman تعلم كيفية تحسين مهاراتك في اختبار API

ملخص

يقوم Postman بأتمتة اختبار API من خلال مجموعات الطلبات (collections)، والتوكيدات (assertions)، والتكامل مع CI/CD عبر Newman. تشمل التقنيات المتقدمة الخوادم الوهمية (mock servers) للاختبار المعزول، ومتغيرات البيئة لإدارة التكوينات، واختبار العقود (contract testing) لضمان التوافق بين API والعميل.

يعد اختبار API اليدوي عنق زجاجة؛ حيث تضغط على زر، وتراقب الاستجابة بالنظر، ثم تضغط مرة أخرى. هذا الأسلوب لا يتوسع. مع نمو API الخاص بك، ستحتاج إلى اختبار مؤتمت يعمل مع كل عملية إرسال كود (commit)، ويوفر نتائج متسقة، ويكتشف التراجعات (regressions) مبكرًا.

لطالما كان Postman أحد أكثر أدوات اختبار API استخدامًا، وفي عام 2026 لا يزال قويًا — لكن المشهد قد تغير. بعد أن أزال Postman وضع العمل دون اتصال (offline mode) في الإصدار v10 وركزت الشركة على سير عمل السحابة أولاً، انتقلت موجة من المستخدمين إلى بدائل أخف تعتمد على العمل المحلي أولاً مثل Bruno (الذي يمتلك الآن حوالي 41 ألف نجمة على GitHub وينمو بسرعة) وHoppscotch. استجاب Postman بالإعلان عن دعم أصلي للعمل دون اتصال، وتخزين نظام الملفات المحلي، والمجموعات القائمة على Git، مع استمرار الطرح خلال عام 2026. إن فهم Postman بعمق — بالإضافة إلى معرفة متى تلجأ للبدائل — يجعلك مطورًا أفضل.

يأخذك هذا الدليل من بناء الطلبات الأساسية إلى سير العمل المتقدم: الاختبار المؤتمت، وخطوط أنابيب CI/CD، والخوادم الوهمية، واختبار العقود.

المتطلبات الأساسية: بناء أول اختبار لك

جوهر Postman هو منشئ الطلبات. أنت تحدد عنوان URL، والرؤوس (headers)، والجسم (body)، ثم ترسل الطلب وتفحص الاستجابة.

POST https://API.example.com/API/users
Content-Type: application/json

{
  "email": "test@example.com",
  "name": "John Doe"
}

لكن القوة الحقيقية تظهر عندما تضيف الاختبارات — وهي كود JavaScript يتم تشغيله بعد وصول الاستجابة.

كتابة اختبارات ما بعد الاستجابة

في تبويب "Post-response" في Postman (الذي كان يسمى سابقًا "Tests" في الإصدارات الأقدم)، تكتب التوكيدات التي تتحقق من صحة الاستجابة.

// Basic status check
pm.test("Status is 201", function() {
  pm.response.to.have.status(201);
});

// Check response structure
pm.test("Response contains user ID", function() {
  pm.expect(pm.response.json()).to.have.property('id');
});

// Validate response data
pm.test("Email matches request", function() {
  const requestBody = JSON.parse(pm.request.body.raw);
  const responseBody = pm.response.json();
  pm.expect(responseBody.email).to.equal(requestBody.email);
});

// Check response time (performance)
pm.test("Response time is under 500ms", function() {
  pm.expect(pm.response.responseTime).to.be.below(500);
});

هذه الاختبارات عبارة عن توكيدات مكتوبة بلغة JavaScript. يستخدم Postman مكتبة التوكيدات Chai، مما يمنحك بناء جملة تعبيريًا قويًا.

المجموعات: تنظيم الطلبات ذات الصلة

تقوم المجموعة (Collection) بتجميع الطلبات ذات الصلة في هيكل هرمي، مما يحاكي سير عمل المستخدم.

مثال على هيكل المجموعة:

User Management API
├── Authentication
│   ├── POST /login
│   ├── POST /refresh
│   └── POST /logout
├── Users
│   ├── GET /users
│   ├── POST /users (create)
│   ├── GET /users/:id
│   ├── PUT /users/:id (update)
│   └── DELETE /users/:id
└── Validation
    ├── Invalid email format
    ├── Missing required fields
    └── Duplicate email error

تسمح لك المجموعات بتنظيم مئات الطلبات بشكل منطقي. يمكنك تشغيل مجموعة كاملة، واختبار سير العمل بالكامل بالتسلسل.

متغيرات البيئة: إدارة التكوين

تعد كتابة عناوين URL وبيانات الاعتماد بشكل ثابت (hardcoding) داخل الطلبات ممارسة سيئة للغاية. استخدم متغيرات البيئة بدلاً من ذلك.

إعداد البيئة:

قم بإنشاء بيئة تحتوي على متغيرات لعنوان URL الخاص بـ API ورمز المصادقة (token):

{
  "base_url": "https://API.example.com",
  "api_key": "sk_live_abc123def456",
  "auth_token": ""
}

أشر إلى المتغيرات باستخدام بناء الجملة {{variable_name}}:

GET {{base_url}}/API/users
Authorization: Bearer {{auth_token}}

تحديث المتغيرات في الاختبارات:

يمكن للاختبارات تحديث متغيرات البيئة. على سبيل المثال، بعد طلب تسجيل الدخول، استخرج الرمز وقم بتخزينه للطلبات اللاحقة:

pm.test("Login successful", function() {
  pm.response.to.have.status(200);
});

// Extract token and save to environment
const token = pm.response.json().token;
pm.environment.set('auth_token', token);

يمكّن هذا النمط من تنفيذ سير عمل كامل (end-to-end): تسجيل الدخول ← الحصول على الرمز ← استخدام الرمز في الطلبات الموثقة اللاحقة.

سكربتات ما قبل الطلب: الإعداد قبل الإرسال

يتم تشغيل سكربتات ما قبل الطلب (Pre-request scripts) قبل إرسال الطلب. استخدمها لإنشاء بيانات ديناميكية، أو طوابع زمنية، أو توقيعات.

// Generate current timestamp
pm.environment.set('timestamp', Date.now());

// Generate a unique email for signup tests
const randomId = Math.random().toString(36).substring(7);
pm.environment.set('test_email', `test_${randomId}@example.com`);

// Generate HMAC signature for signed requests
const crypto = require('crypto');
const secret = pm.environment.get('api_secret');
const message = pm.request.body.raw;
const signature = crypto.createHmac('sha256', secret).update(message).digest('hex');
pm.request.headers.add({key: 'X-Signature', value: signature});

تسمح سكربتات ما قبل الطلب ببيانات اختبار ديناميكية وتتعامل مع أنظمة المصادقة المعقدة.

الخوادم الوهمية: الاختبار بدون API مباشر

تحاكي الخوادم الوهمية (Mock servers) الـ API دون الحاجة إلى تشغيل خلفية (backend). حدد استجابات وهمية لكل نقطة نهاية (endpoint)، وسيقوم Postman بتقديمها.

الفوائد:

• يمكن لفرق الواجهة الأمامية (front-end) بدء التطوير قبل أن تصبح الخلفية جاهزة.
• اختبار سيناريوهات الخطأ (500، 404، 429) دون التسبب في تعطل الإنتاج.
• عزل اختبارات API عن موثوقية الخلفية.
• استجابات متسقة وسريعة.

لإعداد خادم وهمي:

1. انقر بزر الماوس الأيمن على مجموعتك ← "Mock collection".
2. حدد أمثلة للاستجابات لكل نقطة نهاية.
3. يقوم Postman بإنشاء عنوان URL وهمي (مثلاً: https://mock.pstmn.io/abc123).
4. وجه عميلك إلى الخادم الوهمي أثناء التطوير.

التكامل مع CI/CD عبر Newman

Newman هو مشغل سطر الأوامر الخاص بـ Postman. يقوم بتنفيذ المجموعات تلقائيًا في خطوط الأنابيب (pipelines).

الاستخدام الأساسي:

newman run collection.json --environment env.json

المخرجات:

User API

 POST /login
 ✓ Status is 200
 ✓ Token is present

 GET /users
 ✓ Status is 200
 ✓ Response contains user list

 49 requests | 49 passed | 0 failed

التكامل مع GitHub Actions:

name: API Tests
on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Run API tests
        run: |
          npm install -g newman
          newman run postman_collection.json \
            --environment postman_env.json \
            --reporters cli,json \
            --reporter-json-export results.json

      - name: Upload results
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: test-results
          path: results.json

الآن يتم تشغيل اختبارات API الخاصة بك مع كل عملية إرسال كود. الاختبارات الفاشلة تمنع عمليات الدمج (merges).

اختبار العقود: ضمان التوافق بين API والعميل

يتحقق اختبار العقود (Contract testing) من اتفاق API والعميل على الواجهة. فهو يكتشف التغييرات الجذرية (breaking changes) قبل وصولها إلى الإنتاج.

سيناريو مثال: تتوقع واجهتك الأمامية أن يكون user.id رقمًا. قمت بتغييره إلى سلسلة نصية (string). بدون اختبار العقود، سيتعطل العملاء.

يدعم Postman اختبار العقود من خلال توكيدات ما بعد الاستجابة:

pm.test("User schema matches contract", function() {
  const schema = {
    type: "object",
    properties: {
      id: { type: "integer" },
      email: { type: "string" },
      name: { type: "string" },
      created_at: { type: "string" }
    },
    required: ["id", "email", "name"]
  };

  pm.response.to.have.jsonSchema(schema);
});

يضمن هذا التوكيد أن الاستجابة تطابق المخطط (schema) المتوقع. قم بتغيير شكل استجابة API، وسيفشل الاختبار — مما ينبهك إلى التغييرات الجذرية.

بدائل Postman

يُستخدم Postman على نطاق واسع ولكنه لم يعد الوحيد في الساحة. يقدم كل بديل مقايضات مختلفة حول الترخيص، ونموذج التخزين، والبصمة التقنية:

Bruno

• مرخص بموجب MIT، مفتوح المصدر بالكامل، يمتلك حوالي 41 ألف نجمة على GitHub وهو أحد أسرع عملاء API نموًا في الفترة 2024-2026.
• أصلي لـ Git: تعيش المجموعات كملفات نصية عادية في مستودعك، لا يوجد مزامنة سحابية مملوكة لجهة معينة.
• يدعم REST وGraphQL وgRPC وWebSocket.
• الخيار الأفضل عندما يتعامل فريقك مع تعريفات API ككود مصدري.

Hoppscotch

• مفتوح المصدر، متاح كويب وتطبيق سطح مكتب وواجهة سطر أوامر (مع وتيرة إصدارات نشطة في 2026).
• قابل للاستضافة الذاتية (self-hostable) للفرق التي تحتاج إلى العمل محليًا.
• سكربتات ما قبل الطلب والاختبار، بالإضافة إلى مساحات عمل الفريق في النسخة السحابية.
• مناسب جدًا للاختبار السريع عبر المتصفح وعمليات النشر المستضافة ذاتيًا.

Insomnia

• مفتوح المصدر، مملوك لشركة Kong منذ عام 2019.
• تاريخ ملحوظ: جعل إصدار Insomnia 8.0 (سبتمبر 2023) المزامنة السحابية إلزامية مما أثار رد فعل عنيفًا؛ استعاد الإصدار 8.3 المشاريع المحلية فقط، وتدعم الإصدارات الحالية التخزين المحلي (Local Vault)، والمزامنة السحابية، وتخزين Git جنبًا إلى جنب.
• تكامل أوثق مع بوابة Kong API للفرق التي تستخدم تلك التقنيات بالفعل.

Thunder Client

• إضافة لـ VS Code. كانت مجانية ومفتوحة المصدر في الأصل، ولكنها انتقلت إلى نموذج مدفوع في عام 2024 مع نقل الميزات الرئيسية خلف جدار دفع، ولم يعد الكود المصدري مفتوحًا.
• لا تزال مريحة إذا كنت تعيش داخل VS Code وتحتاج فقط إلى اختبارات خفيفة.
• انتقل العديد من المستخدمين إلى Bruno أو إضافة REST Client بعد تغيير الترخيص.

أفضل الممارسات لاختبار API

1. اختبر المسارات السعيدة والحزينة لا تختبر الطلبات الناجحة فقط، بل اختبر أيضًا:

• الحقول المطلوبة المفقودة (400 Bad Request)
• المصادقة غير الصالحة (401 Unauthorized)
• الأذونات غير الكافية (403 Forbidden)
• الموارد غير الموجودة (404 Not Found)
• تجاوز حد المعدل (429 Too Many Requests)

2. استخدم الاختبار القائم على البيانات قم بتشغيل نفس الطلب بقيم إدخال متعددة باستخدام ملفات CSV أو JSON. هذا يكتشف الحالات الاستثنائية (edge cases).

3. ابقِ الأسرار خارج نظام التحكم في الإصدار قم بتخزين مفاتيح ورموز API في ملفات البيئة، وليس في صادرات المجموعات (collection exports).

4. قم بتشغيل الاختبارات بشكل متكرر يوميًا أو كل ساعة، وليس فقط قبل الإصدارات. الاكتشاف المبكر يمنع الأخطاء المكلفة.

5. توثيق السلوك المتوقع اترك تعليقات في طلباتك واختباراتك تشرح ما الذي يتم التحقق منه.

الخاتمة

يقوم Postman بتحويل اختبار API من النقر اليدوي إلى التحقق الآلي. ابدأ بكتابة اختبارات لنقاط النهاية (endpoints) الحرجة. ثم انتقل إلى الإعدادات المعتمدة على البيئة (environment-driven) التي تعمل عبر بيئات التطوير/التجهيز/الإنتاج. قم بالدمج مع CI/CD عبر Newman بحيث يتم تشغيل الاختبارات مع كل عملية رفع كود (commit).

مع تطورك، فكر في اختبار العقود (contract testing) لاكتشاف التغييرات التي قد تسبب أعطالاً، واستخدام الخوادم الوهمية (mock servers) لتمكين التطوير المتوازي. وتذكر: Postman هو أداة واحدة من بين عدة خيارات قوية. خطة Postman المجانية أصبحت الآن محدودة لمستخدم واحد فقط اعتباراً من مارس 2026 — الفرق الصغيرة التي كانت تعتمد سابقاً على التعاون المجاني قد ترغب في موازنة فئات Solo و Team مقابل البدائل مفتوحة المصدر مثل Bruno أو Hoppscotch المستضاف ذاتياً. اختر بناءً على سير عمل فريقك، ومتطلبات التخزين، والميزانية — وليس الارتباط العاطفي بأي منصة معينة.

الاختبار الآلي أمر لا يقبل التفاوض. أياً كان العميل (client) الذي تختاره، فإن الأنماط الواردة في هذا الدليل — التأكيدات (assertions)، ومتغيرات البيئة، والخوادم الوهمية، وتكامل CI، واختبارات العقود — تنطبق عليها جميعاً.