בדיקה במספר מכשירים

‫VTS תומך בבדיקות שדורשות אינטראקציה בין כמה מכשירי Android.

ארכיטקטורה

מערכת VTS משתמשת במסגרת TradeFed כדי לקבל מספרי סידורי של מכשירים ולהעביר אותם למודולים של בדיקות.

איור 1. המספרים הסידוריים של המכשירים מועברים ב-VTS.

דרישות המכשיר, כמו מספר המכשירים וסוגי המכשירים, מפורטות בהגדרת תוכנית הבדיקה. לדוגמה, אפשר לציין תוכנית בדיקה שנדרשים בה שני מכשירי Android עם יעדי בנייה של Sailfish.

הקצאת מכשירים

תשתית הבדיקה (בדרך כלל מתזמן הבדיקות) מקצה מכשירים זמינים שעומדים בדרישות שצוינו בהגדרות של תוכנית הבדיקה ל-VTS framework. מכשירים שהוקצו שמורים לתוכנית הבדיקה גם אם מודול הבדיקה לא משתמש בהם. אחרי כן, קובצי ה-binary של סוכן VTS נדחפים ומופעלים בכל המכשירים שהוקצו (אלא אם יש הוראה ספציפית לא להפעיל אותם). כך מוודאים שחיבורי TCP לפקודות של מעטפת ול-HAL RPC זמינים לכל המכשירים בסקריפט בדיקה.

מכינים למבחנים

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

  • מכיני יעד במכשיר יחיד (דוגמה ב-VtsDeviceInfoCollector):
    • אפשר לציין את ההגדרה הזו רק בהגדרת תוכנית הבדיקה עם רשימת המכשירים הנדרשת (בגרסאות עתידיות תהיה אפשרות להגדיר אותה ברמת המודול).
    • מקבלים רק מספר סידורי אחד של מכשיר.
    • הפעלת משימות של הכנה וניקוי במכשיר ספציפי.
  • כלי הכנה לטירגוט למספר מכשירים (דוגמה ב-VtsPythonVirtualenvPreparer):
    • אפשר לציין את ההגדרה הזו בהגדרות של תוכנית בדיקה או של מודול בדיקה
    • קבלת כל המספרים הסידוריים של המכשירים
    • מריצים משימות הכנה וניקוי לכל מכשיר או לכל המכשירים.

מודולים לבדיקה

מודולים לבדיקה מקבלים רשימה של מכשירים אחרי שהמכינים של הבדיקה מסיימים להגדיר את המארח או המכשירים. מודול בדיקה אחד של Python בצד המארח מופעל עבור כל מודול בדיקה של כמה מכשירים. אפשר לגשת למכשירי Android שהוקצו ממודולי בדיקה של Python כרשימה של אובייקטים מסוג AndroidDevice:

devices = self.android_devices
device1 = devices[0]
device1_serial = device1.serial

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

תקשורת בין מכשירים במהלך הבדיקה

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

סוג 1: בדיקות HAL בצד המארח

בדיקות HAL בצד המארח יכולות להשתמש במנהלי התקנים של VTS HAL שמועברים למכשירים כברירת מחדל:

איור 2. בדיקת HAL בצד המארח.

במקרה כזה:

  • לוגיקת הבדיקה מופעלת במארח.
  • סקריפט בדיקה בצד המארח שולח קריאות RPC למנהלי ההתקנים בכל מכשיר.
  • המארח מתאם את האינטראקציות עם המכשיר.

סוג 2: בדיקות מבוססות-נציג בצד המארח

במקום להשתמש בסוכני VTS במכשיר, בדיקה בצד המארח יכולה גם לדחוף סוכן משלה (אפליקציה או קובץ בינארי) לכל מכשיר:

איור 3. בדיקה מבוססת-סוכן בצד המארח.

במקרה כזה:

  • לוגיקת הבדיקה מופעלת במארח.
  • אפליקציית הסוכן (או קובץ בינארי) מותקנת בכל מכשיר.
  • סקריפט הבדיקה בצד המארח שולח פקודות לאפליקציות בכל מכשיר.
  • המארח מתאם את האינטראקציות עם המכשיר.

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

סוג 3: בדיקות HIDL בצד היעד

בבדיקות HIDL מרובות מכשירים בצד היעד, כל לוגיקת הבדיקה נמצאת בקבצים בינאריים של בדיקות בצד המכשיר, ולכן הבדיקות צריכות לסנכרן את המכשירים במהלך ביצוע הבדיקה:

איור 4. בדיקת HIDL מבוססת-יעד.

במקרה כזה:

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

דוגמה: תוכנית בדיקה לכמה מכשירים

בדוגמה הזו מוגדרת ההגדרה לשני מכשירים:

  • מכשיר 1 כולל ספק build ו-VtsDeviceInfoCollector target preparer.
  • מכשיר 2 כולל עוד FilePusher מכין שמעביר קבוצה של קבצים קשורים שמבוססים על המארח אל המכשיר.
<configuration description="VTS Codelab Plan">
  ...
<device name="device1">
<build_provider class="com.android.compatibility.common.tradefed.build.CompatibilityBuildProvider" />
<target_preparer class="com.android.tradefed.targetprep.VtsDeviceInfoCollector" />
</device>
<device name="device2" >
<build_provider class="com.android.compatibility.common.tradefed.build.CompatibilityBuildProvider" />
<target_preparer class="com.android.tradefed.targetprep.VtsDeviceInfoCollector" />
<target_preparer class="com.android.compatibility.common.tradefed.targetprep.VtsFilePusher">
<option name="push-group" value="HostDrivenTest.push" />
</target_preparer>
</device>
<option name="compatibility:include-filter" value="VtsCodelabHelloWorldMultiDeviceTest" />
</configuration>

דוגמה: סקריפט בדיקה של Python בצד המארח

פרטים ודוגמאות לגבי קבצים להכנת בדיקות זמינים במאמר בנושא קבצים להכנת בדיקות. דוגמה מלאה לשימוש במספר מכשירים בצד המארח מופיעה ב-codelab hello_world_multi. 

def setUpClass(self):
logging.info('number of device: %s', self.android_devices)
asserts.assertEqual(len(self.android_devices), 2, 'number of device is wrong.')
self.dut1 = self.android_devices[0]
self.dut2 = self.android_devices[1]
self.shell1 = self.dut1.shell
self.shell2 = self.dut2.shell

def testSerialNotEqual(self):
'''Checks serial number from two device not being equal.'''
command = 'getprop | grep ro.serial'
res1 = self.shell1.Execute(command)
res2 = self.shell2.Execute(command)

def getSerialFromShellOutput(output):
'''Get serial from getprop query'''
return output[const.STDOUT][0].strip().split(' ')[-1][1:-1]
serial1 = getSerialFromShellOutput(res1)
serial2 = getSerialFromShellOutput(res2)

logging.info('Serial number of device 1 shell output: %s', serial1)
logging.info('Serial number of device 2 shell output: %s', serial2)
asserts.assertNotEqual(serial1, serial2, 'serials from two devices should not be the same')
asserts.assertEqual(serial1, self.dut1.serial, 'serial got from device system property is different from allocated serial')
asserts.assertEqual(serial2, self.dut2.serial, 'serial got from device system property is different from allocated serial')