在 2024 年演示日活动中，观看有关如何使用 Firebase 构建和运行 AI 赋能应用的演示。立即观看。

דף זה תורגם על ידי Cloud Translation API.

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

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

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

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

Firebase Test Lab כולל ספרייה (testlab-instr-lib) שאפשר להשתמש בה כדי לעבד צילומי מסך שצילמתם באמצעות ScreenCapture של AndroidX כשאתם מריצים בדיקות של מכשירי מדידה, כמו בדיקות שנכתבו באמצעות מסגרת הבדיקה של Espresso. בקטע הזה מוסבר איך ליצור אובייקטים מסוג 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. צילום מסך במהלך הבחינה

בכל שלב בבדיקה שבו רוצים לצלם מסך, קוראים ל-method‏ 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 (הוראות מפורטות זמינות במאמר בדיקת האפליקציה).
מעלים את קובצי ה-APK למרכז הבקרה של Test Lab במסוף Firebase.
לבסוף, מריצים את הבדיקה.

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

בסיום הבדיקה, תוכלו לראות את צילומי המסך שצילמתם במסוף Firebase.

בכרטיסייה Tests בוחרים את הבדיקה שהושלמו ולוחצים על הכרטיסייה Results.
בוחרים שוב את הבדיקה ולוחצים על הכרטיסייה צילומי מסך שמופיעה.

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

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

הפעלת Orchestrator

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

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

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

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

חשוב לזכור שכאשר משתמשים ב-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 בדיקות מקרה לכל שריד.

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