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

מדוע בדיקות רגרסיה ויזואליות נשברות בעת שחרורים

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

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

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

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

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

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

מה נותנת בדיקת ממשק אוטומטית: אפקט ומדדים

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

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

השוואה מבוססת מודלים של ראייה (כמו ב-Applitools ובפלטפורמות דומות) מסירה את הרעש הזה: המודל מבחין בין הזזה אמיתית של בלוק לבין ציור מחדש של החלקת הקצוות.

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

מה אנחנו משווים לפני ואחרי ההטמעה:

• שיעור התראות השווא: מ-40–70% בהשוואות פיקסליות גולמיות ל-5–10% לאחר הגדרת מסכות וספים.
• זמן ניתוח הדוח: מחצי שעה של השוואה ידנית ל-5–10 דקות — רואים איזה בלוק זז, באיזה מסך ובאיזה מצב.
• פגמי עיצוב אצל המשתמש: בודדים במקום עשרות, כי הבדיקה רצה בכל שינוי, ולא ממש לפני ההפצה.
• מהירות הפצת השחרור: אישור החלק הוויזואלי מסתכם בשעות, ולא נמשך ימים.
• כיסוי מצבים: לא רק העמודים העיקריים, אלא גם חלונות מודאליים, שגיאות, רשימות ריקות, לוקאלים, טקסטים ארוכים.
• עלות העבודה בתחזוקת תמונות הייחוס: מסכים חדשים מתווספים בלי לכתוב מחדש את מערך הבדיקות ידנית.

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

גישות להשוואת צילומים: פיקסלית, מבנית, ומודל AI

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

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

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

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

שלבי ההטמעה: מביקורת הממשק ועד מסירת נהלים

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

1. ביקורת ממשק ומיפוי מלאי המסכים. מרכיבים מפה של עמודים, חלונות מודאליים, מצבי טעינה ושגיאה, ומסמנים בנפרד אזורים דינמיים — באנרים, מונים, אווטארים — שאין להשוות ישירות.
2. סכימת הבדיקות. קובעים באילו סוגי מכשירים ובאילו דפדפנים מצלמים את תמונות הייחוס ואילו צעדים עוברים לפני הצילום, כדי שהמסך יגיע למצב הרצוי.
3. הגדרת רגישות. בוחרים את סף הרגישות של ההשוואה ואת אזורי המיסוך: סף קפדני מדי מייצר רעש בכל שחרור, סף רך מדי מחמיץ פגמים אמיתיים.
4. צילום תמונות הייחוס וסקירה ידנית. הריצה הראשונה כמעט תמיד מציגה אי-התאמות — סוקרים אותן ומאשרים אותן כנורמה החדשה.
5. הטמעה בצינור הבילד. הבדיקה רצה בכל שינוי וחוסמת מיזוג אם אי-ההתאמה עולה על הסף שהוגדר.
6. בדיקה על שינויים אמיתיים. שוברים בכוונה את הפריסה בענף בדיקה: בודקים אם המערכת תתפוס את הפגם ואם לא תרים התראת שווא.
7. מסירת נהלים. מוסרים תיעוד: כיצד מוסיפים מסכים חדשים, כיצד מעדכנים תמונות ייחוס ומי מוסמך לשנות את הסף.

מה תקבלו: קונפיגורציות, תמונות ייחוס, כללים ותיעוד

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

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

מקרה בוחן: כיצד צמצמנו התראות שווא וזמן בדיקה

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

מה היה לפני ההטמעה

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

מה שינינו

קבענו תמונות ייחוס לפי תרחישי מפתח, ואת ההשוואה מסרנו לשירות ניתוח ויזואלי מבוסס AI — Applitools. הגדרנו אזורי התעלמות לדינמיקה, ספים נפרדים לתפקידים ולגרסאות שפה, השהיה עד לעצירת האנימציות. ההשוואה הפכה למשמעותית: ההדגשה הצביעה על בלוק שבור באמת, ולא על טקסט שזז בכמה נקודות.

מה קרה בסוף

התראות השווא ירדו מכ-65% ל-10%, בדיקת הממשק התקצרה משלוש-ארבע שעות לחצי שעה, הכיסוי גדל מחמישה מסכים נבחרים לארבעים מסכים עיקריים. פגמי פריסה החלו להתגלות בשלב הבילד, ולא אחרי השחרור.

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

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

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

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

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

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

את תמונת הייחוס מעדכנים במכוון, עם סקירה של ההבדלים, אחרת הבדיקה מאבדת את משמעותה. אז השכבה הוויזואלית מוסיפה דקות לבילד, ופגמים מהסוג של «הפריסה זזה, הלוגיקה שלמה» מפסיקים להגיע למשתמשים.

ספקות ומגבלות של בדיקות רגרסיה לממשק

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

האם יהיה צורך לאשר מחדש תמונות ייחוס אחרי כל שחרור?

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

מה יישאר לצוות הלקוח אחרי המסירה?

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

מה ההשוואה האוטומטית לא תתפוס?

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

נדון במשימה ונחזור עם אומדן ותוכנית עבודה

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

אחרי הדיון במשימה נחזור עם החומרים הבאים:

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

תארו את תהליך הבדיקות הנוכחי ואת הממשק — נחזור עם אומדן העבודה, סכימת ההטמעה ולוחות זמנים.