نگاهی به گذشته: تکامل اتوماسیون تست

تولد اتوماسیون تست

بیایید به دهه 1990 بازگردیم، زمانی که مرورگر وب متولد شد. اتوماسیون تست تا دهه 2000 با ظهور پروژه‌های Selenium و WebDriver برای مقابله با چالش‌های تست بین مرورگرها و چند دستگاه به واقعیت تبدیل نشد.

این دو پروژه در سال 2011 به عنوان Selenium WebDriver به یکدیگر پیوستند و در سال 2018 به استاندارد W3C تبدیل شدند. ما معمولاً از آن به عنوان WebDriver یا WebDriver "Classic" یاد می کنیم.

تکامل پروژه Selenium WebDriver.
تکامل پروژه Selenium WebDriver

تست اتوماسیون قبل از WebDriver "Classic" بسیار مشکل بود. توانایی خودکار کردن تست مرورگر به طور قابل توجهی کیفیت زندگی توسعه دهندگان و آزمایش کنندگان را بهبود بخشید.

ظهور جاوا اسکریپت

همانطور که توسعه وب برای تکیه بیشتر بر جاوا اسکریپت تکامل یافت، راه حل های اتوماسیون جدیدی مانند WebdriverIO، Appium، Nightwatch، Protractor (منسوخ شده)، Testcafe، Cypress، Puppeteer و Playwright ظهور کردند.

ابزارهای اتوماسیون جاوا اسکریپت
ابزارهای اتوماسیون جاوا اسکریپت

رویکردهای اتوماسیون

به طور کلی، این ابزارها را می توان به دو گروه عمده بر اساس نحوه خودکارسازی مرورگرها سازماندهی کرد:

  • سطح بالا : ابزارهایی که جاوا اسکریپت را در مرورگر اجرا می کنند. به عنوان مثال، Cypress و TestCafe از API های وب و Node.js برای اجرای آزمایش ها به طور مستقیم در مرورگر استفاده می کنند. واقعیت جالب - اولین نسخه سلنیوم نیز از همین رویکرد استفاده می کرد.
  • سطح پایین : ابزارهایی که دستورات از راه دور را خارج از مرورگر اجرا می کنند. وقتی ابزارها به کنترل بیشتری نیاز دارند، مانند باز کردن چندین تب یا شبیه‌سازی حالت دستگاه، در آن زمان است که باید دستورات از راه دور را برای کنترل مرورگر از طریق پروتکل‌ها اجرا کنند. دو پروتکل اصلی اتوماسیون WebDriver "Classic" و Chrome DevTools Protocol (CDP) هستند.

در بخش بعدی نگاهی به این دو پروتکل خواهیم انداخت تا نقاط قوت و محدودیت های آنها را درک کنیم.

WebDriver Classic و CDP.

WebDriver "Classic" در مقابل پروتکل Chrome DevTools (CDP)

WebDriver "Classic" یک استاندارد وب است که توسط همه مرورگرهای اصلی پشتیبانی می شود. اسکریپت های اتوماسیون دستورات را از طریق درخواست های HTTP به سرور درایور صادر می کنند که سپس از طریق پروتکل های داخلی و مخصوص مرورگر با مرورگرها ارتباط برقرار می کند.

در حالی که از پشتیبانی متقابل مرورگر عالی برخوردار است و API های آن برای آزمایش طراحی شده اند، می تواند کند باشد و برخی از کنترل های سطح پایین را پشتیبانی نمی کند.

WebDriver 'Classic'.
WebDriver "Classic"

به عنوان مثال، تصور کنید یک اسکریپت آزمایشی دارید که روی یک عنصر 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 '{}'

از سوی دیگر، پروتکل کروم DevTools (CDP) در ابتدا برای Chrome DevTools و اشکال زدایی طراحی شد، اما توسط Puppeteer برای اتوماسیون پذیرفته شد. CDP مستقیماً با مرورگرهای مبتنی بر Chromium از طریق اتصالات WebSocket ارتباط برقرار می کند و عملکرد سریعتر و کنترل سطح پایین را ارائه می دهد.

با این حال، فقط با مرورگرهای مبتنی بر Chromium کار می کند و یک استاندارد باز نیست. علاوه بر این، APIهای CDP نسبتاً پیچیده هستند. در برخی موارد، کار با CDP ارگونومیک نیست. به عنوان مثال، کار با iframe های خارج از فرآیند نیاز به تلاش زیادی دارد.

CDP.
پروتکل Chrome DevTools

برای مثال، با کلیک بر روی یک عنصر await coffee.click(); به یک سری دستورات CDP ترجمه می شود.

// 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 "Classic" توسعه یافت، نیازی به کنترل سطح پایین وجود نداشت. اما زمان تغییر کرده است، وب اکنون بسیار توانمندتر است و آزمایش امروز نیازمند اقدامات دقیق تری است.

از آنجایی که CDP برای پوشش تمام نیازهای اشکال زدایی طراحی شده است، در مقایسه با WebDriver "Classic" از کنترل های سطح پایین بیشتری پشتیبانی می کند. این می تواند ویژگی هایی مانند:

  • گرفتن پیام های کنسول
  • رهگیری درخواست های شبکه
  • شبیه سازی حالت دستگاه
  • شبیه سازی موقعیت جغرافیایی
  • و بیشتر!

اینها در WebDriver "Classic" به دلیل معماری متفاوت امکان پذیر نبود - WebDriver "Classic" مبتنی بر HTTP است و اشتراک و گوش دادن به رویدادهای مرورگر را دشوار می کند. از طرف دیگر، CDP مبتنی بر WebSocket است و به طور پیش فرض از پیام رسانی دو طرفه پشتیبانی می کند.

مورد بعدی: WebDriver BiDi

در اینجا خلاصه ای از نقاط قوت WebDriver "Classic" و CDP آمده است:

WebDriver "Classic" پروتکل Chrome DevTools (CDP)
بهترین پشتیبانی از مرورگرهای متقابل پیام رسانی سریع و دوطرفه
استاندارد W3C کنترل سطح پایین را فراهم می کند
برای آزمایش ساخته شده است

WebDriver BiDi قصد دارد بهترین جنبه های WebDriver "Classic" و CDP را ترکیب کند. این یک پروتکل استاندارد جدید اتوماسیون مرورگر است که در حال حاضر در حال توسعه است.

درباره پروژه WebDriver BiDi - نحوه کار، چشم انداز و فرآیند استانداردسازی بیشتر بیاموزید.