การทดสอบภาพหน้าจอ

การทดสอบภาพหน้าจอเป็นวิธีที่มีประสิทธิภาพมากในการยืนยัน UI ของแอป การทดสอบภาพหน้าจอจะอยู่ในการทดสอบคอมโพเนนต์ ฟีเจอร์ และแอปพลิเคชัน

คุณใช้เครื่องมือของบุคคลที่สามเพื่อสร้างการทดสอบภาพหน้าจอทั้งที่มีเครื่องมือและในเครื่องได้ หากคุณใช้ Compose คุณสามารถใช้เครื่องมือทดสอบภาพหน้าจอของตัวอย่าง Compose อย่างเป็นทางการได้

คำจำกัดความ

การทดสอบภาพหน้าจอจะถ่ายภาพหน้าจอของ UI และเปรียบเทียบกับรูปภาพที่ได้รับอนุมัติก่อนหน้านี้ ซึ่งเรียกว่า "การอ้างอิง" หรือ "สีทอง"

การทดสอบภาพหน้าจอจะเปรียบเทียบรูปภาพ 2 รูป ได้แก่ ภาพหน้าจอใหม่ 1 รูปและรูปภาพอ้างอิง 1 รูป
รูปที่ 1 การทดสอบภาพหน้าจอจะเปรียบเทียบรูปภาพ 2 รูป

หากรูปภาพเหมือนกัน การทดสอบก็จะผ่าน หากข้อมูลไม่ตรงกัน เครื่องมือจะสร้างรายงานดังนี้

รายงานการทดสอบภาพหน้าจอที่แสดงภาพหน้าจออ้างอิงและภาพหน้าจอใหม่ในแต่ละด้าน และความแตกต่างตรงกลาง
รูปที่ 2 รายงานการทดสอบภาพหน้าจอที่แสดงภาพหน้าจออ้างอิงและภาพหน้าจอใหม่ในแต่ละด้าน และความแตกต่างตรงกลาง

จากรายงานนี้ คุณจะได้รับการตอบกลับ 2 แบบดังนี้

  • ตระหนักว่ามีข้อผิดพลาดในโค้ดใหม่ แล้วทำการแก้ไข
  • อนุมัติภาพหน้าจอใหม่และแทนที่รูปภาพอ้างอิงด้วยรูปภาพใหม่

การทดสอบภาพหน้าจอมีเวิร์กโฟลว์แตกต่างจากการทดสอบปกติ เนื่องจากผลการทดสอบที่ไม่ผ่านไม่ได้หมายความว่ามีข้อผิดพลาดเสมอไป

ข้อดี

ข้อดีของการทดสอบภาพหน้าจอมีดังนี้

  • การทดสอบภาพหน้าจอจะทำการยืนยันหลายรายการต่อการทดสอบ 1 ครั้ง เช่น การทดสอบครั้งเดียวสามารถตรวจสอบสี ระยะขอบ ขนาด และแบบอักษร
  • การทดสอบภาพหน้าจอเขียน ทำความเข้าใจ และดูแลรักษาได้ง่ายกว่าการทดสอบลักษณะการทำงานที่เทียบเท่า
  • ซึ่งมีประโยชน์อย่างยิ่งเมื่อตรวจสอบและติดตามการเกิดปัญหาซ้ำบนหน้าจอขนาดต่างๆ

ข้อเสีย

อย่างไรก็ตาม การทดสอบภาพหน้าจออาจมีข้อเสียดังนี้

  • การจัดการกับรูปภาพอ้างอิงอาจเป็นเรื่องยุ่งยาก เนื่องจากโปรเจ็กต์ขนาดใหญ่อาจต้องใช้ไฟล์ PNG หลายพันไฟล์
  • แพลตฟอร์มต่างๆ (Linux, Max และ Windows) จะสร้างภาพหน้าจอที่แตกต่างกันเล็กน้อย
  • การทดสอบนี้จะช้ากว่าการทดสอบลักษณะการทำงานที่เทียบเท่า
  • การทดสอบภาพหน้าจอจํานวนมากอาจทําให้เกิดปัญหาได้ เช่น เมื่อการเปลี่ยนแปลงเพียงครั้งเดียวส่งผลต่อภาพหน้าจอหลายพันภาพ

ส่วนต่อไปนี้จะให้คำแนะนำในการจัดการกับปัญหาเหล่านี้

ทดสอบภาพหน้าจอให้น้อยที่สุด

คุณควรลดจำนวนการทดสอบภาพหน้าจอให้เหลือน้อยที่สุด ขณะเดียวกันก็เพิ่มความคิดเห็นและการครอบคลุมสำหรับการถดถอยให้มากที่สุด

การรวมสถานะ UI ที่แตกต่างกันอาจทําให้จํานวนการทดสอบเพิ่มขึ้นอย่างรวดเร็ว ต่อไปนี้คือวิธีบางส่วนในการยืนยัน UI ของแอป

  • เกี่ยวกับธีมต่างๆ
  • การใช้ขนาดแบบอักษรที่แตกต่างกัน
  • อยู่ในหน้าจอขนาดต่างๆ หรือขอบเขตต่างๆ

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

เช่น หากต้องการทดสอบปุ่มที่กําหนดเองด้วยธีมสว่างและธีมดาร์ก รวมถึงปุ่มที่มีขนาดแบบอักษร 3 ขนาด คุณไม่จําเป็นต้องสร้างชุดค่าผสมทั้งหมด แต่คุณจะเลือกเพียงธีมเดียวแทนได้ เนื่องจากลักษณะการตอบสนองของปุ่มต่อคำที่ยาวๆ จะไม่มีผลต่อธีม

คุณละเว้นการผสมผสานพร็อพเพอร์ตี้ UI บางรายการได้
รูปที่ 3 คุณละเว้นชุดค่าผสมของพร็อพเพอร์ตี้ UI บางรายการได้

จัดเก็บรูปภาพอ้างอิง

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

คุณมี 3 ตัวเลือกในการจัดการไฟล์เหล่านี้ ได้แก่

  • ใช้ Git ต่อไป แต่พยายามลดการใช้พื้นที่เก็บข้อมูล
  • ใช้ Git LFS
  • ใช้บริการระบบคลาวด์เพื่อจัดการภาพหน้าจอ

ความแตกต่างของแพลตฟอร์ม

การทดสอบภาพหน้าจอใช้ API ระดับล่างของแพลตฟอร์มเพื่อวาดฟีเจอร์ที่เฉพาะเจาะจง เช่น ข้อความหรือเงา และแพลตฟอร์มต่างๆ สามารถนำไปใช้ได้หลายวิธี หากคุณพัฒนาบน Mac และบันทึกภาพหน้าจอใหม่ที่ถ่ายไว้ในพื้นที่ คุณอาจเห็นการทดสอบที่ไม่ทำงานบนเครื่อง CI ของ Linux

วิธีแก้ไขปัญหามี 2 วิธีดังนี้

  • ยอมรับการเปลี่ยนแปลงเล็กน้อย
  • ถ่ายภาพหน้าจอในเซิร์ฟเวอร์

ทนต่อการเปลี่ยนแปลงเล็กน้อย

คุณสามารถกำหนดค่าไลบรารีการทดสอบภาพหน้าจอส่วนใหญ่เพื่อให้มีความแตกต่างเล็กน้อยเมื่อเปรียบเทียบภาพหน้าจอ 2 ภาพ

ซึ่งทำได้ 2 วิธีดังนี้

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

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

ถ่ายภาพหน้าจอในเซิร์ฟเวอร์

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

เช่น คุณสามารถสร้างขั้นตอนในเวิร์กโฟลว์ CI ที่จะทําสิ่งต่อไปนี้

  1. เรียกใช้การทดสอบภาพหน้าจอ (จำเป็นเฉพาะในกรณีที่ไม่ได้ใช้การจับคู่ที่ตรงกันทุกพิกเซล)
  2. บันทึกภาพหน้าจอใหม่หากขั้นตอนก่อนหน้าไม่สำเร็จ
  3. คอมมิตไฟล์ใหม่ไปยังสาขา
ข้อความแสดงแทน: แผนภาพที่แสดงวิธีถ่ายภาพหน้าจอใน CI
รูปที่ 4 แผนภาพแสดงวิธีจับภาพหน้าจอใน CI

เมื่อใช้แนวทางนี้ การทดสอบภาพหน้าจอจะไม่ล้มเหลวใน CI แต่ระบบจะแก้ไขการเปลี่ยนแปลงให้คุณ วิธีนี้จะช่วยให้คุณและผู้ตรวจสอบการเปลี่ยนแปลงยอมรับภาพหน้าจอใหม่ได้ด้วยการผสานการเปลี่ยนแปลง

เครื่องมือทดสอบภาพหน้าจอ

พิจารณาความแตกต่างที่สำคัญต่อไปนี้ระหว่างเครื่องมือและไลบรารีที่ใช้ได้สำหรับการทดสอบภาพหน้าจอ

  • สภาพแวดล้อม: การทดสอบในเครื่องที่ทำงานบนโฮสต์ หรือการทดสอบที่มีเครื่องควบคุมซึ่งทำงานบนโปรแกรมจำลองหรืออุปกรณ์
  • เครื่องมือแสดงผล: โซลูชันภาพหน้าจอฝั่งโฮสต์สามารถใช้ Layoutlib ซึ่งเป็นเครื่องมือแสดงผลของ Android Studio สำหรับการแสดงตัวอย่าง หรือ Robolectric Native Graphics (RNG)
    • เฟรมเวิร์กที่อิงตาม Layoutlib จะมุ่งเน้นที่การแสดงผลคอมโพเนนต์แบบคงที่โดยใช้สถานะต่างๆ เพื่อแสดงลักษณะการทำงานที่แตกต่างกัน ซึ่งมักจะใช้งานง่ายกว่า
    • เฟรมเวิร์กที่ผสานรวมกับ RNG จะใช้ฟีเจอร์ทั้งหมดจาก Robolectric ได้ ซึ่งช่วยให้การทดสอบมีขอบเขตที่กว้างขึ้น