Playwright หรือ Cypress: หลายเบราว์เซอร์แลกกับดีบักในหน้าเดียว

เลือก Playwright หากเกณฑ์ผ่านของเว็บต้องครอบคลุมหลายเบราว์เซอร์ หรือเทสต์ต้องควบคุมป๊อปอัป หลายหน้า และผู้ใช้แยกสถานะในสถานการณ์เดียว เลือก Cypress ได้เมื่อเส้นทางสำคัญอยู่ในหน้าเว็บเดียว และทีมใช้การดูคำสั่งพร้อมสถานะหน้าเว็บเพื่อหาจุดล้มระหว่างพัฒนาเป็นประจำ ทั้งสองเครื่องมือทดสอบเว็บข้ามเบราว์เซอร์และช่วยดีบักได้ ความต่างอยู่ที่ระดับการรองรับและวิธีทำงานที่ทีมต้องใช้จริง

ก่อนเทียบความเร็ว ให้แยกความต้องการออกเป็นสามเรื่อง: ต้องผ่านเบราว์เซอร์ชนิดใด ต้องควบคุมหน้าหรือบัญชีพร้อมกันหรือไม่ และเมื่อเทสต์ล้มทีมต้องเห็นหลักฐานอะไร การรันชุดเดียวกันบน Chrome กับ Firefox เป็นคนละโจทย์กับการสั่งผู้ใช้สองบัญชีให้โต้ตอบกันทันที ตัวเลขเวลาจากแอปอื่นตอบคำถามเหล่านี้แทนสถาปัตยกรรมของเว็บทีมไม่ได้

เบราว์เซอร์ที่ต้องผ่านเป็นเงื่อนไขแรก

การตั้งค่าเบราว์เซอร์ของ Playwright รองรับการรันโปรเจ็กต์กับ Chromium, Firefox และ WebKit ด้วยรูปแบบเทสต์ร่วมกัน ทีมจึงใช้เส้นทางผู้ใช้เดียวกันตรวจผลแยกตามเอนจินได้โดยไม่ต้องเขียนสถานการณ์ใหม่ทั้งหมด หากระบบมีข้อผิดพลาดเฉพาะเบราว์เซอร์ ผลที่แยกตามโปรเจ็กต์ช่วยบอกได้ทันทีว่าเกณฑ์ผ่านตกในสภาพแวดล้อมใด

WebKit ที่ Playwright จัดเตรียมเป็นบิลด์ของเอนจิน ไม่ใช่ Safari รุ่นที่ติดตั้งบนเครื่องผู้ใช้ ความแตกต่างของระบบปฏิบัติการและส่วนประกอบอย่างตัวถอดรหัสสื่อยังส่งผลต่อพฤติกรรมได้ หากเว็บพึ่งพาวิดีโอหรือคุณสมบัติของแพลตฟอร์ม การผ่าน WebKit บน CI จึงไม่ควรถูกตีความว่าเท่ากับการผ่าน Safari ทุกเครื่อง ส่วนการทดสอบ Chrome หรือ Edge ที่มีตราผู้ผลิตก็ต้องระบุให้ชัดว่าใช้ตัวติดตั้งจริงหรือ Chromium ที่เครื่องมือจัดเตรียม

รายการเบราว์เซอร์ของ Cypress ครอบคลุม Chrome, Edge และ Firefox ขณะที่ WebKit ยังระบุเป็นการรองรับแบบทดลองซึ่งต้องเปิดตัวเลือกและติดตั้งส่วนประกอบเพิ่ม นั่นไม่ได้ทำให้ Cypress ใช้กับงานข้ามเบราว์เซอร์ไม่ได้ แต่ทำให้ทีมที่กำหนด WebKit เป็นเกณฑ์ผ่านประจำต้องคิดถึงความเสี่ยงของฟีเจอร์ทดลองด้วย หากกลุ่มผู้ใช้หลักอยู่บน Chrome และ Firefox เงื่อนไขนี้อาจไม่ใช่ตัวตัดสิน และควรหันไปดูรูปแบบหน้าของแอปกับวิธีแก้เทสต์ล้มแทน

ให้ระบุในเกณฑ์ผ่านว่าเบราว์เซอร์ใดเป็นข้อบังคับ เบราว์เซอร์ใดใช้ตรวจเป็นระยะ และผลต่างแบบใดถือเป็นบั๊กของแอป ข้อกำหนดนี้สำคัญกว่าการนับจำนวนชื่อเบราว์เซอร์ในตารางเปรียบเทียบ เพราะชื่อเดียวกันอาจหมายถึงเอนจินที่จัดเตรียมให้ รุ่นที่ติดตั้งในเครื่อง หรือสภาพแวดล้อม CI คนละระบบปฏิบัติการ

สถานการณ์เดียวเผยข้อจำกัดของหลายหน้า

สมมติว่าเว็บให้ผู้ใช้เข้าสู่ระบบ เปิดหน้าต่างใหม่ กรอกแบบฟอร์มใน iframe และส่งข้อมูลให้ผู้ใช้อีกบัญชีเห็นทันที ให้ถือทั้งหมดเป็นสถานการณ์สมมติชุดเดียว แล้วกำหนดผลที่ต้องเห็นหลังแต่ละการกระทำ การแยกขั้นตอนเช่นนี้ทำให้เห็นว่าเครื่องมือต้องเพียงตรวจลิงก์ปลายทาง หรือจำเป็นต้องควบคุมสองหน้าและสองสถานะการเข้าสู่ระบบพร้อมกัน

ข้อจำกัดที่ Cypress ระบุ คือไม่สามารถควบคุมเบราว์เซอร์ที่เปิดพร้อมกันมากกว่าหนึ่งตัวได้ แม้จะทดสอบหลายแท็บผ่านปลั๊กอิน @cypress/puppeteer ได้ เอกสารเดียวกันระบุว่า iframe ใช้งานได้แต่ยังมีข้อจำกัด และงานที่ต้องติดต่อเซิร์ฟเวอร์หรือฐานข้อมูลอาจต้องผ่าน cy.task() หรือ cy.request() ความแตกต่างนี้มีผลเมื่อผลทดสอบต้องขึ้นกับการโต้ตอบสดระหว่างหน้าหรือบัญชี ไม่ใช่เพียงการเปิดแต่ละหน้าตามลำดับ

• เข้าสู่ระบบ: ให้ทั้งสองเครื่องมือตรวจสิ่งที่ผู้ใช้เห็นหลังส่งข้อมูล เช่น การเปลี่ยนหน้าและชื่อบัญชีที่แสดง เตรียมข้อมูลตั้งต้นแยกจากขั้นตอนผ่านหน้าจอ เพื่อไม่ให้ความผิดพลาดในการสร้างบัญชีถูกเข้าใจว่าเป็นบั๊กของแบบฟอร์มเข้าสู่ระบบ
• ป๊อปอัปหรือแท็บใหม่: Playwright รอหน้าใหม่ที่เกิดจากการกระทำแล้วตรวจต่อในบริบทเดียวกันได้ ส่วน Cypress ต้องเลือกว่าจะใช้ปลั๊กอินสำหรับแท็บจริง หรือจำกัดเกณฑ์ผ่านไว้ที่ลิงก์และปลายทาง การตรวจว่าลิงก์ถูกต้องไม่เท่ากับการตรวจพฤติกรรมหลังเปิดหลายหน้าพร้อมกัน
• iframe: Playwright มี frameLocator สำหรับหาองค์ประกอบภายในเฟรม ส่วน Cypress ต้องพิจารณาที่มาของเฟรมและวิธีเข้าถึงองค์ประกอบที่แอปใช้อยู่จริง โดยเฉพาะเมื่อเฟรมมาจากบริการภายนอก เกณฑ์ผ่านควรระบุว่าต้องกดหรือกรอกข้อมูลภายในเฟรม หรือเพียงตรวจว่าเฟรมแสดงขึ้นมา
• ผู้ใช้หลายบัญชี: Playwright สร้าง browser context แยกสถานะได้ จึงเหมาะกับสถานการณ์ที่ผู้ส่งและผู้รับต้องเปิดหน้าไว้พร้อมกัน Cypress อาจแบ่งการตรวจแต่ละบทบาทเป็นคนละเทสต์และตั้งสถานะผ่าน API ได้ แต่รูปแบบนั้นตอบคำถามต่างจากการเห็นสองบัญชีโต้ตอบกันสด

หากระบบส่งการแจ้งเตือนให้ผู้ใช้อีกคนทันที การแยกเป็นเทสต์ผู้ส่งและเทสต์ผู้รับอาจพลาดข้อผิดพลาดที่เกิดเฉพาะตอนทั้งสองคนออนไลน์พร้อมกัน ในทางกลับกัน หากธุรกิจต้องการเพียงยืนยันว่าคำขอถูกบันทึกและผู้รับเปิดดูภายหลังได้ การบังคับให้ทุกเทสต์ควบคุมหลายหน้าจะเพิ่มความซับซ้อนโดยไม่เพิ่มหลักฐานที่จำเป็น เกณฑ์ผ่านของผลิตภัณฑ์จึงเป็นตัวกำหนดรูปแบบเทสต์ก่อนเลือก API

ภาษาและงานหลังบ้านเปลี่ยนภาระดูแลชุดทดสอบ

ทีมที่เขียน JavaScript หรือ TypeScript อยู่แล้วเริ่มกับเครื่องมือใดก็ได้โดยไม่ต้องเปลี่ยนภาษาหลักของชุด E2E หากผู้รับผิดชอบเทสต์ต้องทำงานใน Python, Java หรือ .NET ด้วย Playwright มีชุดเครื่องมือสำหรับภาษาเหล่านั้นให้พิจารณา Cypress วางการเขียนเทสต์ไว้ในระบบนิเวศ JavaScript จึงเหมาะเมื่อทีมพร้อมดูแลโค้ดทดสอบในภาษานี้ ความสามารถใช้ภาษาเดียวกับบริการหลังบ้านอาจช่วยลดการสลับบริบท แต่ไม่มีประโยชน์มากนักหากไม่มีคนดูแลเทสต์ในภาษานั้นต่อเนื่อง

การสร้างบัญชีทดสอบ ล้างข้อมูล หรือเตรียมคำสั่งซื้อเป็นงานคนละส่วนกับการคลิกหน้าจอ แม้ทุกงานจะเกิดก่อนการตรวจผลเดียวกัน เมื่อขั้นเตรียมข้อมูลผิด เทสต์อาจล้มก่อนผู้ใช้จำลองจะพบหน้าที่ต้องตรวจ ใน Cypress งานนอกเบราว์เซอร์ต้องมีทางผ่านไปยัง Node หรือ HTTP ที่ออกแบบไว้ ส่วนโค้ดทดสอบ Playwright จัดการการเรียกบริการและการควบคุมหน้าเว็บในกระบวนการเดียวกันได้ ทีมยังต้องทำให้ข้อมูลตั้งต้นแยกจากกันและล้างซ้ำได้ ไม่ว่าเลือกทางใด

ข้อแตกต่างที่ควรลองคือความชัดของความล้มเหลว สมมติว่าการเข้าสู่ระบบไม่สำเร็จเพราะบัญชีที่เตรียมไว้ไม่มีสิทธิ์ เทสต์ที่รายงานเพียงว่าปุ่มปลายทางหาไม่พบทำให้ต้องย้อนตรวจหลายชั้น หากชุดทดสอบแยกผลการสร้างข้อมูล การตอบกลับของ API และสิ่งที่หน้าเว็บแสดง ทีมจะรู้เร็วขึ้นว่าต้องแก้บริการ ขั้นเตรียมข้อมูล หรือหน้าจอ ประเด็นนี้เป็นเรื่องโครงสร้างเทสต์และวินัยของทีม ไม่ใช่คุณสมบัติที่ชื่อเฟรมเวิร์กแก้ให้เอง

รันขนานและดีบักต้องวัดคนละต้นทุน

การรันขนานลดเวลารอได้เมื่อเทสต์เป็นอิสระต่อกัน Playwright Test ใช้ worker เพื่อรันงานพร้อมกัน ส่วน Cypress Cloud กระจายไฟล์สเปกไปยังเครื่อง CI หลายเครื่องได้ รูปแบบหลังต้องพิจารณาการบันทึกรันและการจัดสรรเครื่องร่วมด้วย การเพิ่มงานพร้อมกันยังอาจทำให้เทสต์แย่งบัญชีเดียวกัน เขียนข้อมูลทับกัน หรือกดดันบริการที่กำลังทดสอบจนเกิดความล้มเหลวที่ไม่พบในเครื่องนักพัฒนา

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

Open Mode ของ Cypress แสดง Command Log คู่กับหน้าแอป และให้ย้อนดู snapshot ของคำสั่งระหว่างไล่ข้อผิดพลาด จึงมีน้ำหนักมากสำหรับทีมที่มักพบปัญหาขณะเขียนเทสต์ในเครื่อง Playwright มี trace สำหรับดูขั้นตอนและสถานะหลังการรัน ซึ่งเข้ากับความล้มเหลวที่เกิดเฉพาะบน CI มากกว่าเมื่อมีการเก็บไฟล์ trace ไว้จริง ไม่มีเครื่องมือใดช่วยลดเวลาหาสาเหตุได้หากระบบ CI ทิ้งหลักฐานก่อนคนเปิดดู

ให้แยกคำว่าเทสต์ล้มออกเป็นความล้มเหลวของแอป ความล้มเหลวของข้อมูลตั้งต้น และผลที่ไม่แน่นอนจากเวลาเครือข่ายหรือการรอองค์ประกอบ สำหรับงานที่แก้ในเครื่องบ่อย การคลิกย้อนสถานะของคำสั่งอาจช่วยประหยัดเวลาคนมากกว่านาทีที่ได้จากการรันเร็วขึ้นเล็กน้อย หากปัญหาปรากฏหลังส่งขึ้น CI เป็นหลัก รายงาน ข้อผิดพลาด ภาพหรือ trace ที่ผูกกับรันนั้นจะมีน้ำหนักกว่า การเปรียบเทียบต้นทุนจึงต้องรวมเวลาที่คนใช้ระบุสาเหตุและทำซ้ำ ไม่ใช่เพียงค่าเวลาของเครื่อง

ผลวัดเวลา CPU และ RAM มีขอบเขตเฉพาะงาน

งานทดลองกับแอป Angular ใช้สถานการณ์ทดสอบ 5 แบบบนเครื่อง Windows 10 และรันแต่ละสถานการณ์ซ้ำ 50 ครั้งต่อเบราว์เซอร์ในโหมด headless ผู้วิจัยรายงานว่า Playwright ใช้เวลาน้อยกว่าและใช้ RAM ต่ำกว่าในชุดทดลองนั้น ขณะที่การใช้ CPU สูงกว่าเล็กน้อย ผลต่างของเวลายังเปลี่ยนตามเบราว์เซอร์และสถานการณ์ที่วัด จึงควรอ่านเป็นผลของแอป เครื่อง และวิธีทดสอบชุดนี้

สถานการณ์ที่งานวิจัยวัดมีทั้งการสมัครสมาชิก แบบฝึกพิมพ์ เกม และการจัดการเรื่องที่ผู้ใช้แจ้ง ขอบเขตเช่นนี้ให้ภาพของงานแบบฟอร์มและการโต้ตอบในแอป Angular แต่ไม่ได้แทนเว็บที่ต้องควบคุมป๊อปอัปข้ามหน้าอย่างหนัก หรือระบบที่ผู้ใช้หลายคนส่งข้อมูลถึงกันตลอดเวลา ผู้วิจัยยังเตรียมจุดสำหรับรีเซ็ตฐานข้อมูลก่อนการรันเพื่อให้ข้อมูลตั้งต้นสม่ำเสมอ หากชุดของทีมไม่มีความสามารถนี้ ผลเวลาที่แกว่งอาจสะท้อนข้อมูลค้างมากกว่าประสิทธิภาพเฟรมเวิร์ก

เวลาเฉลี่ยของเทสต์หนึ่งกรณีต่างจากเวลาจบทั้ง pipeline ส่วน CPU และ RAM ก็ชี้ปัญหาคนละชนิด เครื่องที่หน่วยความจำตึงอาจเปิดเบราว์เซอร์พร้อมกันได้จำกัด แม้เวลาเฉลี่ยต่อเทสต์ดูดี ขณะที่ worker เพิ่มอาจแย่ง CPU กับแอปหรือฐานข้อมูลในเครื่อง CI เดียวกัน การเห็น Playwright ใช้ RAM ต่ำกว่าในงานวิจัยจึงไม่อนุญาตให้คาดว่าชุดทดสอบทุกขนาดจะใช้หน่วยความจำต่ำกว่าเสมอ

หากทีมจะวัดกับเว็บของตน ให้ใช้เส้นทางผู้ใช้เดียวกัน ข้อมูลตั้งต้นเดียวกัน และเบราว์เซอร์ที่ตรงกับเกณฑ์ผ่าน บันทึกเวลารอทั้งรันพร้อมเวลาต่อเทสต์ ความแปรปรวนระหว่างรัน การใช้ CPU และ RAM รวมถึงจำนวนครั้งที่ต้องรันใหม่ ระบุด้วยว่าค่าที่รายงานรวมการติดตั้งเบราว์เซอร์ การเริ่มบริการ และการอัปโหลดหลักฐานหรือไม่ เมื่อเงื่อนไขเหล่านี้ต่างกัน ความเร็วที่ต่างกันอาจมาจากการเตรียมงานมากกว่าตัวคำสั่ง E2E

สิบคำถามสำหรับจับคู่เครื่องมือกับเว็บของทีม

ตอบคำถามต่อไปนี้ตามเกณฑ์ผ่านของผลิตภัณฑ์และกระบวนการทำงานจริง แยกข้อบังคับออกจากความสะดวกที่ต่อรองได้: หากเครื่องมือทำสถานการณ์บังคับไม่ได้ด้วยวิธีที่ทีมยอมรับ ผลวัดเวลาที่ดีกว่าจะไม่ชดเชยช่องว่างนั้น

1. WebKit เป็นเกณฑ์ผ่านประจำหรือเป็นเพียงการตรวจเพิ่มเติม? หากเป็นเกณฑ์ประจำ Playwright มีทางตั้งค่าโดยตรงกว่า ส่วน Cypress ต้องยอมรับสถานะทดลองของการรองรับนี้ และทั้งสองกรณียังต้องพิจารณาความต่างจาก Safari ที่ผู้ใช้ติดตั้งจริง
2. ต้องตรวจ Chrome, Edge หรือ Firefox รุ่นและระบบปฏิบัติการใด? บันทึกสภาพแวดล้อมเป้าหมายก่อนเลือกเครื่องมือ มิฉะนั้นผลผ่านบนเอนจินที่จัดเตรียมให้อาจถูกเข้าใจว่าแทนเบราว์เซอร์ทุกเครื่องของผู้ใช้
3. เส้นทางสำคัญเปิดป๊อปอัปหรือแท็บใหม่แล้วต้องตรวจทั้งสองหน้าพร้อมกันหรือไม่? ถ้าต้องควบคุมหน้าที่เปิดใหม่ต่อ Playwright ตรงกับโครงสร้างสถานการณ์มากกว่า หากต้องตรวจเพียงปลายทางของลิงก์ วิธีที่ง่ายกว่าอาจเพียงพอ
4. ผู้ใช้ต้องโต้ตอบกับองค์ประกอบใน iframe หรือเพียงเห็นเฟรมปรากฏ? ความต่างนี้กำหนดความลึกของเทสต์ โดยเฉพาะเฟรมจากอีกแหล่งที่มา ควรใช้ iframe ของแอปจริงเป็นตัวอย่าง เพราะเฟรมจำลองที่ง่ายกว่าจะซ่อนข้อจำกัด
5. ต้องเปิดผู้ใช้หลายบัญชีพร้อมกันและดูผลตอบสนองทันทีหรือไม่? หากต้อง Playwright ใช้ context แยกสถานะได้ตรงโจทย์ หากกระบวนการยอมให้ตรวจบทบาททีละช่วง Cypress ยังเป็นทางเลือกได้ แต่เกณฑ์ผ่านต้องระบุว่าครอบคลุมอะไร
6. เทสต์ต้องสร้างข้อมูล ล้างฐานข้อมูล หรือเรียกบริการหลังบ้านบ่อยเพียงใด? ยิ่งพึ่งงานเหล่านี้มาก ยิ่งต้องประเมินความชัดของทางเชื่อมและข้อความผิดพลาด ไม่ใช่ดูเฉพาะความง่ายของคำสั่งคลิก
7. ใครจะดูแลโค้ดทดสอบ และทำงานในภาษาใดทุกวัน? ทีม JavaScript หรือ TypeScript เลือกได้ทั้งคู่ ส่วนความต้องการใช้ Python, Java หรือ .NET ทำให้ Playwright น่าพิจารณาเป็นพิเศษ
8. ไฟล์เทสต์รันขนานโดยไม่แย่งบัญชีและข้อมูลกันได้แล้วหรือยัง? หากยังไม่ได้ การเพิ่ม worker หรือเครื่อง CI จะขยายปัญหาข้อมูลชนกัน ควรแก้การแยกข้อมูลก่อนใช้เวลารันขนานเป็นตัวตัดสิน
9. ความล้มเหลวมักพบขณะเขียนเทสต์ในเครื่องหรือหลังรันบน CI? กรณีแรกให้น้ำหนักกับการดูคำสั่งและ snapshot แบบโต้ตอบ กรณีหลังให้น้ำหนักกับหลักฐานที่เก็บหลังรันและการเปิดดูย้อนกลับได้
10. เมื่อใช้เส้นทางสำคัญของเว็บเอง เวลารอทั้ง pipeline, CPU, RAM และเวลาที่คนใช้หาสาเหตุเป็นอย่างไร? เทียบตัวเลขภายใต้สภาพแวดล้อมเดียวกัน แล้วใช้ผลนี้ตัดสินระหว่างตัวเลือกที่ผ่านเงื่อนไขบังคับแล้ว

คำตอบที่ชี้ไปยัง WebKit หลายหน้า หรือผู้ใช้หลายบัญชีพร้อมกันทำให้ Playwright เป็นจุดเริ่มต้นที่สมเหตุสมผล หากเว็บทำงานหลักในหน้าเดียวและทีมไล่ข้อผิดพลาดระหว่างพัฒนาผ่านลำดับคำสั่งอยู่เสมอ Cypress อาจเข้ากับงานกว่า การทดลองกับเส้นทางจริงขนาดเล็กควรใช้เกณฑ์ผ่านเดียวกัน ก่อนลงทุนสร้างหรือย้ายชุด E2E ทั้งหมด

อ่านเพิ่มเติม:

• Playwright หรือ Cypress: ความเร็วไม่ได้ชนะทุกกรณีทดสอบ
• Postman หรือ Insomnia: ทีมใหญ่แลก RAM กับระบบกำกับ API