DEV Community

Cover image for كيفية استخدام استعلامات قواعد البيانات في اختبارات API باستخدام Apidog (MySQL, MongoDB, Redis)
Yusuf Khalidd
Yusuf Khalidd

Posted on • Originally published at apidog.com

كيفية استخدام استعلامات قواعد البيانات في اختبارات API باستخدام Apidog (MySQL, MongoDB, Redis)

رمز الحالة الأخضر قد يخدع. نقطة النهاية POST /orders تُرجع 201 Created، ونص الاستجابة يبدو مثاليًا، وينجح اختبار HTTP. لكن هل وصل الصف فعلًا إلى قاعدة البيانات بالحالة الصحيحة؟ هل انخفض المخزون؟ اختبار يقرأ استجابة HTTP فقط يتحقق مما قالته واجهة برمجة التطبيقات، لا مما فعله النظام. لسد هذه الفجوة، يجب التحقق من قاعدة البيانات نفسها.

جرّب Apidog اليوم

هنا تأتي قيمة استعلامات قاعدة البيانات داخل سيناريو الاختبار: هيّئ حالة معروفة قبل الطلب، نفّذ الطلب، ثم استعلم عن الجدول لتتأكد من البيانات المخزنة فعليًا. يدعم Apidog ذلك عبر اتصالات قاعدة البيانات ومعالج Database Operation، ما يتيح تشغيل أوامر SQL أو NoSQL كخطوات ضمن السيناريو نفسه الذي يشغّل طلبات HTTP، دون كتابة سكربت خارجي. إذا كنت جديدًا في بناء السيناريوهات، راجع دليل كيفية كتابة سيناريو اختبار باستخدام Apidog. ولتحديث مفاهيم نمذجة البيانات العلائقية، راجع نظرة MDN العامة على جانب الخادم.

ما الذي توفره عمليات قاعدة البيانات في الاختبار؟

اختبار API لا يلامس قاعدة البيانات هو اختبار صندوق أسود: يثق بالاستجابة. هذا يكفي أحيانًا، لكن الأخطاء المهمة غالبًا تقع بين ما ترجعه الواجهة وما تُخزّنه فعليًا، مثل:

  • حقل حالة لا يتغير.
  • مفتاح أجنبي يشير إلى سجل غير موجود.
  • حذف ناعم (soft-delete) يتحول إلى حذف فعلي (hard-delete).
  • عملية ناجحة ظاهريًا لم تُحدّث المخزون أو الرصيد.

تتيح لك خطوات قاعدة البيانات تنفيذ ثلاثة أشياء لا يستطيع اختبار HTTP البحت تنفيذها:

  1. تهيئة حالة بداية دقيقة، بدل الاعتماد على بيانات متبقية من تشغيل سابق.
  2. التحقق من الحقيقة الأساسية بقراءة الصف الذي تدّعي الواجهة أنها كتبته.
  3. استخراج قيم حقيقية من قاعدة البيانات واستخدامها في الطلبات التالية، مثل معرفات أنشأها الخادم.

في Apidog، تتكون العملية من جزأين:

  1. إنشاء اتصال قابل لإعادة الاستخدام من Settings > Database Connections.
  2. إضافة خطوة Database Operation إلى الطلب:
    • Pre Processor قبل الطلب.
    • Post Processor بعد الطلب.

ملاحظة عن التغطية: تعمل MySQL وSQL Server 2014+ وPostgreSQL وOracle ضمن الخطة المجانية. أما ClickHouse وMongoDB وRedis فتحتاج إلى خطة مدفوعة. المثال العملي التالي يستخدم MySQL.

الخطوة 1: إنشاء اتصال قاعدة بيانات

افتح:

Settings > Database Connections
Enter fullscreen mode Exit fullscreen mode

ثم انقر + New، واختر نوع قاعدة البيانات، وأدخل بيانات الاتصال:

  • Host: مثل db.staging.internal أو 127.0.0.1
  • Port: مثل 3306 لـ MySQL
  • Username
  • Password
  • Database Name: مثل shop

إعداد اتصال قاعدة البيانات في Apidog

إذا كانت قاعدة البيانات خلف خادم وسيط، وسّع قسم SSH Tunnel وأضف بيانات مضيف القفز (jump host).

في MySQL، اختر وضع SSL المناسب:

  • Prefer: الافتراضي؛ يحاول SSL ثم يتراجع عند الحاجة.
  • Require: يفرض SSL.
  • Verify CA: يتحقق من المرجع المصدّق.
  • Verify Full: يتحقق من المرجع المصدّق واسم المضيف.

اختر الوضع الأكثر صرامة الذي يدعمه خادمك، ثم اضغط Save.

ملاحظتان مهمتان

  • مصادقة MySQL 8: قد يمنع المكوّن الإضافي الافتراضي caching_sha2_password الاتصال. عند ظهور خطأ مصادقة، جرّب تبديل المستخدم إلى mysql_native_password: 
ALTER USER 'tester'@'%'
IDENTIFIED WITH mysql_native_password BY '...';
Enter fullscreen mode Exit fullscreen mode

راجع دليل MySQL المرجعي لفهم فروق إضافات المصادقة.

  • بيانات الاعتماد محلية: لا تتم مزامنة تفاصيل اتصال قاعدة البيانات مع السحابة. يجب أن يهيّئ كل عضو في الفريق الاتصال على جهازه. راجع مشاركة إعدادات اتصال قاعدة البيانات لتنسيق هذا الإعداد داخل الفريق.

الخطوة 2: تهيئة البيانات باستخدام Pre Processor

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

افتح الطلب، ثم:

  1. انتقل إلى Pre Processors.
  2. مرّر فوق Add Database Processor.
  3. اختر Database Operation.
  4. سمِّ الخطوة مثلًا: seed customer.
  5. اختر اتصال MySQL.
  6. أضف أمر SQL التالي.

تستخدم المتغيرات الديناميكية الصيغة {{variable_name}}:

INSERT INTO customers (id, email, status)
VALUES ({{customer_id}}, '{{customer_email}}', 'active')
ON DUPLICATE KEY UPDATE status = 'active';
Enter fullscreen mode Exit fullscreen mode

بهذا يبدأ كل تشغيل للاختبار بحالة مضمونة:

  • العميل موجود.
  • حالة العميل active.
  • المعرف معروف للخطوات التالية.

هذه التهيئة تجعل الاختبار مستقلًا عن ترتيب التنفيذ أو آثار الاختبارات السابقة.

الخطوة 3: التحقق من قاعدة البيانات باستخدام Post Processor

أضف طلب إنشاء الطلب:

POST /api/orders
Content-Type: application/json

{
  "customer_id": {{customer_id}},
  "items": [{ "sku": "APRON-01", "qty": 2 }]
}
Enter fullscreen mode Exit fullscreen mode

افترض أنك التقطت معرف الطلب من الاستجابة في متغير باسم order_id.

بعد ذلك:

  1. افتح Post Processors للطلب.
    • في DESIGN Mode: من تبويب Run.
    • في DEBUG Mode: من تبويب Request.
  2. اختر Add PostProcessor > Database Operation.
  3. سمِّ الخطوة: verify order row.
  4. اختر اتصال قاعدة البيانات.
  5. أضف الاستعلام: 
SELECT id, status, total_cents
FROM orders
WHERE id = {{order_id}};
Enter fullscreen mode Exit fullscreen mode

تعيد العملية النتائج كمصفوفة كائنات، حيث يمثل كل كائن صفًا.

لاستخراج حقل الحالة من أول صف:

  1. افتح Extract Results (Optional).
  2. أضف Extract Result To Variable.
  3. استخدم اسم المتغير: 
db_order_status
Enter fullscreen mode Exit fullscreen mode
  1. استخدم تعبير JSONPath: 
$[0].status
Enter fullscreen mode Exit fullscreen mode

أرسل الطلب وافتح Console لمراجعة النتيجة الخام والقيمة المستخرجة.

الآن أضف تأكيدًا بأن db_order_status يساوي القيمة المتوقعة، مثل:

pending
Enter fullscreen mode Exit fullscreen mode

بهذا لا يكتفي الاختبار بالتأكد من 201 Created، بل يتحقق من أن الصف المخزن يحمل الحالة الصحيحة. إذا أعادت الواجهة 201 لكنها خزنت status = 'draft'، فسيكشف الاختبار الخطأ.

الخطوة 4: استخراج قيمة من قاعدة البيانات واستخدامها لاحقًا

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

مثال: عند إنشاء طلب، يولد الخادم قيمة fulfillment_ref ويحفظها في جدول orders، لكنها لا تظهر في الاستجابة. تحتاجها لاحقًا في:

GET /api/fulfillments/{ref}
Enter fullscreen mode Exit fullscreen mode

أضف استعلامًا في Post Processor:

SELECT fulfillment_ref
FROM orders
WHERE id = {{order_id}};
Enter fullscreen mode Exit fullscreen mode

ثم استخرج النتيجة باستخدام:

  • Variable Name: fulfillment_ref
  • JSONPath Expression: $[0].fulfillment_ref

بعدها استخدم القيمة في الطلب التالي:

{{fulfillment_ref}}
Enter fullscreen mode Exit fullscreen mode

هذا يشبه تمرير بيانات استجابات HTTP بين الطلبات، لكن مصدر الحقيقة هنا هو قاعدة البيانات. راجع أيضًا:

MongoDB وRedis: قواعد NoSQL

تعمل خطوات قاعدة البيانات بطريقة مشابهة مع مخازن NoSQL، لكن واجهة الإعداد تختلف. اتصال MongoDB وRedis ميزة مدفوعة. راجع وثائق Apidog للحقول المتاحة.

MongoDB

أضف خطوة Database Operation واختر MongoDB.

بدل SQL الخام، استخدم قائمة Operation Type، التي تتضمن:

  • Find
  • Insert
  • Update
  • Delete
  • Run Database Command

لعمليات CRUD، يكون Collection Name مطلوبًا. يقبل حقل Query Condition صيغة JSON:

{ "_id": "65486728456e79993a150f1c" }
Enter fullscreen mode Exit fullscreen mode

يقوم Apidog بتحويل سلسلة المعرف المطابقة إلى ObjectId تلقائيًا. وعند الحاجة إلى أنواع BSON، يمكنك استخدام:

ISODate(...)
ObjectId(...)
NumberDecimal(...)
NumberLong(...)
Enter fullscreen mode Exit fullscreen mode

راجع وثائق MongoDB لمعرفة كيفية تمثيل هذه الأنواع.

ملاحظة: توثق خطوات MySQL استخراج نتيجة JSONPath إلى متغير، لكن وثائق MongoDB وRedis لا تصف الآلية نفسها بشكل صريح. استخدم عمليات MongoDB لتهيئة الحالة والتحقق منها، ولا تفترض أن الاستخراج يعمل بالطريقة نفسها قبل التحقق من Console.

Redis

يتطلب اتصال Redis:

  • Host
  • Port
  • Password
  • Database Index

تدعم قائمة Operation Type العمليات التالية:

  • GET
  • SET
  • DELETE

لقراءة جلسة مخبأة، اختر GET واضبط المفتاح مثلًا على:

user:session:123
Enter fullscreen mode Exit fullscreen mode

لأي أمر غير موجود في القائمة، استخدم تبويب Run Redis Command:

KEYS user:*
Enter fullscreen mode Exit fullscreen mode

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

نماذج متقدمة وقيود

قبل بناء مجموعة اختبارات كبيرة، ضع هذه النقاط في الاعتبار:

  • الحلقات: عند التكرار على الصفوف ضمن خطوة ForEach، أشر إلى العنصر الحالي باستخدام: 
{{$.StepID.element.field}}
Enter fullscreen mode Exit fullscreen mode

استبدل StepID برقم خطوة الحلقة الفعلي.

  • التفرع بناءً على قيمة قاعدة البيانات: استخرج حقل الحالة، ثم وجّه السيناريو بناءً عليه. يمكنك دمج ذلك مع المنطق الشرطي في سيناريوهات اختبار API، مثل تنفيذ مسار عند paid ومسار آخر عند pending.

  • توجيه البيئة: عرّف اتصال قاعدة بيانات لكل بيئة، وسيستخدم Apidog الاتصال المطابق للبيئة النشطة.

  • الإجراءات المخزنة: لا تتعامل الواجهة المرئية مع العمليات المعقدة مثل الإجراءات المخزنة. اجعل SQL في خطوات الاختبار عبارات مباشرة مثل SELECT وINSERT وUPDATE وDELETE.

  • Oracle: يتطلب Oracle تثبيت Oracle Client على جهازك قبل إنشاء الاتصال.

التعامل مع بيانات الاعتماد لكل بيئة

لا يجب أن يصل اختبار بالخطأ إلى بيانات الإنتاج. أنشئ اتصال قاعدة بيانات لكل بيئة، مثل:

local
staging
Enter fullscreen mode Exit fullscreen mode

يحتوي كل اتصال على مضيفه وكلمة مروره الخاصة.

بعدها بدّل البيئة من القائمة المنسدلة في أعلى الواجهة. يوجه Apidog الاستعلامات تلقائيًا إلى الاتصال المطابق للبيئة الحالية:

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

لا تحتاج إلى تعديل SQL بين البيئات.

وبما أن بيانات الاعتماد تُخزن محليًا ولا تُزامن مع المشروع السحابي، تبقى كلمات مرور الإنتاج خارج المشروع المشترك.

أتمتة السيناريو باستخدام Apidog CLI

بعد نجاح السيناريو في التطبيق، شغّله دون واجهة مستخدم ضمن CI حتى تتحقق طلبات السحب من قاعدة البيانات، وليس فقط من عقد HTTP.

ثبّت CLI وسجّل الدخول:

npm install -g apidog-cli
apidog login --with-token <YOUR_ACCESS_TOKEN>
Enter fullscreen mode Exit fullscreen mode

ثم شغّل السيناريو بمعرفه مقابل بيئة محددة:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t <scenario_id> -e <env_id> -r cli
Enter fullscreen mode Exit fullscreen mode

المعاملات هي:

  • -t: معرف سيناريو الاختبار.
  • -e: معرف البيئة.
  • -r: أداة التقرير، مثل cli أو html أو junit.

لأكثر من تقرير:

-r html,cli
Enter fullscreen mode Exit fullscreen mode

تذكر أن تفاصيل اتصال قاعدة البيانات محلية، لذلك يحتاج مشغل CI إلى إعداد الاتصال أو التكوين المصدر (exported configuration) للوصول إلى قاعدة البيانات.

إذا كنت تشغّل السيناريو على مجموعة بيانات، راجع:

الأسئلة الشائعة

ما قواعد البيانات المتاحة مجانًا والمدفوعة؟

تتوفر MySQL وSQL Server 2014+ وPostgreSQL وOracle ضمن الخطة المجانية. تحتاج ClickHouse وMongoDB وRedis إلى خطة مدفوعة. يمكنك تنزيل Apidog وتجربة قواعد البيانات المجانية أولًا.

هل يمكن استخدام قيمة من قاعدة البيانات في طلب لاحق؟

نعم. أضف Post Processor من نوع Database Operation، شغّل استعلام SELECT، ثم استخدم Extract Result To Variable مع JSONPath مثل:

$[0].fulfillment_ref
Enter fullscreen mode Exit fullscreen mode

بعدها استخدم المتغير في الطلب التالي:

{{fulfillment_ref}}
Enter fullscreen mode Exit fullscreen mode

راجع تمرير البيانات بين خطوات الاختبار للمبدأ نفسه مع استجابات HTTP.

هل يحصل أعضاء الفريق تلقائيًا على اتصالات قاعدة البيانات؟

لا. تُخزن بيانات اعتماد الاتصال محليًا على كل جهاز ولا تتم مزامنتها مع السحابة. يجب على كل عضو إعداد اتصاله بنفسه.

لماذا يفشل اتصال MySQL 8؟

قد يكون السبب هو إضافة المصادقة الافتراضية caching_sha2_password. جرّب تبديل المستخدم إلى mysql_native_password:

ALTER USER ... IDENTIFIED WITH mysql_native_password;
Enter fullscreen mode Exit fullscreen mode

هل يمكن تشغيل الإجراءات المخزنة أو منطق قاعدة بيانات معقد؟

ليس من خلال الواجهة المرئية. استخدم عبارات SQL مباشرة مثل SELECT وINSERT وUPDATE وDELETE في خطوات الاختبار.

خلاصة

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

اتبع هذا التسلسل:

  1. هيّئ بيانات معروفة في Pre Processor.
  2. نفّذ طلب API.
  3. تحقق من الصف المخزن في Post Processor.
  4. استخرج القيم التي أنشأها الخادم لاستخدامها في الطلبات التالية.
  5. أنشئ اتصالًا منفصلًا لكل بيئة لتشغيل السيناريو بأمان محليًا أو على بيئة الاختبار.

ابدأ بخطوة بسيطة: نزّل Apidog، اربط اتصال MySQL بقاعدة بيانات التطوير، وأضف Post Processor واحدًا يقرأ الصف الذي أنشأه طلبك.

Top comments (0)