ใช้ภาพหน้าจอสำหรับการแสดงทั้งหน้าจอ OCR สำหรับข้อความที่มองเห็นได้ และการจับคู่รูปภาพสำหรับเป้าหมายภาพที่รู้จัก การทดสอบภาพ Android ที่แข็งแกร่งที่สุดรวมการยืนยันที่เน้นจุดเดียวเข้ากับหลักฐานด้านเวลาและความล้มเหลวที่มั่นคง
คำตอบสั้นๆ คือ ทดสอบสิ่งที่จะต้องเป็นจริง
ใช้การทดสอบภาพหน้าจอเมื่อทั้งหน้าจอ ส่วนประกอบ ระยะห่าง สี หรือตัวพิมพ์ต้องคงความสอดคล้องกันทางสายตา ใช้ OCR เมื่อข้อกำหนดเกี่ยวกับคำที่บุคคลสามารถมองเห็นได้ โดยเฉพาะข้อความที่แปลเป็นภาษาท้องถิ่นหรือแสดงผลแบบไดนามิก ใช้การจับคู่รูปภาพเมื่อไอคอน ปุ่ม ป้าย หรือภาพประกอบที่รู้จักต้องปรากฏขึ้นแม้ว่าจะไม่มีตัวระบุ UI ที่เชื่อถือได้ก็ตาม
เริ่มต้นด้วยตัวเลือก UI หรือสถานะการเข้าถึงเมื่อข้อกำหนดคือความหมาย: มีการควบคุม เปิดใช้งาน ถูกเลือก หรือแสดงป้ายกำกับที่เสถียร เพิ่มการตรวจจับวัตถุเฉพาะเมื่อเป้าหมายอยู่ในคลาสภาพและอาจเปลี่ยนขนาดหรือตำแหน่งมากเกินไปสำหรับเทมเพลตเดียว วิธีการเหล่านี้เป็นแบบเลเยอร์ ไม่ใช่กรอบการทดสอบที่แข่งขันกัน
- ถามว่าหลักฐานใดที่จะโน้มน้าวผู้ตรวจสอบได้ว่าข้อกำหนดดังกล่าวผ่าน
- เลือกสัญญาณที่เชื่อถือได้ที่แคบที่สุด แทนที่จะเปรียบเทียบทุกพิกเซลตามค่าเริ่มต้น
- ปรับความเสถียรของหน้าจอก่อนที่จะสังเกต จากนั้นบันทึกอาร์ติแฟกต์เมื่อการยืนยันล้มเหลว
เปรียบเทียบวิธีทดสอบภาพของ Android
| วิธีการ | ดีที่สุดสำหรับ | จุดอ่อนหลัก | หลักฐานที่เป็นประโยชน์ |
|---|---|---|---|
| UI หรือสถานะการเข้าถึง | การควบคุม ป้ายกำกับ สถานะการเปิดใช้งาน การเลือก โครงสร้างการนำทาง | องค์ประกอบที่แสดงผลแบบกำหนดเองหรือที่ไม่สามารถเข้าถึงได้อาจไม่ปรากฏในแผนผัง UI | ลำดับชั้น UI คุณสมบัติที่เลือก ภาพหน้าจอ |
| ภาพหน้าจอหรือรูปภาพสีทอง | เค้าโครง การเว้นวรรค สี ตัวพิมพ์ รูปลักษณ์ของส่วนประกอบ | ข้อมูลไดนามิก ภาพเคลื่อนไหว ความแตกต่างของอุปกรณ์ และการเปลี่ยนแปลงการเรนเดอร์สามารถสร้างความแตกต่างที่มีสัญญาณรบกวนได้ | รูปภาพปัจจุบัน พื้นฐานที่ได้รับอนุมัติ ความแตกต่างของภาพ |
| โอซีอาร์ | ข้อความที่มองเห็น การแปล ใบเสร็จรับเงิน ข้อความสถานะ ค่าที่แสดงเป็นพิกเซล | คุณภาพการจดจำขึ้นอยู่กับการครอบตัด ขนาด คอนทราสต์ ข้อมูลภาษา การหมุน และการแบ่งส่วน | ครอบตัดต้นทาง ข้อความที่รู้จัก ความเชื่อมั่น หรือรายการผลลัพธ์ |
| การจับคู่เทมเพลต | ไอคอน ปุ่ม ป้ายสถานะ รูปขนาดย่อ หรือพื้นที่เล็กๆ ที่มีเสถียรภาพ | ธีม มาตราส่วน การบีบอัด และการออกแบบใหม่อาจทำให้เทมเพลตใช้ไม่ได้ | เทมเพลต, ขอบเขตการค้นหา, ตรงที่สุด, คะแนน, ภาพหน้าจอ |
| การตรวจจับวัตถุ | วัตถุที่มองเห็นซึ่งคลาสยังคงมีความหมายในขณะที่ตำแหน่งหรือขนาดแตกต่างกันไป | ต้องมีโมเดลที่เข้ากันได้ คลาสที่มีป้ายกำกับ ขีดจำกัด และการตรวจสอบโมเดล | เวอร์ชั่นโมเดล คลาส กล่อง คะแนน สกรีนช็อต |
คำแนะนำในการทดสอบภาพหน้าจออย่างเป็นทางการของ Android อธิบายการเปรียบเทียบการเรนเดอร์ปัจจุบันกับรูปภาพอ้างอิงที่ได้รับอนุมัติ ปลั๊กอินรูปภาพของ Appium เปิดเผยการจับคู่คุณสมบัติ การจับคู่เทมเพลต และการเปรียบเทียบความคล้ายคลึงกัน OpenCV บันทึกกลไกของการเลื่อนเทมเพลตไปเหนือรูปภาพ ในขณะที่ Tesseract จะบันทึกว่าทำไมการประมวลผลล่วงหน้าของ OCR และการแบ่งส่วนหน้าจึงมีความสำคัญ เครื่องมือต่างกัน แต่คำถามในการออกแบบการทดสอบยังคงเหมือนเดิม: ข้อสังเกตใดที่พิสูจน์ข้อกำหนดนี้
เลือกการยืนยันที่ถูกต้องด้วยคำถามสี่ข้อ
1. ข้อกำหนดคือความหมายหรือภาพ?
หากการทดสอบระบุว่า "เปิดใช้งานปุ่มส่งแล้ว" ให้ตรวจสอบสถานะ UI ก่อน หากมีข้อความว่า “ปุ่มส่งไม่ถูกคลิปหลังการเปลี่ยนแบบอักษร” ให้ใช้ภาพหน้าจอหรือการตรวจสอบด้วยภาพที่โฟกัส คิวรีเชิงความหมายมักจะรักษาได้ง่ายกว่า แต่ไม่สามารถพิสูจน์ลักษณะที่ปรากฏได้
2. ข้อความที่แน่นอนมีความสำคัญหรือไม่?
ใช้ OCR เมื่อสตริงที่ผู้ใช้เห็นเป็นข้อกำหนด และข้อความไม่ได้รับการเปิดเผยอย่างน่าเชื่อถือผ่านแผนผัง UI จำกัดการจดจำเฉพาะภูมิภาคที่มีความหมายน้อยที่สุด เลือกภาษาที่ถูกต้อง และเปรียบเทียบผลลัพธ์ที่ทำให้เป็นมาตรฐาน เก็บภาพหน้าจอไว้เนื่องจากสตริง OCR ที่ถูกต้องเพียงอย่างเดียวไม่สามารถแสดงการตัดทอน การทับซ้อนกัน หรือคอนทราสต์ที่ไม่ดีได้
3. มีเป้าหมายการมองเห็นที่มั่นคงเป้าหมายเดียวหรือไม่?
ใช้การจับคู่เทมเพลตสำหรับไอคอนที่รู้จักหรือตัวควบคุมขนาดเล็ก ครอบตัดเทมเพลตให้แน่น ค้นหาภายในภูมิภาคที่สนใจ และกำหนดเกณฑ์จากตัวอย่างเชิงบวกและเชิงลบจริง เกณฑ์สากลประการหนึ่งแทบจะไม่สามารถป้องกันได้กับธีม ความละเอียด และสตรีมระยะไกลที่ถูกบีบอัด
4. องค์ประกอบทั้งหมดจะต้องสอดคล้องกันหรือไม่?
ใช้การเปรียบเทียบภาพหน้าจอเมื่อความสัมพันธ์ระหว่างองค์ประกอบต่างๆ มีความสำคัญ แบบอักษรควบคุม สถานที่ การกำหนดค่าอุปกรณ์ แถบระบบ เวลา ข้อมูลเครือข่าย ภาพเคลื่อนไหว และเนื้อหาที่เริ่มต้น หากไม่สามารถควบคุมอินพุตเหล่านั้นได้ ให้มาสก์หรือครอบตัดขอบเขตไดนามิกแทนที่จะยอมรับการทดสอบที่มีสัญญาณรบกวนอย่างถาวร
สร้างการทดสอบการมองเห็นที่ล้มเหลวอย่างมีประโยชน์
- นำแอปไปสู่สถานะเริ่มต้นที่มีชื่อบนอุปกรณ์หรือโปรแกรมจำลองที่ได้รับอนุญาต
- รอให้สภาวะคงที่ ไม่ใช่แค่ความล่าช้าคงที่ UI Automator ให้ความเสถียรในการรอ และสัญญาณความพร้อมเฉพาะแอปก็ดียิ่งขึ้นไปอีก
- จับภาพบริเวณต้นทางที่เล็กที่สุดซึ่งมีหลักฐานที่จำเป็น
- ดำเนินการยืนยันหลักหนึ่งรายการ: สถานะ UI, OCR, เทมเพลต, การตรวจจับ หรือการเปรียบเทียบภาพหน้าจอ
- บันทึกอิมเมจต้นฉบับและผลลัพธ์ที่มีโครงสร้างก่อนดำเนินการถัดไป
- เมื่อเกิดความล้มเหลว ให้หยุดหรือปฏิบัติตามเส้นทางการกู้คืนที่ได้รับการตรวจสอบแล้ว อย่าแตะสิ่งที่เหมือนกันในบริเวณใกล้เคียงเพียงเพื่อให้การทดสอบดำเนินต่อไป
การตรวจสอบด้วยภาพจะปลอดภัยยิ่งขึ้นเมื่ออนุญาตการเปลี่ยนแปลง สังเกตสถานะปัจจุบัน ทำการยืนยัน ดำเนินการตามที่อนุญาตหลังจากสำเร็จเท่านั้น และตรวจสอบเงื่อนไขภายหลัง นี่เป็นหลักการออกแบบเดียวกันกับที่อธิบายไว้ในคู่มือการคลิกอัตโนมัติของการจดจำภาพ: การจดจำไม่ใช่ข้อพิสูจน์ว่าเวิร์กโฟลว์เสร็จสิ้น
สำหรับการใช้งานบนอุปกรณ์จริงการมิเรอร์หน้าจอ Android สำหรับการทดสอบแอปบนอุปกรณ์เคลื่อนที่ช่วยให้ผู้ตรวจสอบได้รับชมแบบสดในขณะที่การทดสอบกำลังได้รับการออกแบบ คู่มือการทดสอบควัน QA อัตโนมัติของ Androidอธิบายวิธีทำให้การตรวจสอบซ้ำแคบลงและทำซ้ำได้
สถานการณ์การทดสอบภาพของ Android ที่ใช้งานได้จริงสามสถานการณ์
QA การแปลบนหน้าจอชำระเงิน
ใช้สถานะ UI เพื่อนำทางไปยังหน้าจอการชำระเงิน OCR เพื่อยืนยันป้ายกำกับผลรวมและการดำเนินการที่แปลเป็นภาษาท้องถิ่น และภาพหน้าจอที่เน้นเพื่อแสดงว่าสตริงไม่ได้ถูกตัดหรือทับซ้อนกัน รันแต่ละโลแคลด้วยข้อมูลการทดสอบที่มีการควบคุม การเปรียบเทียบพิกเซลแบบเต็มหน้าจอเพียงอย่างเดียวจะไวต่อความยาวสตริงที่แปลมากเกินไป ในขณะที่ OCR เพียงอย่างเดียวจะพลาดความเสียหายของเลย์เอาต์
กำลังตรวจสอบไอคอนแถบเครื่องมือที่ออกแบบใหม่
ใช้เทมเพลตสำหรับไอคอนที่ยอมรับในพื้นที่แถบเครื่องมือขนาดเล็ก เก็บเทมเพลตแยกกันเมื่อรองรับทั้งธีมสว่างและธีมมืด เมื่อการแข่งขันล้มเหลว ให้แนบครอบตัดแถบเครื่องมือและคะแนนผู้สมัครที่ดีที่สุด หากไอคอนได้รับการออกแบบใหม่โดยเจตนา ให้ตรวจสอบและเปลี่ยนเทมเพลตแทนที่จะลดเกณฑ์ลงจนกว่ารูปร่างจะผ่าน
การทดสอบควันจากโทรศัพท์จริงหลังการใช้งาน
เริ่มจากบัญชีและสถานะแอปที่รู้จัก รอหน้าจอเริ่มต้น ยืนยันตัวตน ดำเนินการหนึ่งอย่างที่ได้รับอนุญาต และตรวจสอบสถานะที่มีชื่อถัดไป จับภาพหน้าจอทุกครั้งที่เกิดความล้มเหลว ความหนาแน่นของอุปกรณ์ กล่องโต้ตอบการอนุญาต แป้นพิมพ์ การแจ้งเตือน และการอัปเดตระบบเป็นส่วนหนึ่งของสภาพแวดล้อมโทรศัพท์จริง ดังนั้นการทดสอบควรรายงานสิ่งเหล่านี้แทนที่จะซ่อนไว้
ความล้มเหลวที่ผิดพลาดที่พบบ่อยและวิธีป้องกัน
| อาการ | สาเหตุน่าจะ | ตอบสนองดีขึ้น |
|---|---|---|
| ส่วนต่างของภาพหน้าจอจะเปลี่ยนไปทุกครั้งที่วิ่ง | นาฬิกา แอนิเมชัน โฆษณา ข้อมูลเริ่มต้น แป้นพิมพ์ แถบระบบ หรือเนื้อหาเครือข่าย | หยุดอินพุต รอความเสถียร ครอบตัดหรือมาสก์เฉพาะขอบเขตไดนามิก |
| OCR ส่งคืนข้อความที่เป็นไปได้แต่ผิด | ภาษาไม่ถูกต้อง คอนทราสต์ต่ำ ครอบตัดเล็กน้อย การหมุน จุดรบกวน หรือการแบ่งส่วนที่ไม่เหมาะสม | บันทึกการครอบตัด ปรับปรุงขนาดและคอนทราสต์ เลือกภาษาและการแบ่งส่วนอย่างจงใจ |
| การจับคู่เทมเพลตใช้งานได้บนโทรศัพท์เครื่องเดียวเท่านั้น | ความหนาแน่น ธีม การปรับขนาด อัตราส่วนภาพ หรือการบีบอัดที่แตกต่างกัน | ใช้ภูมิภาคที่สนใจและเทมเพลตที่ผ่านการตรวจสอบแล้วสำหรับรูปแบบภาพที่รองรับ |
| พบภาพที่ถูกต้องแต่การแตะล้มเหลว | พิกัดการจับคู่ไม่ได้ถูกแปลงเป็นหน้าจอปัจจุบันหรืออินพุตบล็อกซ้อนทับ | แยกการรับรู้ออกจากการกระทำและตรวจสอบสถานะถัดไป |
| การทดสอบดำเนินต่อไปบนหน้าจอที่ไม่ถูกต้อง | ไม่มีเงื่อนไขภายหลังหรือความล้มเหลว | ตั้งชื่อสถานะที่คาดหวังและหยุดเมื่อหน้าจอปัจจุบันอยู่นอกเส้นทางที่ตรวจสอบ |
| ตัวตรวจจับวัตถุค้นหาคลาสที่ไม่ถูกต้อง | โมเดลหรือป้ายกำกับไม่พอดีกับโดเมนแอป เกณฑ์ไม่ได้รับการตรวจสอบ | ใช้แบบจำลองที่เข้ากันได้ เวอร์ชันบันทึกและคะแนน ทดสอบตัวอย่างที่เป็นลบ |
การอภิปรายในชุมชนเกี่ยวกับการทดสอบการถดถอยของ Android มักจะกลับไปใช้ค่าบำรุงรักษาเท่าเดิม เช่น เมทริกซ์ของอุปกรณ์ เวลาที่ไม่สม่ำเสมอ การตรวจสอบพื้นฐาน และหน้าจอที่เนื้อหาเปลี่ยนแปลง นั่นไม่ใช่เหตุผลที่จะละทิ้งการทดสอบด้วยภาพ สิ่งเหล่านี้เป็นเหตุผลในการทำให้สภาพแวดล้อมการทดสอบ ความแปรปรวนที่ยอมรับ และส่วนความล้มเหลวมีความชัดเจน
LaiCai Flow เหมาะกับการทดสอบด้วยภาพอย่างไร
LaiCai Flowเป็นคุณสมบัติอัตโนมัติภายใน LaiCai Screen Mirroring Flow สามารถรวมการจับภาพหน้าจอ การตรวจสอบ UI, OCR, การจับคู่เทมเพลต, การตรวจจับวัตถุ, เงื่อนไข, การดำเนินการ และการเปลี่ยนผ่านที่สำเร็จหรือล้มเหลวอย่างชัดเจน วิธีนี้ช่วยให้ผู้ทดสอบจำลองหน้าจอเป็นสถานะ แทนที่จะถือว่าการจดจำเป็นเพียงกลอุบายที่แยกออกมา
ด้วยLaiCai Flow Insideโปรไฟล์ที่เข้ากันได้สามารถทำงานผ่าน LaiCai Android Agent บนโทรศัพท์ได้หลังจากการปรับใช้ ความเข้ากันได้ยังคงขึ้นอยู่กับทุกโหนดและทรัพย์สินที่ใช้โดยโปรไฟล์นั้น OCR ท้องถิ่นใช้ Tesseract; การจับคู่เทมเพลตใช้เนื้อหารูปภาพที่เลือกและคะแนนที่กำหนดค่าได้ การตรวจจับภายในที่เข้ากันได้ใช้โมเดลที่รองรับ โหนดเครือข่ายหรือโมเดลระยะไกลยังคงต้องการการพึ่งพาเครือข่ายของตัวเอง
การดำเนินการนี้ไม่ได้ทำให้การทดสอบด้วยภาพทุกครั้งเชื่อถือได้โดยอัตโนมัติ ทีมยังคงต้องการพื้นฐานที่เป็นตัวแทน เทมเพลต ขอบเขต OCR แบบจำลอง ขีดจำกัด กรณีเชิงลบ และเงื่อนไขภายหลัง คุณค่าคือสามารถตรวจสอบการตัดสินใจและการเปลี่ยนแปลงเหล่านั้นได้ในเวิร์กโฟลว์เดียว คู่มือการทำงานอัตโนมัติของ AndroidAIให้มุมมองที่กว้างขึ้นเกี่ยวกับการเขียนและการดำเนินการบนอุปกรณ์จริง
ชุดหลักฐานขั้นต่ำสำหรับการทดสอบการมองเห็นที่ล้มเหลว
- ชื่อทดสอบ บิลด์แอป รุ่นอุปกรณ์ เวอร์ชัน Android ภาษา ธีม และการวางแนว
- ภาพหน้าจอต้นฉบับหรือพื้นที่ครอบตัดที่ใช้โดยการยืนยัน
- คุณสมบัติพื้นฐาน เทมเพลต ข้อความ คลาส หรือ UI ที่คาดหวัง
- ผลต่างที่สังเกตได้ ผลลัพธ์ OCR กล่องขอบเขต คะแนนการแข่งขัน หรือค่า UI
- สถานะที่ตั้งชื่อไว้ก่อนหน้านี้ พยายามดำเนินการ สถานะถัดไปที่คาดไว้ และเหตุผลที่หยุด
- เนื้อหา โมเดล หรือเวอร์ชันพื้นฐาน เพื่อให้ผู้ตรวจสอบสามารถจำลองการตัดสินใจได้
ป้ายผ่าน/ไม่ผ่านโดยไม่มีบริบทนี้บังคับให้บุคคลถัดไปสร้างการวิ่งทั้งหมดอีกครั้ง ชุดหลักฐานขนาดกะทัดรัดเปลี่ยนความล้มเหลวให้เป็นการตัดสินใจที่ตรวจสอบได้: แก้ไขผลิตภัณฑ์ ทำให้การทดสอบมีเสถียรภาพ อัปเดตเนื้อหาภาพที่ได้รับอนุมัติ หรือปฏิเสธการกำหนดค่าอุปกรณ์ที่ไม่รองรับ
คำถามที่พบบ่อยเกี่ยวกับการทดสอบภาพของ Android
การทดสอบ Android UI ทุกครั้งควรมีภาพหน้าจอหรือไม่
ไม่ ใช้ภาพหน้าจอเมื่อรูปลักษณ์มีความสำคัญหรือเมื่อสิ่งที่ผิดพลาดจะช่วยผู้ตรวจสอบได้ การยืนยันความหมายมักจะดีกว่าสำหรับพฤติกรรมที่แผนผัง UI เปิดเผยได้อย่างน่าเชื่อถือ
OCR ดีกว่าการจับคู่รูปภาพหรือไม่
OCR ตอบคำถามเกี่ยวกับข้อความที่มองเห็นได้ การจับคู่รูปภาพจะตอบคำถามเกี่ยวกับรูปแบบภาพที่ทราบ หากข้อกำหนดมีทั้งป้ายกำกับและรูปลักษณ์ ให้ใช้ OCR บวกกับภาพหน้าจอที่โฟกัสหรือการตรวจสอบเทมเพลต
การทดสอบภาพหน้าจอสามารถทำงานบนโทรศัพท์ Android จริงได้หรือไม่
ใช่ แต่อุปกรณ์จริงทำให้เกิดการเปลี่ยนแปลงมากกว่าตัวเรนเดอร์หรืออีมูเลเตอร์ฝั่งโฮสต์ที่ได้รับการควบคุม บันทึกการกำหนดค่าอุปกรณ์ ทำให้ UI และข้อมูลของระบบเสถียร และกำหนดความคาดหวังสำหรับเมทริกซ์อุปกรณ์ที่คุณรองรับจริง
ฉันควรใช้การตรวจจับวัตถุเมื่อใด
ใช้เมื่อคลาสอ็อบเจ็กต์ที่มีความหมายเคลื่อนที่หรือปรับขนาดเกินเกณฑ์ความคลาดเคลื่อนของเทมเพลตที่เสถียร และเฉพาะเมื่อมีการตรวจสอบโมเดลที่เข้ากันได้บนรูปภาพจริงของแอปเท่านั้น อย่าเพิ่มตัวตรวจจับเพียงเพราะมันฟังดูล้ำหน้ากว่า
เลือกหลักฐานก่อนเลือกเทคโนโลยี
การทดสอบภาพ Android ที่เชื่อถือได้เริ่มต้นด้วยประโยคเดียว: ผู้ตรวจสอบต้องสามารถพิสูจน์อะไรได้บ้าง เลือกสถานะ UI สำหรับความหมาย ภาพหน้าจอสำหรับองค์ประกอบ OCR สำหรับข้อความ การจับคู่เทมเพลตสำหรับเป้าหมายภาพที่รู้จัก และการตรวจจับวัตถุสำหรับคลาสที่ได้รับการตรวจสอบด้วยเรขาคณิตที่แปรผัน
จากนั้นให้เป็นส่วนหนึ่งของการสังเกตของการเปลี่ยนแปลงสถานะ: ทำให้เสถียร ยึดครอง ยืนยัน ดำเนินการหลังจากประสบความสำเร็จเท่านั้น ตรวจสอบเงื่อนไขภายหลัง และรักษาหลักฐานความล้มเหลว การออกแบบดังกล่าวเข้าใจได้ง่ายกว่าคอลเลกชันของการเรียกใช้การมองเห็นที่ขาดการเชื่อมต่อ และดูแลรักษาได้ง่ายกว่ามากเมื่อแอปหรืออุปกรณ์มีการเปลี่ยนแปลง