ในบทความก่อนหน้านี้ เราได้ตรวจสอบโปรโตคอลการทำงานอัตโนมัติที่มีอยู่ ซึ่งได้แก่ WebDriver "CLASS" และ Chrome DevTools Protocol (CDP) รวมถึงข้อดีและข้อจำกัดต่างๆ ของ WebDriver
ป้อน WebDriver BiDi อนาคตของการทำงานอัตโนมัติของเบราว์เซอร์ ซึ่งเป็นโปรโตคอลมาตรฐานใหม่ของเบราว์เซอร์การทำงานอัตโนมัติซึ่งกำลังอยู่ในระหว่างการพัฒนา โดยมีเป้าหมายรวมการใช้ WebDriver แบบ "คลาสสิก" และ CDP เข้าด้วยกันที่ดีที่สุด WebDriver BiDi รับประกันการสื่อสารแบบ 2 ทิศทาง ทำให้รวดเร็วโดยค่าเริ่มต้น และมาพร้อมการควบคุมในระดับต่ำ
WebDriver BiDi | |
---|---|
WebDriver "คลาสสิก" | โปรโตคอลเครื่องมือสำหรับนักพัฒนาเว็บ (CDP) ใน Chrome |
การสนับสนุนข้ามเบราว์เซอร์ที่ดีที่สุด | การรับส่งข้อความแบบ 2 ทิศทางที่รวดเร็ว |
มาตรฐาน W3C | ให้การควบคุมในระดับต่ำ |
สร้างมาเพื่อการทดสอบ |
วิสัยทัศน์ของ WebDriver BiDi คือการให้คุณเขียนการทดสอบโดยใช้เครื่องมือที่คุณชื่นชอบ และทำให้การทดสอบทำงานโดยอัตโนมัติในเบราว์เซอร์หรือไดรเวอร์ใดก็ได้ ทำให้คุณมีความยืดหยุ่นอย่างเต็มที่
การกำหนดมาตรฐาน
คณะทำงานของ WebDriver BiDi ประกอบด้วยกลุ่มผู้ให้บริการเบราว์เซอร์ที่หลากหลาย โปรเจ็กต์การทำงานอัตโนมัติของเบราว์เซอร์แบบโอเพนซอร์ส และบริษัทที่นำเสนอโซลูชันการทำงานอัตโนมัติสำหรับเบราว์เซอร์ การทำงานร่วมกันนี้จะช่วยให้มั่นใจได้ว่าเบราว์เซอร์ทำงานโดยอัตโนมัติในอนาคต
งานส่วนใหญ่จะทำในที่เก็บ GitHub นี้ มีการประชุมรายเดือนร่วมกับผู้ให้บริการเบราว์เซอร์รายใหญ่ทุกราย เพื่อรายงานความคืบหน้าที่เกิดขึ้นจริงและพูดคุยเกี่ยวกับข้อมูลเฉพาะที่ยังมีข้อโต้แย้งและไม่ทราบ คณะทำงานข้ามบริษัทจะตรวจสอบว่าการตัดสินใจสอดคล้องกับผู้มีส่วนเกี่ยวข้องทุกฝ่าย
การสร้างและปรับใช้โปรโตคอลใหม่ไม่ใช่เรื่องเล็กๆ ต้องอาศัยความพยายามร่วมกันจากผู้ให้บริการหลายรายที่ทำงานร่วมกันและร่วมมือกัน กระบวนการเกี่ยวกับ
- ข้อกำหนด: กระบวนการขอความคิดเห็น (RFC) เพื่อรวบรวมความคิดเห็นเกี่ยวกับข้อเสนอ
- การยืนยัน: ชุดการทดสอบที่ทำงานได้ในทุกแพลตฟอร์ม ซึ่งเป็นแหล่งข้อมูลที่เชื่อถือได้ของการติดตั้งใช้งานทั้งหมด
- การใช้งาน: เบราว์เซอร์ใช้โปรโตคอลตามข้อกำหนดและผ่านการทดสอบการยืนยัน
ชาเลนจ์
ในส่วนนี้ เราจะเจาะลึกความท้าทายในการใช้งาน WebDriver BiDi เนื่องจากต้องสร้างความสมดุลระหว่างความเข้ากันได้ ความสามารถในการใช้งาน และความสามารถในการนำไปใช้งาน
ไม่ใช่แค่การโคลนของ CDP: ใช้ความเข้ากันได้ข้ามเบราว์เซอร์
ไม่สามารถจำลอง CDP โดยตรงในข้อกำหนด WebDriver BiDi ที่มีองค์ประกอบเฉพาะของ Chrome และ DevTools การใช้ 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 ต้องใช้การส่งข้อมูลไป-กลับเพียง 1 รอบ ในขณะที่ CDP ต้องใช้ 2 รอบ ทั้งนี้เนื่องจาก WebDriver BiDi จะแสดงผลทั้งรหัสและค่าในคำตอบเดียว (ผลการค้นหาไม่ควรเป็นอนุกรมแบบ JSON) แต่ CDP ต้องแสดงผลแยกต่างหาก
การเน้นการทดสอบแพลตฟอร์มเว็บ (WPT)
การทดสอบแพลตฟอร์มเว็บมีบทบาทสำคัญในงานของ BiDi โดยขณะนี้ครอบคลุม WebDriver แบบ “คลาสสิก” และ WebDriver BiDi โดย WPT ถือเป็นข้อมูลอ้างอิงที่เชื่อถือได้สำหรับการใช้งานทั้งหมด การทดสอบเหล่านี้ออกแบบมาเพื่อให้ใช้งานและส่งผ่านการใช้งานที่หลากหลาย เพื่อให้มั่นใจได้ว่ามีการเรียกใช้โปรโตคอลข้ามเบราว์เซอร์ที่สอดคล้องกัน ซึ่งถือเป็นสิ่งสำคัญต่อความสำเร็จของ 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