Skip to main content

การทดสอบ Visual Regression ด้วยการจับภาพหน้าจอ

ทีมพัฒนาใช้ Webshot เพื่อตรวจจับบั๊กที่ unit test มองไม่เห็น เช่น layout เพี้ยน, ฟอนต์แสดงผลผิดพลาด, ไอคอนหาย, หรือหน้าเว็บพังเมื่อแสดงผลบนอุปกรณ์ต่างๆ ถ่ายภาพหน้า staging, ถ่ายภาพหน้า production, แล้วเปรียบเทียบกัน นำภาพผลต่างไปใส่ในคอมเมนต์ของ PR เพื่อยืนยันว่าการเปลี่ยนแปลงของคุณปลอดภัย (หรือเพื่อพิสูจน์ว่ามีบั๊กใหม่เกิดขึ้น)

🖥️ เดสก์ท็อปเต็มหน้า (PNG, เปรียบเทียบคมชัด) 📱 มือถือเต็มหน้า ⚙️ ใช้ API ฟรีแทน

ทุกปุ่มจะเปิดฟอร์มถ่ายภาพพร้อมตั้งค่าล่วงหน้า คุณสามารถเปลี่ยนรูปแบบและขนาด viewport ได้เมื่อหน้าเว็บโหลดเสร็จ

ทำไมต้องใช้ Webshot สำหรับงานนี้

ถ่ายภาพแม่นยำระดับพิกเซล

โหมด PNG จะรักษาความคมชัดของข้อความและขอบภาพ เหมาะสำหรับเครื่องมือเปรียบเทียบระดับพิกเซล (เช่น `pixelmatch`, ImageMagick `compare`) ซึ่งการบีบอัดของ JPG อาจทำให้เกิดผลลวง (false positive)

Viewport ขนาดเดิมทุกครั้ง

Webshot ถ่ายภาพด้วยขนาด viewport, ตำแหน่งการเลื่อน, และเวลารอโหลดฟอนต์ที่เหมือนกันทุกครั้ง ทำให้ผลการเปรียบเทียบเชื่อถือได้

เป็นมิตรกับ API

เชื่อมต่อ Webshot API ฟรีเข้ากับ CI ของคุณ: ถ่ายภาพก่อนและหลัง deploy, เปรียบเทียบด้วย `pixelmatch`, และสั่งให้ build ล้มเหลวหากจำนวนพิกเซลที่เปลี่ยนไปเกินเกณฑ์ที่กำหนด

ไม่ต้องตั้งค่า headless-Chrome ที่ซับซ้อน

ข้ามขั้นตอนการตั้งค่า puppeteer, การติดตั้งฟอนต์, และ sandbox flags ไปได้เลย Webshot จัดการสิ่งเหล่านี้ให้ทั้งหมดบนโครงสร้างพื้นฐานของเรา CI ของคุณเพียงแค่เรียก HTTP เท่านั้น

วิธีถ่ายภาพเพื่อทดสอบ Visual Regression

  1. เลือกหน้าที่คุณต้องการตรวจสอบ เช่น หน้าแรก, แลนดิ้งเพจสำคัญ, ขั้นตอนการชำระเงิน หรือหน้าใดๆ ที่หากเกิดข้อผิดพลาดแล้วจะส่งผลกระทบ
  2. ถ่ายภาพแต่ละหน้าในรูปแบบ PNG + desktop_full + mobile_full เพื่อสร้างเป็นภาพพื้นฐาน (baseline) ของหน้า production ปัจจุบัน
  3. หลังจากการ deploy ครั้งถัดไป ให้ถ่ายภาพ URL เดิมอีกครั้ง เปรียบเทียบภาพเก่ากับใหม่ด้วย `pixelmatch` หรือ ImageMagick หากมีพิกเซลเปลี่ยนแปลงเกิน 1% ควรให้คนตรวจสอบ
  4. เชื่อมต่อเข้ากับ CI: ใช้ pre-deploy hook ถ่ายภาพหน้า staging, ใช้ post-deploy hook ถ่ายภาพหน้า production และสั่งให้ build ล้มเหลวหากผลต่างเกินเกณฑ์ที่คุณกำหนด

คำถามที่พบบ่อย

การใช้ Headless Chrome ใน CI หมายถึงการต้องติดตั้ง Chromium, ฟอนต์, kernel-flags สำหรับ sandbox และคอยอัปเดตทั้งหมด แต่ด้วย Webshot คุณไม่ต้องติดตั้งอะไรเลย CI ของคุณเพียงแค่เรียก HTTP ไปยัง API ของเราและรับไฟล์ PNG กลับมา เราจัดการเรื่องการอัปเดต Chrome, การแคชฟอนต์ และการป้องกัน SSRF ให้ทั้งหมด

ใช่ เมื่อคุณใช้ PNG + viewport ขนาดเดียวกัน + กลยุทธ์การรอที่เหมือนกัน Webshot จะกำหนดขนาด viewport และรอจนกว่า fonts.ready + network-idle + แอนิเมชันใดๆ ที่ประกาศผ่าน `prefers-reduced-motion` query จะเสร็จสิ้น แอนิเมชันแบบสุ่ม (เช่น lottie loops, พื้นหลังที่ใช้ Date.now()) จะให้ผลต่างกันทุกครั้งที่รัน ควรหยุดการทำงานของสิ่งเหล่านี้ในสภาพแวดล้อมการทดสอบของคุณ

ไม่สามารถทำได้ในครั้งเดียว คุณต้องถ่ายภาพแต่ละ URL แยกกัน แล้วนำมาเปรียบเทียบด้วยไลบรารีอื่น เราต้องการให้ API ของเราเน้นที่การถ่ายภาพ การเปรียบเทียบภาพเป็นสคริปต์เพียง 30 บรรทัด ดูตัวอย่างโค้ดได้ที่ `/developers`

ได้ Webshot จะรอจนกว่าจะถึงสถานะ network-idle (ไม่มี request เป็นเวลา 500ms) และ fonts.ready ก่อนที่จะถ่ายภาพ ดังนั้นแอปที่สร้างด้วย React, Vue, Svelte และ Next.js จะเรนเดอร์จนสมบูรณ์ก่อนการถ่ายสกรีนช็อต สำหรับเว็บไซต์ที่ไม่เคยเข้าสู่สถานะ network-idle (เช่น long polling, websockets) คุณสามารถส่งพารามิเตอร์ `maxWait` ผ่าน API ได้

ฟอร์มสาธารณะฟรีจำกัดที่ 5 ครั้ง/15 นาทีต่อ IP ซึ่งน้อยเกินไปสำหรับ CI แต่ API ระดับฟรีจะให้โควต้าที่มากกว่า ดูรายละเอียดที่ `/developers` สำหรับการทดสอบ regression ปริมาณมาก (50+ ภาพต่อการ build) แผน API เชิงพาณิชย์จะไม่มีการจำกัดต่อ IP

Webshot ทำหน้าที่แค่ถ่ายภาพ คุณต้องจัดการส่วนของการเปรียบเทียบเอง วิธีแก้ปัญหาง่ายๆ สองบรรทัด: `npx pixelmatch baseline.png new.png diff.png` หรือใช้บริการ visual-diff แบบจัดการ (Percy, Chromatic, BackstopJS) แล้วส่งไฟล์ PNG จาก Webshot เข้าไป

พร้อมถ่ายภาพแล้วหรือยัง

ฟรี ไม่ต้องสมัครสมาชิก ไม่มีลายน้ำ แค่วาง URL

📸 เปิดฟอร์มถ่ายภาพ

กรณีการใช้งานอื่นๆ: สกรีนช็อต Google Maps · สกรีนช็อต WordPress · ตรวจสอบคุณภาพแลนดิ้งเพจ · สกรีนช็อตเพื่อเป็นหลักฐานทางกฎหมาย · สกรีนช็อตโซเชียลมีเดีย · สกรีนช็อตสำหรับเวิร์กโฟลว์ของนักพัฒนา · ดูทั้งหมด →

Share: 𝕏 Twitter Facebook LinkedIn