WebDriver BiDi - อนาคตของการทำงานอัตโนมัติแบบข้ามเบราว์เซอร์

Jecelyn Yeen

Maksim Sadym

ในบทความก่อนหน้านี้ เราได้ตรวจสอบโปรโตคอลการทำงานอัตโนมัติที่มีอยู่ ซึ่งได้แก่ WebDriver "คลาสสิก" และ Chrome DevTools Protocol (CDP) พร้อมทั้งข้อดีและข้อจำกัดที่เกี่ยวข้อง

พบกับ WebDriver BiDi ซึ่งเป็นอนาคตของการทำงานอัตโนมัติของเบราว์เซอร์ ซึ่งเป็นโปรโตคอลการทำงานอัตโนมัติของเบราว์เซอร์มาตรฐานใหม่ที่อยู่ระหว่างการพัฒนา โดยมีเป้าหมายเพื่อรวมข้อดีของทั้ง WebDriver "คลาสสิก" และ CDP WebDriver BiDi สัญญาว่าจะสื่อสารแบบ 2 ทิศทาง ซึ่งทําให้ทำงานได้อย่างรวดเร็วโดยค่าเริ่มต้น และมาพร้อมกับการควบคุมระดับล่าง

วิสัยทัศน์เบื้องหลัง WebDriver BiDi คือให้คุณเขียนการทดสอบโดยใช้เครื่องมือที่ชื่นชอบและทำให้การทดสอบเป็นแบบอัตโนมัติในเบราว์เซอร์หรือไดรเวอร์ใดก็ได้ ซึ่งให้ความยืดหยุ่นอย่างเต็มที่

มาตรฐาน

กลุ่มทำงาน BiDi ของ WebDriver ประกอบด้วยกลุ่มผู้ให้บริการเบราว์เซอร์ที่หลากหลาย โปรเจ็กต์การทำงานอัตโนมัติของเบราว์เซอร์แบบโอเพนซอร์ส และบริษัทที่เสนอโซลูชันการทำงานอัตโนมัติของเบราว์เซอร์ การทํางานร่วมกันนี้ช่วยให้มั่นใจได้ว่าอนาคตของการทำงานอัตโนมัติของเบราว์เซอร์จะสดใส

งานส่วนใหญ่ทำในที่เก็บ GitHub นี้ มีการนัดหมายทุกเดือนกับผู้ให้บริการเบราว์เซอร์รายใหญ่ทุกรายเพื่อรายงานความคืบหน้าจริงและพูดคุยเกี่ยวกับข้อเท็จจริงที่โต้แย้งได้และยังไม่ทราบ กลุ่มทำงานข้ามบริษัทจะตรวจสอบว่าการตัดสินใจสอดคล้องกับผู้มีส่วนเกี่ยวข้องทั้งหมด

การสร้างและการใช้โปรโตคอลใหม่ไม่ใช่เรื่องง่าย ซึ่งต้องใช้ความพยายามร่วมกันจากผู้ให้บริการหลายรายที่ทำงานร่วมกัน กระบวนการนี้เกี่ยวข้องกับขั้นตอนต่อไปนี้

• ข้อกําหนด: กระบวนการขอความคิดเห็น (RFC) เพื่อรวบรวมความคิดเห็นเกี่ยวกับข้อเสนอ
• การยืนยัน: ชุดการทดสอบที่ทํางานได้บนแพลตฟอร์มต่างๆ ซึ่งเป็นแหล่งข้อมูลที่เชื่อถือได้สําหรับการติดตั้งใช้งานทั้งหมด
• การใช้งาน: เบราว์เซอร์ใช้โปรโตคอลตามข้อกำหนดและผ่านการทดสอบการยืนยัน

ความท้าทาย

ในส่วนนี้ เราจะเจาะลึกความท้าทายในการใช้งาน WebDriver BiDi เนื่องจาก WebDriver BiDi พยายามรักษาสมดุลระหว่างความเข้ากันได้ ความสามารถในการใช้งาน และความสามารถในการติดตั้งใช้งาน

นอกเหนือจากการโคลน CDP: การยอมรับความเข้ากันได้ในเบราว์เซอร์ต่างๆ

CDP ที่มีองค์ประกอบเฉพาะของ Chrome และ DevTools ไม่สามารถจำลองในข้อกำหนด BiDi ของ WebDriver ได้โดยตรง การใช้ CDP ในรูปแบบปัจจุบันนั้นไม่สามารถทำได้ในเบราว์เซอร์อื่นๆ การทำเช่นนี้จึงทําให้ข้อกําหนดเฉพาะที่บันทึกวิธีการทําดังกล่าวไม่มีความหมาย

การดูแลให้มีเวลาในการตอบสนองต่ำ

WebDriver BiDi ต้องออกแบบมาให้จัดการกับเวลาในการตอบสนองสูงโดยไม่ลดประสิทธิภาพ ใน CDP เวลาในการตอบสนองต่ำเนื่องจากไคลเอ็นต์และเซิร์ฟเวอร์ทำงานบนเครื่องจริงเครื่องเดียวกันเกือบทุกครั้ง แต่ไม่ใช่ใน WebDriver BiDi ดังนั้น WebDriver BiDi จึงต้องลดจำนวนรอบที่จำเป็นระหว่างไคลเอ็นต์กับเซิร์ฟเวอร์

ให้ความสำคัญกับหลักสรีรศาสตร์ใน BiDi

แม้ว่านักพัฒนาซอฟต์แวร์จะไม่ต้องสร้างไคลเอ็นต์ WebDriver BiDi ขึ้นมาใหม่ตั้งแต่ต้น แต่สิ่งสำคัญคือต้องหลีกเลี่ยงการทำให้โปรโตคอลซับซ้อนเกินไป BiDi ที่ซับซ้อนเกินไปไม่เพียงแต่จะติดตั้งใช้งานได้ยากเท่านั้น แต่ยังใช้งานยากด้วย ซึ่งจะขัดขวางการนำไปใช้และการใช้งาน

ตรวจสอบความสามารถในการติดตั้งใช้งานของ BiDi

WebDriver BiDi ต้องใช้งานได้จริงโดยคำนึงถึงข้อจำกัดของเบราว์เซอร์ต่างๆ ตัวอย่างเช่น การเก็บออบเจ็กต์ JavaScript ทั้งหมดที่ BiDi แสดงต่อไคลเอ็นต์อาจส่งผลให้หน่วยความจํารั่วไหล ขณะที่การไม่เก็บออบเจ็กต์ใดๆ เลยจะขัดขวางการแก้ไขข้อบกพร่องและการโต้ตอบกับ JavaScript ของหน้า คุณจึงต้องหาจุดสมดุลที่ช่วยให้การทำงานอัตโนมัติของเบราว์เซอร์มีประสิทธิภาพโดยไม่กระทบต่อประสิทธิภาพ

การเอาชนะอุปสรรค

ในส่วนนี้ เราจะพูดถึงกลยุทธ์ที่ใช้เพื่อรับมือกับความท้าทายในการใช้งาน WebDriver BiDi

การสร้างต้นแบบอย่างรวดเร็ว

การแก้ปัญหาด้านความสามารถในการติดตั้งใช้งานเป็นสิ่งสําคัญต่อความสําเร็จของ BiDi เราใช้แนวทางการสร้างต้นแบบอย่างรวดเร็วโดยใช้ NodeJS เพื่อเร่งความคืบหน้าของข้อกำหนดและทดสอบ ซึ่งไม่เพียงช่วยให้เราทดสอบโซลูชันต่างๆ ได้ แต่ยังช่วยพัฒนาการทดสอบแพลตฟอร์มเว็บด้วย

ออกแบบโดยคำนึงถึงประสิทธิภาพ

การตัดสินใจด้านการออกแบบนี้อิงตามประสิทธิภาพ เนื่องจากในบางกรณี เวลาในการตอบสนองของ WebDriver BiDi จะสูง เช่น เมื่อดึงข้อมูลรหัสออบเจ็กต์และค่าจากเบราว์เซอร์ WebDriver BiDi จะต้องใช้การติดต่อแบบไปกลับเพียงครั้งเดียว ขณะที่ CDP ต้องใช้ 2 ครั้ง เนื่องจาก WebDriver BiDi สามารถแสดงผลทั้งรหัสและค่าในการตอบกลับครั้งเดียว (ผลลัพธ์ไม่ควรเป็น JSON ที่แปลงเป็นอนุกรมได้) ขณะที่ CDP ต้องแสดงผลแยกกัน

เน้นที่การทดสอบแพลตฟอร์มเว็บ (WPT)

การทดสอบแพลตฟอร์มเว็บมีบทบาทสำคัญในการทำงานของ BiDi ปัจจุบัน WPT ครอบคลุม WebDriver "คลาสสิก" และ WebDriver BiDi ซึ่งใช้เป็นข้อมูลอ้างอิงที่เชื่อถือได้สำหรับการติดตั้งใช้งานทั้งหมด การทดสอบเหล่านี้ออกแบบมาเพื่อให้ทํางานและผ่านการใช้งานต่างๆ เพื่อให้แน่ใจว่าการเรียกใช้โปรโตคอลข้ามเบราว์เซอร์สอดคล้องกัน ซึ่งสําคัญต่อความสําเร็จของ WebDriver BiDi ดูผลลัพธ์ WPT ล่าสุดในหน้าแดชบอร์ด

แผนและความคืบหน้าปัจจุบันเป็นอย่างไร

ดูแผนพัฒนา WebDriver BiDi เพื่อให้เข้าใจทิศทางของโปรเจ็กต์ แผนงานนี้อยู่ระหว่างการพัฒนาและเปลี่ยนแปลงอยู่เสมอ

โปรดดูสถานะการใช้งานในเบราว์เซอร์ต่างๆ จากการทดสอบแพลตฟอร์มเว็บล่าสุด เนื่องจากเป็นแหล่งข้อมูลที่ถูกต้อง

ติดตามเป้าหมายของโปรเจ็กต์เพื่อตรวจสอบความคืบหน้า

ดูความสำเร็จในปี 2023 และติดตามการพัฒนาล่าสุด

การรองรับ WebDriver BiDi: วิธีที่คุณจะช่วยได้

คุณตื่นเต้นกับอนาคตของการทํางานอัตโนมัติของเบราว์เซอร์ด้วย WebDriver BiDi ไหม วิธีแสดงการสนับสนุนมีดังนี้

• เป็นผู้ทดสอบและผู้ใช้งานตั้งแต่เนิ่นๆ ซึ่งช่วยกำหนดอนาคตของ WebDriver BiDi
• กระจายข่าวเลย แชร์โปรเจ็กต์ในโซเชียลมีเดียโดยใช้แฮชแท็ก #WebDriverBiDi
• ขอรับการสนับสนุน ยื่นคำขอฟีเจอร์หรือสอบถามเครื่องมือโปรดเกี่ยวกับแผนการนำ WebDriverBiDi มาใช้
• เข้าร่วม RFC โดยให้ความคิดเห็นเกี่ยวกับ API

คำถามที่พบบ่อย

WebDriver BiDi จะเข้ามาแทนที่ Chrome DevTools Protocol (CDP) ไหม

ไม่ เบราว์เซอร์ที่ใช้ Chromium จะยังคงใช้ CDP เพื่อวัตถุประสงค์ในการแก้ไขข้อบกพร่องต่อไป ส่วน WebDriver BiDi เป็นข้อกำหนดใหม่ที่จะช่วยตอบสนองความต้องการด้านการทดสอบด้วย API ที่ใช้งานง่ายขึ้น

การที่ Puppeteer ใช้ CDP หมายความว่า Puppeteer จะเลิกใช้งานไหม

ไม่ แต่ WebDriver BiDi จะช่วยให้ Puppeteer เป็นเครื่องมือการทำงานอัตโนมัติข้ามเบราว์เซอร์ได้

คุณมีโรดแมปสาธารณะไหม

ใช่ โปรดไปที่แผนงานของเราใน GitHub