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

רווחים:

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

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

פירמידת בדיקות: מה לבדוק וכמה

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

סוג בדיקה

היקף

מהירות

יעילות AI

בדיקת יחידה

פונקציה/מעמד יחיד

מהר מאוד

גבוה מאוד

אינטגרציה

שכבת ביניים

בינוני

גבוה

ממשק משתמש / מקצה לקצה

זרם כל המסך

איטי

בינוני (שביר)

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

שלבי כתיבת מבחנים עם AI

1. הגדר את ההתנהגות שיש לבדוק. "פונקציה זו צריכה לתת פלט זה לקלט זה."
2. ציין את המסגרת. JUnit + MockK באנדרואיד, XCTest ב-iOS, אספרסו (אנדרואיד) או XCUITest (iOS) עבור ממשק המשתמש.
3. בקש מצבי גבול. תרחיש שמח + שגיאה + נקודות שבירה.
4. נהל חפצים מדומים. תלות חיצונית כגון רשת ומסד נתונים מוחקים לבדיקה (דמה - דומה מבוקר במקום השירות בפועל).
5. הפעל את הבדיקה ואמת. האם המבחן עובר, האם הוא מאשר משהו משמעותי באמת?

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

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

מדד כיסוי וכשל מבחן

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

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

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

מקרה 2 - מבחן מזויף. צוות אחד הוקל להגדיל את הכיסוי ל-85% עם 40 בדיקות יחידות שהופקו על ידי AI. במהלך הבדיקה, נראה שרוב הבדיקות לא באמת אימתו פלט כלשהו, ​​הם פשוט קראו לפונקציה וכתבו assertTrue(true). הכיסוי היה גבוה אבל ההגנה הייתה אפסית. המבחנים עברו שיפוץ ונכתבו מחדש עם אימותים אמיתיים. שיעור: מספרי סיקור יכולים לשקר.

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

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

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

הנחיה עוצמתית: "הפק בדיקות יחידה עבור פונקציית Kotlin זו עם JUnit5 + MockK. פונקציה: העברת כספים (סכום, מקור, יעד). התנהגויות לבדיקה (מה הקוד צריך לעשות):- העברה חוקית חייבת להצליח- יש לדחות סכום שלילי או אפס- סכום גדול מהיתרה חייב להידחות- שגיאת הרשת צריכה להיות חריגה מתאימה בלבד, שגיאת רשת צריכה להיות חריגה מתאימה בלבד mock שירות חיצוני. אל תכתוב טענה ריקה."

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

תבנית בדיקת יחידה: "צור בדיקות יחידה [JUnit/XCTest] עבור פונקציה זו עבור [שפה]. התנהגות צפויה: [מה לעשות]. כלול: תרחיש שמח, קלט אפס, נקודות שגיאה, מקרה שגיאה. תן לכל בדיקה לאמת התנהגות בודדת; השתמש בטענה משמעותית; לעג. [קוד]"

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

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

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

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

• רק בוחן את התרחיש המאושר. שגיאות מאוחסנות במצבי גבול; בקשו אותם בגלוי.
• קבלת מבחן ריק/חסר תועלת. בדיקות מסוג assertTrue(true) מנפחות את ההיקף ואינן מספקות הגנה.
• לאחר שה-AI יאמת מה הקוד עושה. הבדיקה צריכה לצפות למה שהקוד צריך לעשות; אחרת זה מתקן את הבאג.
• טעות במספר ההיקף למטרה. 90% כיסוי לא אומר 90% דיוק.
• קישור לטקסט בבדיקת ממשק משתמש. המבחן נשבר כאשר הטקסט משתנה; השתמש במזהה יציב (מזהה).
• הגדרת לעג לא נכון. "בדיקת היחידה" הקוראת לשירות בפועל תהיה איטית ושבירה.

לסיכום

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

משימת יישום

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

רשימת בדיקה

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