กำไร:
- ความสามารถในการสร้างโค้ดทดสอบ UI ที่แข็งแกร่งด้วยปัญญาประดิษฐ์ รวมถึงการทดสอบข้อมูล การรอแบบเปิด และการยืนยันที่ยืนยันผลลัพธ์ของผู้ใช้จริง
- ความสามารถในการหลีกเลี่ยงการทดสอบที่เปราะบาง (ตัวเลือกที่ไม่ดี การรอแบบไม่รู้จบ) และทำให้การทดสอบง่ายต่อการบำรุงรักษาในโครงสร้าง Page Object Model
- ความสามารถในการทดสอบทุกการทดสอบ UI ที่เกิดขึ้นโดยการทำลายโค้ดและตรวจจับและแก้ไขการทดสอบที่ผ่านปลอม
ทุกการคลิก ทุกการกรอกแบบฟอร์ม ทุกการเปลี่ยนหน้าที่ผู้ใช้ทำในเบราว์เซอร์ไม่สามารถทดสอบซ้ำแล้วซ้ำอีกด้วยมือได้ นั่นคือสาเหตุที่การทดสอบ UI อัตโนมัติ (อินเทอร์เฟซผู้ใช้ การทดสอบเหล่านี้เลียนแบบพฤติกรรมของผู้ใช้โดยการขับเคลื่อนเบราว์เซอร์จริงโดยทางโปรแกรม) Selenium, Playwright และ Cypress เป็นเครื่องมือที่ใช้บ่อยที่สุดสำหรับงานนี้ ปัญญาประดิษฐ์ (AI) มีทักษะสูงในการเขียนโค้ดสำหรับเครื่องมือเหล่านี้: เมื่อคุณอธิบายกรณีทดสอบ ส่วน AI จะให้ร่างสคริปต์อัตโนมัติที่ใช้งานได้แก่คุณ แต่ที่นี่คำเตือนส่วนกลางของโมดูลนี้กลับมามีบทบาทอีกครั้ง: รหัสทดสอบ UI ที่ AI สร้างขึ้นมักจะเป็นการทดสอบที่เปราะบางที่ "สว่างเป็นสีเขียว แต่ตรวจสอบสิ่งผิด" หรือพนังในสายลม งานของคุณไม่ใช่การเรียกใช้โค้ดนี้ แต่เพื่อให้แน่ใจว่าโค้ดจะตรวจสอบสิ่งที่ถูกต้องได้อย่างมีประสิทธิภาพ
ในหน่วยนี้ เรามุ่งหวังที่จะสร้างการทดสอบ UI ที่มีประสิทธิภาพ บำรุงรักษาได้ และตรวจสอบได้อย่างแท้จริงด้วย AI คุณจะได้เรียนรู้ที่จะหลีกเลี่ยงการทดสอบที่เปราะบาง
เสาหลักสามประการของการทดสอบ UI ที่มั่นคง
1. ตัวระบุตำแหน่งองค์ประกอบที่ถูกต้อง การทดสอบใช้ตัวเลือกเพื่อค้นหาองค์ประกอบบนเพจ AI มักจะสร้างตัวเลือกแบบเปราะ: เส้นทาง XPath แบบยาว (ที่อยู่มากเกินไปขึ้นอยู่กับโครงสร้างหน้า) ตัวเลือกตามชื่อคลาส CSS (หยุดทำงานเมื่อการออกแบบเปลี่ยนแปลง) วิธีที่มีประสิทธิภาพคือแอตทริบิวต์ที่มีความเสถียร เช่น data-testid ที่นักพัฒนาเพิ่มไว้สำหรับการทดสอบ กำหนดสิ่งนี้กับ AI อย่างชัดเจน
2. รออย่างชัดเจน แหล่งที่มาของช่องโหว่อันดับหนึ่งในการทดสอบ UI คือจังหวะเวลา การนอนหลับอย่างต่อเนื่อง (3) (การรอคอยแบบไร้สติ) ถือเป็นการปฏิบัติที่ไม่ดี บางครั้งอาจไม่เพียงพอ บางครั้งทำให้เสียเวลา วิธีที่ถูกต้องคือใช้การรออย่างชัดเจน ซึ่งระบุว่า "รอจนกว่าองค์ประกอบนี้จะปรากฏขึ้น" นักเขียนบทละครทำสิ่งนี้โดยอัตโนมัติเป็นส่วนใหญ่ ใน Selenium คุณต้องร้องขออย่างชัดเจน
3. การยืนยันที่มีความหมาย การทดสอบควรตรวจสอบผลลัพธ์ที่ผู้ใช้เห็นจริง เช่น "หมายเลขคำสั่งซื้อปรากฏบนหน้าจอ" ไม่ใช่แค่ "โหลดหน้าเว็บ" หากการทดสอบที่ AI สร้างขึ้นไม่มีการยืนยันหรือไม่สำคัญ การทดสอบนั้นจะสร้าง Pseudo-Pass (หน่วยที่ 1)
ข้อควรระวัง: เมื่อคุณเห็นการทดสอบ UI ที่สร้างโดย AI เป็นครั้งแรก ให้ตรวจสอบสิ่งที่สำคัญที่สุดสามสิ่ง: ตัวเลือกที่คอมมิต (ทดสอบข้อมูล) กำลังรออยู่ (ไม่มีการหลับตา) และการยืนยันจะตรวจสอบผลลัพธ์ของผู้ใช้จริงหรือไม่ หากทั้งสามข้อนี้โอเค การทดสอบก็น่าจะมั่นคง
โมเดลออบเจ็กต์หน้า
เมื่อการทดสอบมีขนาดใหญ่ขึ้น การเขียนตัวเลือกภายในการทดสอบแต่ละครั้งจะกลายเป็นฝันร้ายในการบำรุงรักษา Page Object Model (POM - รูปแบบการออกแบบที่รวบรวมตัวเลือกและการดำเนินการสำหรับแต่ละหน้า/หน้าจอเป็นคลาสเดียว) เก็บตัวเลือกไว้ในที่เดียว เมื่ออินเทอร์เฟซเปลี่ยนแปลง คุณจะอัปเดตเป็นไฟล์เดียว ให้ AI สร้างการทดสอบในโครงสร้าง POM แทนที่จะทำโดยตรง ทำให้การบำรุงรักษาง่ายขึ้นอย่างมาก
พรอมต์อ่อน / พรอมต์แข็งแกร่ง
จุดอ่อน: "เขียนการทดสอบซีลีเนียมสำหรับหน้าเข้าสู่ระบบ"
แข็งแกร่ง: "เขียนการทดสอบขั้นตอนการเข้าสู่ระบบด้วย Playwright (TypeScript) ตัวเลือกใช้เฉพาะ data-testid เท่านั้น อย่าใช้การควบคุมสิ่งที่ผู้ใช้เห็น ไม่ใช่ชื่อหน้า"
พรอมต์อันทรงพลัง; เครื่องมือนี้ให้ภาษา นโยบายตัวเลือก กลยุทธ์การรอ สถาปัตยกรรม (POM) และความคาดหวังในการยืนยันที่แสดงออก
ทดสอบข้อมูลและความเป็นอิสระของสภาพแวดล้อม
การทดสอบ UI ที่มั่นคงไม่เพียงแต่เขียนอย่างถูกต้องเท่านั้น แต่ยังสร้างและล้างข้อมูลการทดสอบของตัวเองด้วย การทดสอบที่สร้างโดย AI มักจะเชื่อมโยงกับผู้ใช้หรือบันทึกที่ถือว่ามีอยู่แล้วในสภาพแวดล้อม (“เข้าสู่ระบบในฐานะผู้ใช้ผู้ดูแลระบบ”) สมมติฐานนี้จะพังเมื่อการทดสอบรันในสภาพแวดล้อมอื่นหรือหลังจากการทดสอบอื่น (ปัญหาการขึ้นต่อกันของลำดับในหน่วยที่ 9) ความจริงก็คือการทดสอบทุกครั้งจะสร้างข้อมูลที่ต้องการเมื่อเริ่มต้นการทดสอบ (หรือเตรียมการทดสอบด้วยการเรียก API) และล้างข้อมูลในตอนท้าย สั่งสอน AI อย่างชัดเจนให้ "ตั้งค่าข้อมูลใดๆ ที่การทดสอบนี้ขึ้นอยู่กับภายในการทดสอบ อย่าถือว่าข้อมูลสำเร็จรูปจากภายนอก"
จุดสำคัญอีกประการหนึ่งคือการไม่ทำการทดสอบ UI ด้วยข้อมูลผู้ใช้จริง หากใช้สำเนาฐานข้อมูลการผลิตในสภาพแวดล้อมการทดสอบ บันทึกเหล่านี้จะเป็นข้อมูลของบุคคลจริง ภาพหน้าจอและบันทึกการทดสอบอาจเปิดเผยข้อมูลนี้ ใช้บัญชีทดสอบสังเคราะห์ (สมมติ) ทั้งปกป้องความลับและทำให้การทดสอบสามารถทำซ้ำได้ การทำการทดสอบ "การยกเลิกคำสั่งซื้อ" ด้วยบัญชีลูกค้าจริงถือเป็นข้อผิดพลาดทั้งด้านจริยธรรมและการปฏิบัติงาน
เคล็ดลับ: ทำการทดสอบ UI ให้น้อยที่สุดเท่าที่จะเป็นไปได้ ปล่อยให้การตรวจสอบจริงเป็นหน้าที่ของ API และการทดสอบหน่วย ซึ่งรวดเร็วและเสถียร การทดสอบ UI มีราคาแพงและเปราะบาง — ใช้เพื่อตรวจสอบโฟลว์ผู้ใช้แบบ end-to-end อย่างแท้จริงเท่านั้น (ทดสอบตรรกะพีระมิด)
การเปรียบเทียบยานพาหนะ
คุณสมบัติ
ซีลีเนียม
นักเขียนบทละคร
ไซเปรส
ภาษา
จาวา, C#, หลาม, JS
JS/TS, ไพธอน, .NET, ชวา
จาวาสคริปต์/ไทป์สคริปต์
สแตนด์บายอัตโนมัติ
ไม่ (ด้วยมือ)
ใช่ (แข็งแกร่ง)
ใช่
เบราว์เซอร์หลายตัว
กว้าง
โครเมียม/Firefox/WebKit
โครเมียมเด่น
แนวโน้มที่จะเปราะบาง
สูง (สแตนด์บายด้วยตนเอง)
ต่ำ
ต่ำ
ง่ายต่อการเรียนรู้
ปานกลาง
ง่าย
ง่าย
การทำงานแบบขนาน
จำเป็นต้องมีกริด
ในตัว
ผู้อยู่อาศัย / ชำระเงิน
เมื่อขอรหัสจาก AI ให้ระบุชัดเจนว่าเป็นของยานพาหนะใด มิฉะนั้นอาจสร้างโค้ดที่สับสนและใช้งานไม่ได้
เทมเพลตที่สามารถคัดลอกได้สี่แบบ
1) การสร้างการทดสอบ Solid UI:
บทบาทของคุณ: วิศวกรทดสอบอัตโนมัติอาวุโส เขียนการทดสอบด้วย [เครื่องมือ + ภาษา] สำหรับโฟลว์ต่อไปนี้: [โฟลว์] กฎ:- ตัวเลือกข้อมูลทดสอบเท่านั้น การใช้คลาส XPath/CSS - ห้ามคนตาบอด; ใช้การรอที่ชัดเจน/อัตโนมัติ - ใช้โมเดลออบเจ็กต์เพจ - ให้แต่ละการยืนยันยืนยันผลลัพธ์ของผู้ใช้จริง แสดงความคิดเห็นเมื่อเริ่มต้นการทดสอบแต่ละครั้งว่าคุณกำลังตรวจสอบเกณฑ์การยอมรับใดบ้าง
2) การควบคุมความเปราะบาง:
ตรวจสอบการทดสอบ UI ต่อไปนี้เพื่อดูความเปราะบาง:- มีตัวเลือกที่ไม่เสถียรหรือไม่ (long
3) การแปลงเป็นวัตถุหน้า:
แปลงโค้ดทดสอบธรรมดาต่อไปนี้เป็นโครงสร้าง Page Object Model ย้ายตัวเลือกและการดำเนินการไปยังคลาสของหน้า ปล่อยให้ไฟล์ทดสอบอ่านเฉพาะโฟลว์ของสถานการณ์ [เครื่องมือ/ภาษา].รหัส: [วางรหัส]
4) การพิสูจน์การเปลี่ยนผ่านแบบหลอก:
พิสูจน์ว่าการทดสอบ UI นี้ตรวจสอบได้จริง: ฉันจะต้องเปลี่ยนแปลงอะไรบ้างในโค้ดแอปพลิเคชันที่จะทำให้การทดสอบนี้เป็นสีแดง หากคุณไม่พบการเปลี่ยนแปลงที่จะทำลายการทดสอบ แสดงว่าการทดสอบไม่เพียงพอ เพิ่มการยืนยันที่ขาดหายไป ทดสอบ: [วางทดสอบ]
มินิเคสสามอัน
กรณีที่ 1 — การปลดปล่อยจากตัวเลือกที่เปราะบาง จากการทดสอบ 40 ครั้งที่ทีมหนึ่งสร้างด้วย AI พบว่า 70% ใช้งานไม่ได้หลังจากการอัปเดตอินเทอร์เฟซ ไม่มีจุดบกพร่องจริง ๆ เลย แต่ทั้งหมดเป็นเพียงตัวเลือก XPath ที่เปราะบาง ทีมงานแปลงการทดสอบให้เป็นฐานทดสอบข้อมูลด้วยเทมเพลต "การตรวจสอบความเปราะบาง" ในการอัปเดตอินเทอร์เฟซสามรายการถัดไป จำนวนการหยุดที่ผิดพลาดลดลงเหลือศูนย์ เวลาบำรุงรักษาลดลงจาก 6 ชั่วโมงเป็น 30 นาทีต่อสัปดาห์
กรณีที่ 2 — การทดสอบ UI ผ่านการปลอม AI สร้างการทดสอบ "หยิบลงตะกร้า" การทดสอบเป็นสีเขียว เมื่อเรียกใช้เทมเพลต "fake-proof-of-passage" การทดสอบดูเหมือนจะตรวจสอบเฉพาะการคลิกปุ่มและชื่อหน้าเท่านั้น โดยไม่เคยตรวจสอบว่าตัวนับรถเข็นเพิ่มขึ้นหรือไม่ แม้ว่าตรรกะของรถเข็นจะพังอย่างสมบูรณ์ แต่การทดสอบก็ผ่านไป เพิ่มการยืนยันที่แท้จริง (ป้ายรถเข็นเป็น "1")
กรณีที่ 3 — กับดักการรอแบบตาบอด ในการทดสอบซีลีเนียมที่ผลิตโดย AI จะมีการนอนหลับ (2) หลังจากแต่ละขั้นตอน การทดสอบ 60 ครั้งใช้เวลา 14 นาทีและยังคงล้มเหลวในบางครั้ง หลังจากเปลี่ยนมาเป็นเปิด รอ (รอให้องค์ประกอบคลิกได้) เวลาลดลงเหลือ 5 นาที ความเปราะบางก็หายไป การรอแบบคนตาบอดนั้นทั้งช้าและไม่น่าเชื่อถือ
ข้อผิดพลาดทั่วไป
- เห็นด้วยกับตัวเลือกที่เปราะบาง ใช้ XPath แบบยาวที่สร้างโดย AI ตามที่เป็นอยู่ ทดสอบข้อขัดข้องเมื่อเปลี่ยนอินเทอร์เฟซครั้งแรก
- ปล่อยให้คนตาบอด 'นอนหลับ' "การแก้ไข" เวลาด้วยการรอคงที่ ทั้งช้าและไม่เด็ดขาด
- การยืนยันเล็กน้อย เพียงตรวจสอบว่าโหลดเพจแล้ว ไม่ตรวจสอบผลผู้ใช้จริง (ผ่านปลอม)
- เติบโตโดยไม่มี POM กระจายตัวเลือกให้กับการทดสอบแต่ละครั้ง อัปเดตไฟล์หลายสิบไฟล์ด้วยตนเองเมื่ออินเทอร์เฟซเปลี่ยนแปลง
- ไม่ระบุเครื่องมือ. ไม่บอก AI ว่าคุณต้องการเครื่องมือ/ภาษาอะไร ได้รับโค้ดที่ยุ่งเหยิงและใช้งานไม่ได้
- ไว้วางใจเมื่อคุณเรียกใช้โค้ดที่สร้างขึ้นและผ่าน ไม่ใช่การทดสอบโดยการทำลายโค้ด
โดยสรุป
การทดสอบ UI อัตโนมัติตรวจสอบพฤติกรรมของผู้ใช้โดยการขับเคลื่อนเบราว์เซอร์จริงด้วยโปรแกรม AI สร้างโค้ดนี้อย่างรวดเร็ว แต่มีข้อผิดพลาดใหญ่สองประการ: การทดสอบแบบเปราะ (ตัวเลือกที่ไม่ดี การรอคอยแบบตาบอด) และการทดสอบการส่งผ่านปลอม (การยืนยันที่ไม่สมบูรณ์/ไม่สำคัญ) เสาหลักสามประการของการทดสอบ UI ที่มั่นคงคือตัวเลือกการคอมมิต (data-testid) การรอคอยที่ชัดเจน และการยืนยันที่ยืนยันผลลัพธ์ของผู้ใช้จริง การมีการทดสอบที่สร้างขึ้นใน Page Object Model ช่วยลดความยุ่งยากในการบำรุงรักษาอย่างมาก ทดสอบการทดสอบที่สร้างขึ้นแต่ละรายการด้วยคำถาม "การเปลี่ยนแปลงใดที่จะทำลายสิ่งนี้"
งานสมัคร
เลือกโฟลว์ผู้ใช้จากโปรเจ็กต์ของคุณเอง (เช่น การเข้าสู่ระบบหรือการค้นหา) ให้การทดสอบการเขียน AI ด้วยเทมเพลต “การสร้างการทดสอบ UI ที่มีประสิทธิภาพ” จากนั้น: (1) ตรวจสอบและแก้ไขตัวเลือก และรอด้วย "การตรวจสอบความเปราะบาง" (2) พิสูจน์ว่าการทดสอบแต่ละครั้งตรวจสอบได้จริงด้วย "การพิสูจน์ผ่านหลอก" (3) ทำลายรหัสและสังเกตว่าการทดสอบเปลี่ยนเป็นสีแดง รายงานจำนวนการทดสอบที่ผลิตและแก้ไข และจำนวนช่องโหว่และรหัสผ่านหลอกที่คุณพบ
รายการตรวจสอบ
- [ ] ฉันมอบเครื่องมือ ภาษา นโยบายตัวเลือก และสถาปัตยกรรม (POM) ให้กับ AI อย่างชัดเจน
- [ ] ฉันตรวจสอบแล้วว่าตัวเลือกนั้นได้รับการทดสอบข้อมูลแล้ว
- [ ] ฉันแน่ใจว่าจะใช้การรอที่ชัดเจน/อัตโนมัติแทนการหลับแบบคนตาบอด
- [ ] ฉันตรวจสอบว่าการยืนยันแต่ละรายการยืนยันผลลัพธ์ของผู้ใช้จริง
- [ ] ฉันทดสอบการทดสอบแต่ละครั้งโดยทำลายโค้ด ฉันเห็นมันกลายเป็นสีแดง
- [ ] ฉันรวบรวมการทดสอบในโครงสร้าง Page Object Model