การทดสอบ GUI: กรณีทดสอบ UI และตัวอย่าง
โธมัส แฮมิลตัน
⚡ สรุปอย่างชาญฉลาด
การทดสอบ GUI จะตรวจสอบความถูกต้องของทุกองค์ประกอบที่มองเห็นได้ของแอปพลิเคชัน ไม่ว่าจะเป็นปุ่ม เมนู ไอคอน กล่องข้อความ และเค้าโครง เพื่อให้หน้าจอทำงานและแสดงผลได้อย่างถูกต้องตามที่กำหนดไว้ในทุกเบราว์เซอร์ อุปกรณ์ และความละเอียดหน้าจอ ก่อนที่ผู้ใช้จริงจะสัมผัสใช้งาน
เพื่อให้เข้าใจการทดสอบ GUI เราต้องเข้าใจก่อนว่า GUI คืออะไร
GUI คืออะไร?
อินเทอร์เฟซสำหรับแอปพลิเคชันคอมพิวเตอร์มีสองประเภท อินเทอร์เฟซบรรทัดคำสั่งเป็นที่ที่คุณพิมพ์ข้อความและคอมพิวเตอร์ตอบสนองต่อคำสั่งนั้น GUI ย่อมาจาก Graphical User Interface ที่คุณโต้ตอบกับคอมพิวเตอร์โดยใช้รูปภาพแทนข้อความ
ต่อไปนี้เป็นองค์ประกอบ GUI ที่สามารถใช้สำหรับการโต้ตอบระหว่างผู้ใช้และแอปพลิเคชัน:
การทดสอบ GUI คือการตรวจสอบความถูกต้องขององค์ประกอบข้างต้น
การทดสอบ GUI คืออะไร?
การทดสอบ GUI เป็นประเภทการทดสอบซอฟต์แวร์ที่ตรวจสอบส่วนติดต่อผู้ใช้แบบกราฟิกของซอฟต์แวร์ วัตถุประสงค์ของการทดสอบส่วนต่อประสานกราฟิกกับผู้ใช้ (GUI) คือเพื่อให้แน่ใจว่าฟังก์ชันการทำงานของแอปพลิเคชันซอฟต์แวร์ทำงานตามข้อกำหนดโดยการตรวจสอบหน้าจอและการควบคุม เช่น เมนู ปุ่ม ไอคอน ฯลฯ
GUI คือสิ่งที่ผู้ใช้มองเห็น ตัวอย่างเช่น หากคุณเยี่ยมชม guru99.com หน้าแรกที่ปรากฏคือ GUI ของเว็บไซต์ โค้ดต้นฉบับจะถูกซ่อนไว้ มีเพียงส่วนติดต่อผู้ใช้เท่านั้นที่มองเห็นได้ ดังนั้น การทดสอบ GUI จึงมุ่งเน้นไปที่โครงสร้างการออกแบบและการแสดงผลของภาพอย่างถูกต้อง
ในภาพหน้าจอข้างต้น การทดสอบ GUI เริ่มต้นด้วยการตรวจสอบว่ารูปภาพทุกรูปแสดงผลได้อย่างสมบูรณ์ในเบราว์เซอร์ต่างๆ การตรวจสอบที่เหลือในหน้าเดียวกันนั้นมีดังนี้:
- ลิงก์ต่างๆ สามารถใช้งานได้ และปุ่มแต่ละปุ่มจะทำงานเมื่อคลิก
- การปรับขนาดหน้าจอจะไม่ทำให้ภาพหรือข้อความหดลง ถูกตัด หรือทับซ้อนกันแต่อย่างใด
- ไม่มีส่วนใดในเลย์เอาต์พังทลายลงเมื่อย่อขนาดหน้าต่างเบราว์เซอร์ให้แคบลง
💡 เคล็ดลับ: ลองแสดงหน้าเว็บเดียวกันที่ความละเอียด 1920×1080, 1366×768 และ 375×812 ก่อนบันทึกข้อผิดพลาดใดๆ รายงาน "เค้าโครงเสีย" จำนวนมากเกิดจากจุดแบ่งหน้าจอที่ยังไม่ได้ทดสอบนั่นเอง
ความจำเป็นในการทดสอบ GUI
ตอนนี้แนวคิดพื้นฐานของการทดสอบ GUI นั้นชัดเจนแล้ว คำถามบางข้อที่อาจผุดขึ้นในใจคุณก็คือ:
- ทำไมต้องทดสอบ GUI?
- จำเป็นจริงหรือ?
- การทดสอบฟังก์ชันการทำงานและตรรกะของแอปพลิเคชันเพียงอย่างเดียวไม่เพียงพอหรืออย่างไร และทำไมต้องเสียเวลาเพิ่มเติมไปกับการออกแบบส่วนติดต่อผู้ใช้?
เพื่อให้ได้คำตอบ ให้คิดในมุมมองของผู้ใช้งาน ไม่ใช่ในมุมมองของผู้ทดสอบ ผู้ใช้งานไม่รู้ว่าแอปพลิเคชันถูกสร้างขึ้นมาอย่างไร อินเทอร์เฟซต่างหากที่จะเป็นตัวตัดสินว่าผู้ใช้งานจะใช้งานแอปพลิเคชันต่อไปหรือจะเลิกใช้
ผู้ใช้งานทั่วไปมักจะสังเกตการออกแบบและรูปลักษณ์ของแอปพลิเคชันก่อนเป็นอันดับแรก รวมถึงความง่ายในการทำความเข้าใจอินเทอร์เฟซ หากผู้ใช้งานไม่คุ้นเคยกับอินเทอร์เฟซ หรือพบว่าแอปพลิเคชันนั้นซับซ้อนเกินไป ผู้ใช้งานเหล่านั้นก็จะไม่กลับมาใช้งานอีก ดังนั้น GUI จึงเป็นเรื่องสำคัญ และควรทำการทดสอบอย่างเหมาะสมเพื่อให้แน่ใจว่าอินเทอร์เฟซนั้นปราศจากข้อผิดพลาด
ประเภทของการทดสอบ GUI
การรู้ว่าทำไมส่วนติดต่อผู้ใช้จึงมีความสำคัญนั้นเป็นเพียงครึ่งหนึ่งของภาพรวมทั้งหมด การทดสอบ GUI แบ่งออกเป็นห้าประเภท และแต่ละประเภทจะตอบคำถามที่แตกต่างกันเกี่ยวกับหน้าจอเดียวกัน
- การทดสอบการทำงานของ GUI: ยืนยันว่าทุกตัวควบคุมทำงานได้ตามที่สัญญาไว้ เกี่ยวข้องอย่างใกล้ชิดกับ การทดสอบการใช้งานโดยจะถามว่าปุ่มส่งข้อมูลหรือไม่ ตัวกรองแบบดรอปดาวน์ และช่องป้อนข้อมูลยอมรับข้อมูลที่ถูกต้องหรือไม่
- การทดสอบการใช้งาน: วัดว่าบุคคลจริงสามารถทำภารกิจให้สำเร็จได้ง่ายเพียงใด การทดสอบการใช้งาน พิจารณาความลึกของการนำทาง ความสามารถในการอ่าน และว่าข้อความแสดงข้อผิดพลาดช่วยได้จริงหรือไม่
- การทดสอบความเข้ากันได้: แสดงหน้าจอเดียวกันซ้ำๆ ในเบราว์เซอร์ ระบบปฏิบัติการ และขนาดอุปกรณ์ต่างๆ การทดสอบข้ามเบราว์เซอร์ ตรวจจับข้อผิดพลาดในการแสดงผลที่ปรากฏเฉพาะในเอนจิ้นเดียวเท่านั้น
- การทดสอบการเข้าถึง: ตรวจสอบการนำทางด้วยแป้นพิมพ์ ป้ายกำกับสำหรับโปรแกรมอ่านหน้าจอ และความคมชัดของสีตามมาตรฐาน WCAG การทดสอบการเข้าถึง ปัจจุบันนี้เป็นข้อกำหนดที่ต้องปฏิบัติตามในหลายตลาด ไม่ใช่ทางเลือกเพิ่มเติมอีกต่อไป
- การทดสอบด้านภาพและประสิทธิภาพ: เปรียบเทียบภาพหน้าจอที่แสดงผลกับค่าพื้นฐาน และวัดความเร็วในการแสดงผลและการตอบสนองของอินเทอร์เฟซ รวมถึงการซ้อนทับกันping สีสดสวย การทดสอบประสิทธิภาพ.
ทีมส่วนใหญ่ใช้เกณฑ์ทั้งห้าข้อ แต่ให้น้ำหนักแตกต่างกัน: เว็บไซต์สาธารณะจะเน้นเรื่องความเข้ากันได้และการเข้าถึงได้ง่าย ในขณะที่แดชบอร์ดภายในจะเน้นเรื่องการตรวจสอบการทำงาน
ในการทดสอบ GUI คุณตรวจสอบอะไรบ้าง?
รายการตรวจสอบต่อไปนี้จะช่วยให้มั่นใจว่ามีการทดสอบ GUI โดยละเอียดในการทดสอบซอฟต์แวร์
- ตรวจสอบองค์ประกอบ GUI ทั้งหมดสำหรับขนาด ตำแหน่ง ความกว้าง ความยาว และการยอมรับอักขระหรือตัวเลข ตัวอย่างเช่น คุณต้องสามารถใส่ข้อมูลลงในฟิลด์ข้อมูลได้
- ตรวจสอบว่าคุณสามารถดำเนินการฟังก์ชันการทำงานที่ต้องการของแอปพลิเคชันได้โดยใช้ GUI
- ตรวจสอบข้อความแสดงข้อผิดพลาดว่าแสดงอย่างถูกต้องหรือไม่
- ตรวจสอบการแบ่งเขตที่ชัดเจนของส่วนต่างๆ บนหน้าจอ
- ตรวจสอบฟอนต์ที่ใช้ในแอพพลิเคชั่นว่าสามารถอ่านได้หรือไม่
- ตรวจสอบการจัดวางข้อความให้เหมาะสม
- ตรวจสอบสีของแบบอักษรและข้อความเตือนก็ดูสวยงาม
- ตรวจสอบว่าภาพมีความชัดเจนดี
- ตรวจสอบว่ารูปภาพอยู่ในแนวที่ถูกต้อง
- ตรวจสอบตำแหน่งขององค์ประกอบ GUI สำหรับความละเอียดหน้าจอที่แตกต่างกัน
เทคนิคการทดสอบ GUI
เมื่อมีรายการตรวจสอบแล้ว ขั้นตอนต่อไปคือการตัดสินใจว่าจะดำเนินการตามรายการตรวจสอบนั้นอย่างไร เทคนิคการทดสอบ GUI สามารถแบ่งได้เป็นสามส่วน:
การทดสอบแบบแมนนวล
ภายใต้แนวทางนี้ ผู้ทดสอบจะตรวจสอบหน้าจอกราฟิกด้วยตนเองตามข้อกำหนดที่ระบุไว้ในเอกสารข้อกำหนดทางธุรกิจ
บันทึกและเล่นซ้ำ
การทดสอบ GUI สามารถทำได้โดยใช้เครื่องมืออัตโนมัติ ซึ่งแบ่งออกเป็น 2 ส่วน คือ ในระหว่างการบันทึก เครื่องมืออัตโนมัติจะบันทึกขั้นตอนการทดสอบ และในระหว่างการทดสอบซ้ำ ขั้นตอนการทดสอบที่บันทึกไว้จะถูกเรียกใช้งานบนแอปพลิเคชันที่กำลังทดสอบ ตัวอย่างของเครื่องมือดังกล่าว ได้แก่ – QTP.
การทดสอบตามแบบจำลอง
แบบจำลองคือคำอธิบายเชิงกราฟิกของพฤติกรรมของระบบ ช่วยให้เราเข้าใจและคาดการณ์พฤติกรรมของระบบได้ แบบจำลองช่วยในการสร้างกรณีทดสอบที่มีประสิทธิภาพโดยใช้ข้อกำหนดของระบบ แผนภาพด้านล่างแสดงให้เห็นว่าแบบจำลองช่วยขับเคลื่อนการสร้างกรณีทดสอบอย่างไร:
ในการทดสอบโดยใช้แบบจำลองนี้ จำเป็นต้องพิจารณาสิ่งต่อไปนี้:
- สร้างโมเดล
- กำหนดอินพุตสำหรับโมเดล
- คำนวณผลลัพธ์ที่คาดหวังสำหรับโมเดล
- ดำเนินการทดสอบ
- เปรียบเทียบผลลัพธ์จริงกับผลลัพธ์ที่คาดหวัง
- การตัดสินใจดำเนินการต่อไปกับแบบจำลอง
เทคนิคการสร้างแบบจำลองบางอย่างที่สามารถรับกรณีทดสอบได้:
- แผนภูมิ – แสดงสถานะของระบบและตรวจสอบสถานะหลังจากป้อนข้อมูลบางอย่าง
- ตารางการตัดสินใจ – ตารางที่ใช้ในการกำหนดผลลัพธ์สำหรับแต่ละอินพุตที่ใช้
การทดสอบตามแบบจำลองเป็นเทคนิคที่พัฒนาขึ้นสำหรับการสร้างกรณีทดสอบจากข้อกำหนด- ข้อได้เปรียบหลักเมื่อเปรียบเทียบกับสองวิธีข้างต้น ก็คือสามารถระบุสถานะที่ไม่พึงประสงค์ที่ GUI ของคุณสามารถบรรลุได้
การทดสอบ GUI ด้วยตนเองเทียบกับการทดสอบ GUI อัตโนมัติ
ในจำนวนสามเทคนิคดังกล่าว มีสองเทคนิคที่ใช้แรงงานคน และอีกหนึ่งเทคนิคเป็นแบบอัตโนมัติ ซึ่งทำให้เกิดคำถามเชิงปฏิบัติว่าแต่ละเทคนิคควรอยู่ในตำแหน่งใด การทดสอบด้วยตนเอง เพราะมีคนอยู่หน้าจอ จึงสามารถจับภาพขั้นตอนการทำงานที่ดูไม่เป็นธรรมชาติ การใช้คำพูดที่งุ่มง่าม และแอนิเมชั่นที่ดูไม่ถูกต้อง ซึ่งเป็นสิ่งที่บทภาพยนตร์ไม่สามารถทำได้
การทดสอบอัตโนมัติ มันทำการจำลองปฏิสัมพันธ์เดิมซ้ำหลายพันครั้งโดยไม่รู้สึกเหนื่อยล้า ซึ่งทำให้มันเป็นคำตอบที่เหมาะสมสำหรับเส้นทางการถดถอยที่เสถียรและสำหรับการทำซ้ำชุดทดสอบหนึ่งชุดในหลายๆ เบราว์เซอร์ ข้อเสียคือการบำรุงรักษา: สคริปต์ GUI อัตโนมัติจะใช้งานไม่ได้เมื่อใดก็ตามที่ตัวระบุตำแหน่งหรือเค้าโครงเปลี่ยนแปลง ดังนั้นทีมที่มีประสบการณ์ส่วนใหญ่จึงใช้ระบบไฮบริด โดยใช้ระบบอัตโนมัติกับส่วนที่ทำซ้ำได้ และสงวนบุคลากรไว้สำหรับส่วนที่เกี่ยวข้องกับประสบการณ์
| ปัจจัย | การทดสอบ GUI ด้วยตนเอง | การทดสอบ GUI แบบอัตโนมัติ |
|---|---|---|
| เหมาะสำหรับ | หน้าจอใหม่ การตรวจสอบเบื้องต้น รูปลักษณ์และสัมผัส | ชุดทดสอบการถดถอยที่เสถียร การทำงานบนเบราว์เซอร์ที่หลากหลาย |
| ความเร็วต่อรอบ | ช้า และมีข้อจำกัดด้านเวลาทดสอบ | ทำงานเร็ว อัตโนมัติตลอดคืน |
| ค่าใช้จ่ายล่วงหน้า | ต่ำ | ระดับสูง (การเขียนสคริปต์และการตั้งค่าเฟรมเวิร์ก) |
| ซ่อมบำรุง | ไม่มีอะไรนอกเหนือจากการอัปเดตรายการตรวจสอบ | มีความสำคัญเมื่ออินเทอร์เฟซเปลี่ยนแปลง |
| ตรวจจับประเด็นเชิงอัตวิสัย | มี (ใบกำกับภาษีเต็มรูปแบบ) | ไม่ |
ตัวอย่างกรณีทดสอบการทดสอบ GUI
การทดสอบ GUI โดยทั่วไปเกี่ยวข้องกับ
- การทดสอบขนาด ตำแหน่ง ความกว้าง ความสูงขององค์ประกอบ
- ทดสอบข้อความแสดงข้อผิดพลาดที่กำลังแสดงขึ้นมา
- ทดสอบส่วนต่างๆ ของหน้าจอ
- การทดสอบแบบอักษรว่าสามารถอ่านได้หรือไม่
- การทดสอบหน้าจอในความละเอียดต่าง ๆ ด้วยการซูมเข้าและออก เช่น 640 x 480, 600×800 เป็นต้น
- การทดสอบการจัดวางข้อความและองค์ประกอบอื่นๆ เช่น ไอคอน ปุ่ม ฯลฯ อยู่ในตำแหน่งที่เหมาะสมหรือไม่
- ทดสอบสีของฟอนต์
- ทดสอบสีของข้อความแสดงข้อผิดพลาด ข้อความเตือน
- ทดสอบว่าภาพมีความคมชัดดีหรือไม่
- ทดสอบการจัดตำแหน่งของภาพ
- การทดสอบการสะกดคำ
- ผู้ใช้จะต้องไม่หงุดหงิดในขณะที่ใช้อินเทอร์เฟซระบบ
- กำลังทดสอบว่าอินเทอร์เฟซอยู่ที่ใดtracไม่ว่าจะจริงหรือไม่ก็ตาม
- การทดสอบแถบเลื่อนตามขนาดของหน้า ถ้ามี
- การทดสอบสนามที่ถูกปิดใช้งาน ถ้ามี
- การทดสอบขนาดของภาพ
- การทดสอบหัวข้อว่าจัดตำแหน่งอย่างถูกต้องหรือไม่
- การทดสอบสีของไฮเปอร์ลิงก์
การสาธิต: วิธีการทดสอบ GUI
รายการข้างต้นจะชัดเจนยิ่งขึ้นเมื่อนำไปใช้กับหน้าจอจริง ดังนั้นในที่นี้เราจะใช้ตัวอย่างกรณีทดสอบบางส่วนสำหรับบทสนทนาต่อไปนี้
ด้านล่างนี้คือตัวอย่างของกรณีทดสอบ ซึ่งประกอบด้วยสถานการณ์ทดสอบ UI และการใช้งาน หากคุณยังใหม่กับการเขียนกรณีทดสอบ โปรดดูที่นี่ วิธีการเขียนกรณีทดสอบ ก่อน
กรณีทดสอบที่ 01 – ตรวจสอบว่าช่องข้อความที่มีป้ายกำกับ “โฟลเดอร์ต้นทาง” สอดคล้องกันอย่างเหมาะสม
กรณีทดสอบที่ 02 – ตรวจสอบว่าช่องข้อความที่มีป้ายกำกับ “แพ็คเกจ” สอดคล้องกันอย่างเหมาะสม
กรณีทดสอบที่ 03 – ตรวจสอบให้แน่ใจว่าป้ายนั้นมีชื่อว่า “หมวดหมู่สินค้า” คือปุ่มที่อยู่ท้ายข้อความBox ด้วยชื่อ “โฟลเดอร์ต้นทาง".
กรณีทดสอบที่ 04 – ตรวจสอบให้แน่ใจว่าป้ายนั้นมีชื่อว่า “หมวดหมู่สินค้า” คือปุ่มที่อยู่ท้ายข้อความBox ด้วยชื่อ “แพ็คเกจ".
กรณีทดสอบที่ 05 – ตรวจสอบว่าช่องข้อความที่มีป้ายกำกับ “ชื่อ” สอดคล้องกันอย่างเหมาะสม
กรณีทดสอบที่ 06 – ตรวจสอบว่าฉลาก “ตัวปรับเปลี่ยน” ประกอบด้วยปุ่มตัวเลือก 4 ปุ่มพร้อมชื่อสาธารณะ, ค่าเริ่มต้น, ส่วนตัว, ป้องกัน
กรณีทดสอบที่ 07 – ตรวจสอบว่าฉลาก “ตัวปรับเปลี่ยน” ประกอบด้วยปุ่มตัวเลือก 4 ปุ่มซึ่งเรียงกันอย่างเหมาะสม
กรณีทดสอบที่ 08 – ตรวจสอบว่าฉลาก “ซุปเปอร์คลาส” ใต้ป้าย “ตัวปรับเปลี่ยน” ประกอบด้วยเมนูแบบเลื่อนลงซึ่งจะต้องจัดวางอย่างเหมาะสม
กรณีทดสอบที่ 09 – ตรวจสอบว่าฉลาก “ซุปเปอร์คลาส” ประกอบด้วยปุ่มที่มีป้ายกำกับ “หมวดหมู่สินค้า” ซึ่งจะต้องจัดวางให้เหมาะสม
กรณีทดสอบที่ 10 – ตรวจสอบว่าเมื่อคลิกที่ปุ่มตัวเลือกใดๆ ตัวชี้เมาส์เริ่มต้นจะต้องเปลี่ยนเป็นตัวชี้เมาส์รูปมือ
กรณีทดสอบที่ 11 – ตรวจสอบว่าผู้ใช้ไม่สามารถพิมพ์ในช่องดรอปดาวน์ของ “ซุปเปอร์คลาส".
กรณีทดสอบที่ 12 – ตรวจสอบให้แน่ใจว่าต้องมีการแสดงข้อผิดพลาดที่ถูกต้องหากมีการเลือกสิ่งใดผิดพลาด
กรณีทดสอบที่ 13 – ตรวจสอบให้แน่ใจว่าข้อผิดพลาดต้องแสดงเป็นสีแดงทุกครั้งที่จำเป็น
กรณีทดสอบที่ 14 – ตรวจสอบให้แน่ใจว่าได้ใช้ป้ายกำกับที่ถูกต้องในข้อความแสดงข้อผิดพลาดแล้ว
กรณีทดสอบที่ 15 – ตรวจสอบให้แน่ใจว่าปุ่มตัวเลือกแบบเดี่ยวต้องถูกเลือกเป็นค่าเริ่มต้นทุกครั้ง
กรณีทดสอบที่ 16 – ตรวจสอบให้แน่ใจว่าปุ่ม TAB ใช้งานได้ปกติขณะกระโดดping ในอีกช่องหนึ่งที่อยู่ติดกับช่องก่อนหน้า
กรณีทดสอบที่ 17 – ตรวจสอบให้แน่ใจว่าทุกหน้ามีชื่อเรื่องที่ถูกต้อง
กรณีทดสอบที่ 18 – ตรวจสอบให้แน่ใจว่าข้อความในหน้าเว็บจัดเรียงอย่างถูกต้อง
กรณีทดสอบที่ 19 – ตรวจสอบให้แน่ใจว่าหลังจากอัปเดตข้อมูลในช่องใด ๆ แล้ว จะต้องแสดงข้อความยืนยันที่ถูกต้อง
กรณีทดสอบที่ 20 – ตรวจสอบให้แน่ใจว่าต้องเลือกปุ่มตัวเลือกเพียงปุ่มเดียว และไม่สามารถเลือกช่องทำเครื่องหมายมากกว่าหนึ่งช่องได้
ความท้าทายในการทดสอบ GUI
การเขียนกรณีเหล่านั้นเป็นเรื่องง่าย; keeping การทำให้พวกเขายังคงมีชีวิตอยู่ได้ตลอดหลายเวอร์ชันนั้นไม่ใช่เรื่องง่าย ในวิศวกรรมซอฟต์แวร์ ปัญหาที่พบบ่อยที่สุดขณะทำสิ่งนี้คือ... การทดสอบการถดถอย คือ GUI ของแอปพลิเคชันมีการเปลี่ยนแปลงบ่อยครั้ง เป็นการยากมากที่จะทดสอบและระบุว่าเป็นปัญหาหรือการปรับปรุง ปัญหาจะปรากฏขึ้นเมื่อคุณไม่มีเอกสารใดๆ เกี่ยวกับการเปลี่ยนแปลง GUI
⚠️คำเตือน: สคริปต์ที่ระบุตำแหน่งองค์ประกอบโดยใช้พิกัดหน้าจอหรือรหัสที่สร้างขึ้นโดยอัตโนมัติจะใช้งานไม่ได้ในเวอร์ชันถัดไป ควรพิจารณากลยุทธ์การระบุตำแหน่งเป็นส่วนหนึ่งของการออกแบบ ไม่ใช่สิ่งที่คิดขึ้นมาทีหลัง
เครื่องมือทดสอบ GUI
เครื่องมือที่เหมาะสมจะช่วยลดความผันผวนเหล่านั้นได้มาก ต่อไปนี้คือรายชื่อเครื่องมือยอดนิยม เครื่องมือทดสอบ GUI :
- Selenium
- QTP
- Cucumber
- ซิลค์เทสต์
- TestComplete
- เครื่องทดสอบ GUI ของ Squish
คลิกที่นี่เพื่อเรียนรู้ Selenium, QTP & Cucumber.
ต่อไปนี้เป็นเครื่องมือโอเพ่นซอร์สที่มีให้ใช้สำหรับดำเนินการทดสอบ UI อัตโนมัติ
| สินค้า | ภายใต้ใบอนุญาต |
|---|---|
| AutoHotkey | จีพี |
| Selenium | อาปาเช่ |
| ซิคูลี | เอ็มไอที |
| กรอบงานหุ่นยนต์ | อาปาเช่ |
| น้ำ | BSD |
| ชุดเครื่องมือ Dojo | BSD |
ซิคูลี เป็นการใช้ภาพเป็นหลัก มีประโยชน์เมื่อตัวควบคุมไม่มีตัวระบุตำแหน่งที่เชื่อถือได้ Selenium ยังคงเป็นค่าเริ่มต้นสำหรับ การทดสอบแอปพลิเคชันเว็บ.
