הגדרת בדיקות ACTS

בדף הזה מוסבר איך להגדיר בדיקות ACTS.

מקורות ההגדרה

ב-Android Comms Test Suite (ACTS) יש שלושה מקורות הגדרה עיקריים:

  • ממשק שורת הפקודה (CLI)
  • קובץ התצורה ACTS
  • משתני סביבה

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

הערה לגבי משתני סביבה

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

משתני ההגדרה הנדרשים

כל בדיקת ACTS מחייבת הגדרה של המשתנים הבאים.

נתיבי בדיקות של ACTS

הרצת ACTS מתבצעת ממיקום כניסה ראשי אחד. כתוצאה מכך, המיקום של נתיב הבדיקה לא ידוע להרצה.

מגדירים את המיקום של הנתיב לבדיקה באמצעות משתנה הסביבה ACTS_TESTPATH או באמצעות הדגל -tp/--testpaths בשורת הפקודה. הערך יכול להיות רשימה של ספריות.

כיתות בדיקה של ACTS

ACTS צריכים לדעת אילו כיתות בדיקה צריך להריץ. זה יכול להיות ביטוי רגולרי (regex) או רשימה של שמות של כיתות מבחן.

כדי להגדיר את הערך הזה, משתמשים בדגל -tc/--test_class בשורת הפקודה. שימו לב שהדגל הזה מקבל גם רשימה של שמות הכיתות. שמות המחלקות צריכים להיות זהים לשמות הקבצים התואמים שלהם. לדוגמה, SampleTest צריך להיות ב-SampleTest.py.

נתיב היומן ACTS

ל-ACTS חייב להיות מיקום כדי לכתוב יומנים שאינם STDOUT. ACTS כותב יומני ניפוי באגים מלאים שמכילים נתונים שיכולים לעזור לקבוע למה חלק מהבדיקות נכשלות. כדי למנוע בלגן, ACTS לא כותב את היומנים האלה ל-STDOUT.

כדי להגדיר את הנתיב ליומן, משתמשים במשתנה הסביבה ACTS_LOGPATH או בדגל -lp/--logpath בשורת הפקודה.

נתיב ההגדרה של ACTS

כדי להריץ את הבדיקה, ACTS צריך לדעת איזו בדיקה קיימת. ההגדרה של ACTS מכילה את כל המכשירים בקבוצת הבדיקה, וכן פרמטרים מיוחדים של בדיקה או סביבה שייתכן שיהיה צורך בהם. מגדירים את הערך הזה בשורת הפקודה באמצעות -c/--config.

אם יש כמה בדיקות בדיקה בהגדרה, ACTS יריץ את הבדיקות לכל בדיקת בדיקה. כדי להריץ רק בדיקה של קבוצת בדיקה אחת ברשימה, צריך להשתמש בארגומנט של שורת הפקודה -tb/--testbed <NAME>.

דוגמה לתחנת עבודה מקומית

רוב המשתמשים ב-ACTS מפתחים בהסתעפות אחת של מאגר Android, ויש להם הגדרה דומה לזו:

# in ~/.bashrc
ACTS_LOGPATH='/tmp/acts_logpath'
ACTS_TESTPATH='~/android/<REPO_BRANCH>/tools/test/connectivity/acts_tests/'

# On cmdline
$ act.py -c ~/acts_configs/local_config.json -tc SampleTest -tb marlin

אם משתמשי ACTS מריצים כמה הסתעפויות, לרוב הם מריצים ACTS מהספרייה acts/framework ומשתמשים בנתיב יחסי בשביל ACTS_TESTPATH:

# in ~/.bashrc
ACTS_LOGPATH='/tmp/acts_logpath'
ACTS_TESTPATH='../acts_tests/'

# On cmdline
$ cd ~/android/main/tools/test/connectivity/acts_tests/acts_contrib/
$ act.py -c ~/acts_configs/local_config.json -tc SampleTest -tb marlin

הגדרת בדיקות הבדיקה

קובץ התצורה ACTS מספק את כל המידע הנדרש להרצת בדיקות על מכשירי חומרה:

{
  "testbed": {
    "my_testbed": {
      "my_testbed_value": "value"
    },
    "another_testbed": {
      "AndroidDevice": [
        "53R147"
      ]
    }
  },
  "user_parameter_1": "special environment value",
  "user_parameter_2": "other special value"
}

היחידה הבסיסית של ההגדרה הזו היא 'הבדיקה'. בתצורה לדוגמה שלמעלה, מיטת הבדיקה my_testbed נוצרת עם ערך יחיד של ארגז בדיקה. לקבוצת הבדיקה השנייה, another_testbed, יש הגדרה מיוחדת של בקר שכולל את המידע על הרשימה של מכשירי Android. המכשירים האלה מאוחסנים ברשימת מכשירים מתחת ל-self.android_devices. שימו לב שאם ב-Testbed לא צוין אובייקט AndroidDevice, מחלקה בדיקה שמצפה לאובייקט AndroidDevice מעלה חריגות. לרשימה המלאה של הגדרות הבקרה הנתמכות שכלולות ב-ACTS, ראו את הרשימה /acts/framework/acts/controllers/.

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

מקרים מיוחדים ל-AndroidDevice

לצורך נוחות הפיתוח, כשרוצים להגדיר כמה מכשירים עם מאפיינים שונים, AndroidDevice כולל מקרים מיוחדים.

פורמט של תצורת JSON

כל צמדי המפתח/ערך בדוגמה הבאה ל-JSON מוגדרים לאובייקט AndroidDevice המתאים. אם ההגדרה מנסה להחליף פרמטר שהוגדר במאפיין AndroidDevice, המערכת תחליף את ControllerError.

  "AndroidDevice": [{"serial": "XXXXXX", "label": "publisher"},
                    {"serial": "YYYYYY", "label": "subscriber", "user_parameter_1": "anything"}]

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

  def setup_class(self):
      self.pub = next(filter(lambda ad: ad.label == 'publisher',
                             self.android_devices))
      self.sub = next(filter(lambda ad: ad.label == 'user_parameter_1',
                             self.android_devices))

פרמטר אופציונלי

הפרמטר הבא הוא אופציונלי:

  • adb_logcat_param: מחרוזת שמצורפת לפקודה adb logcat לאיסוף יומני adb. כברירת מחדל, נעשה שימוש ב-adb logcat -v threadtime -b all. אם המדיניות adb_logcat_param מוגדרת, הקטע -b all יוחלף. לדוגמה, אם תגדירו את adb_logcat_param ל--b radio, הפקודה תשתנה ל-adb logcat -v threadtime -b radio.