دليل اختبار واجهة برمجة تطبيقات REST: نماذج لحالات اختبار يدوية
فريق التحرير
⚡ ملخص ذكي
يقوم اختبار واجهة برمجة تطبيقات REST بالتحقق من صحة خدمات الويب RESTful عن طريق إرسال طلبات HTTP مثل GET و POST و PUT و DELETE، ثم التحقق من رمز الحالة وعناوين الاستجابة والحمولة التي أعادها الخادم.
ما هو اختبار REST API؟
اختبار واجهة برمجة تطبيقات REST هي تقنية مفتوحة المصدر لاختبار أتمتة الويب، تُستخدم لاختبار واجهات برمجة تطبيقات RESTful لتطبيقات الويب. يهدف اختبار واجهات برمجة تطبيقات REST إلى تسجيل استجابتها عبر إرسال طلبات HTTP/S متعددة للتحقق من سلامة عملها. ويتم ذلك باستخدام طرق GET وPOST وPUT وDELETE.
REST تعني Representational State Transfer (نقل الحالة التمثيلية). وهو أسلوب معماري ونهج للتواصل يستخدم في تطوير خدمات الويبلقد أصبح REST خيارًا منطقيًا لبناء واجهات برمجة التطبيقات (APIs)، لأنه يمكّن المستخدمين من الاتصال والتفاعل مع الخدمات السحابية بكفاءة.
واجهة برمجة التطبيقات (API) هي مجموعة من تعليمات البرمجة للوصول إلى تطبيق برمجي قائم على الويب. بعبارة أخرى، هي مجموعة من الأوامر التي يستخدمها برنامج للتواصل مع برنامج آخر مباشرةً، والاستفادة من وظائف كل منهما للحصول على المعلومات.
على سبيل المثال، Google يمكن أن يحتوي الموقع الإلكتروني على واجهة برمجة تطبيقات (API) للبحث والترجمة والتقويم. بشكل عام، تبدو واجهات برمجة التطبيقات كما في المثال أدناه، مع اسم الخادم والمسارات والمعلمات.
http://<server name>/v1/export/Publisher/Standard_Publisher_Report?format=csv
لكن لماذا يتم استثمار جهد الاختبار في هذه الطبقة على الإطلاق؟
لماذا يُعد اختبار واجهات برمجة تطبيقات REST أمرًا مهمًا؟
تقع واجهة برمجة تطبيقات REST بين واجهة المستخدم وقاعدة البيانات، مما يجعلها الطبقة التي تحتوي على معظم منطق الأعمال. يظهر أي خلل في قاعدة التسعير أو التحقق من الأذونات في استجابة واجهة برمجة التطبيقات قبل أن يلاحظ أي شخص رقمًا خاطئًا على الشاشة، لذا فإن الاختبار هنا يكشف المشاكل مبكرًا وبالقرب من سببها.
السرعة هي السبب الثاني. يتم إكمال الطلب في أجزاء من الثانية، ولا يحتاج إلى متصفح أو محرك عرض أو محددات عناصر حساسة. يمكن للمختبِر اختبار عشرات نقاط النهاية في الوقت الذي يستغرقه اختبار واجهة واحد لتحميل صفحة، ويتصرف الطلب نفسه بنفس الطريقة سواءً كانت الواجهة الأمامية موقع ويب أو تطبيق جوال أو تكاملًا مع شريك.
الاستقرار هو السبب الثالث. تتغير التصاميم باستمرار، ولكن بنية REST المنشورة تبقى ثابتة.tracمن المتوقع أن يظل ثابتًا. الاختبارات التي كُتبت بناءً على ذلكtracلا تصمد أمام عمليات إعادة التصميم، لذا فهي تحمي أجزاء المنتج التي تبني عليها الفرق الأخرى بالفعل.
أنواع طرق API
هناك 4 أنواع رئيسية من اختبار API الطرق: GET، POST، DELETE، و PUT.
- للحصول على– تُستخدم طريقة GET لـtracمعلومات من الخادم المحدد باستخدام عنوان URI محدد. عند استخدام طلب GET، يجب أن يقتصر علىtracبيانات t ولا ينبغي أن يكون لها أي تأثير آخر على البيانات.
- سأعين- يتم استخدام طلب POST لإنشاء كيان جديد. ويمكن استخدامه أيضًا لإرسال البيانات إلى الخادم، على سبيل المثال، معلومات العميل وتحميل الملفات وما إلى ذلك باستخدام نماذج HTML.
- ضع– إنشاء كيان جديد أو تحديث كيان موجود.
- حذف– إزالة كافة التمثيلات الحالية للمورد الهدف المقدم بواسطة URI.
كيفية اختبار REST API
يتطلب اختبار واجهة برمجة تطبيقات REST تفاعل التطبيق مع نموذج لواجهة برمجة التطبيقات لأغراض الاختبار. لاختبار واجهة برمجة تطبيقات، تحتاج إلى أمرين:
- أداة/إطار عمل الاختبار لقيادة واجهة برمجة التطبيقات
- قم بتدوين التعليمات البرمجية الخاصة بك لاختبار نموذج REST API
يمكن اختبار حالات اختبار واجهة برمجة تطبيقات REST باستخدام أدوات مثل:
- عميل الراحة المتقدم
- Postman-راحة العميل
- حليقة في لينكس
سنستخدم هنا برنامج Advanced Rest Client. فيما يلي خطوات الحصول على برنامج Advanced Rest Client.
كيفية الحصول على عميل REST المتقدم؟
- انتقل إلى البرنامج المساعد في التأليف Google Chromeمتجر الويب
- ابحث عن "Advanced Rest Client" أو انتقل مباشرة اضغط هنا وتثبيت الامتداد
- حدد أيقونة "Advanced Rest Client" ضمن قسم تطبيقات Chrome - chrome://apps/
تظهر قائمة المتجر الإلكتروني كما هو موضح أدناه.
بعد اكتمال التثبيت، اتبع الاختبار أدناه لاختبار RESTful API.
خطوات اختبار REST API
نستخدم هنا إضافة عميل REST في متصفح Chrome. ولتوضيح الأمر، نستخدم واجهة برمجة تطبيقات وهمية لأغراض الاختبار.
http://ip.jsontest.com/
الخطوة 1) افتح عميل REST المتقدم
قم بتشغيل التطبيق عميل REST المتقدم (ARC)، بمجرد تثبيته بنجاح.
الخطوة الثانية) أدخل URL واجهة برمجة التطبيقات للاختبار
أدخل نموذج واجهة برمجة تطبيقات REST URL للاختبار في URL مربع الكتابة.
الخطوة 3) حدد طريقة HTTP
حدد الطريقة الخاصة بنوع أساليب HTTP في اختبار API للوصول إلى POST على سبيل المثال
الخطوة 4) توفير مجموعة الرؤوس
قم بتوفير مجموعة الرؤوس في مربع نص الرؤوس. انقر فوق إدراج مجموعة الرؤوس.
الخطوة 5) تأكيد مجموعة الرؤوس
التالي انقر على استخدام هذه المجموعة.
الخطوة 6) توفير محتوى الجسم المطلوب
- انتقل الآن إلى علامة التبويب Body.
- قم بتعيين نوع محتوى النص المطلوب وعرض المحرر، على سبيل المثال نوع محتوى النص: application/json
- عرض المحرر: الإدخال الخام.
- ضمن قسم "الحمولة"، مرر نص طلب واجهة برمجة التطبيقات التجريبية للاختبار على شكل أزواج مفتاح-قيمة، على سبيل المثال {"key1":"value1","key2":"value2"}. إذا كانت واجهة برمجة التطبيقات من نوع POST، فسنحتاج إلى تمرير نص الطلب أو المعاملات. سنمررها ضمن الحمولة المحددة.
{"property" : ["Sites"], "report_type" : ["ALL"]}
⚠️ تحذير: نوع المحتوى application/json مع حمولة غير صالحة JSON يُرجع الخطأ 400 طلب غير صالح.
الخطوة 7) قم بإرسال التفاصيل لبدء الاختبار
- اضغط على زر الإرسال.
- بإمكانك الضغط على زر التفاصيل لرؤية رؤوس الاستجابات.
وفيما يلي تفاصيل الرد:
لا يزال يتعين تقييم الاستجابة في ضوء النتيجة المتوقعة.
التحقق من صحة النتائج
بشكل أساسي، بالنسبة لاختبار واجهة برمجة تطبيقات الويب، نحتاج إلى التحقق من رمز الاستجابة ورسالة الاستجابة وجسم الاستجابة.
تنقسم رموز الاستجابة إلى خمس مجموعات:
| العائلة | الفئة | معنى |
|---|---|---|
| 1xx | معلوماتية | تم الاستلام، ولا يزال قيد المعالجة |
| 2xx | للنجاح | تم الانتهاء؛ 200 موافق، 201 تم الإنشاء |
| 3xx | إعادة توجيه | يلزم اتخاذ إجراء إضافي |
| 4xx | خطأ العميل | حمولة أو رمز أو مورد غير صالح |
| 5xx | خطأ في الخادم | طلب صحيح، فشل الخادم |
فيما يلي رموز الاستجابة التي قد يواجهها المرء.
يُثبت طلب واحد أن نقطة النهاية تعمل. وتُثبت مجموعة من الطلبات أنها تستمر في العمل.
حالات اختبار واجهة برمجة تطبيقات REST التي يجب عليك تغطيتها
تتوزع مجموعة واجهات برمجة تطبيقات REST المفيدة عبر عدة فئات بدلاً من تكرار نفس الاستدعاء الناجح ببيانات مختلفة:
- المسار السعيد: أرسل طلبًا صحيحًا إلى كل نقطة نهاية وقم بتأكيد رمز الحالة والمخطط وقيمة كل حقل.
- الحالات السلبية: إرسال JSON غير صحيح، وطريقة غير مدعومة، ومعرف مورد مفقود، ثم توقع 400 و405 و404 بدلاً من 500.
- قيم الحدود: إذا كان الحقل يقبل من 1 إلى 200 حرف، فقم باختبار 0 و1 و200 و201. قواعد التحقق من الصحة تتعطل عند الحدود.
- الأحرف الخاصة: قم بتمرير الأحرف المميزة والرموز التعبيرية وعلامات الاقتباس والنصوص متعددة البايتات عبر كل حقل للكشف عن أخطاء الترميز.
- معtract checks: قارن الاستجابة بمواصفات OpenAPI أو Swagger المنشورة حتى يتم اكتشاف التغييرات غير الموثقة مبكراً.
- التسلسل: قم باستدعاء نقاط النهاية بترتيب واقعي، مثل POST ثم GET ثم DELETE، لأن الحالة تنتقل بين الاستدعاءات.
- سلامة الأداء: سجل أوقات الاستجابة في كل عملية تشغيل وقم بالإبلاغ عن أي نقطة نهاية تتجاوز الحد المتفق عليه مع الفريق.
أداة اختبار REST API
تختلف الأدوات المناسبة باختلاف مراحل الاختبار.
| أداة | النوع | أفضل ل |
|---|---|---|
| عميل الراحة المتقدم | عميل سطح المكتب | مكالمات يدوية سريعة |
| Postman | عميل سطح المكتب | مجموعات ومساحات عمل جماعية |
| JMeter | اختبار الحمل | أوقات الاستجابة تحت الحمل |
| SoapUI | الاختبار الوظيفي | الراحة والصابون معاً |
| اطمئن، لا تشغل بالك | Java مكتبة | أتمتة الحالات المستقرة |
| cURL | سطر الأوامر | لصق المكالمات في تقارير الأخطاء |
اطلع على ملخص ما يلي: أدوات اختبار واجهة برمجة التطبيقات.
ترفض معظم نقاط النهاية الحقيقية الاستجابة حتى يثبت الطلب هوية مرسله.
التحقق من مصادقة واجهة برمجة تطبيقات REST وفحوصات الأمان
نقاط نهاية العرض التوضيحي العامة متاحة للجميع، لكن واجهة برمجة تطبيقات REST الإنتاجية تعتمد على نظام مصادقة، وأي خلل في المصادقة يُعدّ أكثر ضررًا من مجرد قيمة حقل خاطئة. حدد أولًا آلية المصادقة: مفتاح API ثابت، أو بيانات اعتماد HTTP الأساسية، أو رمز OAuth 2.0، أو رمز JSON Web Token موقّع.
بمجرد نجاح الطلب الموثق، تعامل مع مسارات الفشل بشكل متعمد:
- لا توجد بيانات اعتماد: قم بإزالة رأس Authorization. توقع ظهور رمز 401 غير مصرح به وعدم وجود بيانات سجل في نص الطلب.
- بيانات اعتماد غير صحيحة: حدث خطأ في أحد أحرف الرمز المميز. توقع ظهور رمز الخطأ 401 مرة أخرى، مع رسالة لا توضح السبب.
- بيانات اعتماد منتهية الصلاحية: إعادة استخدام رمز مميز بعد انتهاء صلاحيته. تأكيد رفضه بدلاً من قبوله، وهو عيب شائع في اختلال توقيت الساعة.
- مستوى الامتياز غير صحيح: قم بالمصادقة كمستخدم ذي صلاحيات محدودة واستدعِ نقطة نهاية مخصصة للمسؤولين فقط. توقع ظهور رمز الخطأ 403 (ممنوع)، وليس 200.
- سجل مستخدم آخر: قم بتغيير المعرّف بحيث يطلب المستخدم (أ) بيانات المستخدم (ب). النجاح هنا يُعدّ خللاً خطيراً في نظام التحكم بالوصول.
وأخيرًا، تأكد من أن كل مكالمة تمر عبر بروتوكول HTTPS، وأن الاستجابات الفاشلة لا تُسبب أي تسريب للبيانات. traces أو لافتات الإصدار، وأن التكرار السريع يؤدي إلى ظهور خطأ 429 Too Many Requests.
يُسبب اختبار واجهة برمجة تطبيقات REST أيضًا صعوبات لا يُسببها اختبار الواجهة.
تحديات اختبار API
تتمثل المشكلات المثيرة للاهتمام التي يواجهها المختبرون أثناء اختبار واجهة برمجة تطبيقات REST فيما يلي:
- لضمان أن يقوم نظام الاختبار بتغيير معلمات استدعاءات واجهة برمجة التطبيقات بطريقة تتحقق من الوظائف وتكشف عن حالات الفشل. يتضمن ذلك استكشاف الشروط الحدية وتعيين المعلمات المشتركة.
- إنشاء مجموعات قيمة معلمات مثيرة للاهتمام للمكالمات ذات معلمتين أو أكثر
- تحديد المحتوى الذي يجب إجراء استدعاءات واجهة برمجة التطبيقات (API) في إطاره. قد يشمل ذلك ضبط ظروف البيئة الخارجية (الأجهزة الطرفية، والملفات، وما إلى ذلك) بالإضافة إلى البيانات المخزنة داخليًا التي تؤثر على واجهة برمجة التطبيقات.
- تسلسل استدعاءات واجهة برمجة التطبيقات (API) وفقًا للترتيب الذي سيتم به تنفيذ الوظيفة
- لجعل واجهة برمجة التطبيقات (API) تنتج نتائج مفيدة من المكالمات المتتالية.
