BrowserAct’s stealth browser สามารถผ่านการตรวจสอบการตรวจจับบอท (bot-detection) ในขณะที่การรันแบบ headless เริ่มต้นของ Playwright ถูกระบุว่าเป็นบอท ทั้งที่สคริปต์ทั้งสองชุดดำเนินการตามขั้นตอนการเข้าสู่ระบบ (login flow) แบบเดียวกัน ความแตกต่างนี้แสดงให้เห็นว่าทำไมแนวทางแบบ agent-based ถึงมีความปลอดภัยกว่าเมื่อคุณต้องโต้ตอบกับเว็บไซต์ที่มีการป้องกันการทำงานอัตโนมัติ (automation)

ทำไมการทดสอบนี้จึงสำคัญ

เครื่องมือ automation เป็นหัวใจสำคัญของการทดสอบ การเก็บรวบรวมข้อมูล และการจัดการบัญชี นักพัฒนาส่วนใหญ่มักเลือกใช้ framework ที่ขับเคลื่อนด้วย selector อย่าง Playwright เพราะช่วยให้คุณเขียนคำสั่งที่แม่นยำได้ เช่น “คลิกปุ่มที่มี CSS selector นี้” และตรวจสอบผลลัพธ์ได้อย่างรวดเร็ว อย่างไรก็ตาม เว็บไซต์สมัยใหม่มักฝังสคริปต์ที่คอยตรวจหา headless browser เช่น การใช้ user-agent string แบบทั่วไป, คุณสมบัติ webdriver, หรือรูปแบบการโต้ตอบที่ไม่เหมือนมนุษย์ เมื่อสัญญาณเหล่านี้ปรากฏขึ้น เว็บไซต์จะบล็อกคำขอหรือแสดง CAPTCHA ซึ่งทำให้สคริปต์ใช้งานไม่ได้โดยสิ้นเชิง

Agent browser พยายามเลียนแบบผู้ใช้งานที่เป็นมนุษย์โดยไม่พึ่งพา selector ที่เขียนไว้ล่วงหน้า พวกมันมองหน้าเว็บเป็นชุดขององค์ประกอบที่สามารถโต้ตอบได้ (actionable elements) โดยเลือกองค์ประกอบหนึ่งจากตำแหน่งในดัชนีภายใน (internal index) แทนที่จะใช้ CSS path การทดสอบนี้ได้เปรียบเทียบทั้งสองแนวทางบนหน้าเข้าสู่ระบบที่เรนเดอร์ด้วย JavaScript และเว็บไซต์ที่มีการตรวจสอบบอทโดยเฉพาะ

การทดลอง

ผมได้เขียนสคริปต์สองชุดที่ทำงานในขั้นตอนเดียวกัน ได้แก่ โหลดหน้าเข้าสู่ระบบ, กรอกข้อมูลประจำตัว, กดส่ง และไปยังหน้าคลังสินค้า (inventory page) สคริปต์หนึ่งใช้ Playwright ในโหมด headless เริ่มต้น ส่วนอีกสคริปต์ใช้ stealth browser ของ BrowserAct ซึ่งช่วยพรางลายนิ้วมือ (fingerprints) ที่จะกระตุ้นการตรวจจับบอท

สคริปต์ทั้งสองสามารถยืนยันตัวตนกับไซต์ sandbox ได้สำเร็จ ซึ่งพิสูจน์ว่าขั้นตอนการเข้าสู่ระบบหลักนั้นทำงานได้ไม่ว่าจะใช้เครื่องมือใดก็ตาม ความแตกต่างปรากฏขึ้นเมื่อสคริปต์เข้าไปยังหน้าตรวจสอบบอทโดยเฉพาะซึ่งจะส่งค่า JSON flag isBot กลับมา โดย Playwright รายงานว่า isBot: true ซึ่งทำให้ติดการตรวจสอบถึง 5 รายการ ในขณะที่ BrowserAct ส่งค่า isBot: false ซึ่งบ่งชี้ว่าหน้าเว็บมองว่ามันเป็นผู้เข้าชมที่เป็นมนุษย์ทั่วไป

ผมพบสาเหตุของความแตกต่างนี้จากรายละเอียดทางเทคนิคสองประการ การตั้งค่าเริ่มต้นของ Playwright จะส่ง user-agent string แบบทั่วไปและปล่อยให้ flag webdriver เปิดเผยอยู่ ซึ่งทั้งสองอย่างนี้ตรวจพบได้ง่ายโดยสคริปต์ตรวจจับ ส่วนโหมด stealth ของ BrowserAct จะเขียน user-agent ใหม่, ลบคุณสมบัติ webdriver ออก และปรับลายนิ้วมือ (fingerprint) ให้สอดคล้องกับเบราว์เซอร์บนเดสก์ท็อปทั่วไป

ความแตกต่างของเครื่องมือในระดับโครงสร้างภายใน

หัวข้อ Playwright (เริ่มต้น) BrowserAct (stealth)
รูปแบบการโต้ตอบ ขับเคลื่อนด้วย selector, มีความแน่นอน (deterministic) ขับเคลื่อนด้วย agent, อิงตามดัชนี (index-based)
ความจำเป็นในการเขียน selector ล่วงหน้า จำเป็น; สคริปต์ต้องทราบโครงสร้าง DOM ที่แน่นอน ไม่จำเป็น; agent จะค้นหาองค์ประกอบที่โต้ตอบได้ในขณะรันไทม์
การจัดการเมื่อเลย์เอาต์เปลี่ยน สคริปต์จะพังหาก selector เปลี่ยนแปลง ทำงานต่อไปได้ตราบใดที่ตำแหน่งขององค์ประกอบยังอยู่ในรายการดัชนี
การถูกตรวจจับโดยบอท user-agent และ webdriver ไม่ถูกแก้ไข ลายนิ้วมือ (fingerprints) ถูกพรางไว้อย่างตั้งใจ
กรณีการใช้งานทั่วไป เว็บไซต์ภายใน, UI ที่คงที่, รอบการทดสอบที่รวดเร็ว เว็บไซต์สาธารณะที่มีมาตรการป้องกัน automation, หน้าเว็บที่มีการเปลี่ยนแปลงตลอดเวลา

ตารางนี้แสดงให้เห็นถึงข้อดีข้อเสียในทางปฏิบัติ Playwright จะโดดเด่นเมื่อคุณเป็นเจ้าของเว็บไซต์และสามารถรับประกันตัวระบุองค์ประกอบ (element identifiers) ที่คงที่ได้ ส่วน agent browser จะโดดเด่นเมื่อคุณไม่สามารถคาดเดาโครงสร้างหน้าเว็บได้ หรือเมื่อเว็บไซต์พยายามบล็อกสคริปต์อย่างจริงจัง

ใครได้ประโยชน์และใครที่มีความเสี่ยง

นักพัฒนาที่สร้าง regression suites สำหรับแอปพลิเคชันของตนเองสามารถรักษาต้นทุนให้ต่ำและรักษาความเร็วในการทดสอบให้สูงได้โดยการใช้ Playwright ต่อไป เนื่องจากลักษณะที่แน่นอน (deterministic) ของมันจะช่วยชี้จุดที่ล้มเหลวไปยัง code regressions ได้โดยตรง และการไม่มีเลเยอร์ stealth เพิ่มเติมช่วยลดความซับซ้อนลง

ในทางกลับกัน ทีมที่ทำ data scraping, สร้างบัญชีอัตโนมัติ หรือตรวจสอบเว็บไซต์คู่แข่ง มักจะพบกับอุปสรรคเนื่องจากหน้าเว็บเป้าหมายมีการเปลี่ยนแปลงบ่อยครั้งหรือมีการฝังระบบตรวจจับบอทที่รุนแรง ในสถานการณ์เหล่านั้น agent browser จะช่วยหลีกเลี่ยงทางตันแบบ "คุณคือบอท" และสามารถดำเนินการต่อไปจนถึงข้อมูลที่ต้องการได้

ต้นทุนที่ซ่อนอยู่ของคำว่า “มันทำงานได้”

ผมขอเตือนว่า exit code ที่สำเร็จไม่ได้การันตีว่า automation ทำงานตามที่ตั้งใจไว้ ในการรันด้วย Playwright สคริปต์ทำงานจนจบโดยไม่มี error เกิดขึ้น แต่หน้าเว็บยังคงมองว่าคำขอนั้นเป็นบอท ผลลัพธ์ที่ได้คือความล้มเหลวที่ซ่อนอยู่: ขั้นตอนถัดไป (downstream steps) ที่ต้องพึ่งพาเนื้อหาสำหรับมนุษย์เท่านั้น ไม่ได้รับข้อมูลตามที่คาดหวังไว้

เพื่อตรวจพบความล้มเหลวที่เกิดขึ้นเงียบๆ เหล่านี้ ให้ตรวจสอบหลักฐานบนหน้าเว็บหลังจากการรันแต่ละครั้ง: ตำแหน่งการเลื่อน (scroll position), ความสูงของเอกสาร (document height) และการเรียกใช้งานเครือข่าย (network calls) หาก DOM ดูแตกต่างจากสิ่งที่มนุษย์มองเห็น หรือหากทราฟฟิกเครือข่ายมีการเปลี่ยนเส้นทาง (redirect) ไปยังหน้ายืนยันตัวตน (verification challenges) ที่ไม่คาดคิด แสดงว่าระบบอัตโนมัติอาจทำงานไม่บรรลุเป้าหมาย

บทสรุป

หากคุณเป็นเจ้าของเว็บไซต์และสามารถเขียนสคริปต์โดยใช้ selector ที่มีความเสถียรได้ Playwright ยังคงเป็นทางเลือกที่ใช้งานได้จริง—ทั้งรวดเร็ว ประหยัด และง่ายต่อการรวมเข้ากับ CI pipelines เมื่อคุณต้องเผชิญกับเลย์เอาต์ที่ไม่คุ้นเคย ระบบป้องกันการใช้ระบบอัตโนมัติที่เข้มงวด หรือการเปลี่ยนแปลง UI บ่อยครั้ง เบราว์เซอร์แบบ agent อย่าง BrowserAct จะเป็นทางเลือกที่มีความยืดหยุ่นและทนทานกว่า อย่าเชื่อใจเพียงเพราะการรันสำเร็จโดยไม่ตรวจสอบ ให้ตรวจสอบว่าหน้าเว็บมีการตอบสนองเหมือนที่มนุษย์ทำ และเลือกเครื่องมือที่เหมาะสมกับระดับความเสี่ยง (risk profile) ของเว็บไซต์เป้าหมายของคุณ