يتخذ Robot Framework نهجًا مختلفًا عن أدوات الاختبار التي تبدأ بالكود. بدلًا من كتابة الاختبارات كدوال وبرامج، تكتبها كجداول من كلمات رئيسية قابلة للقراءة. في اختبار واجهات برمجة التطبيقات (API)، تضيف RequestsLibrary طبقة عملية فوق HTTP بحيث تصبح طلبات GET و POST والتحققات كلمات رئيسية يمكن تشغيلها ومراجعتها بسهولة.
في هذا الدليل ستبني مجموعة اختبار API باستخدام Robot Framework خطوة بخطوة: تثبيت الأدوات، كتابة أول ملف .robot، استخدام الجلسات، التحقق من رموز الحالة وحقول JSON، استخراج كلمات رئيسية قابلة لإعادة الاستخدام، ثم تشغيل الاختبارات داخل CI.
ما هو Robot Framework ولماذا يناسب اختبار واجهة برمجة التطبيقات (API)
Robot Framework هو إطار عمل أتمتة مفتوح المصدر لاختبار البرمجيات وأتمتة العمليات. فكرته الأساسية هي بناء جملة الكلمات الرئيسية: تكتب الاختبار كسلسلة خطوات، وكل خطوة تستدعي كلمة رئيسية من مكتبة جاهزة أو من كلماتك المخصصة.
لاختبار API، يفيدك هذا في نقطتين:
- الاختبارات مقروءة من QA، المطورين، وأصحاب المنتج.
- يمكن توسيعها بمكتبات مثل RequestsLibrary لـ HTTP و JSONLibrary للتعامل مع JSON.
إذا كنت تريد فهم مكان هذا الأسلوب بين أنواع الأطر الأخرى، راجع دليل إطار عمل أتمتة الاختبارات.
تثبيت Robot Framework والمكتبات المطلوبة
ابدأ ببيئة افتراضية حتى لا تخلط تبعيات المشروع مع النظام:
python -m venv .venv
source .venv/bin/activate
pip install robotframework
pip install robotframework-requests
pip install robotframework-jsonlibrary
الحزم المستخدمة:
-
robotframework: محرك التشغيل الأساسي. -
robotframework-requests: يضيف كلمات رئيسية لإرسال طلبات HTTP. -
robotframework-jsonlibrary: يساعدك في استخراج القيم من JSON باستخدام JSONPath.
تحقق من التثبيت:
robot --version
للمرجعية الكاملة حول بناء الجملة، استخدم دليل مستخدم Robot Framework.
ملاحظة مهمة: Robot Framework حساس للمسافات البيضاء. افصل بين اسم الكلمة الرئيسية والوسائط بمسافتين على الأقل. إذا فشل التحليل، تحقق أولًا من المسافات.
كتابة أول اختبار API
أنشئ ملفًا باسم tests.robot. ملفات Robot Framework تستخدم الامتداد .robot وتُقسم عادةً إلى:
*** Settings ****** Variables ****** Test Cases ****** Keywords ***
مثال عملي لاختبار نقطة نهاية مستخدم:
*** 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 Fields
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
شغّل الاختبارات:
robot tests.robot
سينشئ Robot Framework تلقائيًا:
output.xmllog.htmlreport.html
فهم ما يحدث داخل الاختبار
في المثال السابق:
-
Create Session api ${BASE_URL}ينشئ جلسة HTTP باسمapi. -
GET On Session api /users/42يرسل طلبGETإلى${BASE_URL}/users/42. -
Status Should Be 200 ${response}يتحقق من رمز الحالة. -
${response.json()}يحول جسم الاستجابة إلى كائن يمكن قراءة حقوله.
هذا يجعل الاختبار واضحًا: افتح جلسة، أرسل طلبًا، تحقق من النتيجة.
العمل مع الجلسات والمصادقة
استخدم الجلسات عندما تحتاج إلى مشاركة عنوان URL أساسي، رؤوس، ملفات تعريف ارتباط، أو مصادقة عبر أكثر من طلب.
مثال: تسجيل الدخول ثم إنشاء طلب شراء:
*** Settings ***
Library RequestsLibrary
Library Collections
*** Variables ***
${BASE_URL} https://api.example.com/v1
*** 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}
استخدم ... لتقسيم الاستدعاء على أكثر من سطر وجعل الطلبات الطويلة أسهل قراءة.
توثيق كلمات RequestsLibrary الخاصة بالجلسات موجود في مرجع RequestsLibrary.
التحقق من نصوص الاستجابة JSON
التحقق من status code وحده غير كافٍ. تحقق أيضًا من شكل الاستجابة وقيم الحقول المهمة.
*** 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.
بناء كلمات رئيسية قابلة لإعادة الاستخدام
إذا كررت تسجيل الدخول أو إنشاء الجلسة في كل اختبار، سينمو الملف بسرعة ويصبح صعب الصيانة. الحل هو تعريف كلمات رئيسية مخصصة في قسم *** Keywords ***.
*** Settings ***
Library RequestsLibrary
Library Collections
*** Variables ***
${BASE_URL} https://api.example.com/v1
*** 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]
${headers}= Create Dictionary Authorization=Bearer ${token}
Set Suite Variable ${AUTH_HEADERS} ${headers}
*** Test Cases ***
Create Order
Authenticate And Open Session
${order}= POST On Session api /orders
... json={"product_id": 7, "quantity": 2}
... headers=${AUTH_HEADERS}
Status Should Be 201 ${order}
الفائدة العملية: إذا تغير مسار تسجيل الدخول أو شكل التوكن، تعدّل كلمة واحدة فقط بدل تعديل كل اختبار.
للمجموعات الأكبر، انقل الكلمات المشتركة إلى ملف موارد. هذا يتبع نفس مبدأ التنظيم الموضح في دليل كتابة نصوص اختبار آلية.
استخدام ملفات الموارد
ملف الموارد هو ملف .robot لا يحتوي على حالات اختبار. يحتوي عادةً على متغيرات وكلمات رئيسية مشتركة.
مثال common.robot:
*** Settings ***
Library RequestsLibrary
Library Collections
*** Variables ***
${BASE_URL} https://api.example.com/v1
*** 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]
${headers}= Create Dictionary Authorization=Bearer ${token}
Set Suite Variable ${AUTH_HEADERS} ${headers}
ثم استورده في ملف الاختبار:
*** Settings ***
Resource common.robot
*** Test Cases ***
Create Order
Authenticate And Open Session
${order}= POST On Session api /orders
... json={"product_id": 7, "quantity": 2}
... headers=${AUTH_HEADERS}
Status Should Be 201 ${order}
تنظيم عملي للمشروع:
tests/
users.robot
orders.robot
resources/
common.robot
auth.robot
users_keywords.robot
orders_keywords.robot
هذا الفصل بين حالات الاختبار والمنطق المشترك هو سبب قابلية Robot Framework للتوسع. إذا أردت مقارنة هذا النمط بأنماط أطر أخرى، راجع إطار عمل أتمتة الاختبارات.
تمرير متغيرات البيئة
لا تضع عناوين staging أو بيانات الاعتماد داخل ملفات الاختبار. مرّرها من سطر الأوامر:
robot --variable BASE_URL:https://staging.example.com/v1 tests/
أو استخدم ملف متغيرات حسب البيئة، ثم شغّل المجموعة بالقيم المناسبة.
مثال لتشغيل نفس الاختبارات على بيئتين:
robot --outputdir results/staging --variable BASE_URL:https://staging.example.com/v1 tests/
robot --outputdir results/prod --variable BASE_URL:https://api.example.com/v1 tests/
تشغيل Robot Framework في CI
Robot Framework مناسب لـ CI لأنه يعمل بدون واجهة رسومية ويعيد رمز خروج غير صفري عند فشل الاختبارات.
أمر أساسي:
robot --outputdir results --variable BASE_URL:https://staging.example.com/v1 tests/
استخدم --outputdir لحفظ التقارير في مجلد معروف يمكن رفعه كـ artifact.
يمكنك أيضًا استخدام الوسوم لتقسيم الاختبارات:
*** Test Cases ***
Get User Smoke Test
[Tags] smoke
Create Session api ${BASE_URL}
${response}= GET On Session api /users/42
Status Should Be 200 ${response}
تشغيل اختبارات smoke فقط:
robot --include smoke --outputdir results tests/
استبعاد اختبارات معينة:
robot --exclude slow --outputdir results tests/
النمط العام داخل GitHub Actions أو أي CI مشابه:
- تثبيت Python.
- تثبيت تبعيات Robot Framework.
- تشغيل
robot. - نشر
log.htmlوreport.htmlكعناصر build.
لربط اختبارات API بخطوط CI/CD، راجع دليل اختبارات API في CI/CD.
متى تستخدم منصة API مخصصة بدل Robot Framework
Robot Framework قوي عندما تريد اختبارات قابلة للقراءة وتعتمد على الكلمات الرئيسية، خاصةً للفرق المختلطة بين QA والمطورين. لكنه أقل ملاءمة إذا كنت تريد في نفس المكان:
- تصميم API.
- المحاكاة Mocking.
- تصحيح الطلبات.
- التحقق من OpenAPI schema.
- إدارة البيئات والبيانات والتقارير بصريًا.
يتعامل Apidog مع هذه الاحتياجات مباشرة. يوفر منشئ اختبار مرئي، تحققًا تلقائيًا من مخطط OpenAPI، تشغيل اختبارات مستندة إلى بيانات من CSV و JSON، إدارة بيئات، تقارير HTML، ومشغل CLI لـ CI.
تستخدم بعض الفرق الاثنين معًا: Robot Framework عندما تكون قابلية القراءة بالكلمات الرئيسية أولوية، و Apidog لتصميم واجهات API ومحاكاتها واختبارها على نطاق أوسع. يمكنك تنزيل Apidog وبناء مجموعة اختبار API دون كتابة مكتبات كلمات رئيسية مخصصة.
الأسئلة المتكررة
هل Robot Framework مخصص فقط لاختبار واجهة المستخدم؟
لا. Robot Framework إطار أتمتة عام. اشتهر في اختبار الواجهات عبر SeleniumLibrary، لكنه مناسب أيضًا لاختبار API باستخدام RequestsLibrary، ويمكن توسيعه لقواعد البيانات و SSH وسيناريوهات أخرى.
ما الفرق بين Create Session والطلب العادي؟
Create Session ينشئ جلسة HTTP مسماة تحفظ عنوان URL الأساسي، الرؤوس، ملفات تعريف الارتباط، والمصادقة. بعد ذلك تستخدم كلمات مثل GET On Session و POST On Session لإعادة استخدام الحالة نفسها. هذا مهم عند التعامل مع تسجيل الدخول أو أي API تعتمد على cookies أو tokens.
هل أحتاج إلى معرفة بايثون لاستخدام Robot Framework؟
ليس لكتابة الاختبارات اليومية. بناء جملة الكلمات الرئيسية مصمم ليكون مقروءًا دون كتابة كود بايثون. ستحتاج إلى بايثون فقط إذا أردت إنشاء مكتبات كلمات رئيسية جديدة بالكامل. في معظم اختبارات API، تكفي RequestsLibrary و JSONLibrary والكلمات المضمنة.
كيف يقارن Robot Framework بـ pytest لاختبار API؟
pytest مناسب أكثر لفرق بايثون التي تريد كتابة الاختبارات ككود ووضعها بجانب التطبيق. Robot Framework مناسب عندما تريد اختبارات بصيغة خطوات واضحة يمكن أن يقرأها QA وغير المطورين. كلاهما يعمل في CI، والاختيار يعتمد غالبًا على من سيكتب الاختبارات ويحافظ عليها.
هل يمكن لـ Robot Framework التحقق من الاستجابات مقابل مخطط OpenAPI؟
ليس بشكل جاهز في النواة. يمكنك التحقق من الحقول الفردية باستخدام الكلمات المضمنة و JSONLibrary، كما توجد مكتبات مجتمع للتحقق من المخططات. إذا كان التحقق التلقائي مقابل OpenAPI جزءًا أساسيًا من سير عملك، فقد تكون منصة مثل Apidog أسهل لأنها توفر ذلك بشكل أصلي.
Top comments (0)