มองย้อนกลับไปในอดีต: วิวัฒนาการของการทดสอบอัตโนมัติ

Jecelyn Yeen

Maksim Sadym

จุดกำเนิดของการทำงานอัตโนมัติในการทดสอบ

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

ทั้ง 2 โปรเจ็กต์ได้มาทำงานร่วมกันในปี 2011 ในฐานะ Selenium WebDriver และกลายเป็นมาตรฐาน W3C ในปี 2018 เรามักเรียกโปรแกรมนี้ว่า WebDriver หรือ WebDriver "เวอร์ชันคลาสสิก"

การทดสอบการทำงานอัตโนมัติก่อน WebDriver "คลาสสิก" ค่อนข้างซับซ้อน การที่การทดสอบเบราว์เซอร์เป็นแบบอัตโนมัติช่วยปรับปรุงคุณภาพชีวิตของนักพัฒนาซอฟต์แวร์และผู้ทดสอบได้อย่างมาก

การเพิ่มขึ้นของ JavaScript

เมื่อการพัฒนาเว็บพัฒนาไปใช้ JavaScript มากขึ้น โซลูชันการทำงานอัตโนมัติใหม่ๆ เช่น WebdriverIO, Appium, Nightwatch, Protractor (เลิกใช้งานแล้ว), Testcafe, Cypress, Puppeteer และ Playwright ก็เกิดขึ้น

แนวทางการทำงานอัตโนมัติ

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

• ระดับสูง: เครื่องมือที่เรียกใช้ JavaScript ภายในเบราว์เซอร์ ตัวอย่างเช่น Cypress และ TestCafe ใช้ประโยชน์จาก API ของเว็บและ Node.js เพื่อทำการทดสอบในเบราว์เซอร์โดยตรง เรื่องน่ารู้ก็คือ Selenium เวอร์ชันแรกก็ใช้วิธีเดียวกันนี้เช่นกัน
• ระดับต่ำ: เครื่องมือที่เรียกใช้คำสั่งระยะไกลนอกเบราว์เซอร์ เมื่อเครื่องมือจำเป็นต้องมีการควบคุมที่มากยิ่งขึ้น เช่น การเปิดหลายแท็บหรือการจำลองโหมดอุปกรณ์ นั่นคือเวลาที่เครื่องมือจำเป็นต้องเรียกใช้คำสั่งระยะไกลเพื่อควบคุมเบราว์เซอร์ผ่านโปรโตคอล โปรโตคอลหลักของระบบอัตโนมัติ 2 รายการคือ WebDriver "คลาสสิก" และโปรโตคอลเครื่องมือสำหรับนักพัฒนาเว็บ (CDP) ของ Chrome

ในส่วนถัดไป เราจะมาดูโปรโตคอลทั้ง 2 รายการนี้เพื่อให้เข้าใจถึงจุดแข็งและข้อจำกัด

WebDriver "คลาสสิก" กับโปรโตคอลสำหรับนักพัฒนาเว็บใน Chrome (CDP)

WebDriver "คลาสสิก" คือมาตรฐานเว็บที่เบราว์เซอร์หลักๆ ทั้งหมดรองรับ สคริปต์การทำงานอัตโนมัติจะออกคำสั่งผ่านคำขอ HTTP ไปยังเซิร์ฟเวอร์ไดรเวอร์ ซึ่งจะสื่อสารกับเบราว์เซอร์ผ่านโปรโตคอลภายในเฉพาะเบราว์เซอร์

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

ตัวอย่างเช่น ลองคิดว่าคุณมีสคริปต์ทดสอบที่คลิกองค์ประกอบ 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 DevTools Protocol (CDP) ได้รับการออกแบบมาสำหรับ Chrome DevTools และการแก้ไขข้อบกพร่องเบื้องต้น แต่ Puppeteer ใช้สำหรับการทำงานอัตโนมัติ CDP สื่อสารกับเบราว์เซอร์แบบ Chromium โดยตรงผ่านการเชื่อมต่อ WebSocket มอบประสิทธิภาพที่รวดเร็วขึ้นและการควบคุมในระดับต่ำ

อย่างไรก็ตาม ฟีเจอร์นี้ทำงานร่วมกับเบราว์เซอร์แบบ Chromium เท่านั้น และไม่ใช่มาตรฐานแบบเปิด นอกจากนี้ CDP API ยังค่อนข้างซับซ้อน ในบางกรณี การทำงานกับ CDP ไม่ได้เป็นไปตามหลักสรีรศาสตร์ ตัวอย่างเช่น การทำงานกับ iframe นอกกระบวนการต้องใช้ความพยายามอย่างมาก

ตัวอย่างเช่น การคลิกองค์ประกอบ 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 "คลาสสิก" มีการพัฒนาขึ้นมา คุณไม่จำเป็นต้องใช้การควบคุมระดับต่ำ แต่เวลาได้เปลี่ยนแปลงไป ปัจจุบันเว็บมีความสามารถมากขึ้น และการทดสอบในปัจจุบันต้องการการดำเนินการที่ละเอียดขึ้น

เนื่องจาก CDP ได้รับการออกแบบให้ครอบคลุมความต้องการในการแก้ไขข้อบกพร่องทั้งหมด จึงรองรับการควบคุมในระดับต่ำลงกว่าเมื่อเทียบกับ WebDriver แบบ "คลาสสิก" จึงสามารถจัดการฟีเจอร์ต่างๆ เช่น:

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

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

ขั้นตอนต่อไป: WebDriver BiDi

ต่อไปนี้เป็นสรุปเกี่ยวกับจุดแข็งของทั้ง WebDriver แบบ "คลาสสิก" และ CDP

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

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