מערכת AI לניתוח תוצאות בדיקות וסיווג שגיאות

ניתוח בדיקות AI: היכן נשבר הסיווג הידני של שגיאות

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

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

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

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

מה משתנה לאחר הטמעת ניתוח תוצאות ב-AI

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

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

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

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

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

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

השוואה בין גישות לניתוח תוצאות הרצות

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

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

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

כיצד מתבצעת ההטמעה: מביקורת דוחות ועד מסירת המודל

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

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

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

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

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

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

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

קונפיגורציות, סכמת מחלקות שגיאה ונוהל הניתוח

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

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

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

מקרה בוחן: כיצד ניתוח הרגרסיה הואץ פי כמה

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

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

מה שינו ומה התקבל

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

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

במה שונה סימון בכללים מאימון על היסטוריית כשלים?

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

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

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

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

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

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

שאלות טכניות נפוצות בנוגע להטמעת הניתוח

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

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

כיצד לנהוג בהתראות שווא של המסווג?

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

מה יקרה עם סוג שגיאה חדש?

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

האם יש לתחזק את המודל לאחר ההפעלה?

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

כיצד זה ישתלב בצינור הדוחות?

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

נדון במשימת ניתוח תוצאות ההרצות שלכם

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

מה להכין לדיון:

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

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