Postman اتعلم إزاي تطور مهاراتك في اختبار الـ API

ملخص

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

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

لقد كان Postman هو المعيار الفعلي لاختبار API منذ إطلاقه. وفي عام 2026، لا يزال قويًا ولكنه يواجه منافسة من بدائل أخف مثل Bruno وHoppscotch وInsomnia. إن فهم 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 يتم تشغيله بعد وصول الاستجابة.

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

في علامة التبويب "Tests" في Postman، تكتب التوكيدات التي تتحقق من صحة الاستجابة.

// 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.expect(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@v3

      - 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@v3
        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);
});

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

بدائل Postman

بينما يهيمن Postman، تقدم البدائل مقايضات مختلفة:

Bruno

• مفتوح المصدر، صديق لـ git، يخزن الطلبات كملفات نصية عادية.
• مثالي إذا كان فريقك يفضل التحكم في الإصدار (version control) على المزامنة السحابية.
• خفيف الوزن ويعمل دون اتصال بالإنترنت.

Hoppscotch

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

Insomnia

• تطبيق مكتبي، مشابه لـ Postman، تكامل قوي مع Kong.
• جيد للفرق التي تستخدم بالفعل بوابات API من Kong.
• يتوفر بنسخ مجانية ومدفوعة.

Thunder Client

• إضافة لـ VS Code، خفيف الوزن وسريع.
• مثالي إذا كنت تقضي معظم وقتك في VS Code.
• مجتمع متنامٍ، ولكنه محدود مقارنة بـ Postman.

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

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

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

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

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

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

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

الخلاصة

يحول Postman اختبار API من النقر اليدوي إلى التحقق المؤتمت. ابدأ بكتابة اختبارات لنقاط النهاية الحرجة. انتقل إلى الإعدادات المعتمدة على البيئة التي تعمل عبر بيئات التطوير/الاختبار/الإنتاج. ادمجها مع CI/CD عبر Newman بحيث تعمل الاختبارات مع كل عملية رفع كود.

مع نموك، فكر في اختبار العقود لاكتشاف التغييرات الجذرية، وخوادم المحاكاة لفتح الطريق للتطوير المتوازي. وتذكر: Postman هو أداة واحدة فقط. Bruno وHoppscotch وغيرهما لكل منها نقاط قوتها. اختر بناءً على سير عمل فريقك، وليس بناءً على التعلق بأي منصة واحدة.

الاختبار المؤتمت أمر لا غنى عنه. وPostman يجعله متاحًا وقويًا.