اختبار REST API باستخدام Postman مشروحاً

يواجه تطوير البرمجيات نموًا هائلًا – إذ يتزايد الطلب على التطبيقات، وتتكرر الإصدارات بشكل أكبر، ويجب الحفاظ على جودتها عند مستوى مقبول. لذلك، يجب أن يضمن فريق ضمان الجودة أن التطبيق يعمل بالشكل المتوقع.

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

بعد إجراء الاختبارات من قبل المطوّر، يحين وقت قيام فريق ضمان الجودة (QA) باختبار وظائف واجهات التطبيق. وهناك الكثير من التوليفات المختلفة مع تقنيات وأدوات متنوعة. في مقال اليوم، سنركّز على اختبار واجهات برمجة التطبيقات (API Testing) مع التركيز على REST API وPostman.

ما هو API ولماذا نحتاجه؟

تخيّل أن لديك جهاز اتصال لاسلكي (walkie-talkie)، وصديقك على الطرف الآخر. تضغط على ذلك الزر، فيصل صوتك إليه، وتسأله إن كانت تمطر في الخارج. يسمع صوتك ويتحقق مما إذا كانت تمطر. وبمجرد أن يعرف الإجابة، يضغط على زر ويرسل معلومات الطقس إليك. يمكن تشبيه API بجهاز الاتصال اللاسلكي الذي يتيح التواصل ثنائي الاتجاه. وبالطبع، الفكرة أكثر تعقيدًا بكثير، لكنني آمل أن تكون قد فهمت المقصود.

API هو اختصار لـ "واجهة برمجة التطبيقات". يؤدي ربط التطبيقات من خلال واجهات API إلى تبسيط تبادل البيانات بين التطبيقات، مما يؤدي إلى زيادة الإنتاجية والإيرادات.

اختبار API هو نوع مكمّل لكل من: اختبار الوحدات واختبار من طرف إلى طرف (E2E). يوفر اختبار API رؤية للمشكلة المحتملة مبكراً في دورة حياة تطوير البرمجيات (SDLC).

عادةً ما تتكون تطبيقات الويب من ثلاث طبقات: واجهة المستخدم (UI)، ومنطق الأعمال، وقاعدة البيانات. ويُجرى اختبار الوحدات على مستوى منطق الأعمال. ولا يمكن إجراء اختبار E2E إلا عند وجود الطبقات الثلاث جميعها. أما اختبار API فيمكن إجراؤه في وقت أبكر لأنه نوع من الاختبارات لا يحتاج إلى واجهة المستخدم، ويمكن تجاوزها.

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

يُستخدم API للتواصل بين التطبيقات ويعمل بالطريقة التالية:

بفضل طريقة الاتصال ونقل البيانات هذه، يتم ضمان الأمان. ويتحقق ذلك من خلال تضمين بيانات اعتماد التفويض اللازمة لتلك الطلبات.

تستخدم واجهة برمجة التطبيقات (API) البروتوكولات الأكثر شيوعاً، مثل SOAP وREST وغيرها. يعتمد SOAP (بروتوكول الوصول البسيط للكائنات) على XML وهو مدفوع بالوظائف. أما REST (نقل الحالة التمثيلي) فيعتمد على HTML. وهو يهيكل بياناته بصيغ XML وYAML وJSON وهو مدفوع بالبيانات. كما يدعم صيغ OpenAPI وSwagger وRAML. وأكثر طلبات REST HTTP شيوعاً هي POST وGET وPUT وDELETE.

عند تحديد البروتوكول الذي ستستخدمه لبناء واجهة برمجة التطبيقات (API) الخاصة بك، يجب أن تأخذ في الاعتبار الميزات أو المزايا التي تحتاجها أكثر من غيرها. تشمل ميزات SOAP التوحيد القياسي والأمان المعزز، بينما تتمثل خصائص REST في المرونة والكفاءة.

اختبار REST API باستخدام Postman

يُستخدم اختبار API للتحقق من صحة واجهات API، حيث يفحص الوظائف والموثوقية والأداء والأمان. يتم إجراء اختبار API عبر عنوان URL، الذي يستدعي نقطة نهاية API. وتُسمى هذه الاستدعاءات Requests. وبعد إرسال Request، ينبغي أن نتوقع استلام Response. ثم تتم مقارنة الاستجابة بالنتائج المتوقعة.

يأتي الطلب بأنواع متنوعة – GET وPOST وPUT وPATCH وDELETE وCOPY وHEAD وOPTIONS وLINK وUNLINK وPURGE وLOCK وUNLOCK وPROPFIND وVIEW. أما الأكثر استخدامًا فهي GET وPOST وPUT وDELETE.

يُستخدم طلب GET للحصول على البيانات من عنوان URL المشترك (نقطة النهاية). لا يتم إجراء أي تغييرات على نقطة النهاية.

يُستخدم طلب POST لإرسال البيانات إلى نقطة النهاية.

يقوم طلب PUT بإنشاء أو تحديث مورد موجود في نقطة النهاية.

يُستخدم طلب DELETE لحذف البيانات على نقطة النهاية.

تُرسَل البيانات إلى نقطة نهاية API عبر URL ونوع الطلب المناسب. ويجب أن تحتوي الاستجابة، بمجرد استلامها، على رمز يبدأ بـ 2**، مما يعني أن الحالة سليمة (OK). ثم يتم التحقق من الاستجابة عبر اختبار.

هناك العديد من الأدوات المستخدمة لاختبار API – مثل Katalon Studio وPostman وApigee وJMeter وRest-assured وAssertible وSoap UI وKarate DSL وRest Console وAPI Fortress وPyresttest وHoppscotch وTaurus وCitrus Framework وAirborne، على سبيل المثال لا الحصر. ولن نشرح كل واحدة منها، ولكن على سبيل المثال، سنكتفي بـ Postman.

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

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

سيكون تركيزنا على مجال الاختبار.

في البداية، نستخدم Swagger كنقطة استدلال لنقاط النهاية المتاحة، وننشئ الطلبات في Postman. بعد إعداد الطلب، نضغط على زر "Send". يجب أن نحصل على الاستجابة بعد وقت قصير. يجب أن تحتوي الاستجابة على "Status: 200 OK" أو رمز حالة مشابه يبدأ بـ "2". في منطقة Body الخاصة بالاستجابة، يجب أن تكون هناك، في معظم الحالات، بعض البيانات التي تم استلامها من الخادم. يتم اختبار هذه البيانات في منطقة Tests في Postman.

هناك الكثير من الأمثلة على الويب يمكنك تعديلها واستخدامها في اختبارات Postman الخاصة بك.

الاختبار الأساسي – التحقق من حالة الاستجابة هو:

pm.test("حالة الاستجابة"، function () {
 pm.response.to.have.status(200);
 });

هناك أيضًا اختبارات تتحقق من منطقة الجسم:

pm.test(“يجب أن تحتوي الاستجابة على”, function () {

pm.response.to.have.jsonBody("[response_data0:]");

pm.response.to.have.jsonBody("[response_data1:]");

pm.response.to.have.jsonBody("[response_data2:]");

});

في تلك الاختبارات، يمكنك استخدام المتغيرات لتخزين البيانات المكتسبة واستخدامها في اختبار آخر كمدخل ديناميكي. يتم تخزين المتغيرات أو المعاملات بالتنسيق التالي: {{variable}}.

يمكن أتمتة اختبارات API، وينبغي أن تغطي بعض طرق الاختبار من دورة حياة تطوير البرمجيات (SDLC)، بما في ذلك: اختبار الاكتشاف، واختبار قابلية الاستخدام، واختبار الأمان، والاختبار الآلي، والتوثيق.

هناك طرق متنوعة عديدة لاستخدام الاختبارات. ونحن نصف بعضًا منها في القسم التالي.

خط أنابيب CI/CD

بمجرد إعدادها، يمكن استخدام اختبارات API بشكل أوسع. أحد الاحتمالات هو استخدامها في خط أنابيب CI/CD الخاص بك. ما هو خط أنابيب CI/CD؟

CI اختصار لـ Continuous Integration (التكامل المستمر). خط أنابيب CI/CD هو سلسلة من الخطوات الآلية لتسليم أحدث إصدار من البرمجيات. في بعض الأحيان تكون هناك حاجة لتنفيذ خطوات معينة يدويًا وهذا ممكن أيضًا. القوة الحقيقية لخط أنابيب CI/CD تكمن في أتمتته. يمكن العثور على مزيد من التفاصيل حول خط أنابيب CI/CD في مواد DevOps.

إذا أردنا وضع اختبارات معينة في تلك السلسلة، يمكننا أيضاً استخدام اختبارات API التي أنشأناها بالفعل في Postman. وينبغي تنظيم تلك الاختبارات بترتيب منطقي. وقبل تضمينها في السلسلة، ينبغي اختبارها في Postman’s Runner وألا تحتوي على أي أخطاء.

بعد التأكد من أن كل شيء يعمل بشكل صحيح، يمكننا تصدير البيانات من Postman – يجب أن تكون لدينا ملفات Collections.json وEnvironment.json.

لتشغيل Postman Collection.json وEnvironment.json، يجب علينا تثبيت Newman. يمنحنا Newman القدرة على استخدام اختبارات Postman API في خط أنابيب CI/CD.

للبدء، قم بتثبيت nodejs. بعد ذلك، في سطر الأوامر، شغّل "npm install -g newman”.

يجب وضع هذين الملفين اللذين قمنا بتصديرهما من Postman سابقًا معًا في نفس المسار.

بعد ذلك، شغّل ذلك باستخدام Newman.

يمكنك القيام بذلك باستخدام "newman run [collection name] -e [collection environment]” حيث “-e” يشير إلى معامل البيئة.

إلى جانب Newman، يمكننا أيضاً استخدام أدوات CI/CD مثل TeamCity وJenkins وغيرها.

إذا كنت ترغب في استخدام Jenkins بدلاً من ذلك، فهناك خطوات معينة يجب اتباعها. أولاً، يجب تثبيت Jenkins وتشغيله. يجب إعداد مهمة Jenkins كمشروع Freestyle. ثم أضف خطوة بناء تنفّذ أمر shell يستدعي نص الاختبار.

للحصول على جميع التفاصيل حول كيفية إعداد ذلك، يرجى البحث عن دروس تعليمية متخصصة حول Newman أو Jenkins.

رموز استجابة الخادم الشائعة

تتراوح رموز استجابة الخادم لواجهة REST API بين 100 و500. وتحتوي على "رموز فرعية" توفر شرحًا أكثر تحديدًا، لكننا لن نتعمق إلى هذا الحد في هذه المقالة. على سبيل المثال، في سلسلة 400، يعرف الجميع الرمز "404 – Not Found".

ستجد أدناه نظرة عامة على الرموز:

1** – استجابات مؤقتة مثل "Continue" و"Switching Protocols" و"Processing"

2** – ردود إيجابية من الخادم مثل "OK" و"Created" و"Accepted" وغيرها.

3** – إعادة التوجيه ردود مثل "خيارات متعددة"، "استخدام الوكيل"، "إعادة توجيه مؤقتة"، إلخ.

4** – هذه السلسلة من الاستجابات هي شيء لا ترغب في رؤيته في معظم الحالات الإيجابية، إذ إن بعضها "طلب غير صالح"، "غير موجود"، "محظور"، "غير مصرّح به"، وما إلى ذلك.

5** – هذه السلسلة مرتبطة تحديدًا بأخطاء جانب الخادم – النوع الذي لا تريد رؤيته أيضًا. بعضها «خطأ داخلي في الخادم»، «غير مُنفَّذ»، «بوابة سيئة»، «الخدمة غير متاحة»، «مصادقة الشبكة مطلوبة»، إلخ.

أفضل الممارسات والمنهجيات في اختبار API

• ابدأ بالتعرّف على التطبيق الذي ستختبره لتتمكن من الإجابة عن نقاط النهاية المتاحة وما يجب اختباره.
• يجب أن تكون مواصفات الاختبار دقيقة ومفصلة.
• حدد نطاق التطبيق.
• حدد نطاق اختبارات API.
• حدّد الاستجابات المقبولة وغير المقبولة، في كل من النص البرمجي ورمز الاستجابة.
• حدد حالات الاختبار مجمعة حسب الفئات.
• حدّد المستخدمين في المرحلة المبكرة من التطوير، إذا لزم الأمر.
• يجب أن تعكس الاختبارات التسمية المستخدمة في نقاط النهاية.
• يجب كتابة المعاملات في حالات الاختبار.
• أبقِ الأمر بسيطًا – وظيفة واحدة، اختبار واحد.
• لا تقم بربط الاختبارات ببعضها البعض.
• لا تتسرّع في الطلبات التي قد تلحق الضرر بالنظام المستهدف.
• يتم تحقيق تغطية اختبار عالية من خلال السيناريوهات الإيجابية والسلبية معاً.

الخلاصة

مع اختبار API، هناك مساحة ضخمة يمكن تغطيتها وفحصها. وكما هو الحال مع أي شيء آخر، فإن هذه الطريقة ليست حلاً "مضمونًا" أيضًا. بصفتك متخصصًا في ضمان الجودة (QA)، ستحتاج إلى تنفيذ جميع مجموعات وأنواع الاختبارات المختلفة لضمان جودة البرمجيات.

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

بسيط لكن فعّال.