מבחן ייצור ואבטחת איכות

רווחים:

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

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

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

שני הצדדים של הבדיקה: תיקון התנהגות לעומת אימות

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

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

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

שלב אחר שלב: כתיבת מבחנים חזקים עם AI

1. תן את המפרט, לא רק את הקוד. אם תוסיף את המידע "פונקציה זו צריכה לעשות זאת", ה-AI יכול לכתוב את הציפייה הנכונה; זה יבדוק את ההתנהגות הנוכחית אם רק תספק את הקוד.
2. בקשו תיקי קצה. ריק, ריק, אפס, שלילי, גדול מדי, פורמט גרוע, מקבילות - עזוב במפורש את הדרך המאושרת.
3. ציין את מסגרת הבדיקה והסגנון. "השתמש ב-pytest", "סדר-מעשה-תביע דפוס", "תן לכל מבחן לבדוק דבר אחד" וכו'.
4. בדוק ציפיות (טענה). השווה עם המפרט שכל טענה בודקת את הערך הנכון.
5. סגור פערים בהיקף. תנו בדיקות קיימות ושאלו "אילו ענפים ומקרים לא נבדקו?" לגרום לך לשאול; לאחר מכן בדוק בדיקות נוספות שהופקו.

שלושה מיני מארזים

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

מקרה 2 - מלכודת קיבוע הציפיות הכוזבות. פונקציית עיגול כסף הייתה למעשה שגויה; במקום לעגל 2.675 ל-2.67, זה היה לעגל 2.67 במקום 2.68. ה-AI הסתכל על הקוד וכתב assert round_money(2.675) == 2.67 - הקפאת השגיאה כ"אמיתית". כשהמפתח קרא את המפרט, הוא תיקן את הציפייה ותפס את הבאג האמיתי. בדיקת הכלל, לא הקוד, עשתה את ההבדל.

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

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

יצירת בדיקה מבוססת מפרט:

תפקיד: מפתח שכותב מבחנים. מסגרת: {{pytest/JUnit/Jest...}}.מה הפונקציה צריכה לעשות (מפרט): {{כלל}}כתוב מבחנים עבור הפונקציה הבאה. כתוב ציפיות לפי המפרט, לא הפלט הנוכחי של הקוד. שביל שמח + הוסף לפחות 4 מקרים קצה. תן לכל מבחן לבדוק דבר אחד, השתמש בשם תיאורי. {{פונקציה}}

סיעור מוחות של מקרה קצה:

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

ניתוח פערי כיסוי:

להלן הפונקציות והבדיקות הזמינות. אילו ענפים, תנאים ומקרים לא נבדקו? רשום את הליקויים וכתוב מבחנים חדשים רק עבור הליקויים. אל תחזור על הקיימים. פונקציה:{{function}}בדיקות:{{existing_tests}}

נתוני בדיקה / יצירת אובייקט מדומה:

צור נתוני בדיקה מציאותיים עבור בדיקות {{function/service}}: דוגמאות חוקיות, דוגמאות גבול ודוגמאות לא חוקיות בנפרד. הצע התנהגות מדומה פשוטה עבור התלות החיצונית {{X}}. שימוש בנתונים סודיים/PII אמיתיים; צור נתונים מזויפים.

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

חלש: "כתוב מבחן לפונקציה הזו."

חזקה: "עם pytest. פונקציה apply_discount(total, percent) — כלל: הנחה חייבת להיות 0%–30%, מחוץ לתחום צריכה לזרוק ValueError, התוצאה צריכה להיות מעוגלת ל-2 עשרונים. כתוב ציפיות לפי הכלל הזה (לא לפי קוד). Happy path + מקרי קצה אלה: 0%, 30%, [31]%, total" = error.

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

סוג בדיקה

תרומת AI

שליטה אנושית

בדיקות יחידות דרכים שמחות

שלד מהיר

האם הציפייה נכונה?

מארזי קצה

סיעור מוחות נרחב

לחסל את הלא רלוונטי

מילוי פערים בהיקף

מוצא ענפים שדילג עליהם

אשר את המשמעות

נתוני בדיקה/לעג

מייצר מדגם ריאליסטי

אין PII, בקרת ריאליזם

בדיקות מנהלות איכות, לא מבטיחות זאת

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

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

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

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

לסיכום

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

משימת יישום

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

רשימת בדיקה

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