בדיקה במכשירים מרובים

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

ארכיטקטורה

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

איור 1. VTS העברת מספרי מכשיר.

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

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

תשתית הבדיקה (בדרך כלל מתזמן הבדיקות) מקצה למסגרת VTS את המכשירים הזמינים שעומדים בדרישות שצוינו בהגדרות של תוכנית הבדיקה. המכשירים שהוקצו שמורים לתוכנית הבדיקה גם אם מודול הבדיקה לא משתמש בהם. לאחר מכן, קובצי ה-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. בדיקה מבוססת-סוכן בצד המארח.

בתרחיש כזה:

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

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

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

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

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

בתרחיש כזה:

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

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

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

  • מכשיר 1 כולל ספק build ו-VtsDeviceInfoCollector target preparer.
  • מכשיר 2 כולל FilePusher preparer נוסף שמעביר למכשיר קבוצה של קבצים קשורים שמנוהלים על ידי המארח.
<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 בצד המארח

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

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')