در مقاله قبلی خود، پروتکل‌های اتوماسیون موجود، یعنی WebDriver "Classic" و Chrome DevTools Protocol (CDP) را به همراه مزایا و محدودیت‌های مربوطه بررسی کردیم.
WebDriver BiDi را وارد کنید، آینده اتوماسیون مرورگر! این یک پروتکل استاندارد جدید اتوماسیون مرورگر است که در حال حاضر در حال توسعه است، با هدف ترکیب بهترین های WebDriver "Classic" و CDP. WebDriver BiDi نوید ارتباط دو طرفه را می دهد، به طور پیش فرض آن را سریع می کند و با کنترل سطح پایین همراه است.
| WebDriver BiDi | |
|---|---|
| WebDriver "Classic" | پروتکل Chrome DevTools (CDP) |
| بهترین پشتیبانی از مرورگرهای متقابل | پیام رسانی سریع و دوطرفه |
| استاندارد W3C | کنترل سطح پایین را فراهم می کند |
| برای آزمایش ساخته شده است | |
چشم انداز WebDriver BiDi این است که به شما اجازه می دهد با استفاده از هر یک از ابزارهای مورد علاقه خود تست بنویسید و آنها را در هر مرورگر یا درایوری به طور خودکار انجام دهید و انعطاف پذیری کامل را به شما می دهد.
استاندارد سازی
گروه کاری WebDriver BiDi شامل گروه متنوعی از فروشندگان مرورگر، پروژه های اتوماسیون مرورگر منبع باز و شرکت هایی است که راه حل های اتوماسیون مرورگر را ارائه می دهند. این همکاری آینده امیدوار کننده ای را برای اتوماسیون مرورگر تضمین می کند.
کار بیشتر در این مخزن GitHub انجام می شود. جلسات ماهانه با همه فروشندگان اصلی مرورگر وجود دارد که پیشرفت واقعی را گزارش می‌کنند و در مورد جزئیات قابل بحث و ناشناخته بحث می‌کنند. گروه کاری بین شرکتی اطمینان حاصل می کند که تصمیمات با همه ذینفعان هماهنگ است.
ایجاد و پیاده سازی یک پروتکل جدید کار کمی نیست. این نیاز به تلاش های هماهنگ از سوی فروشندگان مختلف دارد که با هم همکاری کنند. این فرآیند شامل:
- مشخصات : فرآیند درخواست نظرات (RFC) برای جمع آوری بازخورد در مورد پیشنهاد.
- تأیید : مجموعه‌ای از آزمایش‌هایی که در سراسر پلتفرم‌ها قابل اجرا هستند و به عنوان منبع حقیقت برای همه پیاده‌سازی‌ها عمل می‌کنند.
- پیاده سازی : مرورگرها پروتکل ها را طبق مشخصات پیاده سازی می کنند و تست های تایید را پشت سر می گذارند.
چالش ها
در این بخش، چالش‌های پیاده‌سازی WebDriver BiDi را بررسی خواهیم کرد، زیرا به دنبال ایجاد تعادل بین سازگاری، قابلیت استفاده و پیاده‌سازی است.
فراتر از یک کلون CDP: سازگاری بین مرورگرها را در بر می گیرد
CDP، با عناصر خاص Chrome و DevTools، نمی‌تواند مستقیماً در مشخصات WebDriver BiDi تکرار شود. پیاده‌سازی CDP همانطور که هست برای سایر مرورگرها غیرممکن است و مشخصاتی را که صرفاً نحوه انجام این کار را مستند می‌کند بی‌معنا می‌سازد.
اطمینان از تاخیر کم
WebDriver BiDi باید به گونه‌ای طراحی شود که تأخیر بالا را بدون کاهش عملکرد مدیریت کند. در CDP، تأخیر کم است زیرا کلاینت و سرور تقریباً همیشه در یک ماشین فیزیکی اجرا می‌شوند، اما در WebDriver BiDi اینطور نیست. بنابراین، WebDriver BiDi باید تعداد رفت و برگشت های مورد نیاز بین مشتری و سرور را به حداقل برساند.
اولویت بندی ارگونومی در BiDi
در حالی که از توسعه دهندگان انتظار نمی رود که کلاینت های WebDriver BiDi را از ابتدا بسازند، اجتناب از پیچیده شدن بیش از حد پروتکل بسیار مهم است. یک BiDi بیش از حد پیچیده نه تنها برای پیاده سازی چالش برانگیز است، بلکه کار با آن نیز دشوار است و مانع پذیرش و استفاده می شود.
اطمینان از قابلیت پیاده سازی BiDi
WebDriver BiDi باید با در نظر گرفتن محدودیت های مرورگرهای مختلف، به طور واقعی قابل پیاده سازی باشد. به عنوان مثال، حفظ تمام اشیاء جاوا اسکریپت که تا به حال توسط BiDi در معرض کلاینت‌ها قرار گرفته‌اند، می‌تواند منجر به نشت حافظه شود، در حالی که نگه‌داشتن هیچ کدام مانع اشکال‌زدایی و تعامل با جاوا اسکریپت صفحه می‌شود. ایجاد تعادلی که امکان اتوماسیون موثر مرورگر را بدون به خطر انداختن عملکرد فراهم کند، ضروری است.
غلبه بر چالش ها
در این بخش، استراتژی‌های بکار گرفته شده برای مقابله با چالش‌های پیاده‌سازی WebDriver BiDi را مورد بحث قرار خواهیم داد.
نمونه سازی سریع
پرداختن به چالش پیاده سازی برای موفقیت BiDi بسیار مهم است. برای تسریع پیشرفت در مشخصات و آزمایش‌ها، ما یک رویکرد نمونه‌سازی سریع با استفاده از NodeJS اتخاذ کردیم. این نه تنها ما را قادر می‌سازد تا راه‌حل‌های مختلف را آزمایش کنیم، بلکه توسعه تست‌های پلتفرم وب را نیز تسهیل می‌کند.
طراحی با در نظر گرفتن عملکرد
این تصمیم طراحی توسط عملکرد هدایت می شود زیرا در برخی موارد تأخیر در WebDriver BiDi زیاد است. به عنوان مثال، هنگام بازیابی یک شناسه و مقدار شی از مرورگر، WebDriver BiDi فقط به یک رفت و برگشت نیاز دارد، در حالی که CDP به دو سفر نیاز دارد. این به این دلیل است که WebDriver BiDi می‌تواند هم ID و هم مقدار را در یک پاسخ برگرداند (نتیجه نباید JSON-Serializable باشد)، در حالی که CDP باید آنها را جداگانه برگرداند.
تاکید بر تست های بستر وب (WPT)
تست های پلتفرم وب نقش مهمی در کارهای BiDi دارند. در حال حاضر تحت پوشش WebDriver "Classic" و WebDriver BiDi، WPT به عنوان یک مرجع قابل اعتماد برای همه پیاده سازی ها عمل می کند. این آزمایش‌ها به گونه‌ای طراحی شده‌اند که اجرا شوند و در پیاده‌سازی‌های مختلف اجرا شوند و از اجرای پروتکل بین مرورگرهای متقابل یکنواخت اطمینان حاصل کنند که برای موفقیت WebDriver BiDi حیاتی است. آخرین نتیجه WPT را در داشبورد بررسی کنید.
برنامه و پیشرفت فعلی چیست؟
برای درک مسیر پروژه، به نقشه راه WebDriver BiDi نگاهی بیندازید. نقشه راه کاری است در حال پیشرفت و دائما در حال تغییر است.
برای وضعیت پیاده‌سازی در مرورگرها به آخرین آزمایش‌های پلتفرم وب مراجعه کنید، زیرا منبع حقیقت است.
با نقاط عطف پروژه همراه باشید تا پیشرفت آن را نظارت کنید.
دستاوردهای به دست آمده در سال 2023 را کشف کنید و در جریان آخرین پیشرفت ها باشید!
پشتیبانی از WebDriver BiDi: چگونه می توانید کمک کنید
آیا در مورد آینده اتوماسیون مرورگر با WebDriver BiDi هیجان زده هستید؟ در اینجا چگونه می توانید حمایت خود را نشان دهید:
- آزمایش کننده و پذیرنده اولیه باشید و به شکل گیری آینده WebDriver BiDi کمک کنید.
- انتشار دهید! پروژه را با استفاده از هشتگ #WebDriverBiDi در شبکه های اجتماعی به اشتراک بگذارید.
- درخواست حمایت کنید . درخواست ویژگی را ارسال کنید یا با ابزارهای مورد علاقه خود در مورد برنامه های آنها برای پذیرش WebDriverBiDi بررسی کنید.
- در RFC شرکت کنید و در مورد API ها بازخورد ارائه دهید.
سوالات رایج
آیا WebDriver BiDi قرار است جایگزین پروتکل Chrome DevTools (CDP) شود؟
خیر. مرورگرهای مبتنی بر Chromium به استفاده از CDP برای اهداف اشکال‌زدایی ادامه خواهند داد، در حالی که WebDriver BiDi مشخصات جدیدی برای رفع نیازهای آزمایشی با یک API ارگونومیک‌تر است.
از آنجایی که Puppeteer از CDP استفاده می کند، آیا این به این معنی است که Puppeteer منسوخ خواهد شد؟
خیر. با این حال، WebDriver BiDi Puppeteer را قادر می سازد تا به یک ابزار اتوماسیون بین مرورگرها تبدیل شود.
آیا نقشه راه عمومی دارید؟
بله، از نقشه راه ما در GitHub دیدن کنید.
،
در مقاله قبلی خود، پروتکل‌های اتوماسیون موجود، یعنی WebDriver "Classic" و Chrome DevTools Protocol (CDP) را به همراه مزایا و محدودیت‌های مربوطه بررسی کردیم.
WebDriver BiDi را وارد کنید، آینده اتوماسیون مرورگر! این یک پروتکل استاندارد جدید اتوماسیون مرورگر است که در حال حاضر در دست توسعه است و هدف آن ترکیب بهترین WebDriver "Classic" و CDP است. WebDriver BiDi نوید ارتباط دو طرفه را می دهد، به طور پیش فرض آن را سریع می کند و با کنترل سطح پایین همراه است.
| WebDriver BiDi | |
|---|---|
| WebDriver "Classic" | پروتکل Chrome DevTools (CDP) |
| بهترین پشتیبانی از مرورگرهای متقابل | پیام رسانی سریع و دوطرفه |
| استاندارد W3C | کنترل سطح پایین را فراهم می کند |
| برای آزمایش ساخته شده است | |
چشم انداز پشت WebDriver BiDi این است که به شما امکان می دهد با استفاده از هر یک از ابزارهای مورد علاقه خود، تست ها را بنویسید و آنها را در هر مرورگر یا درایوری به طور خودکار انجام دهید و انعطاف پذیری کامل را به شما می دهد.
استاندارد سازی
گروه کاری WebDriver BiDi شامل گروه متنوعی از فروشندگان مرورگر، پروژه های اتوماسیون مرورگر منبع باز و شرکت هایی است که راه حل های اتوماسیون مرورگر را ارائه می دهند. این همکاری آینده امیدوار کننده ای را برای اتوماسیون مرورگر تضمین می کند.
کار بیشتر در این مخزن GitHub انجام می شود. جلسات ماهانه با همه فروشندگان اصلی مرورگر وجود دارد که پیشرفت واقعی را گزارش می‌کنند و در مورد جزئیات قابل بحث و ناشناخته بحث می‌کنند. گروه کاری بین شرکتی اطمینان حاصل می کند که تصمیمات با همه ذینفعان هماهنگ است.
ایجاد و پیاده سازی یک پروتکل جدید کار کمی نیست. این امر مستلزم تلاش های هماهنگ فروشندگان مختلف است که با یکدیگر همکاری و همکاری کنند. این فرآیند شامل:
- مشخصات : فرآیند درخواست نظرات (RFC) برای جمع آوری بازخورد در مورد پیشنهاد.
- تأیید : مجموعه‌ای از آزمایش‌هایی که در سراسر پلتفرم‌ها قابل اجرا هستند و به عنوان منبع حقیقت برای همه پیاده‌سازی‌ها عمل می‌کنند.
- پیاده سازی : مرورگرها پروتکل ها را طبق مشخصات پیاده سازی می کنند و تست های تایید را پشت سر می گذارند.
چالش ها
در این بخش، چالش‌های پیاده‌سازی WebDriver BiDi را بررسی می‌کنیم، زیرا به دنبال ایجاد تعادل بین سازگاری، قابلیت استفاده و پیاده‌سازی است.
فراتر از یک کلون CDP: سازگاری بین مرورگرها را در بر می گیرد
CDP، با عناصر خاص Chrome و DevTools، نمی‌تواند مستقیماً در مشخصات WebDriver BiDi تکرار شود. پیاده‌سازی CDP همانطور که هست برای سایر مرورگرها غیرممکن خواهد بود و مشخصاتی را که صرفاً نحوه انجام این کار را مستند می‌کند بی‌معنی می‌سازد.
تضمین تاخیر کم
WebDriver BiDi باید به گونه‌ای طراحی شود که تأخیر بالا را بدون کاهش عملکرد مدیریت کند. در CDP، تأخیر کم است زیرا کلاینت و سرور تقریباً همیشه در یک ماشین فیزیکی اجرا می‌شوند، اما در WebDriver BiDi اینطور نیست. بنابراین، WebDriver BiDi باید تعداد رفت و برگشت های مورد نیاز بین مشتری و سرور را به حداقل برساند.
اولویت بندی ارگونومی در BiDi
در حالی که از توسعه دهندگان انتظار نمی رود که کلاینت های WebDriver BiDi را از ابتدا بسازند، اجتناب از پیچیده شدن بیش از حد پروتکل بسیار مهم است. یک BiDi بیش از حد پیچیده نه تنها برای پیاده سازی چالش برانگیز است، بلکه کار با آن نیز دشوار است و مانع پذیرش و استفاده می شود.
اطمینان از قابلیت پیاده سازی BiDi
WebDriver BiDi باید با در نظر گرفتن محدودیت های مرورگرهای مختلف، به طور واقعی قابل پیاده سازی باشد. به عنوان مثال، حفظ تمام اشیاء جاوا اسکریپت که تا به حال توسط BiDi در معرض کلاینت‌ها قرار گرفته‌اند، می‌تواند منجر به نشت حافظه شود، در حالی که نگه‌نداشتن هیچ کدام مانع اشکال‌زدایی و تعامل با جاوا اسکریپت صفحه می‌شود. ایجاد تعادلی که امکان اتوماسیون موثر مرورگر را بدون به خطر انداختن عملکرد فراهم کند، ضروری است.
غلبه بر چالش ها
در این بخش، استراتژی‌های بکار گرفته شده برای مقابله با چالش‌های پیاده‌سازی WebDriver BiDi را مورد بحث قرار خواهیم داد.
نمونه سازی سریع
پرداختن به چالش پیاده سازی برای موفقیت BiDi بسیار مهم است. برای تسریع پیشرفت در مشخصات و آزمایش‌ها، ما یک رویکرد نمونه‌سازی سریع با استفاده از NodeJS اتخاذ کردیم. این نه تنها ما را قادر می‌سازد تا راه‌حل‌های مختلف را آزمایش کنیم، بلکه توسعه تست‌های پلتفرم وب را نیز تسهیل می‌کند.
طراحی با در نظر گرفتن عملکرد
این تصمیم طراحی توسط عملکرد هدایت می شود زیرا در برخی موارد تأخیر در WebDriver BiDi زیاد است. به عنوان مثال، هنگام بازیابی یک شناسه و مقدار شی از مرورگر، WebDriver BiDi فقط به یک رفت و برگشت نیاز دارد، در حالی که CDP به دو سفر نیاز دارد. این به این دلیل است که WebDriver BiDi می‌تواند هم ID و هم مقدار را در یک پاسخ برگرداند (نتیجه نباید JSON-Serializable باشد)، در حالی که CDP باید آنها را جداگانه برگرداند.
تاکید بر تست های بستر وب (WPT)
تست های پلتفرم وب نقش مهمی در کارهای BiDi دارند. در حال حاضر تحت پوشش WebDriver "Classic" و WebDriver BiDi، WPT به عنوان یک مرجع قابل اعتماد برای همه پیاده سازی ها عمل می کند. این تست‌ها به گونه‌ای طراحی شده‌اند که اجرا شوند و در پیاده‌سازی‌های مختلف اجرا شوند و از اجرای پروتکل متقابل مرورگر منسجم اطمینان حاصل کنند، که برای موفقیت WebDriver BiDi حیاتی است. آخرین نتیجه WPT را در داشبورد بررسی کنید.
برنامه و پیشرفت فعلی چیست؟
برای درک مسیر پروژه، به نقشه راه WebDriver BiDi نگاهی بیندازید. نقشه راه کاری است در حال پیشرفت و دائما در حال تغییر است.
برای وضعیت پیاده‌سازی در مرورگرها به آخرین آزمایش‌های پلتفرم وب مراجعه کنید، زیرا منبع حقیقت است.
با نقاط عطف پروژه همراه باشید تا پیشرفت آن را نظارت کنید.
دستاوردهای به دست آمده در سال 2023 را کشف کنید و در جریان آخرین پیشرفت ها باشید!
پشتیبانی از WebDriver BiDi: چگونه می توانید کمک کنید
آیا در مورد آینده اتوماسیون مرورگر با WebDriver BiDi هیجان زده هستید؟ در اینجا چگونه می توانید حمایت خود را نشان دهید:
- آزمایش کننده و پذیرنده اولیه باشید و به شکل گیری آینده WebDriver BiDi کمک کنید.
- انتشار دهید! پروژه را با استفاده از هشتگ #WebDriverBiDi در شبکه های اجتماعی به اشتراک بگذارید.
- درخواست حمایت کنید . درخواست ویژگی را ارسال کنید یا با ابزارهای مورد علاقه خود در مورد برنامه های آنها برای پذیرش WebDriverBiDi بررسی کنید.
- در RFC شرکت کنید و در مورد API ها بازخورد ارائه دهید.
سوالات رایج
آیا WebDriver BiDi قرار است جایگزین پروتکل Chrome DevTools (CDP) شود؟
خیر. مرورگرهای مبتنی بر Chromium به استفاده از CDP برای اهداف اشکال‌زدایی ادامه خواهند داد، در حالی که WebDriver BiDi مشخصات جدیدی برای رفع نیازهای آزمایشی با یک API ارگونومیک‌تر است.
از آنجایی که Puppeteer از CDP استفاده می کند، آیا این به این معنی است که Puppeteer منسوخ خواهد شد؟
خیر. با این حال، WebDriver BiDi Puppeteer را قادر می سازد تا به یک ابزار اتوماسیون بین مرورگرها تبدیل شود.
آیا نقشه راه عمومی دارید؟
بله، از نقشه راه ما در GitHub دیدن کنید.