סיכון אמון כוזב, איכות בדיקות ובדיקת מוטציות: בדיקות בדיקות

רווחים:

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

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

תקן הזהב למדידת איכות הבדיקה: בדיקת מוטציות

הדרך החזקה ביותר להבין האם בדיקה אכן מגנה או לא היא בדיקת מוטציות (בדיקת מוטציות – טכניקה שמייצרת עיוותים/מוטציות קטנות מכוונות בקוד המקור ומודדת האם הבדיקות מזהות עיוותים אלו). ההיגיון פשוט: אם אתה שובר את הקוד בכוונה (הופכים + ל-, a > ל->=, אמת ל-false), חבילת בדיקות טובה צריכה לתפוס את השחיתות הזו ולהפוך לאדום. אם לא, ההפרעה הזו היא מוטציה ששרדה - כך שהבדיקות שלך לא ממש משמרות את ההתנהגות הזו.

ציון מוטציה = מוטציה נהרגה / מוטציה כוללת. חבילה עם 90% כיסוי קו עשוי לקבל ציון מוטציה של 40%; זה מציין שהקווים פועלים אך ההתנהגות לא מאומתת. ציון המוטציה הוא מדד הרבה יותר כנה לאיכות מאשר אחוזי כיסוי.

טיפ: ישנם כלי מוטציה אוטומטיים (PIT/Pitest עבור Java, Stryker עבור JavaScript/TypeScript, Stryker.NET עבור .NET, mutmut עבור Python). אלה יוצרים ובודקים באופן אוטומטי מאות מוטציות. אם אין לך כלי, אפילו השיטה הידנית של "שבור את הקוד" חשובה לאין ערוך עבור פונקציות קריטיות.

שלושת הפנים של פסאודו-אמון והתרופה נגדו

טופס פסאודו-אמון

סימפטום

תרופה נגד

מבחן ללא טענה

הקוד עובד, שום דבר לא מאומת

טענה אמיתית בכל מבחן; בדיקה עם מוטציה

מבחן המאשר את עצמו

צפוי = פלט של קוד

חשב את הערך הצפוי באופן עצמאי

טענה טריוויאלית

"לא ריק", "200 הוחזרו"

אימות כלל עסקי/תוצאה בפועל

כשל בהיקף גבוה

90% קווים, הגנה נמוכה

תסתכל על ציון המוטציה

סובלנות שביר למבחן

"שוב נתקעת, תעבור"

סיבת שורש + בדיקה דטרמיניסטית

שימוש בבינה מלאכותית כ"צוות אדום"

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

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

מוטציות מקבילות וגבולות הניקוד

בדיקת מוטציות היא רבת עוצמה, אבל יש לה מלכוד: חלק מהמוטציות לא משנות כלל את התנהגות הקוד. אלה נקראות מוטציות מקבילות (מוטציה שווה - קוד פגום, מוטציה שמייצרת בדיוק את אותה תוצאה כמו המקור). לדוגמה, שינוי הערך ההתחלתי של משתנה שמעולם לא נעשה בו שימוש אינו משפיע על הפלט; שום מבחן לא יכול ולא צריך לתפוס את זה. לכן, ציון של 100% מוטציה לרוב אינו בר השגה בפועל ואינו המטרה. ניכוש מוטציות שוות ביד הוא עתיר עבודה; אז אל תקראו את ציון המוטציה כציון בחינה מוחלט, אלא כאינדיקטור כנה ל"האם המבחנים שלי באמת מגנים?"

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

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

הנחיה חלשה / הנחיה חזקה

חלש: "האם הבדיקות שלי מספיקות?"

חזק: "פעלו כצוות אדום עבור הפונקציה וחבילת הבדיקות הזו. (1) צור 8 מוטציות בקוד שניתן להרוג (החלפת אופרטור, שינוי גבול, היפוך תנאי, החלפת ערך החזרה). (2) עבור כל מוטציה, ציינו איזו מהבדיקות הקיימות יתפוס אותה ואיזו לא. (3) עבור כל מוטציה ששורדת, כתוב בדיקה חדשה שתצליח להרוג את כל אלה. בודקים אך מפר את הכלל העסקי קוד+בדיקות: [הדבק]"

הנחיה עוצמתית; הוא מציב את הבינה המלאכותית כבוחן פורץ מבחנים, לא כמכונת שבח.

ארבע תבניות הניתנות להעתקה

1) בקרת מוטציות ידנית:

צור 8 מוטציות משמעותיות (שיבושים מכוונים קלים) עבור קוד זה: החלפת אופרטור אריתמטי, מגבלת השוואה (> לעומת >=), היפוך לוגי, החזרה/החלפה קבועה, דילוג על תנאי. עבור כל מוטציה, חזה אילו מהבדיקות הזמינות יתפסו אותה או לא. קוד+בדיקות: [הדבק]

2) הרג את המוטציה השורדת:

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

3) צוות אדום - דם הבדיקה:

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

4) בדיקת איכות בדיקה:

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

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

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

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

מקרה 3 - מלכודת השבחים. בוחן זוטר שאל את ה-AI, "האם המבחנים שלי טובים?" והוקל לו לשמוע את התשובה "מקיף מאוד". עמיתו הבכיר בדק את אותן בדיקות באמצעות תבנית "ביקורת איכות הבדיקה"; התברר ש-12 מתוך 20 בדיקות היו תפאורה (ללא טענה או זבל). השאלה הנכונה הביאה את התשובה הנכונה.

טעויות נפוצות

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

לסיכום

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

משימת יישום

ייבא פונקציה המכילה כלל עסקי והבדיקות שלו מהפרויקט שלך. אם אפשר, הפעל כלי מוטציה (Stryker/Pitest/mutmut) ומדוד את ציון המוטציה; אם אין כלי, צור לפחות 8 מוטציות עם התבנית "בקרת מוטציות ידנית" ונסה אותן ידנית. עבור כל מוטציה שורדת, כתוב בדיקה חדשה עם תבנית "הרוג שורדת מוטציה". לבסוף, עם דפוס "הצוות האדום", בדוק אם ה-AI יכול לייצר קוד שמטעה את הבדיקות שלך. דווח על ציון המוטציה ההתחלתי והסיום שלך (או שיעור המוטציה שנתפס/סך הכל).

רשימת בדיקה

• [ ] הערכתי את איכות הבדיקה לפי ציון מוטציה, לא כיסוי.
• [ ] הרצתי בדיקת מוטציות (באמצעות כלי או ידנית) עבור קוד קריטי.
• [ ] כתבתי בדיקות חדשות לכל מוטציה ששרדה.
• [ ] השתמשתי בבינה מלאכותית כצוות האדום וחיפשתי פרצות בבדיקות שלי.
• [ ] לא לקחתי את השבחים של ה-AI של "הבדיקות שלך טובות" כהרגעה.
• [ ] בדקתי שכל בדיקה מאמתת את הטענה בפועל, הערך הצפוי העצמאי והכלל העסקי.