كيفية الانتقال من ReadyAPI إلى Apidog

ملخص سريع

يعد الانتقال من ReadyAPI إلى Apidog أمرًا بسيطًا لمجموعات الاختبار التي تعتمد بشكل كبير على REST. قم بتصدير مشروع ReadyAPI الخاص بك، وحوّل ما تستطيع عبر استيراد OpenAPI، وأعد إنشاء نصوص Groovy البرمجية يدويًا في JavaScript. تتطلب حالات اختبار SOAP معظم العمل اليدوي. خطط لترحيل مرحلي للحفاظ على تغطية الاختبار مستمرة.

💡

Apidog هي منصة تطوير واجهات برمجة تطبيقات (API) مجانية ومتكاملة تستورد مواصفات OpenAPI وتجميعات Postman وتقوم بتشغيل مسارات اختبار باستخدام نصوص JavaScript البرمجية. جرب Apidog مجانًا، لا يلزم وجود بطاقة ائتمان.

زر

مقدمة

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

يوضح هذا الدليل عملية الترحيل خطوة بخطوة. ويغطي تصدير مشروع ReadyAPI الخاص بك، وتحليل ما لديك، والاستيراد إلى Apidog، والتعامل مع تحويل Groovy إلى JavaScript، وإعداد CI/CD، وإدارة الفترة الانتقالية عندما تعمل كلتا الأداتين بالتوازي.

الخطوة 1: تدقيق مشروع ReadyAPI الخاص بك قبل البدء

قبل تصدير أي شيء، اقضِ بعض الوقت في فهم محتويات مشروع ReadyAPI الحالي. يشكل هذا التدقيق المدة التي يستغرقها الترحيل والمكان الذي تركز فيه جهودك.

افتح مشروع ReadyAPI الخاص بك وأجب عن هذه الأسئلة:

كم عدد مجموعات الاختبار وحالات الاختبار وخطوات الاختبار لديك؟ افتح لوحة Navigator وقم بالعد. يمكن ترحيل مشروع يحتوي على 50 حالة اختبار في غضون ساعات. بينما مشروع يحتوي على 500 حالة يستغرق أيامًا.

ما هي نسبة حالات اختبار REST مقابل SOAP؟ يتم ترحيل حالات اختبار REST بشكل أنظف بكثير. تتطلب حالات اختبار SOAP مزيدًا من العمل اليدوي، خاصة إذا كانت تستخدم سياسات WS-Security أو تأكيدات معقدة.

كم يبلغ حجم نصوص Groovy البرمجية في حالات الاختبار لديك؟ انقر فوق حالات الاختبار الخاصة بك وابحث عن خطوات Script. احسب عدد حالات الاختبار التي تحتوي على منطق Groovy مخصص. تتطلب كل نص Groovy برمجي تحويلاً يدويًا إلى JavaScript.

هل تستخدم اختبارات مدفوعة بالبيانات مع خطوات DataSource؟ يدعم Apidog الاختبار المدفوع بالبيانات باستخدام ملفات بيانات CSV و JSON، ولكن الإعداد يختلف عن نمط DataSource/DataSink في ReadyAPI.

هل تستخدم Properties أو خطوات Property Transfer بكثافة؟ تعمل هذه الأنماط بشكل مختلف في Apidog. ستستخدم المتغيرات والمتغيرات البيئية بدلاً من ذلك.

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

وثّق نتائجك. جدول بيانات يتضمن اسم حالة الاختبار، والنوع (REST/SOAP)، وهل تحتوي على Groovy (نعم/لا)، والتعقيد (بسيط/متوسط/معقد) يمنحك تقديرًا للترحيل قبل البدء.

الخطوة 2: تصدير مشروع ReadyAPI الخاص بك

يخزن ReadyAPI المشاريع كملفات XML. لتصدير مشروع للتحليل:

افتح ReadyAPI وافتح مشروعك.
انتقل إلى File > Save As لحفظ المشروع كملف XML مستقل.
احفظ أي ملفات بيانات خارجية (CSV، Excel، بيانات اختبار XML) التي تشير إليها اختباراتك.
لاحظ أي تكوينات بيئية قمت بإعدادها ضمن قسم Environments.

يحتوي ملف المشروع XML على جميع مجموعات الاختبار وحالات الاختبار وخطوات الاختبار والنصوص البرمجية والتكوين. وهو تمثيل كامل لمشروع الاختبار الخاص بك.

الخطوة 3: استخراج تعريفات واجهة برمجة التطبيقات (API) الخاصة بك

يمر مسار الترحيل الأسهل لواجهات برمجة تطبيقات REST عبر مواصفات OpenAPI، وليس مباشرة من ملف XML لمشروع ReadyAPI.

الخيار أ: التصدير من ReadyAPI. إذا كان لديك خدمة REST في ReadyAPI، فانقر بزر الفأرة الأيمن عليها في لوحة Navigator وابحث عن خيار تصدير أو إنشاء تعريف واجهة برمجة تطبيقات. يمكن لـ ReadyAPI تصدير مواصفات Swagger/OpenAPI من تعريفات الخدمة.

الخيار ب: استخدم مواصفات OpenAPI للواجهة الخلفية الخاصة بك. إذا كانت خدمة الواجهة الخلفية الخاصة بك تعرض بالفعل مواصفات OpenAPI (على /openapi.json أو ما شابه)، فقم بتنزيلها مباشرة. يمنحك هذا التعريف الأكثر دقة وحداثة.

الخيار ج: الاستخراج يدويًا. لواجهات برمجة التطبيقات التي لا تحتوي على مواصفات موجودة، استخدم طلبات ReadyAPI REST كمصدر. لاحظ نقاط النهاية، ونصوص الطلب، والرؤوس، وهياكل الاستجابة. ستقوم بإعادة إنشائها في Apidog.

الخطوة 4: الاستيراد إلى Apidog

مع مواصفات OpenAPI الجاهزة، قم باستيرادها إلى Apidog.

افتح Apidog وأنشئ مشروعًا جديدًا.
انتقل إلى APIs > Import واختر التنسيق الخاص بك (OpenAPI 3.0، Swagger 2.0، إلخ).
قم بتحميل ملف المواصفات أو الصق عنوان URL.
يقوم Apidog بتحليل المواصفات وإنشاء تعريفات واجهة برمجة التطبيقات لجميع نقاط النهاية.

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

إذا كان لديك مجموعات Postman موجودة (ربما تم ترحيلها من أداة سابقة)، فإن Apidog يستوردها أيضًا عبر File > Import > Postman.

الخطوة 5: إعادة إنشاء حالات الاختبار لنقاط نهاية REST

بالنسبة لحالات اختبار REST، تكون عملية الترحيل كالتالي:

افتح حالة اختبار ReadyAPI REST.
حدد الطلبات والتأكيدات وأي مصادر بيانات تستخدمها.
أنشئ حالة اختبار مقابلة في Apidog عن طريق تحديد نقطة نهاية API وإضافة خطوات اختبار.

تترجم التأكيدات على النحو التالي:

يصبح تأكيد الاحتواء (يحتوي النص على سلسلة) تأكيد JavaScript: pm.test('contains value', () => { pm.expect(pm.response.text()).to.include('expected string'); });
تأكيد رمز الحالة: pm.test('status 200', () => { pm.response.to.have.status(200); });
تأكيدات JSONPath: pm.test('field value', () => { pm.expect(pm.response.json().fieldName).to.equal('expected'); });

بالنسبة لاختبارات GET و POST المباشرة بدون Groovy، يكون هذا الترحيل سريعًا. يمكن إعادة إنشاء حالة اختبار بسيطة تحتوي على 5 إلى 10 تأكيدات في 15 إلى 30 دقيقة.

الخطوة 6: تحويل نصوص Groovy البرمجية إلى JavaScript

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

أنماط Groovy الشائعة ومكافئاتها في JavaScript:

قراءة قيمة الاستجابة:

// Groovy (ReadyAPI)
def response = context.expand('${TestStep#Response}')
def json = new groovy.json.JsonSlurper().parseText(response)
def value = json.fieldName

// JavaScript (Apidog)
const response = pm.response.json();
const value = response.fieldName;

تعيين متغير:

// Groovy
testRunner.testCase.setPropertyValue('myVariable', someValue)

// JavaScript
pm.variables.set('myVariable', someValue);

تأكيدات شرطية:

// Groovy
if (statusCode == 200) {
  assert responseBody.contains("success")
}

// JavaScript
if (pm.response.code === 200) {
  pm.test('response contains success', () => {
    pm.expect(pm.response.text()).to.include('success');
  });
}

معالجة التاريخ:

// Groovy
def now = new Date()
def formatted = now.format('yyyy-MM-dd')

// JavaScript
const now = new Date();
const formatted = now.toISOString().split('T')[0];

بالنسبة لنصوص Groovy المعقدة التي تحتوي على استيرادات مكتبات Java أو منطق معقد، يتطلب التحويل تحليلاً دقيقًا. اقرأ كل نص برمجي، وافهم ما يفعله، واكتب JavaScript مكافئًا. لا تحاول الترجمة الآلية - الدلالات قريبة بما يكفي لخداعك ولكنها مختلفة بما يكفي لتسبب أخطاء صامتة.

الخطوة 7: التعامل مع حالات اختبار SOAP

تعتبر حالات اختبار SOAP الجزء الأكثر تحديًا في أي عملية ترحيل من ReadyAPI. لا يحتوي Apidog على أدوات SOAP مخصصة، لذا تتطلب هذه الحالات نهجًا مختلفًا.

بالنسبة لخدمات SOAP التي تعرض أيضًا واجهة REST (وهو أمر شائع بشكل متزايد)، قم بترحيل الاختبارات لاستخدام نقاط نهاية REST وتجاهل طبقة SOAP.

بالنسبة لخدمات SOAP التي لا تحتوي على بديل REST، لديك خياران:

الاحتفاظ بـ ReadyAPI لـ SOAP فقط. قم بتشغيل ReadyAPI بالتوازي لحالات اختبار SOAP واستخدم Apidog لـ REST. هذا حل وسط عملي يحافظ على تغطية SOAP دون عرقلة ترحيل REST.

استخدام SoapUI مفتوح المصدر. SoapUI مفتوح المصدر مجاني ويتعامل مع اختبار SOAP. لا يمكنه استبدال جميع ميزات ReadyAPI، لكنه يغطي اختبار الوظائف الأساسية لـ SOAP دون تكلفة ترخيص.

لا تتعجل في ترحيل SOAP. حالات اختبار WS-Security على وجه الخصوص تنطوي على مخاطر كبيرة إذا لم يتم إعادة إنتاج تأكيداتها بعناية.

الخطوة 8: إعداد البيئات والمتغيرات

تتوافق ميزة Environment في ReadyAPI مع نظام Environment في Apidog. لكل بيئة ReadyAPI قمت بتكوينها:

أنشئ بيئة مطابقة في Apidog (Settings > Environments).
أضف نفس المتغيرات: عناوين URL الأساسية، رموز المصادقة، الرؤوس المشتركة، إلخ.
تحقق من أن حالات الاختبار تشير إلى المتغيرات باستخدام بناء جملة Apidog الصحيح: {{variableName}} في حقول URL ونصوص الطلب.

الخطوة 9: تهيئة CI/CD

يتضمن إعداد CI في ReadyAPI عادةً أمر testrunner على وكلاء البناء. يستخدم Apidog نهجًا مختلفًا.

قم بتثبيت واجهة سطر الأوامر (CLI) الخاصة بـ Apidog على وكيل CI الخاص بك:

npm install -g apidog-cli

قم بتشغيل مجموعة اختبار:

apidog run "path/to/collection.json" -e "environment-id"

بالنسبة لـ GitHub Actions، قد تبدو خطوة سير العمل كالتالي:

- name: Run API tests
  run: apidog run collection.json --environment staging

بالنسبة لـ Jenkins، أضف خطوة shell إلى مسار العمل الخاص بك تستدعي واجهة سطر الأوامر الخاصة بـ Apidog. لا يلزم تثبيت ReadyAPI على وكيل البناء.

حدث ملفات تكوين CI الخاصة بك لاستخدام الأمر الجديد. قم بإزالة إشارات ReadyAPI testrunner بمجرد أن يتم التحقق من صحة تشغيل Apidog بشكل صحيح.

الخطوة 10: تشغيل كلتا الأداتين بالتوازي خلال الفترة الانتقالية

لا تنتقل من ReadyAPI إلى Apidog في يوم واحد. قم بتشغيل كلتا الأداتين بالتوازي خلال دورة إصدار واحدة على الأقل.

خلال الفترة المتوازية:

قم بتشغيل اختبارات ReadyAPI في CI كبوابة اختبار موثوقة.
قم بتشغيل اختبارات Apidog بالتوازي وقارن النتائج.
ابحث عن أي إخفاقات في Apidog لا تظهر في ReadyAPI.
أضف تدريجيًا حالات اختبار جديدة في Apidog فقط.

بمجرد أن تكون واثقًا من أن Apidog يلتقط نفس الإخفاقات التي يلتقطها ReadyAPI، قم بإزالة ReadyAPI من مسار CI. احتفظ بتثبيت ReadyAPI متاحًا لبضعة أشهر كنسخة احتياطية.

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

ما هي المدة التي يستغرقها ترحيل ReadyAPI إلى Apidog عادة؟ يمكن لمشروع REST فقط مع الحد الأدنى من البرمجة النصية بـ Groovy أن يتم ترحيله في يوم إلى ثلاثة أيام. قد يستغرق مشروع كبير يحتوي على نصوص Groovy نصية مكثفة، وحالات اختبار SOAP، وهياكل اختبار معقدة من أسبوعين إلى ستة أسابيع. يمنحك التدقيق في الخطوة 1 التقدير الأوضح قبل الالتزام.

هل ستعمل ملفات بيانات اختبار ReadyAPI الخاصة بي في Apidog؟ تعمل ملفات بيانات CSV مع ميزة الاختبار المدفوع بالبيانات في Apidog. تنسيق الاستيراد مشابه. تتطلب ملفات Excel التحويل إلى CSV أولاً. تحتاج ملفات بيانات XML إلى إعادة هيكلة اعتمادًا على كيفية استخدامها في ReadyAPI.

هل يمكنني تشغيل ReadyAPI و Apidog في نفس مسار CI أثناء الترحيل؟ نعم، وهذا هو النهج الموصى به. أضف خطوة Apidog CLI إلى مسار العمل الحالي الخاص بك جنبًا إلى جنب مع خطوة ReadyAPI testrunner. قارن النتائج تشغيلًا تلو الآخر خلال الفترة الانتقالية.

هل أحتاج إلى إعادة إنشاء البيئات يدويًا أم هناك طريقة آلية؟ يجب إعادة إنشاء تكوين البيئة يدويًا في Apidog. لا يوجد استيراد آلي لإعدادات بيئة ReadyAPI. احتفظ ببيئات ReadyAPI مفتوحة في نافذة واحدة أثناء إعادة إنشائها في Apidog.

ماذا يحدث لاختبارات ReadyAPI التي ليس لها مكافئ REST؟ بالنسبة لحالات اختبار SOAP فقط التي ليس لها بديل REST، فإن الخيارات العملية هي الحفاظ على ReadyAPI (ربما على عدد أقل من التراخيص) لتلك الاختبارات المحددة، أو الترحيل إلى SoapUI مفتوح المصدر، أو قبول فجوة في الاختبار إذا كانت الخدمات قديمة ومنخفضة المخاطر.

هل يدعم Apidog نفس أنواع التأكيدات مثل ReadyAPI؟ يدعم Apidog تأكيدات JavaScript التي يمكنها التعبير عن نفس الشروط المنطقية مثل أنواع التأكيدات المضمنة في ReadyAPI. يختلف بناء الجملة ولكن القدرات قابلة للمقارنة لاختبار REST. بعض أنواع التأكيدات الخاصة بـ ReadyAPI (SOAP Fault, WS-Security) ليس لها مكافئ في Apidog.

إن الترحيل من ReadyAPI إلى Apidog هو مشروع ذو مغزى، وليس مهمة بعد ظهر يوم واحد. الفرق التي تخطط له بعناية، وتبدأ بتدقيق واضح، وترحل حالات اختبار REST أولاً، وتشغل كلتا الأداتين بالتوازي خلال الفترة الانتقالية تكمله دون فجوات في التغطية أو تراجعات في الاختبار.