دروس اختبار API: دليل كامل للمبتدئين

قائمة دروس اختبار API
نظرة عامة على البرامج التعليمية في سلسلة اختبارات API هذه
اختبار API التعليمي
تقديم اختبار API في مؤسستك
- - (i) الاختبار الوظيفي

يوضح هذا البرنامج التعليمي لاختبار API المتعمق كل شيء عن اختبار API وخدمات الويب وكيفية تقديم اختبار API في مؤسستك:

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

مفاهيم مثل Web API ، وكيف تعمل API (مع مثال من العالم الحقيقي) وكيف تختلف عن خدمات الويب موضحة جيدًا بأمثلة في هذا البرنامج التعليمي.

قائمة دروس اختبار API

البرنامج التعليمي رقم 1: اختبار API التعليمي: دليل كامل للمبتدئين

البرنامج التعليمي رقم 2: دروس خدمات الويب: المكونات ، الهندسة المعمارية ، الأنواع & amp؛ أمثلة

البرنامج التعليمي رقم 3: أفضل 35 أسئلة مقابلة مع ASP.Net وواجهة برمجة تطبيقات الويب مع الإجابات

البرنامج التعليمي رقم 4: برنامج POSTMAN التعليمي: اختبار API استخدام POSTMAN

البرنامج التعليمي رقم 5: اختبار خدمات الويب باستخدام عميل Apache HTTP

نظرة عامة على البرامج التعليمية في سلسلة اختبارات API هذه

البرنامج التعليمي #

ما ستتعلمه

البرنامج التعليمي_ # 1:

اختبار اختبار API : دليل كامل للمبتدئين

سيشرح هذا البرنامج التعليمي حول اختبار API المتعمق كل شيء عن اختبار API وخدمات الويب بالتفصيل ، كما سيعلمك كيفية تقديم اختبار API في مؤسستك.

البرنامج التعليمي_ # 2:

دروس خدمات الويب: المكونات ، الهندسة المعمارية ، الأنواع & amp؛ أمثلة

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

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

في لقطة الشاشة أدناه ، أدخل المستخدم وزنًا غير صالح ، وهو أكثر من 2267 كجم المقبول. تستجيب واجهة برمجة التطبيقات برمز حالة الخطأ ورسالة الخطأ. ومع ذلك ، تذكر رسالة الخطأ بشكل غير صحيح وحدات الوزن مثل رطل بدلاً من كجم. هذا عيب يمكن أن يربك العميل النهائي.

(ii) اختبار الحمل والأداء

من المفترض أن تكون واجهات برمجة التطبيقات قابلة للتطوير حسب التصميم.

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

هذه البيانات مفيدة أثناء التخطيط لتوسيع نطاق تطبيق. سيساعد توفر هذه المعلومات في دعم القرارات والتخطيط خاصةً إذا كانت المنظمة تخطط لإضافة المزيد من العملاء ، مما يعني المزيد من الوافدينالطلبات.

كيفية تقديم اختبار API في مؤسستك

تشبه عملية تقديم اختبار API في أي مؤسسة العملية المستخدمة لتنفيذ أو طرح أي أداة اختبار وإطار عمل آخر.

يلخص الجدول أدناه الخطوات الرئيسية مع النتيجة المتوقعة لكل خطوة.

المرحلة	الخطوة	النتيجة المتوقعة
اختيار الأداة	جمع المتطلبات وتحديد القيود	فهم متطلبات البحث سوق لأداة اختبار API المناسبة. على سبيل المثال ما نوع واجهة برمجة التطبيقات التي يتم اختبارها - SOAP أم REST؟ هل نحتاج إلى توظيف مختبِر لهذا الدور أو تدريب المختبرين الحاليين؟ ما نوع الاختبارات التي سيتم إجراؤها - الاختبارات الوظيفية ، واختبارات الأداء وما إلى ذلك. ما هي ميزانية التنفيذ؟
	تقييم الأدوات المتاحة	قارن الأدوات المتاحة والقائمة المختصرة 1 أو 2 من الأدوات التي تلبي المتطلبات على أفضل وجه.
	إثبات المفهوم	تنفيذ مجموعة فرعية من الاختبارات باستخدام أداة القائمة المختصرة. عرض النتائج على أصحاب المصلحة. إنهاء الأداة المراد تنفيذها.
التنفيذ	البدء	اعتمادًا على اختيارك للأداة ، قد تحتاج إلى تثبيت الأداة المطلوبة على جهاز كمبيوتر أو جهاز ظاهري أو خادم. إذا كانت الأداة المفضلة تعتمد على الاشتراك ، قم بإنشاء الفريق المطلوبالحسابات. تدريب الفريق إذا لزم الأمر.
	البدء	إنشاء الاختبارات تنفيذ الاختبارات الإبلاغ عن العيوب

التحديات الشائعة وطرق التخفيف منها

دعونا نناقش بعض التحديات الشائعة التي تواجه فرق ضمان الجودة تواجه أثناء محاولة تنفيذ إطار اختبار API في مؤسسة.

# 1) اختيار الأداة الصحيحة

تحديد الأداة الصحيحة للوظيفة هو التحدي الأكثر شيوعًا. هناك العديد من أدوات اختبار API المتوفرة في السوق.

قد يبدو تطبيق أحدث وأغلى أداة متوفرة في السوق أمرًا جذابًا - ولكن إذا لم تحقق النتائج المرجوة ، فهذه الأداة لا فائدة منه.

ومن ثم ، اختر دائمًا الأداة التي تتناول المتطلبات "الضرورية" بناءً على احتياجاتك التنظيمية.

هنا نموذج مصفوفة تقييم أداة لـ أدوات API المتاحة

الأداة	التسعير	ملاحظات
Soap UI	إصدار مجاني متاح لـ SoapUI Open Source (اختبار وظيفي)	* REST و SOAP وبروتوكولات API و IoT الشائعة الأخرى. * مضمن في الإصدار المجاني اختبار SOAP و REST المخصص تأكيد الرسالة اسحب & amp؛ إنشاء اختبار السقوط اختبار السجلات اختبار التكوين اختبار من التسجيلات تقرير الوحدة. * قائمة الميزات الكاملة يمكن أن تكون وجدت فيالموقع الإلكتروني.
Postman	يتوفر تطبيق Postman المجاني	* الأكثر استخدامًا لـ REST. * يمكن العثور على الميزات في موقع الويب الخاص بهم.
Parasoft	إنها أداة مدفوعة وتتطلب شراء ترخيص ثم تتطلب التثبيت قبل استخدام الأداة.	* اختبار شامل لواجهة برمجة التطبيقات: وظيفي ، تحميل ، اختبار أمان ، إدارة بيانات الاختبار
vREST	استنادًا إلى عدد المستخدمين	* اختبار API REST الآلي. * التسجيل والإعادة. * إزالة التبعية من الواجهة الأمامية والخلفية باستخدام واجهات برمجة تطبيقات وهمية. * التحقق من صحة الاستجابة القوية. * يعمل للتطبيقات التجريبية المنشورة على المضيف المحلي / الإنترانت / الإنترنت. * تكامل JIRA ، استيراد Jenkins Integration من Swagger ، Postman.
HttpMaster	الإصدار السريع: تنزيل مجاني الإصدار الاحترافي: استنادًا إلى عدد المستخدمين	* يساعد في اختبار موقع الويب وكذلك اختبار واجهة برمجة التطبيقات. * تشتمل الميزات الأخرى على القدرة على تحديد المعلمات العامة ، وتزويد المستخدم بالقدرة على إنشاء عمليات تحقق للتحقق من صحة استجابة البيانات باستخدام مجموعة كبيرة من أنواع التحقق من الصحة التي يدعم.
Runscope	استنادًا إلى عدد المستخدمين وأنواع الخطط	* لمراقبة واختبار API. * يمكن استخدامه للتحقق من صحة البيانات لضمان إرجاع البيانات الصحيحة. * يحتوي على ميزةالتتبع والإخطار في حالة حدوث أي فشل في معاملة واجهة برمجة التطبيقات (إذا كان تطبيقك يتطلب التحقق من صحة الدفع ، فيمكن أن تكون هذه الأداة اختيارًا جيدًا).
LoadFocus	استنادًا إلى عدد المستخدمين وأنواع الخطط	* يمكن استخدامها لاختبار تحميل واجهة برمجة التطبيقات - يسمح بإجراء بعض الاختبارات لمعرفة عدد المستخدمين الذين يمكن لواجهة برمجة التطبيقات دعمها. * سهل الاستخدام - يسمح بإجراء الاختبارات داخل المتصفح.
PingAPI	مجاني لمشروع واحد (1000 طلب )	* مفيد للاختبار والمراقبة الآلي لواجهة برمجة التطبيقات.

# 2) مواصفات الاختبار مفقودة

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

على سبيل المثال ، ضع في اعتبارك المتطلبات الواردة أدناه:

"يجب أن يقبل التطبيق فقط تاريخ شحن صالحًا ويجب رفض جميع المتطلبات غير الصالحة"

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

يعتبر تاريخ الشحن صالحًا إذا كانهو

ليس في الماضي
أكبر أو يساوي تاريخ اليوم
بتنسيق مقبول: DD / MM / YYYY

رمز حالة الاستجابة = 200

الرسالة: موافق

3) تاريخ الشحن الذي لا يفي بالمعايير المذكورة أعلاه يجب اعتباره غير صالح. إذا أرسل العميل تاريخ شحن غير صالح ، فيجب عليه الرد برسالة (رسائل) الخطأ التالية:

3.1

رمز حالة الاستجابة ليس 200

خطأ: تاريخ الشحن المقدم غير صالح ؛ يرجى التأكد من أن التاريخ بتنسيق DD / MM / YYYY

3.2

رمز حالة الاستجابة ليس 200

خطأ: تاريخ الشحن المقدم في الماضي

# 3) منحنى التعلم

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

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

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

# 4) مجموعة المهارات الحالية

يرتبط هذا مباشرة بالنقطة السابقة حول منحنى التعلم.

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

دراسة حالة

المهمة

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

التحديات

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

النهج الذي يتبعه الفريق للتخفيف من المخاطر والتغلب على التحديات

عمل فريق ضمان الجودة مع فريق المشروع لتحديد المتطلبات التالية:
- نوع API (REST / SOAP): REST
- الاختبارات المطلوبة (وظيفية ، التحميل ، الأمان): الاختبار الوظيفي فقط
- الاختبارات الآلية المطلوبة (نعم / لا): اختيارية حاليًا
- تقارير الاختبار (نعم / لا ): مطلوب
قام فريق ضمان الجودة بتقييم الأداة على أدوات اختبار API المتاحة بناءً على المتطلبات الضرورية. تم الانتهاء من أداة Postman API كأداة من اختيارهم لأنها كانت مجانية وسهلة الاستخدام أيضًا ، وبالتالي تقليل منحنى التعلم ، ولديها القدرة على أتمتة الاختبارات ، وتأتي مع تقارير جيدة مضمنة.
تم تدريب نفس المختبِر الذي اختبر التطبيق على استخدام Postman لإنشاء اختبارات أولية وبالتالي القضاء على أي ثغرات في المعرفة بالمنتج.
للتعامل مع المتطلبات المفقودة ، قام فريق المشروع ببناء وثائق ميدانية رفيعة المستوى باستخدام Swagger . ومع ذلك ، فقد ترك هذا بعض الثغرات فيما يتعلق بتنسيقات البيانات المقبولة وقد تم تناول ذلك مع فريق المشروع وتم الاتفاق على التنسيقات المتوقعة وتوثيقها. اكتسبت شعبية في الآونة الأخيرة. هذه التطبيقات أكثرقابلة للتطوير مقارنة بالتطبيقات / البرامج التقليدية وتسمح بالتكامل الأسهل مع واجهات برمجة التطبيقات أو التطبيقات الأخرى.
شرح هذا البرنامج التعليمي لاختبار API كل شيء عن اختبار API واختبار التحول إلى اليسار وخدمات الويب وواجهة برمجة تطبيقات الويب بالتفصيل. استكشفنا أيضًا الاختلافات بين Web Services vs Web API مع أمثلة.

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

تحقق من البرنامج التعليمي القادم لمعرفة المزيد عن خدمات الويب مع أمثلة !!

البرنامج التعليمي التالي
يشرح البرنامج التعليمي للخدمات الهندسة المعمارية والأنواع وأمبير. مكونات خدمات الويب جنبًا إلى جنب مع المصطلحات المهمة والاختلافات بين SOAP مقابل REST.

البرنامج التعليمي_ # 3:

أهم 35 سؤال مقابلة مع ASP.Net و Web API مع إجابات

يمكنك استكشاف قائمة الأسئلة الأكثر شيوعًا التي يتم طرحها بشكل متكرر حول ASP.Net و Web API مع إجابات وأسئلة وأجوبة. أمثلة للمبتدئين والمحترفين ذوي الخبرة في هذا البرنامج التعليمي.

البرنامج التعليمي_ # 4:

POSTMAN Tutorial: API Testing Using POSTMAN

سيشرح هذا البرنامج التعليمي خطوة بخطوة اختبار API باستخدام POSTMAN جنبًا إلى جنب مع أساسيات POSTMAN ومكوناته وطلب العينة & amp؛ الاستجابة بعبارات بسيطة لفهمك بسهولة.

البرنامج التعليمي_ # 5:

اختبار خدمات الويب باستخدام عميل Apache HTTP

هذا البرنامج التعليمي لواجهة برمجة التطبيقات يدور حول إجراء عمليات CRUD المختلفة على خدمات الويب واختبار خدمات الويب باستخدام عميل Apache HTTP

اختبار API التعليمي

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

واجهة برمجة التطبيقات ( واجهة برمجة التطبيقات) عبارة عن مجموعة من جميع الإجراءات والوظائف التي تسمح لنا بإنشاء تطبيق من خلال الوصول إلى بيانات أو ميزاتنظام التشغيل أو المنصات. يُعرف اختبار مثل هذه الإجراءات باسم اختبار API.

Shift Left Testing

أحد أنواع الاختبارات المهمة التي يتم طرحها في الوقت الحاضر في مقابلات اختبار API هو اختبار Shift Left. يتم ممارسة هذا النوع من الاختبار في جميع المشاريع تقريبًا التي تتبع منهجية Agile.

قبل تقديم اختبار Shift Left ، ظهر اختبار البرنامج فقط بعد اكتمال الترميز وتسليم الكود إلى المختبرين. أدت هذه الممارسة إلى صخب اللحظة الأخيرة للوفاء بالموعد النهائي كما أعاقت جودة المنتج إلى حد كبير.

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

دورة حياة تطوير البرامج (SDLC) قبل Shift Left الاختبار

كان تدفق SDLC التقليدي: المتطلبات - & GT. تصميم - & GT. الترميز - & GT. الاختبار.

عيوب الاختبار التقليدي

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

وبالتالي ، ظهرت فكرة جديدة لتحويل مرحلة الاختبار إلى اليسار مما أدى إلى اختبار التحول إلى اليسار.

اقترح القراءة = & gt ؛ اختبار التحول إلى اليسار: Aالتعويذة السرية لنجاح البرنامج

مراحل اختبار التحول الأيسر

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

Web API

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

كيف تعمل واجهة برمجة التطبيقات؟

لنأخذ سيناريو شائع جدًا لحجز رحلة طيران على www.makemytrip.com ، وهي خدمة سفر عبر الإنترنت تجمع المعلومات من عدة شركات طيران. عندما تذهب لحجز رحلة ، تقوم بإدخال معلومات مثل تاريخ الرحلة / تاريخ العودة ، والفئة ، وما إلى ذلك ، ثم انقر فوق بحث.

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

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

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

Web Services

خدمات الويب (مثل Web API) هي الخدمات التي تخدم من جهاز إلى آخر. لكن الاختلاف الرئيسي الذي ينشأ بين API وخدمات الويب هو أن خدمات الويب تستخدم شبكة.

من الآمن أن نقول إن جميع خدمات الويب عبارة عن واجهات برمجة تطبيقات ويب ولكن جميع واجهات برمجة تطبيقات الويب ليست خدمات ويب (موضحة في الجزء الأخير من المقال). وبالتالي ، فإن خدمات الويب هي مجموعة فرعية من Web API. راجع الرسم التخطيطي أدناه لمعرفة المزيد حول Web API و Web Services.

Web API vs Web Services

Web Services vs Web Services vs واجهة برمجة تطبيقات الويب

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

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

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

خدمة الويب

خدمة الويب هي مجموعة فرعية من Web API. على سبيل المثال ، خدمات الويب تعتمد فقط على ثلاثة أنماط من الاستخدام ، مثل SOAP و REST و XML-RPC.
تحتاج خدمات الويب دائمًا إلى شبكة للعمل.
خدمات الويب تدعم "تطبيقات مختلفة برمز واحد". هذا يعني أن رمزًا أكثر عمومية مكتوبًا عبر تطبيقات مختلفة.

Web API

تستخدم واجهة برمجة تطبيقات الويب بشكل عام JSON (JavaScript Object Notation) ، مما يعني أن Web API أسرع.
Web API أسرع لأن JSON خفيف الوزن ، على عكس XML.
Web APIs هي مجموعة شاملة من خدمات الويب. على سبيل المثال ، جميع الأنماط الثلاثة لخدمات الويب موجودة في واجهة برمجة تطبيقات الويب أيضًا ، ولكن بصرف النظر عن ذلك ، تستخدم أنماطًا أخرى مثل JSON - RPC.
واجهة برمجة تطبيقات الويب لا تتطلب بالضرورة شبكة للعمل.
واجهة برمجة تطبيقات الويب قد تدعم أو لا تدعم إمكانية التشغيل التفاعلي اعتمادًا على طبيعة النظام أو التطبيق.

تقديم اختبار API في مؤسستك

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

على سبيل المثال ، دعنا نعتبر أنك تتصفح المنتجات على Amazon.com وترى منتجًا / صفقة تعجبك حقًا وترغب في مشاركتها مع شبكة Facebook الخاصة بك.

لحظة النقر فوق على أيقونة Facebook في قسم المشاركة بالصفحة وأدخل ملفبيانات اعتماد حساب Facebook المراد مشاركتها ، فأنت تتفاعل مع واجهة برمجة تطبيقات تربط موقع Amazon على الويب بسلاسة. التي اكتسبت التطبيقات القائمة على API شعبية في الآونة الأخيرة.

هناك العديد من الأسباب التي تحول المنظمات إلى المنتجات والتطبيقات القائمة على API. وقد تم إدراج عدد قليل منهم أدناه للرجوع إليه.

# 1) التطبيقات القائمة على واجهة برمجة التطبيقات أكثر قابلية للتطوير عند مقارنتها بالتطبيقات / البرامج التقليدية. يكون معدل تطوير الكود أسرع ويمكن لواجهة برمجة التطبيقات نفسها أن تخدم المزيد من الطلبات دون أي كود رئيسي أو تغييرات في البنية التحتية.

# 2) لا تحتاج فرق التطوير إلى بدء الترميز من البداية كل الوقت الذي يبدأون فيه العمل على تطوير ميزة أو تطبيق. غالبًا ما تعيد واجهات برمجة التطبيقات استخدام الوظائف الحالية والقابلة للتكرار والمكتبات والإجراءات المخزنة وما إلى ذلك ، وبالتالي يمكن لهذه العملية أن تجعلها أكثر إنتاجية بشكل عام.

على سبيل المثال ، إذا كنت مطورًا يعمل على موقع التجارة الإلكترونية وتريد إضافة Amazon كمعالج دفع - فلن تضطر إلى كتابة الرمز من البداية.

كل ما عليك فعله هو إعداد التكامل بين موقع الويب الخاص بك و Amazon API باستخدام مفاتيح التكامل واستدعاء Amazon API لمعالجة المدفوعات أثناء الخروج.

# 3) تسمح واجهات برمجة التطبيقاتسهولة التكامل مع الأنظمة الأخرى للتطبيقات المستقلة المدعومة وكذلك مع منتجات البرامج القائمة على API.

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

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

دعونا نناقش هذا بالتفصيل.

(i) الاختبار الوظيفي

يمكن أن يكون الاختبار الوظيفي مهمة صعبة بسبب عدم وجود واجهة GUI.

دعونا نرى كيف يختلف نهج الاختبار الوظيفي لواجهات برمجة التطبيقات عن التطبيق القائم على واجهة المستخدم الرسومية وسنناقش أيضًا بعض الأمثلة حوله.

a) الاختلاف الأكثر وضوحًا هو أنه لا توجد واجهة مستخدم رسومية للتفاعل معها. يجد المختبِرون الذين يقومون عادةً باختبار وظيفي قائم على واجهة المستخدم الرسومية أنه من الأصعب قليلاً الانتقال إلى اختبار تطبيق بخلاف واجهة المستخدم الرسومية مقارنةً بـشخص على دراية به بالفعل.

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

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

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

على سبيل المثال ، إذا كان التطبيق يحتاج إلى تنسيق التاريخ ليكون DD / MM / YYYY ، فيمكننا تطبيق هذا التحقق من الصحة على النموذج الذي يجمع المعلومات للتأكد من أن التطبيق يتلقى ويعالج تاريخًا صالحًا.

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

ج) اختبار