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

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

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

   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()
       }
   }
   // ...

2. בקובץ 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")
     // ...

3. בקובץ 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>
   ...
   

4. בקובץ AndroidManifest.xml של האפליקציה, מוסיפים את השורות הבאות בתוך הרכיב <manifest>:

    <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>
   

5. בקובץ AndroidManifest.xml, מציינים את הרשאות המערכת של האפליקציה על ידי הוספת השורות הבאות בתוך התג <manifest>. אם אתם בודקים את האפליקציה ב-Android 10 (רמת API 29) ואילך, צריך להשמיט את ההרשאה WRITE_EXTERNAL_STORAGE (האפליקציה לא זקוקה להרשאה הזו כדי לקרוא ולכתוב צילומי מסך במכשיר).

   <manifest ... >
       <!-- WRITE_EXTERNAL_STORAGE is not needed on Android 10 (API level 29) or higher. -->
       <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:

• מבצעים צילום מסך מלא ב-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. פיתוח והרצה של הבדיקה

1. מפתחים את האפליקציה ובודקים את חבילות ה-APK (הוראות מפורטות זמינות במאמר בדיקת האפליקציה).

2. מעלים את קובצי ה-APK למרכז הבקרה של Test Lab במסוף Firebase.

3. לבסוף, מריצים את הבדיקה.

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

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

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

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

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

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

הפעלת Orchestrator

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

כדי להפעיל תזמור עבור Test Lab, בהגדרה של בדיקת אינסטרומנטציה,לוחצים על Additional options > Run with תזמור.

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

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

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

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

--environment-variables clearPackageData=true

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

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

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

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

1. בהגדרת הבדיקה של הכלי,לוחצים על אפשרויות נוספות.

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

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

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

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