Firebase Test Lab Deprecation

Firebase Test Lab is deprecated and will be fully shut down on September 30, 2027. To maintain your testing workflows, you can migrate to the Developer Device Platform on Google Cloud. See the Developer Device Platform Migration Guide and FAQ for more details.

‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

תחילת העבודה עם בדיקות אינסטרומנטציה

במדריך הזה מוסבר איך להכין ולהריץ בדיקת אינסטרומנטציה באמצעות Firebase Test Lab. כדי להשתמש במדריך הזה, תצטרכו בדיקת אינסטרומנטציה (שאתם או הצוות שלכם כתבתם) שמשתמשת במסגרות הבדיקה Espresso או UI Automator ל-Android. בדיקות אינסטרומנטציה יכולות להימשך עד 45 דקות במכשירים פיזיים ועד 60 דקות במכשירים וירטואליים.

בשלבים הבאים תעלו את קובץ ה-APK של האפליקציה ואת קובץ ה-APK של הבדיקה ל-Firebase.

(אופציונלי) הוספת ספריית צילומי המסך לאפליקציה

‫Firebase Test Lab כולל ספרייה (testlab-instr-lib) שבה אפשר להשתמש כדי לעבד צילומי מסך שצולמו באמצעות ScreenCapture של AndroidX, כשמריצים בדיקות אינסטרומנטציה, כמו בדיקות שנכתבו באמצעות Espresso test framework. בקטע הזה מוסבר איך ליצור אובייקטים של ScreenCapture באמצעות ספריית AndroidX ואיך לעבד אותם באמצעות testlab-instr-lib.

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

התנסות באפליקציה לדוגמה

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

שלב 1. הוספת ספריית צילומי המסך לפרויקט

בקובץ Gradle של ההגדרות ברמת הבסיס של פרויקט הבדיקה (settings.gradle.kts או settings.gradle), מוסיפים את מאגר ה-Maven של Google לכל קטע של repositories:

pluginManagement {
    repositories {
        // Add the following line:
        google() // Google's Maven repository
        mavenCentral()
        gradlePluginPortal()
    }
}
dependencyResolutionManagement {
    repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
    repositories {
        // Add the following line:
        google() // Google's Maven repository
        mavenCentral()
    }
}
// ...

בקובץ Gradle של המודול (ברמת האפליקציה) (בדרך כלל <project>/<app-module>/build.gradle.kts או <project>/<app-module>/build.gradle), מוסיפים תלות בספריית צילומי המסך של Test Lab.
```
dependencies {
  // ...
  // Add Test Lab's instrumentation test screenshot library:
  androidTestImplementation("com.google.firebase:testlab-instr-lib:0.2")
  // ...
```

בקובץ AndroidManifest.xml של הבדיקה, רושמים את FirebaseScreenCaptureProcessor בתג מטא-נתונים בתוך הרכיב <instrumentation>. אפשר גם לציין את המעבד כארגומנט ב-AndroidJUnitRunner (הוראות מפורטות זמינות במאמרי העזרה של AndroidJUnitRunner).

<instrumentation
  // Check that you have the following line (if not, add it):
  android:name="androidx.test.runner.AndroidJUnitRunner" // Specifies AndroidJUnitRunner as the test runner
  android:targetPackage="com.your.package.name">

// Add the following:
<meta-data
  android:name="screenCaptureProcessors"
  android:value="com.google.firebase.testlab.screenshot.FirebaseScreenCaptureProcessor" />
</instrumentation>
...

בקובץ AndroidManifest.xml של האפליקציה, מוסיפים את השורות הבאות בתוך הרכיב <manifest>:
```
 <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>
```
בקובץ AndroidManifest.xml, מציינים את הרשאות המערכת של האפליקציה על ידי הוספת השורות הבאות בתוך התג <manifest>. אם אתם בודקים ב-Android בגרסה 10 (רמת API‏ 29) ומעלה, השמיטו את ההרשאה WRITE_EXTERNAL_STORAGE (האפליקציה לא צריכה את ההרשאה הזו כדי לקרוא ולכתוב צילומי מסך במכשיר).
```
<manifest ... >
    
    <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>
    <uses-permission android:name="android.permission.INTERNET"/>
    ...
</manifest>
```

שלב 2. צילום מסך במהלך הבדיקה

בכל שלב בבדיקה שבו רוצים לצלם את המסך, מפעילים את השיטה Screenshot.capture() מספריית AndroidX. כך נוצר אובייקט ScreenCapture. כשמפעילים את process() באובייקט ScreenCapture, הוא מעובד באמצעות ScreenCaptureProcessor שרשום ב-AndroidManifest.xml. שימו לב: אם לא רשומים מעבדים, המערכת משתמשת ב-BasicScreenCaptureProcessor. מאחר שנרשמת ל-FirebaseScreenCaptureProcessor, צילומי המסך שלך יעובדו באמצעות FirebaseScreenCaptureProcessor ויהיו זמינים לך עם התוצאות כשתריץ את הבדיקה באמצעות Firebase Test Lab.

תרחישים לדוגמה ליצירת `ScreenCapture`:

כדי לצלם את המסך המלא ב-API Build.VERSION_CODES.JELLY_BEAN_MR2 ואילך:
```
Screenshot.capture()
```
מצלמים ScreenCapture של הפעילות בכל רמת API. שימו לב שזו האפשרות היחידה למכשירים עם גרסה ישנה יותר מ-Build.VERSION_CODES.JELLY_BEAN_MR2.
```
@Rule
  public ActivityTestRule<MainActivity> activityRule = new ActivityTestRule<>(MainActivity.class);
...
Screenshot.capture(activityRule.getActivity());
...
```

תרחישים לדוגמה לעיבוד של ScreenCapture

מבצעים ScreenCapture דרך FirebaseScreenCaptureProcessor:
```
Screenshot.capture().process();
```

עיבוד של ScreenCapture באמצעות ScreenCaptureProcessor שצוין (כך אפשר לדלג על רישום המעבד):

Set<ScreenCaptureProcessor> processors = new HashSet<>();
processors.add(new FirebaseScreenCaptureProcessor());
Screenshot.capture().process(processors);

מגדירים את השם והפורמט של ScreenCapture ומעבדים אותו באמצעות המעבד הרשום:
```
Screenshot.capture().setName("myscreenshot").setFormat(CompressFormat.JPEG).process();
```

שלב 3. יצירה והפעלה של הבדיקה

מפתחים את האפליקציה ובודקים את חבילות ה-APK (הוראות מפורטות זמינות במאמר בדיקת האפליקציה).
במסוף Firebase, נכנסים לדף DevOps & Engagement ‏ > Test Lab ומעלים את קובצי ה-APK.
לסיום, מריצים את הבדיקה.

שלב 4. צפייה בצילומי המסך של הבדיקה

אחרי שהבדיקה מסתיימת, אפשר לראות את צילומי המסך שנוצרו:

במסוף Firebase, עוברים אל DevOps & Engagement (DevOps ומעורבות) > Test Lab.
בכרטיסייה בדיקות, בוחרים את הבדיקה שהסתיימה ולוחצים על הכרטיסייה תוצאות.
בוחרים שוב את הבדיקה ולוחצים על הכרטיסייה צילומי מסך שמופיעה.

(אופציונלי) הפעלת תכונות בדיקה נוספות

אתם יכולים להפעיל את התכונות הבאות בבדיקה לפני שמריצים אותה באמצעות Test Lab:

הפעלת Orchestrator

תזמור בדיקות ל-Android הוא כלי שמריץ כל אחת מבדיקות האינסטרומנטציה של האפליקציה באופן עצמאי. ‫Test Lab תמיד משתמש בגרסה העדכנית של Orchestrator.

כדי להפעיל את Orchestrator ב-Test Lab, בהגדרת בדיקת האינסטרומנטציה,לוחצים על אפשרויות נוספות > הפעלה באמצעות Orchestrator.

כשמשתמשים ב-Orchestrator, נהנים מהיתרונות הבאים:

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

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

כדי להגדיר אפשרויות נוספות ל-Orchestrator, צריך לציין אותן בשדה environmentVariables. לדוגמה, כדי להשתמש ב-clearPackageData, משתמשים באפשרות הזו ב-gcloud:

--environment-variables clearPackageData=true

הפעלת חלוקה למקטעים (sharding)

פיצול בדיקות מחלק קבוצה של בדיקות לקבוצות משנה (פיצולים) שפועלות בנפרד ובבידוד. ‫Test Lab מריץ באופן אוטומטי כל פיצול במקביל באמצעות כמה מכשירים, ומשלים את כל קבוצת הבדיקות בפחות זמן.

לדוגמה, אם יוצרים N פיצולים, לכל מכשיר שבוחרים, Test Lab מפעיל N מכשירים זהים ומריץ קבוצת משנה של הבדיקות בכל מכשיר. כלומר, מקרי בדיקה מפוצלים יכולים להוביל לכמה הרצות של בדיקות בכל מכשיר. לעומת זאת, מקרי בדיקה ללא פיצול יוצרים ביצוע בדיקה אחד לכל מכשיר. מושגי מפתח של Test Lab.

כדי להפעיל חלוקה של בדיקות למקטעים במסוף Firebase:

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

חיוב על פיצולים לבדיקה

‫Test Lab מטמיע את הפיצולים באמצעות מנגנון הפיצול המובנה של AndroidJUnitRunner. כדי להימנע מחיוב על הפעלת מקטעים ריקים (מקטעים שלא הוקצו להם מקרי בדיקה), מספר המקטעים שאתם יוצרים צריך להיות קטן מהמספר הכולל של מקרי הבדיקה. בהתאם למשך הזמן שלוקח להריץ כל מקרה בדיקה, בדרך כלל מומלץ להקצות 2-10 מקרי בדיקה לכל שאילתה.

מידע נוסף על חיוב זמין במאמר שימוש, מכסות וחיוב.