בדיקה של צילום מסך

בדיקת צילומי מסך היא דרך יעילה מאוד לאימות ממשק המשתמש של האפליקציה. בדיקות של צילומי מסך יכולות להיות קיימות בבדיקות רכיבים, בבדיקות של תכונות ובבדיקות אפליקציה.

אפשר להשתמש בכלים של צד שלישי כדי ליצור בדיקות של צילומי מסך מקומיים וגם בדיקות עם ציוד למדידת ביצועים. אם אתם משתמשים ב-Compose, תוכלו להשתמש בכלי הרשמי לבדיקת צילומי מסך של Compose Preview.

הגדרה

בבדיקה של צילומי מסך, מתבצע צילום מסך של ממשק המשתמש והוא מושווה לתמונה שאושרה בעבר, שנקראת 'תמונה לצורך בדיקה' או 'תמונה מוזהבת':

בבדיקה של צילום מסך מושווים שני תמונות: צילום מסך חדש ותמונה להשוואה.
איור 1. בדיקת צילום מסך משווה בין שתי תמונות

אם התמונות זהות, הבדיקה עוברת. אם יש הבדלים ביניהם, הכלי יוצר דוח:

דוח בדיקת צילום מסך שבו מוצגים צילום המסך של הקובץ העזר וצילום המסך החדש משני הצדדים, וההבדל באמצע.
איור 2. דוח בדיקת צילום מסך שבו מוצגים צילום המסך של הקובץ העזר וצילום המסך החדש משני הצדדים, וההבדל באמצע.

בדוח יש שתי תשובות אפשריות:

  • להבין שיש שגיאה בקוד החדש ולתקן אותה.
  • מאשרים את צילום המסך החדש ומחליפים את תמונת העזר בתמונה החדשה.

תהליך העבודה של בדיקות צילומי מסך שונה מתהליך העבודה של בדיקות רגילות, כי בדיקה שנכשלה לא תמיד מעידה על שגיאה.

יתרונות

היתרונות של בדיקות צילומי מסך הם:

  • בבדיקה של צילום מסך מתבצעות כמה טענות נכוֹנוּת לכל בדיקה. לדוגמה, בבדיקה אחת אפשר לבדוק את הצבעים, השוליים, הגדלים והגופנים.
  • קל יותר לכתוב בדיקת צילום מסך, להבין אותה ולתחזק אותה מאשר בדיקת התנהגות מקבילה.
  • הן שימושיות במיוחד כדי לאמת ולזהות נסיגות (regressions) במסכים בגדלים שונים.

חסרונות

עם זאת, לבדיקות של צילומי מסך יש גם חסרונות:

  • עבודה עם קובצי ה-reference יכולה להיות מסורבלת, כי בפרויקט גדול יכולים להצטבר אלפי קובצי PNG.
  • בפלטפורמות שונות (Linux,‏ Mac ו-Windows) נוצרות צילומי מסך שונים במקצת.
  • הם איטיים יותר מבדיקות התנהגות מקבילות.
  • מספר גדול של בדיקות של צילומי מסך עלול לגרום לבעיות, למשל כאשר שינוי יחיד משפיע על אלפי צילומי מסך.

בקטעים הבאים מפורטות המלצות לפתרון הבעיות האלה.

כדאי לצמצם את מספר הבדיקות של צילומי המסך

מומלץ לצמצם את מספר בדיקות צילומי המסך, תוך הגדלת המשוב והכיסוי של רגרסיות.

שילובים של מצבי ממשק משתמש שונים יכולים להגדיל את מספר הבדיקות במהירות רבה. ריכזנו כאן כמה מהדרכים לאימות חלק מממשק המשתמש של האפליקציה:

  • בנושאים שונים
  • שימוש בגופנים בגדלים שונים
  • בגדלים שונים של מסכים או בגבולות שונים

אם תבצעו את הפעולות האלה לכל רכיב, פריסה ומסך באפליקציה, תקבלו אלפי קובצי צילומי מסך, ברובם לא תקבלו משוב נוסף.

לדוגמה, אם רוצים לבדוק לחצן מותאם אישית עם עיצובים בהירים וחשוכים וב-3 גדלי גופן, אין צורך ליצור שילובים של כל האפשרויות האלה. במקום זאת, אפשר לבחור רק אחד מהעיצובים. הסיבה לכך היא שלאופן התגובה של הלחצן למילים ארוכות אין השפעה על העיצוב.

אפשר להשמיט חלק מהשילובים של מאפייני ממשק משתמש.
איור 3. אפשר להשמיט חלק מהשילובים של מאפייני ממשק המשתמש.

תמונות לעיון בחנות

בדרך כלל, קובצי אימג' של עזר (או קובצי אימג' מוזהבים) הם קובצי PNG שאפשר להוסיף למערכת בקרת הגרסאות. עם זאת, Git ורוב מנהלי בקרת המקורות עוברים אופטימיזציה לקובצי טקסט, ולא לקבצים בינאריים גדולים.

יש 3 אפשרויות לניהול הקבצים האלה:

  • להמשיך להשתמש ב-git, אבל לנסות לצמצם את השימוש באחסון.
  • משתמשים ב-Git LFS.
  • אפשר להשתמש בשירות ענן כדי לנהל את צילומי המסך.

הבדלים בין פלטפורמות

בדיקות של צילומי מסך מסתמכות על ממשקי API ברמה נמוכה של הפלטפורמה כדי לצייר תכונות ספציפיות כמו טקסט או צלליות, ופלטפורמות יכולות להטמיע אותן בדרכים שונות. אם אתם מפתחים ב-Mac ושומרים צילומי מסך חדשים שצולמו באופן מקומי, יכול להיות שתראו בדיקות שבורות במכונה של Linux CI.

יש 2 דרכים לפתור את הבעיה:

  • עמידות בשינויים קטנים
  • צילום מסך בשרת

להתמודד עם שינויים קלים

אפשר להגדיר את רוב ספריות הבדיקה של צילומי המסך כך שיאפשרו הבדלים קטנים בהשוואה בין שני צילומי מסך.

יש שתי גישות לכך:

  • מגדירים טווח סבירות לפי אחוז מהפיקסלים ששונו או לפי אחוז מההבדל הכולל בערכי הפיקסלים.
  • משתמשים ב-smart differ – האלגוריתם שמשויך את צילומי המסך – כדי לאמת את הדמיון המבני והסמנטי במקום את הדמיון בפיקסלים.

החיסרון של גישה זו הוא שהיא יכולה ליצור תוצאות חיוביות מוטעות ולא לזהות שגיאות שנמצאות מתחת לסף, או שהן נחשבות בטעות לדומות מספיק.

צילום מסך בשרת

כדי להשתמש במשווא לצילום מסך באיכות פיקסלים מושלמת, צריך לוודא שבבדיקות מתבצעים צילומי מסך באותם תנאים. כדי לעשות זאת, אפשר להשתמש במערכת האינטגרציה הרצייפה (CI) או להשתמש בשירות בענן.

לדוגמה, אפשר ליצור שלב בתהליך העבודה של CI שמבצע את הפעולות הבאות:

  1. הפעלת בדיקות צילומי המסך (נדרש רק אם לא משתמשים בהתאמה מדויקת לפי פיקסלים).
  2. תיעוד של צילומי מסך חדשים אם השלב הקודם נכשל.
  3. שומרים את הקבצים החדשים בהסתעפות.
טקסט חלופי: תרשים שמראה איך לצלם צילומי מסך ב-CI
איור 4. תרשים שמראה איך לצלם צילומי מסך ב-CI

בגישה הזו, בדיקות צילומי המסך אף פעם לא נכשלות ב-CI, אבל הן משנות את השינוי בשבילכם. כך אתם וגורמי הבדיקה של השינויים תוכלו לאשר את צילומי המסך החדשים על ידי מיזוג השינוי.

כלים לבדיקה של צילומי מסך

כדי לבדוק את צילומי המסך, כדאי לשים לב להבדלים העיקריים הבאים בין הכלים הזמינים לבין הספריות:

  • סביבה: בדיקות מקומיות שפועלות במארח, או בדיקות עם מכשירי מדידה שפועלות במהדמ או במכשיר.
  • מנוע עיבוד: פתרונות לצילום מסך בצד המארח יכולים להשתמש ב-Layoutlib – מנוע העיבוד של Android Studio לתצוגות מקדימות – או ב-Robolectric Native Graphics‏ (RNG).
    • frameworks שמבוססות על Layoutlib מתמקדות בעיבוד של רכיבים סטטיים, ומשתמשים במצבים שונים כדי להציג התנהגות שונה. בדרך כלל קל יותר להשתמש בהן.
    • מסגרות שמשתלבות עם RNG יכולות להשתמש בכל התכונות של Robolectric, ומאפשרות לבצע בדיקות בהיקף גדול יותר.