ملخص سريع
يعد الانتقال من ReadyAPI إلى Apidog أمرًا بسيطًا لمجموعات الاختبار التي تعتمد بشكل كبير على REST. قم بتصدير مشروع ReadyAPI الخاص بك، وحوّل ما تستطيع عبر استيراد OpenAPI، وأعد إنشاء نصوص Groovy البرمجية يدويًا في JavaScript. تتطلب حالات اختبار SOAP معظم العمل اليدوي. خطط لترحيل مرحلي للحفاظ على تغطية الاختبار مستمرة.
💡Apidog هي منصة تطوير واجهات برمجة تطبيقات (API) مجانية ومتكاملة تستورد مواصفات OpenAPI وتجميعات Postman وتقوم بتشغيل مسارات اختبار باستخدام نصوص JavaScript البرمجية. جرب Apidog مجانًا، لا يلزم وجود بطاقة ائتمان.
مقدمة
يعد ترحيل البنية التحتية لاختبار واجهة برمجة التطبيقات (API) مهمة تتطلب تخطيطًا دقيقًا خاصة مع مشاريع ReadyAPI التي قد تحتوي على سنوات من حالات الاختبار، ونصوص Groovy، وملفات بيانات، وبيئات، وهياكل اختبار معقدة. يجب معرفة ما يمكن نقله تلقائيًا، وما يحتاج تحويل يدوي، وما يمكن الاستغناء عنه.
هذا الدليل يشرح الخطوات العملية لترحيل مشروعك من ReadyAPI إلى Apidog: تصدير المشروع، تحليل البيانات، الاستيراد، تحويل نصوص Groovy إلى JavaScript، إعداد CI/CD، وإدارة فترة التشغيل المتوازي لتحقيق انتقال سلس دون فقد تغطية الاختبار.
الخطوة 1: تدقيق مشروع ReadyAPI الخاص بك قبل البدء
ابدأ بتدقيق مشروعك لفهم حجم وتفاصيل الترحيل. افتح مشروع ReadyAPI وقم بالإجابة على الأسئلة التالية:
- كم عدد مجموعات وحالات وخطوات الاختبار؟ استخدم لوحة Navigator للعد والتقدير الزمني.
- نسبة REST إلى SOAP؟ حالات REST تُرحّل بسهولة، SOAP يتطلب عمل يدوي أكثر خاصة مع WS-Security أو تأكيدات معقدة.
- كمية نصوص Groovy البرمجية؟ تحقق من وجود منطق Groovy مخصص في خطوات Script؛ كل نص يحتاج تحويل يدوي إلى JavaScript.
- هل تستخدم اختبارات مدفوعة بالبيانات؟ Apidog يدعم البيانات بصيغة CSV أو JSON، لكن الإعداد يختلف عن ReadyAPI.
- استخدام Properties أو Property Transfer؟ Apidog يعتمد على المتغيرات البيئية بدلًا من Properties.
- هل تستخدم اختبارات التحميل مع LoadUI Pro؟ سيتطلب اختبار التحميل إعداد k6 أو أداة خارجية.
وثّق النتائج في جدول بيانات باسم الحالة، النوع (REST/SOAP)، وجود Groovy، مستوى التعقيد. هذا سيساعدك في جدولة الترحيل بدقة.
الخطوة 2: تصدير مشروع ReadyAPI الخاص بك
ReadyAPI يخزن كل شيء في ملف XML. قم بما يلي:
- افتح ReadyAPI وافتح مشروعك.
- من File > Save As احفظ المشروع كملف XML مستقل.
- احفظ أي ملفات بيانات خارجية مستخدمة (CSV، Excel، XML).
- دوّن أي إعدادات للبيئة ضمن Environments.
ملف XML يحتوي كل مجموعات وحالات وخطوات الاختبار والنصوص البرمجية والتكوينات.
الخطوة 3: استخراج تعريفات واجهة برمجة التطبيقات (API)
مسار الترحيل الأسهل لواجهات REST يكون عبر مواصفات OpenAPI:
الخيار أ: التصدير من ReadyAPI
إذا كان لديك خدمة REST، انقر بزر الفأرة الأيمن > تصدير/إنشاء تعريف API (Swagger/OpenAPI).الخيار ب: الحصول على مواصفة OpenAPI مباشرة
إذا كانت الخدمة توفر OpenAPI (مثلاً/openapi.json) فقم بتنزيلها مباشرة.الخيار ج: الاستخراج اليدوي
إذا لم تتوفر المواصفات، استخرج نقاط النهاية ونماذج الطلب/الاستجابة من ReadyAPI يدويًا لإعادة إنشائها لاحقًا في Apidog.
الخطوة 4: الاستيراد إلى Apidog
مع توفر ملف OpenAPI:
- افتح Apidog وأنشئ مشروعًا جديدًا.
- اذهب إلى APIs > Import واختر التنسيق (OpenAPI 3.0، Swagger 2.0، إلخ).
- ارفع الملف أو الصق رابط URL.
- Apidog سيحلل المواصفة ويستخرج النقاط والمعلمات ومخططات الاستجابة تلقائيًا.
إذا كان لديك مجموعات Postman، يمكنك استيرادها عبر File > Import > Postman.
الخطوة 5: إعادة إنشاء حالات الاختبار لنقاط نهاية REST
لترحيل حالات اختبار REST:
- افتح حالة اختبار ReadyAPI REST.
- حدد الطلبات والتأكيدات ومصادر البيانات المستخدمة.
- أنشئ حالة اختبار مقابلة في Apidog وحدد نقطة النهاية وأضف خطوات الاختبار.
ترجمة التأكيدات النموذجية:
// تأكيد الاحتواء
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');
});
عادةً، تستغرق إعادة إنشاء حالة اختبار REST بسيطة من 15 إلى 30 دقيقة.
الخطوة 6: تحويل نصوص Groovy البرمجية إلى JavaScript
هذا الجزء يتطلب جهدًا يدويًا للمشاريع المعتمدة على Groovy. أمثلة شائعة:
قراءة الاستجابة:
// 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 معقد، اقرأ المنطق بعناية واكتب مكافئًا بـ JavaScript بدلًا من الترجمة الآلية.
الخطوة 7: التعامل مع حالات اختبار SOAP
حالات SOAP تتطلب جهدًا يدويًا أكبر:
- إذا كانت خدمة SOAP تقدم أيضًا REST، قم بترحيل الاختبارات إلى REST.
- إذا لم يوجد بديل REST:
- استمر باستخدام ReadyAPI فقط لاختبارات SOAP بالتوازي مع Apidog.
- أو استخدم SoapUI مفتوح المصدر (مناسب للاختبارات الأساسية فقط).
لا تتعجل في ترحيل اختبارات WS-Security أو تأكيدات SOAP المعقدة.
الخطوة 8: إعداد البيئات والمتغيرات
لكل بيئة في ReadyAPI:
- أنشئ بيئة مماثلة في Apidog: Settings > Environments.
- أضف نفس المتغيرات (URLs، رموز المصادقة، الرؤوس).
- استخدم بناء الجملة الصحيح للمتغيرات في Apidog:
{{variableName}}في الحقول المطلوبة.
الخطوة 9: تهيئة CI/CD
استخدم apidog-cli في مسار CI بدلاً من testrunner الخاص بـ ReadyAPI:
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-cli.
بعد التأكد من نجاح التشغيل، أزل أوامر testrunner الخاصة بـ ReadyAPI من مسار العمل.
الخطوة 10: تشغيل كلتا الأداتين بالتوازي خلال الفترة الانتقالية
لا تنتقل دفعة واحدة. شغّل ReadyAPI وApidog معًا لدورة إصدار واحدة على الأقل:
- شغّل اختبارات ReadyAPI في CI كمرجعية.
- شغّل اختبارات Apidog وقارن النتائج.
- عالج أي اختلافات في النتائج.
- أضف حالات اختبار جديدة في Apidog فقط.
- بعد التأكد من التغطية، أزل ReadyAPI تدريجيًا من CI واحتفظ به كنسخة احتياطية لبعض الوقت.
الأسئلة الشائعة
كم يستغرق الترحيل عادة؟
مشروع REST بسيط بدون Groovy: من يوم إلى 3 أيام. مشروع كبير مع نصوص Groovy واختبارات SOAP: من أسبوعين إلى 6 أسابيع. تدقيق الخطوة 1 يحدد التقدير الأدق.
هل تعمل ملفات بيانات ReadyAPI في Apidog؟
يدعم Apidog اختبار البيانات بـ CSV. ملفات Excel يجب تحويلها إلى CSV. ملفات XML تحتاج إعادة هيكلة وفق استخدامك في ReadyAPI.
هل يمكن تشغيل ReadyAPI وApidog في نفس CI أثناء الترحيل؟
نعم. أضف خطوة apidog-cli بجانب testrunner وقارن النتائج حتى تثق في الانتقال الكامل.
هل يجب إعادة إنشاء البيئات يدويًا؟
نعم، يجب نقل إعدادات البيئة يدويًا إلى Apidog. افتح إعدادات ReadyAPI وادخلها يدويًا في Apidog.
ماذا عن اختبارات ReadyAPI التي ليس لها REST؟
لـ SOAP فقط: احتفظ بـ ReadyAPI (حتى بعد تقليل التراخيص)، أو استخدم SoapUI مفتوح المصدر، أو اقبل فجوة اختبار إذا كانت الخدمات منخفضة الأهمية.
هل يدعم Apidog نفس أنواع التأكيدات؟
يدعم Apidog تأكيدات JavaScript تغطي أغلب المنطق الموجود في ReadyAPI لاختبارات REST. بعض تأكيدات SOAP/WS-Security ليس لها مكافئ مباشر.
ترحيل البنية التحتية من ReadyAPI إلى Apidog يتطلب تخطيطًا دقيقًا وتنفيذًا مرحليًا. باتباع الخطوات أعلاه، تستطيع نقل اختبارات REST بسرعة، وتحويل النصوص البرمجية، وضمان استمرار التغطية دون فجوات أو تراجع في جودة الاختبار.
Top comments (0)