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

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

במדריך הזה מוסבר איך להכין ולהריץ בדיקת מכשור באמצעות 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 שלהם נמוכה מ-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. איך יוצרים ומריצים את הבדיקה

מבצעים build לאפליקציה ובודקים את קובצי ה-APK (הוראות מופיעות במאמר בדיקת האפליקציה).
מעלים את קובצי ה-APK לTest Labלוח הבקרה של Firebase Console.
לסיום, מריצים את הבדיקה.

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

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

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

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

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

הפעלת Orchestrator

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

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

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

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

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

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

--environment-variables clearPackageData=true

הפעלת שרדינג

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

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

כדי להפעיל את התכונה 'חלוקת בדיקות' במסוף Firebase:

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

חיוב על חלקי בדיקה

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

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