บันทึกการตัดสินใจด้านสถาปัตยกรรม: เฟรมเวิร์กระบบอัตโนมัติของเบราว์เซอร์สำหรับการทดสอบ E2E (Playwright หรือ Selenium)

1. บริบท

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

ในฐานะ สตาร์ทอัป โฟกัสของเราอยู่ที่ การพัฒนาแบบ agile โดยต้องวนซ้ำและพัฒนาอย่างรวดเร็ว ทีมของเราทำงานกับ TypeScript และ Python เป็นหลัก และความสามารถในการเขียนการทดสอบด้วยภาษาเหล่านี้เป็นสิ่งจำเป็น นอกจากนี้ แพลตฟอร์มมี แผนภูมิและแดชบอร์ดแบบโต้ตอบ ซึ่งทำให้สำคัญยิ่งที่เครื่องมืออัตโนมัติรองรับ UI ที่สมบูรณ์และเปลี่ยนแปลงได้เป็นอย่างดี

สองตัวเลือกสำหรับงานนี้คือ Playwright และ Selenium แต่ละตัวมีจุดแข็งและข้อแลกเปลี่ยนของตน เราต้องประเมินเฟรมเวิร์กเหล่านี้ตามฟีเจอร์และข้อกำหนดที่ระบุไว้ด้านล่าง

2. ทางเลือกที่พิจารณา

• Playwright (โดย Microsoft)
• Selenium (โดย Selenium Project)

3. ปัจจัยขับเคลื่อนการตัดสินใจ

ปัจจัยที่มีอิทธิพลต่อการตัดสินใจของเราคือ:

1. การพัฒนาแบบ agile: เครื่องมือที่เลือกต้องเอื้อให้วงจรการพัฒนารวดเร็วและยืดหยุ่น
2. การรองรับภาษา: ทีมของเราต้องการการรองรับทั้ง TypeScript และ Python
3. การทดสอบ UI แบบโต้ตอบ: ความสามารถในการทดสอบแผนภูมิแบบโต้ตอบ แดชบอร์ด และองค์ประกอบที่เปลี่ยนแปลงได้อย่างน่าเชื่อถือเป็นสิ่งจำเป็น
4. ความเร็วขณะทำงาน: แม้ไม่ใช่ข้อกังวลหลัก แต่ประสิทธิภาพในไปป์ไลน์ CI/CD เป็นข้อพิจารณา
5. ความสามารถในการปรับขนาด: เราไม่ได้วางแผนปรับขนาดอย่างมหาศาลในอนาคตอันใกล้ แต่ต้องการให้แน่ใจว่าโซลูชันรองรับการเติบโตในอนาคตได้
6. ความเข้ากันได้ย้อนหลัง: ระบบเดิมและความเข้ากันได้กับเบราว์เซอร์รุ่นเก่ายังไม่สำคัญต่อโครงการของเราในตอนนี้
7. การทดสอบบนมือถือ: แม้ไม่ใช่จุดเน้นทันที เฟรมเวิร์กควรทดสอบฟีเจอร์ที่ตอบสนองต่อมือถือได้หรือขยายสำหรับกรณีใช้งานเช่นนั้นได้
8. การทดสอบแบบหลายหน้าจอ: การรองรับการตั้งค่าแบบหลายหน้าจอเป็นข้อกำหนดรอง โดยเฉพาะหากเราปรับขนาดขึ้นในอนาคตเพื่อทดสอบเวิร์กโฟลว์ของผู้ใช้ที่ซับซ้อนขึ้น
9. การทดสอบการอัปโหลดไฟล์: เฟรมเวิร์กต้องจัดการการอัปโหลดไฟล์ได้อย่างมีประสิทธิภาพ ซึ่งเป็นข้อกำหนดหลักของความต้องการด้านการทดสอบของเรา

4. เกณฑ์การประเมิน

• ความง่ายในการใช้: เขียนและบำรุงรักษาการทดสอบง่ายเพียงใด
• การรองรับภาษา: เฟรมเวิร์กรองรับ TypeScript และ Python ซึ่งเป็นสองภาษาที่ทีมของเราใช้บ่อยที่สุดหรือไม่
• การทดสอบ UI แบบโต้ตอบ: เฟรมเวิร์กจัดการส่วนติดต่อผู้ใช้แบบโต้ตอบที่ซับซ้อน เช่น แผนภูมิ การอัปโหลดไฟล์ และข้อมูลที่เปลี่ยนแปลงได้ดีเพียงใด
• การรวมกับ CI/CD: เฟรมเวิร์กรวมกับเครื่องมือและบริการ CI/CD ทั่วไปได้ดีเพียงใด
• การรองรับหลายเบราว์เซอร์: รองรับเบราว์เซอร์ใดบ้างและทำงานได้ดีเพียงใด
• ประสิทธิภาพและความเร็ว: การทดสอบทำงานเร็วเพียงใด โดยเฉพาะในไปป์ไลน์ CI/CD
• ความสามารถในการปรับขนาด: เฟรมเวิร์กปรับขนาดได้ดีเพียงใดหากเพิ่มการทดสอบมากขึ้นหรือสถานการณ์ที่ซับซ้อนขึ้น
• ชุมชนและระบบนิเวศ: ชุมชนของเฟรมเวิร์กคึกคักเพียงใด มีการรวมระบบและปลั๊กอินมากมายหรือไม่

5. ข้อพิจารณา

5.1 Playwright

ข้อดี:

1. API ที่ฉลาดกว่าสำหรับการอัปโหลดไฟล์ในเครื่อง: API ของ Playwright สำหรับโต้ตอบกับไฟล์ในเครื่องและทำการอัปโหลดไฟล์เรียบง่ายและเข้าใจง่ายกว่า ทำให้การทดสอบการอัปโหลดไฟล์นำไปใช้และบำรุงรักษาง่ายขึ้น
2. ไวยากรณ์และการสร้างโค้ด: Playwright มีไวยากรณ์ที่สั้นและกระชับกว่า ทำให้โค้ดซ้ำซ้อนน้อยลง ซึ่งปรับปรุงความสามารถในการบำรุงรักษาและประสิทธิภาพของนักพัฒนา นอกจากนี้ไวยากรณ์ที่สั้นกว่ายังปรับปรุงคุณภาพของการสร้างโค้ดของ OpenAI ทำให้สร้างสคริปต์ทดสอบโดยอัตโนมัติได้ง่ายขึ้น
3. การทดสอบ UI แบบโต้ตอบ: Playwright โดดเด่นในการทดสอบเว็บแอปพลิเคชันที่เปลี่ยนแปลงได้และโต้ตอบได้ เช่น แอปที่มีแผนภูมิสมบูรณ์ การโต้ตอบของผู้ใช้ที่ซับซ้อน และการอัปเดตแบบเรียลไทม์ จัดการ WebSocket, WebRTC, shadow DOM และเทคโนโลยีเว็บสมัยใหม่อื่น ๆ ได้อย่างมีประสิทธิภาพมาก
4. การรองรับหลายเบราว์เซอร์: Playwright รองรับ Chromium, WebKit และ Firefox มีประสิทธิภาพสม่ำเสมอข้ามเบราว์เซอร์เหล่านี้ ซึ่งควรครอบคลุมความต้องการด้านการทดสอบส่วนใหญ่ของเรา
5. การรวมกับ CI/CD: Playwright รวมกับแพลตฟอร์ม CI/CD สมัยใหม่ (GitHub Actions, Jenkins ฯลฯ) ได้อย่างราบรื่น รันการทดสอบแบบขนานข้ามเบราว์เซอร์ต่าง ๆ ได้ ซึ่งเพิ่มประสิทธิภาพเวลารันการทดสอบและเหมาะกับการพัฒนาอย่างรวดเร็ว
6. เร็วและเชื่อถือได้: Playwright โดยทั่วไปเร็วกว่า Selenium โดยเฉพาะในโหมด headless และทนทานกว่าต่อองค์ประกอบเว็บแบบอะซิงโครนัส

ข้อเสีย:

1. การทดสอบบนมือถือที่จำกัด: แม้ Playwright จะรองรับการจำลองมือถือสำหรับเบราว์เซอร์ แต่ขาดความสามารถการทดสอบบนมือถือในตัวอย่างการรวม Appium ของ Selenium สำหรับการทดสอบมือถือจริง
2. ระบบนิเวศที่เล็กกว่า: Playwright ยังใหม่กว่าและเป็นที่ยอมรับน้อยกว่า Selenium แม้จะมีชุมชนที่เติบโตเร็วและเอกสารดี แต่อาจยังไม่มีระบบนิเวศขนาดใหญ่ของปลั๊กอินและการรวมระบบที่ Selenium มี
3. การรองรับเบราว์เซอร์ที่จำกัด: แม้ Playwright จะครอบคลุมเบราว์เซอร์สมัยใหม่หลัก (Chrome, Safari, Firefox) แต่การรองรับเบราว์เซอร์รุ่นเก่า (เช่น Internet Explorer) ไม่แข็งแกร่งเท่า Selenium

5.2 Selenium

ข้อดี:

1. ประวัติยาวนานและความสมบูรณ์: Selenium มีมานานและมีประวัติที่พิสูจน์แล้ว ใช้อย่างแพร่หลายโดยหลายทีมและอุตสาหกรรม ทำให้เกิดระบบนิเวศขนาดใหญ่ของปลั๊กอิน การรวมระบบ และทรัพยากร
2. การรองรับหลายเบราว์เซอร์และแพลตฟอร์ม: Selenium รองรับ เบราว์เซอร์หลากหลาย และเวอร์ชันต่าง ๆ รวมถึง Internet Explorer และรวมกับเครื่องมือต่าง ๆ เช่น Docker, Selenium Grid และ บริการคลาวด์ สำหรับการทดสอบแบบกระจายได้
3. การทดสอบบนมือถือ: Selenium ผ่านการรวมกับ Appium แข็งแกร่งกว่ามากสำหรับการทดสอบบนมือถือ รวมถึงแอปพลิเคชันทั้ง Android และ iOS ทำให้เป็นตัวเลือกที่ดีกว่าสำหรับโครงการที่เน้นมือถือเป็นหลักหรือเน้นมือถืออย่างมาก
4. การทดสอบแบบหลายหน้าจอ: Selenium รองรับสถานการณ์ หลายหน้าจอ หรือการโต้ตอบหลายหน้าต่างที่ซับซ้อนได้ดีกว่า

ข้อเสีย:

1. ความซับซ้อน: API ของ Selenium ยืดยาวและชัดเจนกว่า แม้ในบางกรณีอาจเป็นข้อดี แต่หมายถึงโค้ดที่ต้องเขียนและบำรุงรักษามากขึ้น ซึ่งอาจลดความคล่องตัวของนักพัฒนา โดยเฉพาะสำคัญในสภาพแวดล้อมสตาร์ทอัป
2. ประสิทธิภาพ: Selenium โดยทั่วไปทำงานช้ากว่า Playwright โดยเฉพาะในโหมด headless ซึ่งอาจส่งผลต่อไปป์ไลน์ CI/CD โดยเฉพาะเมื่อจำนวนการทดสอบเพิ่มขึ้น
3. การทดสอบ UI แบบโต้ตอบ: Selenium ไม่ลื่นไหลเท่า Playwright ในการทดสอบ UI เว็บสมัยใหม่แบบโต้ตอบ โดยเฉพาะกับแผนภูมิและการอัปเดตข้อมูลแบบเรียลไทม์ ต้องใช้การกำหนดค่าและการจัดการมากกว่าเพื่อโต้ตอบกับเนื้อหาที่เปลี่ยนแปลงได้อย่างน่าเชื่อถือ

6. สรุปการเปรียบเทียบ

ฟีเจอร์	Playwright	Selenium
ความง่ายในการใช้	ไวยากรณ์สั้นกว่า เข้าใจง่ายกว่าสำหรับ UI สมัยใหม่	ชัดเจนกว่า ต้องมีโค้ดซ้ำซ้อนมากกว่า
การรองรับภาษา	TypeScript, Python, JavaScript	TypeScript, Python, Java, Ruby, C#
การทดสอบ UI แบบโต้ตอบ	ยอดเยี่ยมสำหรับ UI แบบเรียลไทม์ที่เปลี่ยนแปลงได้	จัดการ UI พื้นฐานได้ แต่ยืดยาวและซับซ้อนกว่าสำหรับการโต้ตอบที่สมบูรณ์
การทดสอบการอัปโหลดไฟล์	API ที่ฉลาดกว่าสำหรับการอัปโหลดไฟล์	API ที่ยืดยาวกว่าและเข้าใจยากกว่า
การรวมกับ CI/CD	รวมกับ GitHub Actions, Jenkins ได้ง่าย	การรวมที่แข็งแกร่งกับเครื่องมือ CI จำนวนมาก
การทดสอบบนมือถือ	จำกัด เฉพาะการจำลอง	รองรับเต็มรูปแบบผ่าน Appium
การรองรับหลายเบราว์เซอร์	Chromium, WebKit, Firefox	รองรับเต็มรูปแบบสำหรับเบราว์เซอร์หลักและรุ่นเก่า
ประสิทธิภาพ	เร็ว ปรับให้เหมาะกับการทดสอบแบบ headless	ช้ากว่า โดยเฉพาะในโหมด headless
การทดสอบแบบหลายหน้าจอ	จำกัด	การรองรับที่ดีสำหรับการตั้งค่าหลายหน้าจอ
ชุมชนและระบบนิเวศ	เติบโต เอกสารดี	ใหญ่ สมบูรณ์ ระบบนิเวศที่กว้างขวาง

7. การตัดสินใจ

หลังจากพิจารณาข้อกำหนดและข้อแลกเปลี่ยน Playwright เป็นตัวเลือกที่ดีกว่าสำหรับความต้องการปัจจุบันของเรา API ที่ฉลาดกว่าสำหรับการทดสอบการอัปโหลดไฟล์ในเครื่อง ไวยากรณ์ที่กระชับ และการรองรับที่แข็งแกร่งสำหรับการทดสอบ UI แบบโต้ตอบทำให้เหมาะอย่างยิ่งกับวงจรการพัฒนาแบบ agile ของเรา ข้อเท็จจริงที่ว่ารองรับทั้ง TypeScript และ Python เป็นสิ่งสำคัญสำหรับทีมของเรา และแนวทางสมัยใหม่ของเฟรมเวิร์กต่อการทดสอบช่วยให้เราเขียนโค้ดที่สะอาดและบำรุงรักษาได้

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

8. ผลที่ตามมา

• การดำเนินการทันที: เราจะนำ Playwright มาใช้สำหรับการทดสอบ E2E ของเรา โดยเน้นการทดสอบเส้นทางผู้ใช้ที่เกี่ยวข้องกับการลงทะเบียน การเข้าสู่ระบบ การอัปโหลดไฟล์ แดชบอร์ด และการดาวน์โหลดรายงาน
• ข้อพิจารณาระยะยาว: เราจะจับตาดูระบบนิเวศที่พัฒนาของ Playwright หากความต้องการของเราเปลี่ยนไป โดยเฉพาะเกี่ยวกับการทดสอบบนมือถือหรือการรองรับเบราว์เซอร์รุ่นเก่า เราอาจพิจารณา Selenium ใหม่
• การฝึกอบรมและเอกสาร: ทีมพัฒนาจะต้องทำความคุ้นเคยกับ API ของ Playwright โดยเฉพาะสำหรับการจัดการ UI ที่เปลี่ยนแปลงได้และการอัปโหลดไฟล์
• การย้าย: การทดสอบ Selenium ที่มีอยู่ (หากมี) จะค่อย ๆ ย้ายไปยัง Playwright

9. ข้อพิจารณาในอนาคต