במסמך הזה מתוארים אירועי AVD ב-Test Lab, כולל יתרונות ומגבלות ידועות. אנחנו גם מספקים המלצות לבדיקה של האפליקציה לאורך מחזור החיים של הפיתוח. מכונות וירטואליות של Test Lab דומות למכונות הווירטואליות של Android Studio, אבל הן מותאמות לביצועים באמצעות בדיקות בענן, ולכן יש כמה הבדלים ביניהן.
Test Lab קובצי AVD עם הסיומת .arm או (Arm) הם אמולטורים מתקדמים שמספקים את היתרונות הבאים:
זמן ביצוע מהיר יותר של הבדיקות
גודל המסך ודחיסות המסך תואמים ל-AVDs של Android Studio לצורך עקביות
גרפיקה מואצת שנתמכת ב-GPU
בטבלה הבאה מתוארים יתרונות השימוש במכשירים וירטואליים:
| ההטבה | תיאור | תרחישים לדוגמה |
| זמינות גבוהה | כשבודקים באמצעות מכשירי וירטואליים, אפשר להריץ בדיקות ולקבל את תוצאות הבדיקה מהר יותר. מאחר שמכשירים וירטואליים נוצרים על פי דרישה, הבדיקות מתחילות כמעט מיד, ומאפשרות אימות מהיר של האפליקציה. | בדיקת עדכונים קטנים באפליקציה או בדיקת רגרסיה. |
| משכי בדיקה ארוכים יותר | במכשירים וירטואליים אפשר לבצע בדיקות של עד 60 דקות. הבדיקות במכשירים פיזיים מוגבלות למשך 45 דקות בכל מכשיר. | הרצת בדיקות ארוכות יותר |
| עלויות נמוכות יותר | המחיר של מכשירי וירטואליים הוא 1$ לשעה לכל מכשיר וירטואלי שמשמש לבדיקה של האפליקציה. | בדיקה יומית באמצעות מערכות אינטגרציה רציפה (CI), או לפני שמטמיעים את הקוד. מידע נוסף זמין במאמר רמות שימוש, מכסות ותמחור ב-Test Lab. |
בדיקת האפליקציה במכשירים וירטואליים
אפשר לבדוק את האפליקציה במכשירים וירטואליים באותו אופן שבו בודקים אותה במכשירים פיזיים. כשמגדירים מטריצה של בדיקות, אפשר לבחור מכשירי וירטואליים לבדיקות. למידע נוסף על הרצת בדיקות באמצעות Test Lab, ראו איך מתחילים לבצע בדיקות ל-Android באמצעות Firebase Test Lab.
הצגת הדגמים וממשקי ה-API הנתמכים
כדי להציג מודלים של AVD וממשקי API שנתמכים על ידי Test Lab, מריצים את הפקודה הבאה:
gcloud firebase test android models list --filter=virtual
שיטות מומלצות לבדיקה של האפליקציה
מכשירי וירטואליים מגדילים את מגוון האפשרויות כשבודקים את האפליקציה באמצעות Test Lab. מומלץ להשתמש בשיטות המומלצות הבאות כדי לבדוק את האפליקציה לאורך מחזור החיים של פיתוח האפליקציה:
שימוש באמולטור Android Studio או במכשיר פיזי מחובר
כשאתם מפתחים את האפליקציה, אתם יכולים להשתמש במהדמ של Android Studio או במכשיר פיזי מחובר כדי לבדוק כל גרסה זמנית לאימות ראשוני. אם יש לכם בדיקות של מכשירי מדידה, תוכלו להריץ את הבדיקות האלה גם מ-Android Studio במכשירים פיזיים או וירטואליים שסופקו על ידי Test Lab.
שימוש במערכות CI בכל שינוי קוד כשעובדים בפרויקטים משותפים
אם אתם עובדים על פרויקט גדול או תורמים לפרויקטים שמשותפים באמצעות GitHub או אתר דומה, מומלץ להשתמש במערכות של שילוב רצוף (CI). כדאי לבדוק את האפליקציות במכשירים וירטואליים בכל פעם שמערכת ה-CI פועלת, או לפני כל בקשת משיכה. מידע נוסף על השימוש ב-Test Lab עם מערכות CI זמין במאמר שימוש ב-Test Lab ל-Android עם מערכות אינטגרציה רציפה.
בדיקת האפליקציה במכשירים פיזיים באמצעות Test Lab לפני פרסום עדכונים משמעותיים לאפליקציה
לפני שמפרסמים עדכוני אפליקציות עם שינויים משמעותיים בממשק המשתמש ובפונקציונליות, מומלץ להשתמש ב-Test Lab כדי לבדוק את האפליקציה במכשירים פיזיים. כך תוכלו לוודא שהאפליקציה יציבה ומבצעת את הפעולות בצורה טובה במגוון רחב של מכשירים פיזיים פופולריים. בדיקה במכשירים פיזיים מבטיחה גם כי כל פונקציונליות של האפליקציה שמבוססת על תכונות של מכשיר פיזי שלא ניתן לדמות במכשירים וירטואליים תהיה מכוסה בבדיקות. מידע נוסף על התכונות האלה זמין במאמר מגבלות ידועות.
עדכונים של מכשיר וירטואלי
מדי פעם, צוות Android מוסיף תמונות חדשות של מכשירים וירטואליים, מוציא משימוש תמונות ישנות ומעדכן תמונות קיימות. אנחנו מחילים את העדכונים האלה על התמונות במכשירים הווירטואליים שלנו כדי לוודא שאתם בודקים גרסאות Android עדכניות שמשקפות את חוויית המשתמשים.
במקרים נדירים, העדכונים האלה עלולים לגרום לכישלון בלתי צפוי של בדיקות. אם יש עדכון ידוע שעלול לגרום לשיבושים, Test Lab יכלול מידע בהערות למהדורה. מומלץ להשתמש במסגרות בדיקה (למשל, Espresso) עמידות בשינויים האלה ככל האפשר. אם זה לא אפשרי, מומלץ לטרגט מכשירי וירטואליים של Arm, שאפשר לצפות לעדכן בתדירות נמוכה יותר.
מגבלות ידועות
חלק מהתכונות של מכשירים פיזיים לא מדמות כרגע במכשירים וירטואליים, או שהן מדמות עם מגבלות מסוימות. בטבלה הבאה מפורטות התכונות שאינן זמינות כרגע במכשירים וירטואליים, או שזמינות עם מגבלות מסוימות:
| Feature | לפרטים |
| Application Binary Interfaces (ABI) | לא כל המכשירים תומכים בכל ממשקי ה-ABI. אם אתם מפתחים באמצעות Android NDK, הקפידו ליצור קוד לממשקי ה-ABI הנתמכים במכשירים שאתם מטרגטים (ראו מכשירים זמינים בקטע Test Lab). למידע נוסף על ניהול ממשקי ABI, ראו ממשקי ABI של Android.
הערה: אם בדיקה במטריצה של הבדיקות מסומנת בתווית 'לא תקינה', יכול להיות שהסיבה לכך היא שהאפליקציה שלכם תלויה בקוד מקומי שאינו נתמך על ידי ABI של המכשיר. |
| ביצועי הגרפיקה | במכשירים הווירטואליים של Nexus ו-Pixel נעשה שימוש בתוכנה לעיבוד גרפיקה. אפליקציות עתירות גרפיקה עלולות להניב ביצועים נמוכים יותר. אם האפליקציה שלכם כוללת הרבה גרפיקה, מומלץ להשתמש ב-SmallPhone.arm, ב-MediumPhone.arm או במכשירים פיזיים במקום זאת. |
| ממשקי API לגרפיקה | אין תמיכה ב-OpenGL ES 3.x במכשירים ברמה API 29 ומטה. מכשירים חדשים יותר לא תואמים ב-100% לממשקי ה-API של OpenGL/Vulkan, ויכול להיות שתבחינו בהבדלים קלים בגרפיקה. |
| אפליקציית חנות Google Play | אי אפשר להשתמש באפליקציית חנות Google Play במכשירים וירטואליים עם מעבד Arm. |
| פונקציונליות של מציאות רבודה (AR) | אי אפשר לבדוק את הפונקציונליות של המציאות הרבודה (AR) במכשירים וירטואליים. |
| רמות API ישנות יותר | Test Lab במכשירים וירטואליים של ARM אין תמיכה ברמות API נמוכות מ-26. |