เจาะลึก 4 สัญญาณลวงเว็บพัง และบทเรียนการทดสอบระบบอัตโนมัติที่นักพัฒนาต้องรู้
นักพัฒนาแชร์ประสบการณ์ใช้เวลาหนึ่งเย็นตรวจสอบ 27 เว็บแอปพลิเคชัน พบ 4 ครั้งที่เครื่องมืออัตโนมัติแจ้งเตือนว่าระบบพัง แต่ความจริงแล้วปกติทุกอย่าง
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- ตรวจสอบเครื่องมืออัตโนมัติ 27 แอป พบ 4 ครั้งที่แจ้งเตือนเว็บพังทั้งที่ใช้งานได้ปกติ
- การเช็ก DOM หรือ Network อย่างเดียวแยกไม่ออกระหว่างระบบล่มกับข้อจำกัดของเครื่องมือ
- การถ่ายภาพหน้าจอ (Screenshot) ก่อนเริ่มวัดผลคือขั้นตอนที่แม่นยำและได้ผลที่สุด
- ข้อผิดพลาดส่วนใหญ่เกิดจากการถูกบล็อกการเข้าถึง (Filtering) หรือการตั้งค่าเครื่องมือ
เรื่องราวเริ่มต้นจากการใช้เวลาหนึ่งช่วงเย็นเปิดใช้งานเครื่องมือปรับแต่งผลิตภัณฑ์ 3 มิติและพารามิเตอร์บนเว็บไซต์ของผู้ผลิตจำนวน 27 แห่ง เพื่อค้นหาข้อบกพร่องที่เกิดขึ้นจริง โดยพบปัญหาจริงในหลายจุด แต่สิ่งที่น่าสนใจคือมีถึง 4 ครั้งในคืนนั้นที่ระบบอัตโนมัติรายงานว่าแอปพลิเคชันพัง ทั้งที่ระบบยังทำงานเป็นปกติ แม้ว่าการตรวจสอบอัตโนมัติเหล่านั้นจะถูกออกแบบมาอย่างรัดกุมก็ตาม สิ่งเดียวที่ช่วยจับผิดพลาดเหล่านี้ได้คือรูปภาพหน้าจอ
สำหรับผู้ที่เขียนสคริปต์ตรวจสอบหน้าเว็บของผู้อื่น เช่น การเช็ก Uptime, การวิเคราะห์คู่แข่ง, การตรวจสอบการดึงข้อมูล (Scraping) หรือการทำ QA ของวิดเจ็ตฝังตัว คุณมักจะต้องเจอกับปัญหาเหล่านี้ โดยอาการหลักที่พบคือไม่มีแท็ก <canvas> และข้อความ innerText เกือบว่างเปล่า ซึ่งดูเหมือนเป็นปัญหาใหญ่เมื่อหน้าเว็บมีชื่อหัวข้อว่า Configurator แต่ในความเป็นจริง นี่คือลักษณะที่ถูกต้องของเว็บที่ปกติถึง 3 สถานการณ์ด้วยกัน
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
กฎเหล็กข้อแรกที่ถูกนำมาใช้ก่อนการวัดผลใดๆ คือการถ่ายภาพหน้าจอเป็นอันดับแรกและมองดูรูปภาพนั้น สิ่งใดที่ไม่สามารถมองเห็นได้ในภาพ สิ่งนั้นไม่ต้องนำมาวัดผล ซึ่งใช้เวลาเพียงแค่หนึ่งวินาทีแต่ให้ผลลัพธ์คุ้มค่าที่สุด บทเรียนที่ได้คือระบบอัตโนมัติบอกได้แค่ว่าเข้าถึงได้หรือไม่ แต่ไม่เคยบอกว่าใช้งานได้จริง เมื่อใดก็ตามที่คุณกำลังออกแบบการตรวจสอบอัตโนมัติรอบที่ 5 สิ่งที่คุณต้องการจริงๆ อาจเป็นแค่มนุษย์หนึ่งคนเปิดหน้าเว็บแล้วคลิกปุ่มที่เห็นได้ชัดเจนเท่านั้น
"No canvas" and "empty innerText". The two least reliable signals I use. Demoted permanently: they are now a reason to look at a screenshot, never a finding.
ตัวอย่างสัญญาณลวงอื่นๆ ที่พบได้แก่ การอ่านพิกเซลจาก WebGL canvas ของผู้อื่น ซึ่งจะได้ค่าเป็นศูนย์เนื่องจาก WebGL จะล้างบัฟเฟอร์การวาดภาพทิ้งหลังจากการคอมโพสิต เว้นแต่จะตั้งค่า preserve_drawing_buffer ไว้ นอกจากนี้ยังมีปัญหาเรื่อง ERR_ABORTED ที่เกิดจากการตัดการโหลดเว็บเร็วเกินไปก่อนที่เครือข่ายจะนิ่งสนิท รวมถึงปัญหาจากวิดเจ็ตของบุคคลที่สามอย่างตัวบล็อกโฆษณาที่ทำให้เกิดข้อผิดพลาด net::ERR_FAILED และ CORS ในสภาพแวดล้อมของผู้ทดสอบเอง
การวิเคราะห์เพิ่มเติม: ปัญหาความผิดพลาดจากการตรวจสอบอัตโนมัติ (False Positives) มักเกิดขึ้นเมื่อสคริปต์ทำหน้าที่ประเมินเว็บเพจภายนอกที่ไม่ได้เป็นเจ้าของเอง ปัจจัยอย่างนโยบายความปลอดภัยของเว็บเป้าหมาย (WAF), การกรองไอพีดาต้าเซ็นเตอร์ (Datacenter IP filtering) หรือการไม่มี User-Agent ที่ถูกต้อง มักทำให้เครื่องมือตรวจสอบได้รับรหัสสถานะ 403 หรือ 503 กลับมาโดยที่ตัวเว็บไซต์ไม่ได้มีความผิดพลาดใดๆ การเข้าใจข้อจำกัดเหล่านี้ช่วยให้นักพัฒนาไม่ต้องเสียเวลาตรวจสอบสิ่งที่ปกติอยู่แล้ว
ปัญหาเรื่องการถูกบล็อกการเข้าถึง (Filtering) ยังรวมถึงการส่งคำขอแบบไม่มี User-Agent ซึ่งทำให้เว็บเซิร์ฟเวอร์ตอบกลับด้วยรหัส 403 และขนาดข้อมูล 118 ไบต์ แต่หากใช้เบราว์เซอร์จริงจะได้รับรหัส 200 ปกติ การแก้ปัญหาที่ดีกว่าการใช้พร็อกซีภายนอกที่อาจล่มได้พร้อมกัน คือการดึงข้อมูลจากไฟล์ข้างเคียง (Neighbouring object) ในเครือข่ายและคำขอเดียวกัน เพราะระบบกรองใดๆ ไม่สามารถเลือกบล็อกไฟล์หนึ่งแล้วปล่อยไฟล์ข้างเคียงผ่านไปได้หากไฟล์นั้นมีอยู่จริง นอกจากนี้ยังมีข้อควรระวังในทางปฏิบัติคือ ควรให้แต่ละเว็บไซต์มีแท็บเบราว์เซอร์แยกจากกันเด็ดขาด เพื่อป้องกันปัญหาหน้าเว็บค้างแล้วส่งผลให้การนำทางไปยังหน้าอื่นสะดุดตามไปด้วย
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น