סוכן של App Testing (ל-Android)

סוכן App Testing הוא סוכן ליצירה, לניהול ולביצוע של תרחישי בדיקה שמבוסס על Gemini ב-Firebase. אתם מגדירים את יעדי הבדיקה בשפה טבעית, והסוכן משתמש ב-AI כדי להבין את האפליקציה ולנווט בה, לדמות אינטראקציות של משתמשים ולספק תוצאות בדיקה מפורטות.

איך סוכן App Testing משתמש בנתונים שלכם

סוכן App Testing מסופק על ידי Gemini ב-Firebase והוא כפוף לאותם תנאים. במאמר איך Gemini ב-Firebase משתמש בנתונים שלכם יש מידע נוסף על האופן שבו Gemini ב-Firebase משתמש בנתונים שלכם.

לפני שמתחילים

אם עדיין לא עשיתם זאת, עליכם לרשום את האפליקציה ב-Firebase.

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

יצירת תרחיש בדיקה

כדי להריץ בדיקות מבוססות-AI, סוכן App Testing משתמש בתרחישי הבדיקה בשפה טבעית כדי להריץ בדיקות באפליקציה.

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

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

שימוש בקובצי YAML

בדוגמה הבאה מוצג קובץ YAML שמגדיר שני תרחישי בדיקה:

tests:
- displayName: Login as guest
  id: login-as-guest
  steps:
  - goal: Log in as a guest
    finalScreenAssertion: The home screen is visible
- displayName: View biography card birth date
  prerequisiteTestCaseId: login-as-guest
  steps:
  - goal: Open the article on "Bob Dylan"
    hint: Use the search function to find it
    finalScreenAssertion: >-
      The article is opened and the title "Bob Dylan" is visible.
  - goal: Find Bob Dylan's birthday in the article
    hint: >-
      Look for the "Born" section in the infobox on the right side of the page.
    finalScreenAssertion: >-
      The text "May 24, 1941" is visible on the screen.

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

שימוש במסוף App Distribution

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

  1. בכרטיסייה Test Cases (תרחישי בדיקה), לוחצים על New test case (תרחיש בדיקה חדש). אם אתם לא רוצים ליצור תרחיש בדיקה משלכם, אתם יכולים לשנות את תרחיש הבדיקה לדוגמה שסיפקנו או להשתמש בו.
  2. בתיבת הדו-שיח הוספת תרחיש בדיקה, נותנים שם לתרחיש הבדיקה. הערך הזה משמש לזיהוי הבדיקה, אבל הסוכן מתעלם ממנו.
  3. (אופציונלי) בוחרים תרחיש בדיקה של דרישות מוקדמות שמכיל שלבי הגדרה להרצה לפני הבדיקה הראשית. אם בדיקת הדרישות המוקדמות נכשלת, כל הבדיקה מסומנת ככישלון. השלבים והתוצאות של הבדיקות המקדימות והבדיקות העיקריות יוצגו יחד בתוצאות הבדיקה.
  4. אפשר לפצל את הבדיקה לכמה שלבים באמצעות הלחצן Add another step (הוספת שלב נוסף).
  5. נותנים לכל שלב יעד שמתאר מה סוכן App Testing צריך לעשות במהלך השלב הזה.
  6. (אופציונלי) מוסיפים הערה כדי לספק מידע נוסף שיעזור לסוכן לבדיקת האפליקציה להבין את האפליקציה ולנווט בה במהלך השלב הזה.
  7. מוסיפים Final screen assertion כדי לעזור לסוכן App Testing לקבוע מתי השלב הושלם בהצלחה. הטענה הזו צריכה להתייחס רק למה שמוצג במסך.
  8. בסיום ההתאמה האישית של הבדיקה, לוחצים על שמירה.

מקרה בדיקה לדוגמה

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

כותרת הבדיקה

טעינות דף הבית
מטרה

טעינת דף הבית
רמז

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

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

הרצת בדיקה

אופן ההרצה של הבדיקות תלוי באופן שבו יוצרים ומנהלים את תרחישי הבדיקה. אם מגדירים תרחישי בדיקה באמצעות קובצי YAML, מריצים את הבדיקות האלה באמצעות Firebase CLI. אם יוצרים את תרחישי הבדיקה במסוף הפצת אפליקציות, מריצים אותם מהמסוף או באמצעות אחד מכלי ה-CLI של הפצת אפליקציות.

שימוש בקובצי YAML

אפשר להריץ תרחישי בדיקה שמוגדרים בקובצי YAML באמצעות Firebase CLI.

  1. מתקינים או מעדכנים את הגרסה האחרונה של Firebase CLI. מומלץ להוריד את הקובץ הבינארי העצמאי של ה-CLI שמתאים למערכת ההפעלה שלכם.
  2. נכנסים לחשבון ובודקים שאפשר לגשת לפרויקטים. שימו לב: אם אתם משתמשים ב-Firebase CLI בסביבת CI, אתם יכולים גם לבצע אימות באמצעות חשבון שירות או באמצעות login:ci.

  3. מריצים את הפקודה apptesting:execute. לדוגמה:

    firebase apptesting:execute \
  --app=1:1234567890:android:0a1b2c3d4e5f67890 \
  --test-dir=./mytests \
  ./app/build/outputs/apk/debug/app-debug.apk
apptesting:execute [options] [/path/to/app/binary]
--app

חובה: מזהה האפליקציה ב-Firebase. אפשר למצוא את מזהה האפליקציה במסוף Firebase, בדף הגדרות כלליות.

--app 1:1234567890:android:0a1b2c3d4e5f67890
--test-dir

הנתיב לספרייה שמכילה קובצי YAML של תרחישי בדיקה. הפקודה תחפש באופן רקורסיבי בספרייה הזו, כך שאפשר לארגן את הקבצים בתיקיות משנה. אם לא מגדירים את המדיניות, המערכת תשתמש בערך './tests' כברירת מחדל.
--test-devices או
--test-devices-file

המכשירים שבהם יופעלו הבדיקות.

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

--test-devices "model=tokay,version=36,locale=en,orientation=portrait;model=b0q,version=33,locale=en,orientation=portrait"

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

--test-devices-file "/path/to/test-devices.txt"

אפשר לחפש את הדגמים הזמינים של המכשירים באמצעות CLI של gcloud.
--test-username

שם המשתמש לכניסה אוטומטית שבו ישתמשו במהלך הבדיקות.
--test-password או
--test-password-file

הסיסמה להתחברות אוטומטית שתשמש במהלך הבדיקות.

אפשר גם לציין את הנתיב לקובץ טקסט פשוט שמכיל סיסמה:

--test-password-file: "/path/to/test-password.txt"
--test-non-blocking

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

קטגוריה מותאמת אישית של Google Cloud Storage ‏ (GCS) שבה נשמרות תוצאות הבדיקה. אם לא מציינים קטגוריה, המערכת משתמשת בקטגוריית ברירת המחדל. הקטגוריה חייבת להיות בבעלות פרויקט שמופעל בו חיוב, וציון קטגוריה גורם לחיוב על נפח האחסון שנעשה בו שימוש.
--test-file-pattern

דפוס של ביטוי רגולרי. רק בדיקות שנמצאות בקבצים שתואמים לתבנית הזו יופעלו.
--test-name-pattern

תבנית של ביטוי רגולרי. רק בדיקות עם שמות מוצגים שתואמים לתבנית הזו יבוצעו.
/path/to/app/binary

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

שימוש במסוף App Distribution

כדי להריץ תרחישי בדיקה שמאוחסנים בהפצת אפליקציות, אפשר להשתמש במסוף Firebase, ב-Firebase CLI או בתוספים של Gradle או fastlane של App Distribution.

ייבוא וייצוא של תרחישי בדיקה באמצעות קובצי YAML

ייבוא של תרחישי בדיקה מקובצי YAML שימושי כשרוצים לנהל תרחישי בדיקה מחוץ למסוף Firebase. ייצוא של תרחישי בדיקה יכול להיות שימושי גם להעברה שלהם בין פרויקטים. אתם יכולים להשתמש ב-LLM כדי לשפר תרחישי בדיקה קיימים או ליצור תרחישי בדיקה חדשים. אתם יכולים לייבא ולייצא תרחישי בדיקה מהדף Test Cases (תרחישי בדיקה) במסוף Firebase או באופן פרוגרמטי באמצעות Firebase CLI. דוגמה למקרה בדיקה ב-YAML מופיעה במאמר יצירת מקרה בדיקה ב-YAML.

צפייה בתוצאות הבדיקה

אפשר לראות את תוצאות הבדיקות בדף גרסאות בכרטיסייה סוכן App Testing של גרסה. הכפתור הצגת פרטים יפתח את תיבת הדו-שיח 'תוצאות הבדיקה' ויציג את הבעיות, צילומי המסך של האפליקציה והפעולות ש-Gemini ביצע במהלך הבדיקה.

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

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

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

ניפוי באגים בתוצאות הבדיקה

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

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

בעיות ידועות ומגבלות

לגרסת טרום-השקה (Preview) של סוכן App Testing יש כמה מגבלות ידועות:

  • הזמן הקצוב לתפוגה של בדיקות מבוססות-AI הוא 5 דקות. אחרי שהבדיקה מתחילה, היא צריכה להצליח בפרק הזמן הזה, אחרת היא תסתיים מוקדם ותיחשב כבדיקה שנכשלה.
  • מכיוון שסוכן App Testing משתמש ב-AI גנרטיבי כדי לבדוק את האפליקציה, לפעמים הוא יבצע פעולות שונות למרות שהוא פועל לפי אותן הוראות.
  • הסוכן של App Testing תומך רק בפעולות הבאות: הקשה, הזנת טקסט, החלקה למעלה/למטה/ימינה/שמאלה, לחיצה ארוכה, גרירה ושחרור, חזרה והמתנה.
  • לסוכן App Testing יש בעיה בהרצת בדיקות שמכילות רק שלב אחד שנדרשות בו פעולות רבות כדי להשלים אותו. הוא מתפקד טוב יותר כשמשימות מורכבות מחולקות לכמה שלבים קצרים יותר.
  • לפעמים, סוכן בדיקת האפליקציות לא גולל כדי לחשוף רכיבים אחרים שלא מוצגים במסך. זה קורה יותר כשאין אינדיקציה ויזואלית לכך שאפשר לגלול. כפתרון עקיף, אפשר להשתמש בשדה 'רמזים' כדי להציע גלילה.
  • לפעמים לסוכן App Testing יש בעיה בספירה, למשל בביצוע פעולה מספר מסוים של פעמים.
  • אם האפשרות FLAG_SECURE מופעלת, סוכן App Testing לא יכול לנווט באפליקציה. במקום צילומי מסך של האפליקציה, הוא יראה רק מסך ריק.

בדיקת מכסות

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

חשוב לזכור שאם בוחרים להריץ כמה תרחישי בדיקה, או להריץ את אותו תרחיש בדיקה בכמה מכשירים, זה נחשב לכמה בדיקות. לדוגמה, אם מריצים 2 תרחישי בדיקה ב-2 מכשירים, זה נחשב ל-4 בדיקות בסך הכול.

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