نظرة على الماضي: تطوّر الأساليب المبرمَجة التجريبية

Jecelyn Yeen

Maksim Sadym

بداية التشغيل الآلي للاختبار

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

في عام 2011، تعاون هذان المشروعان مع Selenium WebDriver وأصبحا معيارًا ضِمن إطار W3C في عام 2018. نشير إليها عادةً باسم WebDriver أو WebDriver "كلاسيكي".

كان اختبار الأتمتة قبل WebDriver "كلاسيكي" صعبًا للغاية. من خلال توفير إمكانية إجراء اختبار المتصفح بشكل مبرمَج، حسّنت بشكل كبير جودة تجربة المطوّرين والمختبِرين.

تطوّر JavaScript

مع تطوّر تطوير الويب للاعتماد بشكل أكبر على JavaScript، ظهرت حلول تلقائية جديدة، مثل WebdriverIO وAppium و Nightwatch وProtractor (متوقّف نهائيًا) وTestcafe وCypress وPuppeteer وPlaywright.

أساليب التشغيل الآلي

بشكل عام، يمكن تنظيم هذه الأدوات في مجموعتَين رئيسيتَين استنادًا إلى طريقة تشغيل المتصفّحات آليًا:

• المستوى العالي: الأدوات التي تنفذ JavaScript داخل المتصفح. على سبيل المثال، يستفيد كل من Cypress وTestCafe من واجهات برمجة تطبيقات الويب وNode.js لإجراء الاختبارات في المتصفح مباشرةً. حقيقة ممتعة: استخدم الإصدار الأول من Selenium الطريقة نفسها أيضًا.
• مستوى منخفض: الأدوات التي تنفّذ الأوامر عن بُعد خارج المتصفِّح. عندما تتطلب الأدوات قدرًا أكبر من التحكُّم، مثل فتح علامات تبويب متعددة أو محاكاة وضع الجهاز، يكون ذلك عندما تحتاج إلى تنفيذ الأوامر عن بُعد للتحكّم في المتصفِّح من خلال البروتوكولات. بروتوكولا التشغيل الآلي الرئيسيان هما WebDriver "الكلاسيكي" وبروتوكول أدوات مطوّري البرامج في Chrome (CDP).

في القسم التالي، سنلقي نظرة على هذين البروتوكولين لفهم نقاط القوة والقيود المفروضة علىهما.

WebDriver "كلاسيكي" مقابل بروتوكول أدوات مطوّري البرامج في Chrome (CDP)

WebDriver "الكلاسيكي" هو معيار ويب متوافق مع جميع المتصفحات الرئيسية. تُصدر النصوص البرمجية للتشغيل الآلي أوامر من خلال طلبات HTTP إلى خادم برنامج التشغيل، الذي يتصل بعد ذلك بالمتصفّحات من خلال بروتوكولات داخلية خاصة بالمتصفّح.

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

على سبيل المثال، لنفترض أنّ لديك نصًا برمجيًا تجريبيًا ينقر على أحد العناصر await coffee.click();. وقد تمت ترجمتها إلى سلسلة من طلبات HTTP.

# WebDriver: Click on a coffee element

curl -X POST http://127.0.0.1:4444/session/:element_id/element/click
   -H 'Content-Type: application/json'
   -d '{}'

من ناحية أخرى، تم تصميم بروتوكول أدوات مطوّري البرامج في Chrome (CDP) في البداية من أجل أدوات مطوّري البرامج في Chrome وتصحيح الأخطاء، ولكن اعتمده Puppeteer لإجراء التشغيل الآلي. يتواصل CDP مباشرةً مع المتصفحات المستندة إلى Chromium من خلال اتصالات WebSocket، ما يوفر أداء أسرع وعناصر تحكم منخفضة المستوى.

ومع ذلك، فهي تعمل فقط مع المتصفحات المستندة إلى Chromium ولا تمثل معيارًا مفتوحًا. علاوة على ذلك، تتسم واجهات برمجة تطبيقات CDP بالتعقيد نسبيًا. في بعض الحالات، لا يسهُل العمل مع CDP. على سبيل المثال، يتطلب العمل على إطارات iframe خارج المعالجة الكثير من الجهد.

على سبيل المثال، تتم ترجمة النقر على عنصر "await coffee.click();" إلى سلسلة من أوامر بروتوكول "أدوات مطوّري البرامج في Chrome".

// CDP: Click on a coffee element

// Mouse pressed
{ 
  command: 'Input.dispatchMouseEvent', 
  parameters: {
    type: 'mousePressed', x: 10.34, y: 27.1, clickCount: 1 }
}

// Mouse released
{ 
  command: 'Input.dispatchMouseEvent', 
  parameters: {
    type: 'mouseReleased', x: 10.34, y: 27.1, clickCount: 1 }
}

ما هي عناصر التحكّم المنخفضة المستوى؟

عندما تم تطوير WebDriver "كلاسيكي"، لم تكن هناك حاجة إلى تحكُّم منخفض المستوى. لكن بمرور الزمن، أصبح الويب أكثر قدرة على الاشتراك، والاختبار يتطلّب اليوم إجراءات أكثر دقة.

نظرًا لتصميم CDP لتلبية جميع الاحتياجات المتعلقة بتصحيح الأخطاء، فهو يتوافق مع المزيد من عناصر التحكّم ذات المستوى المنخفض مقارنةً بـ WebDriver "الكلاسيكي". وهو قادر على التعامل مع ميزات مثل:

• تسجيل رسائل وحدة التحكم
• اعتراض طلبات الشبكة
• محاكاة وضع الجهاز
• محاكاة رصد الموقع الجغرافي
• ومقاييس أخرى

لم يكن ذلك ممكنًا في WebDriver "الكلاسيكي" بسبب اختلاف البنية، حيث يعتمد WebDriver "كلاسيكي" على بروتوكول HTTP، ما يجعل من الصعب الاشتراك والاستماع إلى أحداث المتصفّح. من ناحية أخرى، يستند CDP إلى WebSocket، يدعم المراسلة ثنائية الاتجاه بشكل افتراضي.

الخطوات التالية: WebDriver BiDi

في ما يلي ملخص لنقاط القوة في كل من WebDriver "كلاسيكي" وCDP:

تهدف WebDriver BiDi إلى الجمع بين أفضل جوانب WebDriver "الكلاسيكي" وCDP. وهو بروتوكول قياسي جديد للتشغيل الآلي للمتصفِّح، وهو قيد التطوير حاليًا.

يمكنك الاطّلاع على مزيد من المعلومات عن مشروع WebDriver BiDi، أي آلية عمله والرؤية وعملية توحيد المقاييس.