أفضل أدوات اختبار API المعتمد على البيانات باستخدام CSV أو JSON

اختبار نقطة نهاية واجهة برمجة التطبيقات (API endpoint) لمرة واحدة أمر سهل ومباشر. تقوم بإرسال طلب، ومراجعة الاستجابة، والتأكد من أن كل شيء يعمل كما هو متوقع. يبدأ التحدي الحقيقي عندما تحتاج إلى تشغيل نفس الاختبار مقابل العشرات - أو حتى المئات - من مجموعات البيانات المختلفة. التحديث اليدوي للمعلمات وإرسال الطلبات بشكل متكرر ليس مضيعة للوقت فحسب، بل إنه عرضة للأخطاء ويستحيل توسيعه.

هنا يأتي دور اختبار واجهة برمجة التطبيقات المعتمد على البيانات (data-driven API testing). بدلاً من إعادة كتابة أو إعادة إرسال الطلبات يدويًا، يمكنك تحديد حالة اختبار واحدة وتشغيلها تلقائيًا باستخدام مجموعات متعددة من بيانات الإدخال. والنتيجة هي تغطية أوسع ودقة أعلى وجهد يدوي أقل بكثير.

للقيام بذلك بكفاءة، تحتاج إلى الأداة المناسبة. يبرز Apidog بتقديمه دعمًا أصليًا للاختبار المعتمد على البيانات باستخدام ملفات CSV و JSON. بصفته منصة شاملة لتطوير واختبار واجهة برمجة التطبيقات، يتيح لك Apidog ربط ملفات البيانات الخارجية بسيناريو اختبار وتنفيذه بشكل متكرر، مع التحقق من صحة كل استجابة تلقائيًا.

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

الآن، دعنا نتعمق في دليل كامل ومفصل خطوة بخطوة لإتقان اختبار واجهة برمجة التطبيقات المعتمد على البيانات باستخدام Apidog مع CSV و JSON.

دليل خطوة بخطوة لاختبار واجهة برمجة التطبيقات المعتمد على البيانات باستخدام CSV و JSON

دعنا نمر بالعملية بأكملها، من الإعداد إلى التنفيذ، باستخدام مثال ملموس. سنختبر نقطة نهاية واجهة برمجة تطبيقات لتسجيل المستخدمين.

الخطوة 1: تحديد طلب واجهة برمجة التطبيقات الأساسي الخاص بك

أولاً، تقوم بإنشاء طلب واجهة برمجة التطبيقات الذي سيكون بمثابة قالب الاختبار الخاص بك.

1. في Apidog، أنشئ طلبًا جديدًا لنقطة نهاية تسجيل المستخدمين (مثل POST /api/v1/users).
2. قم بإعداد الرؤوس (على سبيل المثال، Content-Type: application/json).
3. في علامة التبويب Body (الجسد)، أنشئ حمولة JSON الخاصة بك. بدلاً من ترميز القيم بشكل ثابت، ستستخدم بنية المتغيرات الديناميكية الخاصة بـ Apidog {{}} لإنشاء عناصر نائبة.

{
  "username": "{{username}}",
  "email": "{{email}}",
  "password": "{{password}}",
  "role": "{{role}}"
}

لاحظ العناصر النائبة: {{username}}، {{email}}، وما إلى ذلك. سيقوم Apidog باستبدال هذه بقيم فعلية من ملف البيانات الخاص بك أثناء التنفيذ.

الخطوة 2: إنشاء ملف بيانات الاختبار الخاص بك (CSV أو JSON)

الآن، أنشئ الملف الخارجي الذي سيغذي البيانات في العناصر النائبة الخاصة بك.

الخيار أ: استخدام ملف CSV

تنسيق CSV مثالي للبيانات الجدولية. أنشئ ملفًا باسم user_data.csv:

username,email,password,role,expected_status
john_doe,john@example.com,SecurePass123!,user,201
jane_smith,jane@example.com,AnotherPass456!,admin,201
bad_user,not-an-email,short,user,400
duplicate_user,john@example.com,SomePass789!,user,409

• يحدد الصف الأول أسماء المتغيرات التي تتطابق مع العناصر النائبة الخاصة بك (username، email، إلخ)، بالإضافة إلى expected_status إضافي للتحقق.
• كل صف لاحق هو حالة اختبار مع البيانات الخاصة بهذا التشغيل.

الخيار ب: استخدام ملف JSON

تنسيق JSON مثالي للهياكل المتداخلة أو الأكثر تعقيدًا للبيانات. أنشئ ملفًا باسم user_data.json:

[
  {
    "username": "john_doe",
    "email": "john@example.com",
    "password": "SecurePass123!",
    "role": "user",
    "expected_status": 201
  },
  {
    "username": "jane_smith",
    "email": "jane@example.com",
    "password": "AnotherPass456!",
    "role": "admin",
    "expected_status": 201
  },
  {
    "username": "bad_user",
    "email": "not-an-email",
    "password": "short",
    "role": "user",
    "expected_status": 400
  }
]

الخطوة 3: تكوين الاختبار المعتمد على البيانات في Apidog

هنا تظهر قوة سير عمل Apidog المتكامل.

1. انتقل إلى علامة التبويب "Test" (اختبار) داخل لوحة التحكم الخاصة بك (أو أنشئ حالة اختبار جديدة في مجموعة اختبار).

2. انقر لإضافة خطوة اختبار جديدة وحدد طلب POST /api/v1/users الخاص بك.

3. تحميل بيانات الاختبار: انقر على "Test Data" (بيانات الاختبار) > "+New" (جديد) لتحميل ملف user_data.csv أو user_data.json الخاص بك. سيقوم Apidog بتحليله وعرض معاينة لصفوف البيانات.

4. ربط المتغيرات (إذا لزم الأمر): يقوم Apidog تلقائيًا بربط أسماء الأعمدة (CSV) أو مفاتيح الخصائص (JSON) بالعناصر النائبة {{variable}} في طلبك. تحقق من صحة عملية الربط.

الخطوة 4: كتابة تأكيدات باستخدام متغيرات البيانات الخاصة بك

تأتي القوة الحقيقية من التحقق من النتائج المتوقعة المختلفة بناءً على بيانات الإدخال الخاصة بك. في علامة التبويب Test، تكتب تأكيدات (assertions) (تسمى أيضًا "asserts" أو "checks").

الأهم من ذلك، يمكنك الإشارة إلى نفس متغيرات البيانات من ملفك في تأكيداتك.

على سبيل المثال، أضف تأكيد Response Status Code (رمز حالة الاستجابة):

• القيمة المتوقعة (Expected Value): {{expected_status}}

هذا يعني: "لتشغيل الاختبار الأول (john_doe)، تأكد من أن رمز الحالة يساوي 201. وللتشغيل الثالث (bad_user)، تأكد من أنه يساوي 400." يتغير التأكيد ديناميكيًا مع كل تكرار.

يمكنك إضافة تأكيدات أكثر تعقيدًا باستخدام JavaScript في قسم Script في Apidog:

// مثال: التحقق من نص الاستجابة لعملية إنشاء ناجحة
pm.test("رمز الحالة هو " + pm.variables.get("expected_status"), function () {
    pm.response.to.have.status(pm.variables.get("expected_status"));
});

// تحقق من معرف المستخدم فقط إذا كنا نتوقع إنشاء ناجحًا
if (pm.variables.get("expected_status") === 201) {
    pm.test("الاستجابة تحتوي على معرف المستخدم", function () {
        var jsonData = pm.response.json();
        pm.expect(jsonData.id).to.be.a('number');
        pm.expect(jsonData.username).to.eql(pm.variables.get("username"));
    });
}

الخطوة 5: تشغيل الاختبار وتحليل النتائج

انقر على زر Run (تشغيل). سيقوم Apidog بتنفيذ خطوة الاختبار الواحدة الخاصة بك عدة مرات، مرة واحدة لكل صف في ملف البيانات الخاص بك.

التقرير هو حيث تتجمع كل الأمور:

يقدم Apidog تقريرًا واضحًا ومجمعًا يوضح:

• إجمالي التكرارات: (على سبيل المثال، "4/4 اجتاز")
• تفاصيل لكل صف بيانات: يمكنك التوسيع لرؤية الطلب الدقيق الذي تم إرساله (بالقيم الفعلية المستبدلة) والاستجابة التي تم تلقيها لهذا التكرار المحدد.
• يتم تحديد أي أخطاء إلى صف البيانات المحدد الذي تسبب في المشكلة. هل فشل duplicate_user لأن الحالة لم تكن 409؟ سترى ذلك على الفور.

هذا يجعل تصحيح الأخطاء فعالاً بشكل لا يصدق. لا يتعين عليك تخمين أي حالة اختبار فشلت؛ أنت تعلم أنها كانت التكرار مع مجموعة البيانات المحددة {"username": "duplicate_user", ...}.

أفضل الممارسات لاختبار واجهة برمجة التطبيقات المعتمد على البيانات

1. بيانات خاصة بالبيئة: ادمج الاختبار المعتمد على البيانات مع البيئات (Environments) في Apidog. قد يكون لديك متغير base_url في بيئتك يتغير من مرحلة التجريب (staging) إلى مرحلة الإنتاج (production)، بينما يحتوي ملف CSV الخاص بك على حالات الاختبار القابلة للتطبيق على كليهما.
2. بيانات اختبار قابلة لإعادة الاستخدام: قم بتخزين ملفات CSV/JSON الخاصة بك في مكان مركزي داخل مشروع Apidog الخاص بك. يمكن لمجموعات اختبار متعددة الإشارة إلى نفس ملف البيانات، مما يضمن الاتساق.
3. إنشاء ملفات البيانات برمجيًا: للسيناريوهات المعقدة، استخدم سكريبت (Python، Node.js) لإنشاء ملف test_data.csv الخاص بك. هذا ممتاز للاختبار ببيانات عشوائية أو نطاق واسع من القيم (على سبيل المثال، اختبار الترقيم مع 100 تركيبة مختلفة من page و limit).
4. إعداد/تنظيف الاختبار: استخدم سكريبتات ما قبل الطلب (pre-request scripts) وميزات إزالة الاختبار (test teardown features) في Apidog بالتزامن مع الاختبارات المعتمدة على البيانات. على سبيل المثال، قبل كل تكرار لاختبار DELETE، يمكنك استخدام سكريبت ما قبل الطلب لإنشاء المورد الذي سيتم حذفه.

الخلاصة: تحويل سير عمل اختبار واجهة برمجة التطبيقات الخاص بك

ينقلك الاختبار المعتمد على البيانات في Apidog باستخدام ملفات CSV/JSON من التحقق اليدوي المتكرر إلى التحقق الشامل الآلي. إنه يجسد المبدأ الأساسي للاختبار الجيد: أن تكون دقيقًا دون التضحية بالكفاءة.

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

توقف عن اختبار واجهات برمجة التطبيقات حالة واحدة تلو الأخرى. قم بتنزيل Apidog مجانًا اليوم، واستورد أول ملف CSV الخاص بك، واختبر مدى قوة وفعالية اختبار واجهة برمجة التطبيقات حقًا.