במסמך הזה מתוארים אירועי AVD ב-Test Lab, כולל יתרונות ומגבלות ידועות. אנחנו גם מספקים המלצות לבדיקה של האפליקציה לאורך מחזור החיים של הפיתוח. מכונות וירטואליות של Test Lab דומות למכונות הווירטואליות של Android Studio, אבל הן מותאמות לביצועים באמצעות בדיקות בענן, ולכן יש כמה הבדלים ביניהן.
מכונות AVD מסוג Test Lab עם הסיומת .arm או (Arm) הן מכונות וירטואליות מתקדמות שמספקות את היתרונות הבאים:
זמן ביצוע מהיר יותר של הבדיקות
גודל המסך ודחיסות המסך תואמים ל-AVDs של Android Studio לצורך עקביות
גרפיקה מואצת שנתמכת ב-GPU
בטבלה הבאה מתוארים היתרונות של שימוש במכשירים וירטואליים:
| הטבה | תיאור | תרחישים לדוגמה |
| זמינות גבוהה | כשבודקים באמצעות מכשירי וירטואליים, אפשר להריץ בדיקות ולקבל את תוצאות הבדיקה מהר יותר. מאחר שמכשירים וירטואליים נוצרים על פי דרישה, הבדיקות מתחילות כמעט מיד, ומאפשרות אימות מהיר של האפליקציה. | בדיקת עדכונים קטנים באפליקציה או בדיקת רגרסיה. |
| משכי בדיקה ארוכים יותר | במכשירים וירטואליים אפשר לבצע בדיקות של עד 60 דקות. הבדיקות במכשירים פיזיים מוגבלות למשך 45 דקות בכל מכשיר. | הרצת בדיקות ארוכות יותר |
| עלויות נמוכות יותר | המחיר של מכשירי וירטואליים הוא 1 $לשעה לכל מכשיר וירטואלי שמשמש לבדיקה של האפליקציה. | בדיקה יומית באמצעות מערכות אינטגרציה רציפה (CI), או לפני שמטמיעים את הקוד. מידע נוסף זמין במאמר רמות שימוש, מכסות ותמחור ב-Test Lab. |
בדיקת האפליקציה במכשירים וירטואליים
אפשר לבדוק את האפליקציה במכשירים וירטואליים באותו אופן שבו בודקים אותה במכשירים פיזיים. כשמגדירים מטריצה של בדיקות, אפשר לבחור מכשירי וירטואליים לבדיקות. מידע נוסף על הפעלת בדיקות באמצעות Test Lab זמין במאמר תחילת העבודה עם בדיקות ל-Android באמצעות Firebase Test Lab.
הצגת הדגמים וממשקי ה-API הנתמכים
כדי להציג את המודלים וה-API של AVD שנתמכים על ידי 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 Interface (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. |