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

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

במדריך הזה נסביר איך להכין ולבצע בדיקת מכשור באמצעות Firebase Test Lab. כדי להשתמש במדריך זה, יש צורך בבדיקת אינסטרומנטציה (שנכתבה על ידכם או על ידי הצוות שלכם) שמשתמשת ב-Espresso או ב-UI Automator מסגרות בדיקה ל-Android. בדיקות אינסטרומנטציה יכולות להימשך עד 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. צילום מסך במהלך הבחינה

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

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

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

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

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

--environment-variables clearPackageData=true

הפעלת חלוקה לפלחים

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

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

כדי להפעיל חלוקה לפלחים לצורך בדיקה במסוף Firebase:

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

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

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

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