בדיקות בפלטפורמת Android

פרויקט הקוד הפתוח של Android‏ (AOSP) מספק כמה כלים וחבילות בדיקה לבדיקת חלקים שונים בהטמעה. לפני שמשתמשים בדפים שבקטע הזה, חשוב להכיר את המונחים הבאים:

מכשיר שתואם ל-Android
מכשיר שיכול להריץ כל אפליקציה של צד שלישי שנכתבה על ידי מפתחים של צד שלישי באמצעות Android SDK ו-NDK. מכשירים שתואמים ל-Android צריכים לעמוד בדרישות של מסמך הגדרת התאימות (CDD) ולעבור את חבילת הבדיקות לתאימות (CTS). מכשירים שתואמים ל-Android עומדים בדרישות להשתתפות במערכת האקולוגית של Android, שכוללת רישוי פוטנציאלי של Google Play, רישוי פוטנציאלי של חבילת האפליקציות וממשקי ה-API של Google Mobile Services (GMS) ושימוש בסימן המסחרי של Android. כל אחד יכול להשתמש בקוד המקור של Android, אבל כדי שמכשיר ייחשב כחלק מהסביבה העסקית של Android, הוא צריך להיות תואם ל-Android.
artifact
יומן שקשור לבנייה ומאפשר פתרון בעיות מקומי.
מסמך הגדרת תאימות (CDD)
מסמך שמפרט את דרישות התוכנה והחומרה למכשיר שתואם ל-Android.
חבילת בדיקות התאימות (CTS)

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

בדיקות CTS ובדיקות פלטפורמה לא סותרות זו את זו. הנה כמה הנחיות כלליות:

  • אם בדיקה מאמתת את התקינות של פונקציות או התנהגויות של ממשקי API של מסגרות, והבדיקה צריכה להיות מחייבת אצל שותפי OEM, היא צריכה להיות ב-CTS.
  • אם מטרת הבדיקה היא לזהות רגרסיות במהלך פיתוח הפלטפורמה, והיא עשויה לדרוש הרשאה מיוחדת לביצוע, והיא עשויה להיות תלויה בפרטי ההטמעה (כפי שפורסמו ב-AOSP), היא צריכה להיות בדיקת פלטפורמה.
Google Mobile Services (GMS)

אוסף של אפליקציות וממשקי API של Google שאפשר להתקין מראש במכשירים.

GoogleTest (GTest)

מסגרת לבדיקות ולדמויות פיקטיביות ב-C++‎. בדרך כלל, קובצי GTest בינאריים ניגשים לשכבות הפשטה ברמה נמוכה יותר או מבצעים IPC גולמי מול שירותי מערכת שונים. גישת הבדיקה ב-GTest בדרך כלל קשורה באופן הדוק לשירות שנבדק. ‫CTS מכיל את מסגרת GTest.

בדיקת אינסטרומנטציה

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

Logcat

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

logging

שימוש ביומן כדי לעקוב אחרי אירועים במערכת המחשב, כמו שגיאות. רישום ביומן ב-Android הוא תהליך מורכב בגלל השילוב של סטנדרטים שונים שמשמשים את הכלי Logcat.

בדיקה אחרי שליחה

בדיקת Android שמתבצעת כשמבצעים קומיט לתיקון חדש בענף ליבת משותף. אם מזינים aosp_kernel כשם חלקי של ענף, אפשר לראות רשימה של ענפי ליבה עם תוצאות זמינות. לדוגמה, תוצאות של android-mainline אפשר למצוא בכתובת https://ci.android.com/builds/branches/aosp_kernel-common-android-mainline/grid.

בדיקה לפני שליחה

בדיקה שמשמשת למניעת כשלים בקרנלים הנפוצים.

Trade Federation

נקרא גם Tradefed, מסגרת בדיקה רציפה שנועדה להריץ בדיקות במכשירי Android. לדוגמה, Tradefed משמש להפעלת בדיקות של חבילת הבדיקות לתאימות (CTS) וחבילת הבדיקות לספקים (VTS).

חבילת בדיקות לספקים (VTS)

מערך נרחב של יכולות לבדיקות ב-Android, לקידום תהליך פיתוח מבוסס-בדיקות ולאוטומציה של בדיקות בשכבת הפשטת החומרה (HAL) ובליבת מערכת ההפעלה.

סוגי בדיקות בפלטפורמה

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

  • ‫(Type 1) ממשקי API של framework לתרגילים באמצעות Android framework. ממשקי API ספציפיים שנעשה בהם שימוש יכולים לכלול:
    • ממשקי API ציבוריים שמיועדים לאפליקציות של צד שלישי
    • ממשקי API מוסתרים שמיועדים לאפליקציות עם הרשאות, כלומר ממשקי API של המערכת או ממשקי API פרטיים (@hide או protected או package private)
  • (סוג 2) הפעלה של שירותי מערכת Android באמצעות binder גולמי או שרתי proxy של IPC באופן ישיר.
  • ‫(Type 3) אינטראקציה ישירה עם HAL באמצעות ממשקי API ברמה נמוכה או ממשקי IPC.

בדרך כלל, בדיקות מסוג 1 ו-2 הן בדיקות מכשור, ובדיקות מסוג 3 הן בדרך כלל GTests.

מה השלב הבא?

למידע מפורט יותר, אפשר לקרוא את המסמכים הבאים: