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

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 ใช้ประโยชน์จาก Web API และ Node.js เพื่อทำการทดสอบในเบราว์เซอร์โดยตรง เรื่องน่ารู้คือ Selenium เวอร์ชันแรกก็ใช้วิธีการเดียวกันนี้ด้วย
• ระดับต่ำ: เครื่องมือที่เรียกใช้คำสั่งจากระยะไกลภายนอกเบราว์เซอร์ เมื่อเครื่องมือต่างๆ ต้องการการควบคุมที่มากยิ่งขึ้น เช่น การเปิดแท็บหลายแท็บหรือการจำลองโหมดอุปกรณ์ นั่นจึงเป็นช่วงเวลาที่จำเป็นต้องเรียกใช้คำสั่งจากระยะไกลเพื่อควบคุมเบราว์เซอร์ผ่านโปรโตคอล โปรโตคอลหลักของระบบอัตโนมัติ 2 รายการ ได้แก่ WebDriver "คลาสสิก" และ Chrome DevTools Protocol (CDP)

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

WebDriver "คลาสสิก" เทียบกับ Chrome DevTools Protocol (CDP)

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

แม้ว่า Google Chrome จะรองรับการทำงานข้ามเบราว์เซอร์ได้อย่างยอดเยี่ยม และ 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 แต่นำมาใช้โดย 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 ทั้งวิธีการทำงาน วิสัยทัศน์ และกระบวนการกำหนดมาตรฐาน