רווחים:
- יכולת לייצר קוד בדיקת ממשק משתמש חזק עם בינה מלאכותית, כולל בדיקת נתונים, המתנה פתוחה וטענה המאמתים את תוצאת המשתמש האמיתית
- יכולת להימנע מבדיקות שבירות (בורר גרוע, המתנה עיוורת) ולהפוך את הבדיקות לקלות לתחזוקה במבנה ה-Page Object Model
- יכולת לבדוק כל בדיקת ממשק משתמש המופקת על ידי שבירת הקוד ולאתר ולתקן בדיקות מזויפות שעברו
כל קליק, כל מילוי טופס, כל מעבר עמוד שמשתמש מבצע בדפדפן לא ניתנים לבדיקה שוב ושוב ביד - זו הסיבה שקיימת אוטומציה של בדיקות ממשק משתמש (ממשק משתמש; בדיקות אלו מחקות את התנהגות המשתמש על ידי הפעלת דפדפן אמיתי באופן פרוגרמטי). סלניום, מחזאי וברוש הם הכלים הנפוצים ביותר לעבודה זו. בינה מלאכותית (AI) מיומנת מאוד בכתיבת הקוד עבור הכלים האלה: אתה מתאר מקרה מבחן, AI נותן לך טיוטה של סקריפט אוטומציה בר ביצוע. אבל כאן נכנסת שוב האזהרה המרכזית של המודול הזה: קוד בדיקת ממשק המשתמש שה-AI מייצר יכול להיות לעתים קרובות בדיקות שבריריות ש"נדלקות בירוק אבל מאמתות את הדבר הלא נכון" או מתנופפות ברוח. התפקיד שלך הוא לא להפעיל את הקוד הזה, אלא לוודא שהוא אכן מאמת בצורה חזקה את הדבר הנכון.
ביחידה זו, אנו שואפים לייצר מבחני ממשק משתמש חזקים, ניתנים לתחזוקה ומאמתים באמת עם AI; תלמד להימנע ממבחנים שבירים.
שלושת עמודי התווך של בדיקות ממשק משתמש מוצקות
1. תקן את איתור האלמנטים. בדיקה משתמשת בבורר כדי למצוא את האלמנט בדף. בינה מלאכותית מייצרת לעתים קרובות בוררים שבירים: נתיבי XPath ארוכים (כתובת תלויה יתר על המידה במבנה העמוד), בוררים המבוססים על שמות מחלקות CSS (הפסקה כאשר עיצוב משתנה). הדרך החזקה היא תכונות יציבות כמו data-testid שהמפתח הוסיף לבדיקה. כפה זאת במפורש על ה-AI.
2. המתנה מפורשת. המקור מספר אחד לפגיעות בבדיקות ממשק משתמש הוא התזמון. השינה המתמדת(3) (המתנה עיוורת) היא תרגול רע: לפעמים זה לא מספיק, לפעמים זה מבזבז זמן. הדרך הנכונה היא להשתמש בהמתנה מפורשת, שאומר "המתן עד שהאלמנט הזה יופיע". מחזאי עושה זאת במידה רבה אוטומטית; בסלניום עליך לבקש זאת במפורש.
3. קביעה משמעותית. הבדיקה צריכה לאמת את התוצאה שהמשתמש יראה בפועל - כמו "מספר ההזמנה הופיע על המסך", לא רק "העמוד נטען". אם למבחן המופק על ידי ה-AI אין טענה או שהוא לא חשוב, המבחן הזה מייצר פסאודו-פס (יחידה ראשונה).
זהירות: כאשר אתה רואה לראשונה בדיקת ממשק משתמש שנוצרה בינה מלאכותית, בדוק שלושה דברים לכל היותר: האם הבוררים מחויבים (data-testid), הם ממתינים (ללא שינה עיוורת), והאם הטענה מאמתת את תוצאת המשתמש בפועל? אם שלושת אלה תקינים, כנראה שהבדיקה מוצקה.
מודל אובייקט עמוד
ככל שהבדיקות גדלות, כתיבת בוררים בתוך כל מבחן הופכת לסיוט תחזוקה. מודל אובייקט עמוד (POM - תבנית עיצוב שאוסף בוררים ופעולות עבור כל עמוד/מסך למחלקה אחת) שומר את הבורר במקום אחד; כאשר הממשק משתנה, אתה מעדכן אותו בקובץ בודד. בקש מה-AI לייצר את הבדיקות במבנה POM, ולא ישירות; זה מקל בצורה קיצונית על התחזוקה.
הנחיה חלשה / הנחיה חזקה
חלש: "כתוב מבחן סלניום עבור דף הכניסה."
חזק: "כתוב מבחן זרימת התחברות עם Playwright (TypeScript). הבוררים משתמשים רק ב-data-testid; אל תשתמש בשליטה במה שהמשתמש רואה, לא בכותרת העמוד."
הנחיה עוצמתית; הכלי נותן את השפה, מדיניות הבורר, אסטרטגיית המתנה, ארכיטקטורה (POM) וציפיות ביטוי אקספרסיביות.
בדיקת נתונים ועצמאות סביבתית
מבחן ממשק משתמש מוצק לא רק כתוב בצורה נכונה, אלא גם בונה ומנקה את נתוני הבדיקה שלו. בדיקות שנוצרו על ידי בינה מלאכותית מקשרות לרוב למשתמש או לרשומה שכבר מניחים שקיימים בסביבה ("התחבר כמשתמש אדמין"). הנחה זו נשברת כאשר הבדיקה פועלת בסביבה אחרת או לאחר בדיקה נוספת (בעיית תלות בהזמנה ביחידה 9). האמת היא שכל בדיקה יוצרת את הנתונים הדרושים לו בתחילת הבדיקה (או מכינה אותם בקריאה ל-API) ומנקה אותם בסוף. הוראה מפורשות ל-AI "להגדיר כל נתונים שהבדיקה הזו תלויה בהם בתוך הבדיקה; אל תניח נתונים מוכנים מבחוץ."
נקודה קריטית נוספת היא לא לעשות בדיקות ממשק משתמש עם נתוני משתמש אמיתיים. אם נעשה שימוש בעותק של מסד נתונים ייצור בסביבת הבדיקה, רשומות אלה הן נתונים של אנשים אמיתיים; צילומי מסך והקלטות בדיקה עשויים לחשוף נתונים אלה. השתמש בחשבונות בדיקה סינתטיים (בדיוניים); זה גם מגן על סודיות וגם הופך את הבדיקות לניתנות לשחזור. עריכת בדיקת "ביטול הזמנה" עם חשבון לקוח אמיתי היא טעות אתית ותפעולית כאחד.
טיפ: שמור כמה שפחות מבחני ממשק משתמש; השאירו את האימות בפועל ל-API ולבדיקות היחידה, שהן מהירות ויציבות. בדיקות ממשק משתמש יקרות ושבירות - השתמש בהן רק כדי לאמת זרימת משתמש אמיתית מקצה לקצה (לוגיקת פירמידת בדיקה).
השוואת רכבים
תכונה
סלניום
מחזאי
ברוש
שפות
Java, C#, Python, JS
JS/TS, Python, .NET, Java
JavaScript/TypeScript
המתנה אוטומטית
לא (ביד)
כן (חזק)
כן
דפדפן רב
רחב
Chromium/Firefox/WebKit
דומיננטי בכרום
נטייה לשבירות
גבוה (המתנה ידנית)
נמוך
נמוך
קלות למידה
בינוני
קל
קל
פעולה מקבילה
נדרשת רשת
מובנה
תושב/בתשלום
בעת בקשת קוד מ-AI, ציינו בבירור לאיזה רכב הוא שייך; אחרת, זה עלול לייצר קוד מבלבל ולא עובד.
ארבע תבניות הניתנות להעתקה
1) יצירת בדיקות ממשק משתמש מוצקות:
התפקיד שלך: מהנדס אוטומציה בכיר לבדיקות. כתוב מבחנים עם [כלי + שפה] עבור הזרימה הבאה: [זרימה]. כללים:- Selectors data-testid בלבד; שימוש ב-XPath/CSS-class. - אין שינה עיוורת; השתמש בהמתנה מפורשת/אוטומטית. - החל מודל אובייקט עמוד. - תן לכל טענה לאמת את תוצאת המשתמש בפועל. הערה בתחילת כל מבחן אילו קריטריוני קבלה אתה מאמת.
2) בקרת שבירות:
בדוק את מבחן ה-UI הבא לאיתור שבירות: האם יש בורר לא יציב (ארוך
3) המרה לאובייקט עמוד:
המר את קוד הבדיקה הפשוט הבא למבנה מודל אובייקט עמוד. העבר בוררים ופעולות למחלקות עמודים; תן לקובץ הבדיקה לקרוא רק את זרימת התרחיש. [כלי/שפה]. קוד: [הדבק קוד]
4) הוכחה פסאודו-מעבר:
הוכח שמבחן ממשק משתמש זה אכן מאמת: איזה שינוי בודד אני מבצע בקוד האפליקציה שיהפוך את המבחן הזה לאדום? אם אינך יכול למצוא שינוי שישבור את המבחן, הבדיקה אינה מספקת; הוסף טענות חסרות. מבחן: [הדבק מבחן]
שלושה מיני תיקים
מקרה 1 - שחרור מבורר שביר. מתוך 40 הבדיקות שצוות אחד ייצר עם AI, 70% נשברו לאחר עדכון ממשק; אף אחד מהם לא היה באגים ממשיים, כולם היו בוררי XPath שבירים. הצוות המיר את הבדיקות לבסיס בדיקות נתונים עם תבנית "בדיקת שבירות". במהלך שלושת עדכוני הממשק הבאים, מספר הפסקות השווא ירד לאפס; זמן התחזוקה ירד מ-6 שעות ל-30 דקות בשבוע.
מקרה 2 - מבחן ממשק משתמש מזויף. AI הפיקה מבחן "הוסף לעגלה"; המבחן היה ירוק. כאשר התבנית "הוכחת מעבר מזויפת" הופעלה, נראה היה שהבדיקה בודקת רק את הלחיצה על הכפתור וכותרת העמוד, ולעולם לא אימתה אם מונה העגלות גדל או לא. גם אם ההיגיון של העגלה נשבר לחלוטין, המבחן עבר. הוספה טענה אמיתית (תג העגלה הוא "1").
מקרה 3 - מלכודת המתנה עיוורת. במבחן הסלניום שהופק על ידי AI, הייתה שינה(2) לאחר כל שלב; 60 בדיקות ארכו 14 דקות ועדיין נשברו מדי פעם. לאחר המעבר להמתנה פתוחה (המתינו שהאלמנט יהיה ניתן ללחיצה) הזמן ירד ל-5 דקות והשבריריות נעלמה. ההמתנה העיוורת הייתה איטית ולא אמינה כאחד.
טעויות נפוצות
- הסכמה לבוררים שבירים. שימוש ב-XPaths הארוכים שנוצרו על ידי ה-AI כפי שהם; הבדיקות קורסות בשינוי הממשק הראשון.
- משאירים 'שינה' עיוור. "פתרון" העיתוי בהמתנה קבועה; גם איטי וגם חסר החלטיות.
- טענה טריוויאלית. רק ודא שהדף נטען; לא בודק את תוצאת המשתמש בפועל (Feke-pass).
- לגדול ללא POM. חלק בוררים לכל מבחן; עדכון ידני של עשרות קבצים כאשר הממשק משתנה.
- לא מפרט את הכלי. לא לומר ל-AI איזה כלי/שפה אתה רוצה; מקבל קוד מבולגן ולא עובד.
- אמון כשאתה מפעיל את הקוד שנוצר ועובר. לא בודק על ידי שבירת הקוד.
לסיכום
אוטומציה של בדיקות ממשק משתמש מאמתת את התנהגות המשתמש על ידי הפעלת הדפדפן בפועל עם התוכנית. בינה מלאכותית מייצרת את הקוד הזה במהירות, אבל ישנן שתי מלכודות גדולות: מבחנים שבירים (בורר גרוע, עיוור ממתין) ומבחנים עוברים מזויפים (טענה לא שלמה/טריוויאלית). שלושת עמודי התווך של בדיקת ממשק משתמש מוצקה הם בורר המחויבות (data-testid), המתנה מפורשת וטענה המאמתת את תוצאת המשתמש בפועל. ביצוע בדיקות ב-Page Object Model מפשט באופן קיצוני את התחזוקה. בדוק כל מבחן שנוצר בשאלה "איזה שינוי ישבור את זה?"
משימת יישום
בחר זרימת משתמשים מהפרויקט שלך (למשל התחברות או חיפוש). בקש את בדיקות הבינה המלאכותית לכתוב עם התבנית "יצירת בדיקות ממשק משתמש חזק". לאחר מכן: (1) לבדוק ולתקן את הבוררים ולהמתין עם "בדיקת שבירות", (2) להוכיח שכל בדיקה אכן מאמתת עם "הוכחה פסאודו-עוברת", (3) לשבור את הקוד ולראות שהבדיקה הופכת לאדום. דווח על מספר הבדיקות שהופקו ותוקנו, ועל מספר הפגיעויות והפסאודו-מעברים שמצאת.
רשימת בדיקה
- [ ] נתתי ל-AI את הכלי, השפה, מדיניות הבורר והארכיטקטורה (POM) בצורה ברורה.
- [ ] וידאתי שהבוררים הם נתונים-testid.
- [ ] הקפדתי להשתמש בהמתנה מפורשת/אוטומטית במקום שינה עיוורת.
- [ ] בדקתי שכל טענה מאמתת את תוצאת המשתמש בפועל.
- [ ] בדקתי כל מבחן על ידי שבירת הקוד; ראיתי שהוא הופך לאדום.
- [ ] אספתי את הבדיקות במבנה Page Object Model.