دليل عملي لأتمتة اختبار API باستخدام Robot Framework

يتخذ Robot Framework موقفًا مختلفًا عن الأدوات التي تعتمد على الأكواد أولاً. فبدلاً من كتابة الاختبارات كشفرة برنامج، يمكنك كتابتها كجداول من الكلمات الرئيسية المقروءة بشريًا. يكاد الاختبار يُقرأ وكأنه قائمة تحقق، مما يعني أن محللي ومهندسي ضمان الجودة يمكنهم تأليف ومراجعة نفس المجموعة. لاختبار واجهة برمجة التطبيقات (API)، يحول RequestsLibrary استدعاءات HTTP إلى نفس الكلمات الرئيسية المقروءة هذه.

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

ما هو Robot Framework ولماذا يناسب اختبار واجهة برمجة التطبيقات (API)

Robot Framework هو إطار عمل أتمتة عام ومفتوح المصدر لأتمتة الاختبارات وأتمتة العمليات الروبوتية. السمة المميزة له هي بناء جملة الكلمات الرئيسية: تُكتب الاختبارات في جداول عادية، ويتم بناء السلوك المعقد من مكتبات الكلمات الرئيسية المطبقة في Python أو Java.

لاختبار واجهة برمجة التطبيقات (API)، لهذا ميزتان حقيقيتان. أولاً، يمكن قراءة الاختبارات من قبل أشخاص لا يكتبون أكواد، لذلك يمكن للمختبر أو مالك المنتج متابعة ما تتحقق منه المجموعة. ثانيًا، الإطار قابل للتوسيع: RequestsLibrary يغلف مكتبة `requests` في Python ويكشف عمليات HTTP ككلمات رئيسية، بينما تغطي مكتبات أخرى JSON وقواعد البيانات والمزيد. إذا كانت بنية الكلمات الرئيسية جديدة بالنسبة لك، فإن دليلنا الأوسع نطاقًا حول إطار عمل أتمتة الاختبارات يشرح مكانها بين أنواع الأطر الأخرى.

تثبيت Robot Framework ومكتباته

يتم تثبيت Robot Framework ومكتباته عبر pip. اعمل داخل بيئة افتراضية للحفاظ على نظافة المشروع:

python -m venv .venv
source .venv/bin/activate
pip install robotframework
pip install robotframework-requests
pip install robotframework-jsonlibrary

تغطي الحزم الثلاث معظم احتياجات اختبار واجهة برمجة التطبيقات (API):

`robotframework` هو المحرك الأساسي ومشغل الاختبارات.
`robotframework-requests` (مكتبة RequestsLibrary) يرسل طلبات HTTP ككلمات رئيسية.
`robotframework-jsonlibrary` يستخرج ويتحقق من القيم داخل استجابات JSON.

تأكد من التثبيت باستخدام `robot --version`. يعتبر دليل مستخدم Robot Framework الرسمي هو المرجع لأسئلة بناء الجملة كلما كبرت مجموعتك.

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

كتابة أول اختبار لواجهة برمجة التطبيقات (API)

تستخدم ملفات اختبار Robot Framework امتداد `.robot` وهي مقسمة إلى أقسام تحمل علامة `*** Settings ***` و `*** Variables ***` و `*** Test Cases ***`. فيما يلي ملف كامل يتحقق من نقطة نهاية للمستخدمين:

*** Settings ***
Library           RequestsLibrary
Library           Collections

*** Variables ***
${BASE_URL}       https://api.example.com/v1

*** Test Cases ***
Get User Returns 200
    Create Session    api    ${BASE_URL}
    ${response}=      GET On Session    api    /users/42
    Status Should Be  200    ${response}

Get User Returns Expected Email
    Create Session    api    ${BASE_URL}
    ${response}=      GET On Session    api    /users/42
    ${body}=          Set Variable    ${response.json()}
    Should Be Equal As Integers    ${body}[id]    42
    Should Be Equal    ${body}[status]    active

يقوم قسم `*** Settings ***` باستيراد المكتبات. تفتح `Create Session` جلسة HTTP مسماة. ترسل `GET On Session` الطلب وتُعيد كائن الاستجابة. `Status Should Be` و `Should Be Equal` هما كلمات رئيسية للتحقق. قم بتشغيل المجموعة باستخدام `robot tests.robot`، وسيقوم Robot Framework بإنشاء تقرير HTML وسجل تلقائيًا.

العمل مع الجلسات

إن `Create Session` يقوم بأكثر من مجرد تخزين عنوان URL أساسي. تحتفظ الجلسة بالرؤوس الافتراضية، المصادقة، وملفات تعريف الارتباط (cookies)، لذا فإن كل طلب يتم إجراؤه عليها يرث تلك الحالة. هذا مهم لأي واجهة برمجة تطبيقات (API) تتطلب تسجيل دخول، لأنك تصادق مرة واحدة وتعيد استخدام الجلسة.

*** Test Cases ***
Create Order With Authenticated Session
    Create Session    api    ${BASE_URL}
    ${login}=         POST On Session    api    /auth/login
    ...               json={"email": "qa@example.com", "password": "test-pass"}
    ${token}=         Set Variable    ${login.json()}[token]
    ${headers}=       Create Dictionary    Authorization=Bearer ${token}
    ${order}=         POST On Session    api    /orders
    ...               json={"product_id": 7, "quantity": 2}
    ...               headers=${headers}
    Status Should Be  201    ${order}

يعمل بناء الجملة `...` على مواصلة استدعاء الكلمة الرئيسية إلى السطر التالي، مما يحافظ على سهولة قراءة الطلبات الطويلة. تنشئ `Create Dictionary` خريطة الرؤوس. نظرًا لاستمرار الجلسة، يمكنك إجراء عدة طلبات متابعة دون إعادة إنشائها. يتم توثيق الكلمات الرئيسية لمكتبة RequestsLibrary الخاصة بالجلسات في مرجع RequestsLibrary.

التحقق من نصوص الاستجابة

التحقق من رمز الحالة هو الخطوة الأولى. للتحقق من النص، قم بتحليل JSON والتحقق من حقوله. تغطي الكلمات الرئيسية المضمنة في Robot Framework المساواة والاحتواء، وتضيف JSONLibrary استخراجًا قائمًا على المسار:

*** Settings ***
Library           RequestsLibrary
Library           JSONLibrary
Library           Collections

*** Variables ***
${BASE_URL}       https://api.example.com/v1

*** Test Cases ***
Order Response Has Correct Shape
    Create Session    api    ${BASE_URL}
    ${response}=      POST On Session    api    /orders
    ...               json={"product_id": 7, "quantity": 2}
    Status Should Be  201    ${response}
    ${body}=          Set Variable    ${response.json()}
    Dictionary Should Contain Key    ${body}    total
    Should Be Equal As Integers      ${body}[quantity]    2
    ${status}=        Get Value From Json    ${body}    $.status
    Should Be Equal    ${status}[0]    pending

تؤكد `Dictionary Should Contain Key` وجود حقل. تقارن `Should Be Equal As Integers` القيم الرقمية دون مفاجآت عدم تطابق النوع. تستخدم `Get Value From Json` تعبير JSONPath للوصول إلى البيانات المتداخلة. للحصول على مجموعة أوسع من الفحوصات الجديرة بالتشغيل على استجابة API، فإن دليلنا حول تأكيدات API هو رفيق جيد.

بناء كلمات رئيسية قابلة لإعادة الاستخدام

تكرار `Create Session` وتدفق تسجيل الدخول في كل اختبار هو ما يعادل النسخ واللصق في سياق الكلمات الرئيسية. يتيح لك Robot Framework تعريف كلماتك الرئيسية الخاصة في قسم `*** Keywords ***`، بحيث تصبح الخطوات الشائعة أسطرًا فردية قابلة للقراءة:

*** Keywords ***
Authenticate And Open Session
    Create Session    api    ${BASE_URL}
    ${login}=         POST On Session    api    /auth/login
    ...               json={"email": "qa@example.com", "password": "test-pass"}
    ${token}=         Set Variable    ${login.json()}[token]
    Set Suite Variable    ${AUTH_HEADERS}    Bearer ${token}

*** Test Cases ***
Create Order
    Authenticate And Open Session
    ${headers}=       Create Dictionary    Authorization=${AUTH_HEADERS}
    ${order}=         POST On Session    api    /orders
    ...               json={"product_id": 7, "quantity": 2}    headers=${headers}
    Status Should Be  201    ${order}

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

ملف الموارد هو ملف `.robot` لا يحتوي على حالات اختبار، فقط أقسام `*** Keywords ***` و `*** Variables ***`. يمكنك استيراده من ملف اختبار باستخدام `Resource common.robot` في الإعدادات. هذا يحافظ على تدفق تسجيل الدخول، وعنوان URL الأساسي، والأجزاء المشتركة الأخرى في مكان واحد. مع نمو المشروع، يكون التخطيط النموذجي بملف موارد واحد لكل منطقة API بالإضافة إلى ملف علوي للإعدادات العامة. هذا الفصل بين حالات الاختبار والمنطق الداعم هو جوهر بنية الكلمات الرئيسية، ويشرح دليلنا الأوسع حول إطار عمل أتمتة الاختبارات لماذا يتوسع بهذه الطريقة.

تشغيل Robot Framework في CI

يعمل Robot Framework بدون واجهة رسومية ويعيد رمز خروج غير صفري عند الفشل، وهو بالضبط ما تحتاجه خط الأنابيب (pipeline) لإفشال البناء. يكتب المشغل أيضًا `output.xml` و `log.html` و `report.html` بعد كل تشغيل، لذا تتوفر عناصر CI دون تكوين إضافي.

تُسهم بعض الأعلام في جعل عمليات CI أنظف. استخدم `--outputdir` لإرسال التقارير إلى مجلد معروف، و `--include` و `--exclude` مع العلامات لتشغيل مجموعات فرعية، وملفات المتغيرات أو `--variable` لحقن قيم خاصة بالبيئة مثل عناوين URL الأساسية وبيانات الاعتماد دون تعديل ملفات الاختبار:

robot --outputdir results --variable BASE_URL:https://staging.example.com/v1 tests/

قم بوضع علامات على اختباراتك باستخدام `[Tags]` بحيث يمكنك تشغيل مجموعة سريعة من اختبارات Smoke Test عند كل عملية دفع (commit) والمجموعة الكاملة ليلاً. يتم ربط هذا بـ GitHub Actions أو أي خط أنابيب آخر بنفس النمط كما هو موضح في دليلنا لاختبارات API في CI/CD: تثبيت التبعيات، تشغيل الأمر، نشر عناصر التقرير.

متى تكون منصة واجهة برمجة تطبيقات (API) مخصصة أكثر فائدة

يُعد Robot Framework خيارًا قويًا عندما تريد اختبارات قابلة للقراءة وتعتمد على الكلمات الرئيسية يمكن أن تشاركها الفرق ذات المهارات المختلطة. لكنه أقل ملاءمة عندما تحتاج أيضًا إلى تصميم API، والمحاكاة (mocking)، وتصحيح الأخطاء في مكان واحد، أو عندما تريد التحقق من صحة المخطط (schema validation) مقابل مواصفات OpenAPI دون تجميعها من المكتبات.

يتعامل Apidog مع هذه الاحتياجات مباشرة. فهو يوفر منشئ اختبار مرئي، والتحقق التلقائي من صحة مخطط OpenAPI، وتشغيل الاختبارات المستندة إلى البيانات من CSV و JSON، وإدارة البيئات، وتقارير HTML، مع مشغل CLI لـ CI. غالبًا ما تستخدم الفرق كلاهما: Robot Framework حيث تكون سهولة القراءة القائمة على الكلمات الرئيسية هي الأهم، و Apidog لتصميم واجهات برمجة التطبيقات قيد الاختبار، ومحاكاتها، واختبارها على نطاق واسع. يمكنك تنزيل Apidog وإنشاء مجموعة اختبار API عاملة دون كتابة أي مكتبات كلمات رئيسية.

الأسئلة المتكررة

هل Robot Framework مخصص فقط لاختبار واجهة المستخدم؟

لا. Robot Framework هو إطار عمل أتمتة عام. بفضل RequestsLibrary، يتعامل جيدًا مع اختبار واجهة برمجة التطبيقات (API)، وتغطي المكتبات الأخرى قواعد البيانات و SSH والمزيد. تصميمه القائم على الكلمات الرئيسية لا يعتمد على الطبقة. أصبح الإطار شائعًا لاختبار واجهة المستخدم من خلال SeleniumLibrary، لكن اختبار واجهة برمجة التطبيقات هو استخدام شائع بنفس القدر.

ما الفرق بين Create Session والطلب العادي؟

تفتح `Create Session` جلسة HTTP مسماة ومستمرة تخزن عنوان URL أساسيًا، ورؤوسًا، وملفات تعريف ارتباط، ومصادقة. تُعيد الكلمات الرئيسية اللاحقة مثل `GET On Session` استخدام هذه الحالة، وهو أمر ضروري لواجهات برمجة التطبيقات التي تتطلب تسجيل الدخول. لن يحمل الطلب بدون جلسة ملفات تعريف الارتباط أو المصادقة بين الاستدعاءات، مما يجبرك على إعادة إرسال كل شيء في كل مرة.

هل أحتاج إلى معرفة بايثون لاستخدام Robot Framework؟

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

كيف يقارن Robot Framework بـ pytest لاختبار واجهة برمجة التطبيقات (API)؟

pytest يعتمد على الكود أولاً ويناسب فرق بايثون التي ترغب في وضع الاختبارات بجانب كود التطبيق. أما Robot Framework فيعتمد على الكلمات الرئيسية ويناسب الفرق ذات المهارات المختلطة التي تقدر الاختبارات المقروءة بتنسيق الجدول. كلاهما يعمل في CI وينتج تقارير. يرجع الاختيار إلى من يكتب المجموعة ويحافظ عليها بدلاً من القدرة الخام.

هل يمكن لـ Robot Framework التحقق من صحة الاستجابات مقابل مخطط OpenAPI؟

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