ما هو API Testing؟ شرح عملي للمبتدئين

ما هو API Testing؟

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

ماذا لو ظهرت رسالة النجاح، لكن السعر المحسوب كان خطأ؟ أو استطاع مستخدم مشاهدة طلبات شخص آخر؟ هنا يأتي دور اختبار واجهات برمجة التطبيقات (API Testing).

أولًا، ما هو الـAPI؟

اختصار API يعني Application Programming Interface، أي «واجهة برمجة التطبيقات». وهي وسيلة تتيح للبرامج والمكوّنات التواصل وتبادل البيانات وفق قواعد محددة.

في تطبيق التوصيل مثلًا، يمكن استخدام الـAPI لجلب قائمة الطعام، وإنشاء طلب جديد، والاستعلام عن حالة التوصيل.

واجهة المستخدم تعرض المعلومات والأزرار، بينما يتيح الـAPI الوصول إلى العمليات والبيانات التي تقف خلفها. وسنركّز في هذا المقال على واجهات الويب التي تستخدم HTTP.

ماذا نختبر في API Testing؟

نرسل طلبًا مباشرة إلى الـAPI، ثم نتحقق من الاستجابة والسلوك الناتج عنه، وفق متطلبات النظام.

لا يقتصر الاختبار على سؤال: «هل وصل الرد؟»، بل يشمل:

• صحة البيانات: هل القيم والحسابات صحيحة؟
• قواعد العمل: هل يمنع النظام إنشاء طلب بكمية غير مقبولة؟
• الصلاحيات: هل يصل المستخدم إلى البيانات المسموحة له فقط؟
• معالجة الأخطاء: هل يتعامل النظام بوضوح مع البيانات الناقصة؟
• الأثر الفعلي: هل حُفظ الطلب فعلًا وبالبيانات الصحيحة؟

ويمكن تنفيذ هذه الاختبارات يدويًا أو أتمتتها.

كيف يعمل الطلب والاستجابة؟

يرسل التطبيق Request إلى الخادم، ثم يستقبل Response.

يتكوّن الطلب عادةً من:

• Endpoint: عنوان العملية المطلوبة، مثل /orders.
• Method: نوع العملية؛ مثل GET لاسترجاع البيانات، أو POST لإرسال بيانات لمعالجتها، وغالبًا لإنشاء مورد جديد.
• Headers: معلومات مرافقة، مثل نوع المحتوى وبيانات المصادقة.
• Body: البيانات التي تحتاجها العملية، مثل الصنف والكمية، إن كان الطلب يتطلبها.

أما الاستجابة فتتضمن كود حالة Status Code، وترويسات، وقد تتضمن بيانات أو تفاصيل خطأ.

مثال عملي من تطبيق توصيل

لنفترض أن سعر الوجبة 5 دنانير، ورسوم التوصيل ديناران، دون ضرائب أو خصومات إضافية.

عند طلب وجبتين، يكون الإجمالي المتوقع:

وجبتان × 5 دنانير + ديناران للتوصيل = 12 دينارًا.

بعد إرسال طلب إنشاء الطلب، لا تكتفِ بظهور رسالة نجاح. تحقق من أن:

1. الكمية المسجّلة تساوي وجبتين.
2. الإجمالي يساوي 12 دينارًا وبالعملة الصحيحة.
3. الطلب مرتبط بحساب المستخدم الصحيح.
4. يمكنك استرجاع الطلب بعد إنشائه وتجد بياناته محفوظة.

ثم جرّب حالات غير صحيحة: ماذا يحدث إذا كانت الكمية صفرًا؟ أو كان الصنف غير موجود؟ أو أُرسل الطلب دون تسجيل الدخول رغم أن العملية تتطلب ذلك؟

حدّد النتيجة المتوقعة من المتطلبات قبل تنفيذ الاختبار.

هل كود 200 يعني أن الاختبار نجح؟

لا، ليس وحده. كود 200 OK يشير إلى نجاح الطلب على مستوى HTTP، لكنه لا يثبت صحة جميع البيانات وقواعد العمل.

قد يستجيب النظام بكود 200، لكنه يعيد إجماليًا خاطئًا أو بيانات مستخدم آخر. وقد يكون الكود المتوقع أصلًا 201 Created إذا كانت العملية تنشئ موردًا جديدًا.

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

هل يغني اختبار API عن اختبار الواجهة؟

كل منهما يكشف أخطاء مختلفة.

قد يحسب الـAPI السعر بشكل صحيح، بينما تعرض الشاشة قيمة قديمة. وقد تمنع الشاشة إدخال كمية سالبة، لكن الخادم يقبلها عند إرسال الطلب مباشرة.

اختبار API يفحص العمليات والبيانات، واختبار الواجهة يفحص العرض والتفاعل؛ وتحتاج المسارات المهمة إلى التحقق من عملهما معًا.

كيف تبدأ؟

ابدأ بأداة مثل Postman، وبواجهة موثّقة في بيئة اختبار:

1. اختر عملية بسيطة لاسترجاع بيانات.
2. اقرأ متطلباتها وحدّد النتيجة المتوقعة.
3. أرسل الطلب وافحص الكود والبيانات.
4. غيّر أحد المدخلات وراقب طريقة التعامل مع الخطأ.
5. وثّق أي فرق بين النتيجة المتوقعة والفعلية.

يمكنك البدء دون كتابة كود، ثم تعلّم إضافة Assertions للتحقق من النتائج تلقائيًا.

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